From mobike-bounces@machshav.com Mon Dec 6 04:17:03 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15886 for ; Mon, 6 Dec 2004 04:17:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3F4C4FB27C; Mon, 6 Dec 2004 09:17:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B3795FB255; Mon, 6 Dec 2004 09:17:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 81997FB279; Mon, 6 Dec 2004 09:16:59 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id 722B5FB246 for ; Mon, 6 Dec 2004 09:16:58 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iB69Gvtc008083 for ; Mon, 6 Dec 2004 10:16:57 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB69GulD011074 for ; Mon, 6 Dec 2004 10:16:56 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Dec 2004 10:16:56 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C6B3@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: mobike@machshav.com Date: Mon, 6 Dec 2004 10:16:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Mobike] Zero Address Set 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 hi all, i thought about the functionality of the "zero address set". one important question is: what is this functionality good for? draft says: " seconds how long the peer assumes to be disconnected " pasi calls this functionality (in draft ): " temporarily forwarding the traffic of some SA to /dev/null " draft is more verbose on this issue: " One of the features which might be useful would be for the peer to announce the other end that it will now disconnect for some time, i.e. it will not be reachable at all. For instance, a laptop might go to suspend mode. In this case the peer could send address notification with zero new addresses, which means that it will not have any valid addresses anymore. The responder of that kind of notification would then acknowledge that, and could then temporarily disable all SAs. If any of the SAs gets any packets they are simply dropped. This could also include some kind of ACK spoofing to keep the TCP/IP sessions alive (or simply set the TCP/IP keepalives and timeouts large enough not to cause problems), or it could simply be left to the applications, i.e. allow TCP/IP sessions to notice the link is broken. The local policy could then decide how long the peer would allow other peers to be disconnected, i.e. whether this is only allowed for few minutes, or do they allow users to disconnect Friday evening and reconnect Monday morning (consuming resources during weekend too, but on the other hand not more than is normally used during week days, but we do not need lots of extra resources on the Monday morning to support all those people connecting back to network). " i see this issue from a different point of view. we have a dead peer detection to provide a mechanism to delete the ike sa (and ipsec sas) if the other does not respond anymore. if a laptop has establish an ike sa with a gateway, uses dead peer detection and goes into the suspend mode then (even after a short amount of time) the ike sa will be gone. the 'zero address set' functionality could possibly be seen as temporarily suspending the dead peer protection on a specific address (or path). is this totally bogus? ciao hannes _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 04:17:11 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15915 for ; Mon, 6 Dec 2004 04:17:11 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8035FFB289; Mon, 6 Dec 2004 09:17:12 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AB765FB279; Mon, 6 Dec 2004 09:17:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D6EFCFB26F; Mon, 6 Dec 2004 09:17:00 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id 43EEEFB255 for ; Mon, 6 Dec 2004 09:16:59 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iB69Gv8e016213; Mon, 6 Dec 2004 10:16:57 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB69GulD011072; Mon, 6 Dec 2004 10:16:56 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Dec 2004 10:16:56 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C6B2@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Tero Kivinen , jari.arkko@piuha.net Subject: RE: [Mobike] issue 4: how to signal support for MOBIKE Date: Mon, 6 Dec 2004 10:16:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi all, i went thought about the two most important options: notify and vendor id they both seem to provide the same capability. notify is used for errors but also for indicating sender capabilities. the same is true for the vendor id. as a text proposal i suggest to enhance the text offered by jari as follows: ----------------------- X. Indicating Support for MOBIKE A node needs to be able to guarantee that its address change messages are understood by the peer. Otherwise an address change may render the connection useless, and it is important that both sides realize this as early as possible. Ensuring that the messages are understood can in be arranged either by marking some IKEv2 payloads critical so that they are either processed or an error message is returned, by using Vendor ID payloads or via a Notify. The first solution approach is to use Vendor ID payloads during the initial IKEv2 exchange using a specific string denoting MOBIKE to signal the support of the MOBIKE protocol. This ensures that in all cases a MOBIKE capable node knows whether its peer supports MOBIKE or not. The second solution approach uses the Notify payload which is also used for NAT detection (via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP), . Both, a Vendor ID and a Notify payload, might be used to indicate the support of certain extensions. Note that the node could also attempt MOBIKE optimistically with the critical bit set to one when a movement has occurred. The drawback of this approach is, however, that the an unnecessary MOBIKE message round is introduced on the first movement. ----------------------- ciao hannes > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Dienstag, 30. November 2004 11:41 > To: jari.arkko@piuha.net > Cc: MOBIKE Mailing List > Subject: [Mobike] issue 4: how to signal support for MOBIKE > > Jari Arkko writes: > > So I would suggest that we use the Vendor ID approach. > > I would suggest NOTIFY approach. I.e we send notify saying > MOBIKE_SUPPORTED and thats it. Similar thatn what is done for > the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. > > In most cases we do not want to fail the negotiation even if > the other end does not support MOBIKE, we simply revert back > to redoing the authentication every time IP-addresses changes. > > If our final protocol is going to use notifies to send the > IP-addresses, then we can use those notifies to signal the > use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. > -- > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 04:17:20 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15940 for ; Mon, 6 Dec 2004 04:17:20 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 74428FB290; Mon, 6 Dec 2004 09:17:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CB911FB26F; Mon, 6 Dec 2004 09:17:10 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A2D1BFB27A; Mon, 6 Dec 2004 09:17:02 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id 460D3FB266 for ; Mon, 6 Dec 2004 09:16:59 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iB69Gv8e016214; Mon, 6 Dec 2004 10:16:57 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB69GulD011070; Mon, 6 Dec 2004 10:16:56 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Dec 2004 10:16:56 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C6B1@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: jari.arkko@piuha.net, MOBIKE Mailing List Subject: RE: [Mobike] issue 10: changing addresses or paths? Date: Mon, 6 Dec 2004 10:16:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi jari, i agree with you that we need to test paths rather than addresses. i have read your multi6 draft which also derives this conclusion. my personal experience with path-coupled signaling in the nsis environment also supports this observation. ciao hannes > Our earlier resolution of issue 17 (if both parties have > several addresses, do we assume that all pairs have > connectivity between them?) was that we should NOT assume > full connectivity in these cases. > > I believe the above resolution implies that upon a problem, > we may have to switch paths, not just an address. I also > explained the issue in Washington in my presentation. > > So I think its pretty clear that the answer to this question > is that we need to be able to change paths. > Suggested text below: > > Change design draft from > > 6. Changing addresses or changing the paths (issue #10, #14) > > The question here is, if it is enough for the MOBIKE to detect the > dead-address, or do it need to detect also dead-paths. > Dead-address > detection means that we only detect that we cannot get packets > through to that remote address by using the local > IP-address given by > the local IP-stack (i.e. local address selected normally by the > routing information). Dead-path detection means that we > need to try > all possible local interfaces/IP-addresses for each > remote addresses, > i.e. find all possible paths between the hosts and try them all to > see which of them work (or at least find one working path). > > Doing the dead-address detection is simpler, and there is > less probe > packets to be sent, thus it does not cause that much stress to the > network. It also is enough for the scenarios where the connection > problems are local (i.e. interfaces going down, WLAN access > disappearing etc). It does not help if some router somewhere along > the path breaks down, in which case rerouting the packets along > another path might get around that broken router. The question is, > whether rerouting around that problem inside the core network is a > problem that MOBIKE needs to solve. > > to > > 6. Changing addresses or changing the paths (issue #10, #14) > > The question here is, if it is enough for the MOBIKE to detect the > dead-address, or do it need to detect also dead-paths. > Dead-address > detection means that we only detect that we cannot get packets > through to that remote address by using the local > IP-address given by > the local IP-stack (i.e. local address selected normally by the > routing information). Dead-path detection means that we > need to try > all possible local interfaces/IP-addresses for each > remote addresses, > i.e. find all possible paths between the hosts and try them all to > see which of them work (or at least find one working path). > > While performing just an address change is simpler, the existence > of locally operational addresses are not, however, a guarantee > that communications can be established with the peer. A > failure in the routing infrastructure can prevent the sent packets > from reaching their destination. Or a failure of an interface on > one side can be related to the failure of an interface on the > other side, making it necessary to change more than one address > at a time. > > --Jari > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 06:03:14 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23436 for ; Mon, 6 Dec 2004 06:03:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CE994FB279; Mon, 6 Dec 2004 11:03:14 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EF3E3FB255; Mon, 6 Dec 2004 11:03:13 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B4F83FB266; Mon, 6 Dec 2004 11:03:11 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id C99FCFB246 for ; Mon, 6 Dec 2004 11:03:10 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iB6B398e019157 for ; Mon, 6 Dec 2004 12:03:09 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB6B37lE021563 for ; Mon, 6 Dec 2004 12:03:09 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Dec 2004 12:03:07 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C6FD@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: MOBIKE Mailing List Date: Mon, 6 Dec 2004 12:02:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Mobike] issue 3: nat traversal 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 hi all, let us try to close the nat traversal issue (issue 3) from http://www.vpnc.org/ietf-mobike/issue3.txt here is what we currently have: - charter says that we should not modify the ikev2 nat traversal mechanism. none of the proposal tries to todo that. - draft addresses nat traversal. - draft and additionally add a mechanism to indicate nat traversal prevention. a number of people pointed to the need to support nat traversal. hence, i think that we could have support for - nat traversal and - a nat traversal prevention (if you think you don't need it) without conflicting with the charter. to address the scenarios there also needs to support for an end host moving from not-behind a nat to behind a nat. ciao hannes _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 07:03:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28769 for ; Mon, 6 Dec 2004 07:03:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 19F38FB279; Mon, 6 Dec 2004 12:03:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A2FCBFB246; Mon, 6 Dec 2004 12:03:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B6C5FFB255; Mon, 6 Dec 2004 12:03:13 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id A9156FB240 for ; Mon, 6 Dec 2004 12:03:12 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iB6C3B8e011432 for ; Mon, 6 Dec 2004 13:03:11 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB6C3BlD024644 for ; Mon, 6 Dec 2004 13:03:11 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Dec 2004 13:03:11 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C72B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: mobike@machshav.com Date: Mon, 6 Dec 2004 13:02:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Mobike] When to do Return Routability Checks 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 hi all, i would like to close the 'When to do Return Routability Checks' issue (which can be found at: http://www.vpnc.org/ietf-mobike/issue6.txt) please take a look at previous text in the design document on this issue: " 3.2 When to do Return Routability Checks One of the decisions that needs to be done, when to do return routability checks. The simple approach is to do it always. ^^^^^^^^ [hannes] 'always' is not very precise. Another option is to do it every time new IP-address is taken in to use. [hannes] jari introduces useful terminology relevant for this sentence in . we might want to use some of it in mobike. The basic format of the return routability check could be similar than dead-peer-detection, but the problem is that if that fails then the IKEv2 specification requires the IKE SA to be deleted. Because of this we might need to do some kind of other exchange. If the other end is SGW with limited set of fixed IP-addresses, then the SGW can get certificate having all the IP-addresses in the certificate. If the certificate includes all the IP-addresses, it is no point to do weaker return routability check, the data in the certificate is already properly authenticated after the IKE SA is created, so the peer might simply use that and ignore return routability checks. Another option is to use draft-dupont-mipv6-3bombing [I.D.dupont-mipv6-3bombing] approach: do it only if you had to send the update from some other address than indicated preferred address. Final option would simply not to do return routability checks at all. If we use indirect change notifications then we only move to the new IP address after successfull dead-peer-detection on the new address, which is already return routability check. In the direct change notifications the authenticated peer have given out authenticated IP-address, thus we could simply trust the other end. There is no way external attacker can cause any attacks, but we are not protected by the internal attacker, i.e. the authenticatede peer forwarding its traffic to the new address. On the other hand we do know the identity of the peer in that case. " [hannes] the relationship between authorization and the aspect of timing (WHEN to send return routability checks - if at all) needs to be separated. discussions during the ietf meeting (see issue tracker web page) concluded that it is a policy issue when to perform the return routability checks. this conclusion seems to be fine with me. i will try to produce a new text proposal. ciao hannes _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 11:42:23 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28770 for ; Mon, 6 Dec 2004 11:42:22 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 474E9FB27A; Mon, 6 Dec 2004 16:42:22 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B3935FB266; Mon, 6 Dec 2004 16:42:20 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2B4E1FB26F; Mon, 6 Dec 2004 16:42:19 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 07D65FB246 for ; Mon, 6 Dec 2004 16:42:18 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iB6GgGeh023909 for ; Mon, 6 Dec 2004 17:42:16 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB6GgFmf024152 for ; Mon, 6 Dec 2004 17:42:15 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Dec 2004 17:42:15 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C7F9@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: MOBIKE Mailing List Date: Mon, 6 Dec 2004 17:42:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Mobike] issue 1: direct or indirect indicators 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 hi all, i would like to discuss issue #1: http://www.vpnc.org/ietf-mobike/issue1.txt the current text on this issue says: -------------------- [Comment from secretary: TEMP-draft-kivinen-mobike-protocol-00.txt has both direct indications (peer explicitly requests change) and indirect based on address lists (when current address seems to have stopped working, try others). draft-dupont-ikev2-addrmgmt-04.txt also has both.] -------------------- here are some basic observations: you need to have more than one address anyway to switch to another one. it depends which entity detects the problem first. if the initiator detects that there is a problem (e.g., on the local link) then it can switch to a new address. sending an ikev2 notification message from the new address to the responder is fine and might cause an address update of the ipsec sa with or without return routability check (authorization decision). if the responder detects that there was a problem (e.g., on its local link) then it might want to send the initiator a notification that it should use a different address. if the initiator uses a dead peer detection mechanism he will also discover the problem (after some time). as a summary: i am not quite about the possible conclusion of this issue since the issue description is too fuzzy. a separate question but also of interest: - should a peer send an address list in one message or individual messages (which only contain one address/message)? (the address list does not work in a nat environment.) answer: both seems to be desired. - should the individual address be part of the protected payload or taken from info of the header? answer: both is desired (depending on whether nat traversal is desired or not) - should the address list be idempotent or not? answer: this is still an open issue. always resending the full list (idempotent operation) requires more bandwidth but avoid synchonization issue which needs to be addressed. , for example, seems to offer an approach which defines add/delete operations. ciao hannes i do not necessarily see the relationship between an address list and the term 'direct/indirect' indications. in any case a peer might want to be able to send a message to the other peer if it detects that an address does not work anymore (based on some triggers provided by other protocols. see ) i don't see the big difference. there is little doubt that a mobike protocol needs some mechanisms that allows one peer to inform the other peer about address changes. (direct indications) i think think that the term indirect indication has anything todo with address lists. for me an indirect indication is a hint provided by other protocols or mechanisms to switch from one address to another. draft talks about various hints provided by other protocols which may lead to the conclusion to switch from one address to another. address lists are a separate issue and a performance aspect. with some respect address lists (as traffic selectors are already supported in ikev2) which allow multiple ipsec sas to be established with one child-sa exchange. if ipsec sas should be modified without using a new child sa exchange then they might use address lists again or one message exchange per traffic selector. ciao hannes _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 11:57:03 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29628 for ; Mon, 6 Dec 2004 11:57:02 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 33CFCFB27C; Mon, 6 Dec 2004 16:57:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B859AFB266; Mon, 6 Dec 2004 16:57:00 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1B531FB26F; Mon, 6 Dec 2004 16:57:00 +0000 (UTC) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by machshav.com (Postfix) with ESMTP id 82E6DFB246 for ; Mon, 6 Dec 2004 16:56:59 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iB6Guwdt012707; Mon, 6 Dec 2004 09:56:58 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iB6GuvJd020037; Mon, 6 Dec 2004 11:56:57 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iB6Guvn2008658; Mon, 6 Dec 2004 11:56:57 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iB6GuuEj008657; Mon, 6 Dec 2004 11:56:56 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Mobike] Zero Address Set From: Bill Sommerfeld To: Tschofenig Hannes In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0542C6B3@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F0542C6B3@mchp905a.mch.sbs.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1102352215.7940.69.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 06 Dec 2004 11:56:56 -0500 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 Mon, 2004-12-06 at 04:16, Tschofenig Hannes wrote: > i thought about the functionality of the "zero address set". one important > question is: what is this functionality good for? temporary tunnel suspension when the endpoint knows it will be unreachable for a while. > i see this issue from a different point of view. > we have a dead peer detection to provide a mechanism to delete the ike sa > (and ipsec sas) if the other does not respond anymore. well, let's distinguish two cases: 1) we haven't heard from the peer in a while. 2) the peer has crashed and forgot about the connection For some applications, tearing down state because of (1) may rightly viewed as a bug, not a feature -- but you may want fast recovery from (2) without tearing down connections merely because of inactivity. > if a laptop has establish an ike sa with a gateway, uses dead peer detection > and goes into the suspend mode then (even after a short amount of time) the > ike sa will be gone. > > the 'zero address set' functionality could possibly be seen as temporarily > suspending the dead peer protection on a specific address (or path). Sorta. - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 12:07:07 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00227 for ; Mon, 6 Dec 2004 12:07:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C6E90FB27A; Mon, 6 Dec 2004 17:07:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ED599FB26F; Mon, 6 Dec 2004 17:07:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F2E9EFB277; Mon, 6 Dec 2004 17:07:03 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 058E9FB266 for ; Mon, 6 Dec 2004 17:07:03 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iB6H72eh011990; Mon, 6 Dec 2004 18:07:02 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB6H71mf011805; Mon, 6 Dec 2004 18:07:02 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 6 Dec 2004 18:07:01 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C803@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Bill Sommerfeld Subject: RE: [Mobike] Zero Address Set Date: Mon, 6 Dec 2004 18:06:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi bill, thanks for your quick response. the term 'zero address set' is quite confusing but i tend to agree with the discussions on the mailing list which came to the conclusion that this feature should not incorporated into a mobike protocol. the desire to check connectivity (via some sort of message exchange) periodically has the unpleasant(?) effect that the ike/ipsec sa will be deleted if one of the peers is not reachable anymore. ciao hannes > On Mon, 2004-12-06 at 04:16, Tschofenig Hannes wrote: > > > i thought about the functionality of the "zero address set". one > > important question is: what is this functionality good for? > > temporary tunnel suspension when the endpoint knows it will > be unreachable for a while. > > > i see this issue from a different point of view. > > we have a dead peer detection to provide a mechanism to > delete the ike > > sa (and ipsec sas) if the other does not respond anymore. > > well, let's distinguish two cases: > 1) we haven't heard from the peer in a while. > 2) the peer has crashed and forgot about the connection > > For some applications, tearing down state because of (1) may > rightly viewed as a bug, not a feature -- but you may want > fast recovery from (2) without tearing down connections > merely because of inactivity. > > > if a laptop has establish an ike sa with a gateway, uses dead peer > > detection and goes into the suspend mode then (even after a short > > amount of time) the ike sa will be gone. > > > > the 'zero address set' functionality could possibly be seen as > > temporarily suspending the dead peer protection on a > specific address (or path). > > Sorta. > > > > - Bill > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 13:15:36 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07152 for ; Mon, 6 Dec 2004 13:15:35 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 1CF17FB27A; Mon, 6 Dec 2004 18:15:35 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B9E97FB266; Mon, 6 Dec 2004 18:15:32 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 03D3FFB26F; Mon, 6 Dec 2004 18:15:31 +0000 (UTC) Received: from smtp813.mail.sc5.yahoo.com (smtp813.mail.sc5.yahoo.com [66.163.170.83]) by machshav.com (Postfix) with SMTP id 4608BFB246 for ; Mon, 6 Dec 2004 18:15:30 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 6 Dec 2004 18:05:26 -0000 Message-ID: <007401c4dbbe$29652460$861167c0@adithya> From: "Mohan Parthasarathy" To: "Tschofenig Hannes" , "MOBIKE Mailing List" References: <2A8DB02E3018D411901B009027FD3A3F0542C6FD@mchp905a.mch.sbs.de> Subject: Re: [Mobike] issue 3: nat traversal Date: Mon, 6 Dec 2004 10:05:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.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 Hannes, > let us try to close the nat traversal issue (issue 3) from > http://www.vpnc.org/ietf-mobike/issue3.txt > > here is what we currently have: > > - charter says that we should not modify the ikev2 nat traversal mechanism. > none of the proposal tries to todo that. > - draft addresses nat traversal. > - draft and > additionally add a mechanism to > indicate nat traversal prevention. > > a number of people pointed to the need to support nat traversal. > The issue is a bit confusing to me. I agree that we don't want to modify the IKEv2 NAT traversal as specified in the IKEv2 draft. But do we want MOBIKE to work when moving behind NATs ? I am not sure which question is being asked here. Could you clarify ? I see this as two separate things. If we want to track this as two separate issues, i am fine with that. -mohan > hence, i think that we could have support for > - nat traversal and > - a nat traversal prevention (if you think you don't need it) > without conflicting with the charter. > > to address the scenarios there also needs to support for an end host moving > from not-behind a nat to behind a nat. > > ciao > hannes > > > _______________________________________________ > 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 Dec 6 13:17:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07407 for ; Mon, 6 Dec 2004 13:17:18 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7E285FB279; Mon, 6 Dec 2004 18:17:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F0B6EFB266; Mon, 6 Dec 2004 18:17:19 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8A44DFB26F; Mon, 6 Dec 2004 18:17:18 +0000 (UTC) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by machshav.com (Postfix) with ESMTP id A22A6FB246 for ; Mon, 6 Dec 2004 18:17:17 +0000 (UTC) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iB6IGiW29136; Mon, 6 Dec 2004 13:16:45 -0500 (EST) Received: from [47.16.67.20] (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 WKL3NH4S; Mon, 6 Dec 2004 13:16:44 -0500 Message-ID: <41B4A20A.8060109@nortelnetworks.com> Date: Mon, 06 Dec 2004 13:16:43 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes Subject: Re: [Mobike] When to do Return Routability Checks References: <2A8DB02E3018D411901B009027FD3A3F0542C72B@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0542C72B@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.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 Tschofenig Hannes wrote: > hi all, > > i would like to close the 'When to do Return Routability Checks' issue > (which can be found at: > http://www.vpnc.org/ietf-mobike/issue6.txt) > > please take a look at previous text in the design document on this issue: > > " > 3.2 When to do Return Routability Checks > > One of the decisions that needs to be done, when to do return > routability checks. The simple approach is to do it always. > ^^^^^^^^ > [hannes] 'always' is not very precise. > > Another > option is to do it every time new IP-address is taken in to use. > > [hannes] jari introduces useful terminology relevant for this sentence in > . we might want to use > some > of it in mobike. > > The > basic format of the return routability check could be similar than > dead-peer-detection, but the problem is that if that fails then the > IKEv2 specification requires the IKE SA to be deleted. Because of > this we might need to do some kind of other exchange. > > If the other end is SGW with limited set of fixed IP-addresses, then > the SGW can get certificate having all the IP-addresses in the > certificate. If the certificate includes all the IP-addresses, it is > no point to do weaker return routability check, the data in the > certificate is already properly authenticated after the IKE SA is > created, so the peer might simply use that and ignore return > routability checks. > > Another option is to use draft-dupont-mipv6-3bombing > [I.D.dupont-mipv6-3bombing] approach: do it only if you had to send > the update from some other address than indicated preferred address. > > Final option would simply not to do return routability checks at all. > If we use indirect change notifications then we only move to the new > IP address after successfull dead-peer-detection on the new address, > which is already return routability check. In the direct change > notifications the authenticated peer have given out authenticated > IP-address, thus we could simply trust the other end. There is no way > external attacker can cause any attacks, but we are not protected by > the internal attacker, i.e. the authenticatede peer forwarding its > traffic to the new address. On the other hand we do know the identity > of the peer in that case. > " > > [hannes] the relationship between authorization and the aspect of timing > (WHEN to send return routability checks - if at all) needs to be > separated. > > discussions during the ietf meeting (see issue tracker web page) > concluded > that it is a policy issue when to perform the return routability checks. > this conclusion seems to be fine with me. i will try to produce a new > text > proposal. > Thanks. There was a discussion on this earlier this year and some of us came to the same conclusion, i.e., it is a local matter (but there was a fair amount of disagreement on this :-)). I summarized some guidelines in this message from the archive: http://www.machshav.com/pipermail/mobike/2004-May/000176.html best regards, Lakshminath > ciao > hannes > > _______________________________________________ > 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 Dec 6 13:23:07 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07736 for ; Mon, 6 Dec 2004 13:23:05 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DD243FB279; Mon, 6 Dec 2004 18:23:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 39D2AFB266; Mon, 6 Dec 2004 18:23:07 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3F6FAFB26F; Mon, 6 Dec 2004 18:23:06 +0000 (UTC) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by machshav.com (Postfix) with ESMTP id BDE0CFB246 for ; Mon, 6 Dec 2004 18:23:05 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iB6IN4dt027048; Mon, 6 Dec 2004 11:23:05 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iB6IN4Jd025371; Mon, 6 Dec 2004 13:23:04 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iB6IN4HN009173; Mon, 6 Dec 2004 13:23:04 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iB6IN4S1009172; Mon, 6 Dec 2004 13:23:04 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: [Mobike] Zero Address Set From: Bill Sommerfeld To: Tschofenig Hannes In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0542C803@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F0542C803@mchp905a.mch.sbs.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1102357383.7940.238.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 06 Dec 2004 13:23:04 -0500 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 Mon, 2004-12-06 at 12:06, Tschofenig Hannes wrote: > thanks for your quick response. the term 'zero address set' is quite > confusing but i tend to agree with the discussions on the mailing list which > came to the conclusion that this feature should not incorporated into a > mobike protocol. whereas I think it makes obvious sense and would like to see it included... - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 13:23:56 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07779 for ; Mon, 6 Dec 2004 13:23:56 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3699DFB27C; Mon, 6 Dec 2004 18:23:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 77790FB266; Mon, 6 Dec 2004 18:23:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BB09DFB26F; Mon, 6 Dec 2004 18:23:53 +0000 (UTC) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by machshav.com (Postfix) with ESMTP id CD8DAFB246 for ; Mon, 6 Dec 2004 18:23:52 +0000 (UTC) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iB6INQf05822; Mon, 6 Dec 2004 13:23:27 -0500 (EST) Received: from [47.16.67.20] (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 WKL3NHX2; Mon, 6 Dec 2004 13:23:26 -0500 Message-ID: <41B4A39C.9060300@nortelnetworks.com> Date: Mon, 06 Dec 2004 13:23:24 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE References: <2A8DB02E3018D411901B009027FD3A3F0542C6B2@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0542C6B2@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , jari.arkko@piuha.net, 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 This sounds good. I was initially leaning toward Notify only, but there is no harm in allowing Vendor ID. I wouldn't necessarily suggest the use of "critical bit" here. Clearly, an implementation may choose to use that feature, but there is no need to make that suggestion in each context. Thanks. regards, Lakshminath Tschofenig Hannes wrote: > hi all, > > i went thought about the two most important options: notify and vendor id > > they both seem to provide the same capability. notify is used for > errors but > also for indicating sender capabilities. the same is true for the > vendor id. > > > as a text proposal i suggest to enhance the text offered by jari as > follows: > > ----------------------- > > X. Indicating Support for MOBIKE > > A node needs to be able to guarantee that its address change messages are > understood by the peer. Otherwise an address change may render the > connection useless, and it is important that both sides realize this as > early as possible. > > Ensuring that the messages are understood can in be arranged either by > marking some IKEv2 payloads critical so that they are either processed > or an > error message is returned, by using Vendor ID payloads or via a Notify. > > The first solution approach is to use Vendor ID payloads during the > initial > IKEv2 exchange using a specific string denoting MOBIKE to signal the > support > of the MOBIKE protocol. This ensures that in all cases a MOBIKE > capable node > knows whether its peer supports MOBIKE or not. > > The second solution approach uses the Notify payload which is also > used for > NAT detection (via NAT_DETECTION_SOURCE_IP and > NAT_DETECTION_DESTINATION_IP), . > > Both, a Vendor ID and a Notify payload, might be used to indicate the > support of certain extensions. > > Note that the node could also attempt MOBIKE optimistically with the > critical bit set to one when a movement has occurred. The drawback of > this > approach is, however, that the an unnecessary MOBIKE message round is > introduced on the first movement. > > ----------------------- > > ciao > hannes > > > > -----Original Message----- > > From: Tero Kivinen [mailto:kivinen@iki.fi] > > Sent: Dienstag, 30. November 2004 11:41 > > To: jari.arkko@piuha.net > > Cc: MOBIKE Mailing List > > Subject: [Mobike] issue 4: how to signal support for MOBIKE > > > > Jari Arkko writes: > > > So I would suggest that we use the Vendor ID approach. > > > > I would suggest NOTIFY approach. I.e we send notify saying > > MOBIKE_SUPPORTED and thats it. Similar thatn what is done for > > the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. > > > > In most cases we do not want to fail the negotiation even if > > the other end does not support MOBIKE, we simply revert back > > to redoing the authentication every time IP-addresses changes. > > > > If our final protocol is going to use notifies to send the > > IP-addresses, then we can use those notifies to signal the > > use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. > > -- > > 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 > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 13:32:41 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08865 for ; Mon, 6 Dec 2004 13:32:41 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9FDFCFB277; Mon, 6 Dec 2004 18:32:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D1F8BFB266; Mon, 6 Dec 2004 18:32:41 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 989F4FB26F; Mon, 6 Dec 2004 18:32:39 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 88852FB246 for ; Mon, 6 Dec 2004 18:32:38 +0000 (UTC) Message-ID: <016801c4dbc2$17663890$5d6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Dondeti, Lakshminath" , "Tschofenig Hannes" References: <2A8DB02E3018D411901B009027FD3A3F0542C6B2@mchp905a.mch.sbs.de> <41B4A39C.9060300@nortelnetworks.com> Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE Date: Mon, 6 Dec 2004 10:33:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: jari.arkko@piuha.net, MOBIKE Mailing List , 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 I think we ought to choose either Vendor ID or Notify. While I support Notify (since this is a standardized, and not a vendor specific, option), I would rather go with Vendor ID if that's what a majority of the WG wants rather than have both. jak ----- Original Message ----- From: "Dondeti, Lakshminath" To: "Tschofenig Hannes" Cc: "MOBIKE Mailing List" ; ; "Tero Kivinen" Sent: Monday, December 06, 2004 10:23 AM Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE > This sounds good. I was initially leaning toward Notify only, but there > is no harm in allowing Vendor ID. I wouldn't necessarily suggest the > use of "critical bit" here. Clearly, an implementation may choose to > use that feature, but there is no need to make that suggestion in each > context. Thanks. > > regards, > Lakshminath > > Tschofenig Hannes wrote: > > > hi all, > > > > i went thought about the two most important options: notify and vendor id > > > > they both seem to provide the same capability. notify is used for > > errors but > > also for indicating sender capabilities. the same is true for the > > vendor id. > > > > > > as a text proposal i suggest to enhance the text offered by jari as > > follows: > > > > ----------------------- > > > > X. Indicating Support for MOBIKE > > > > A node needs to be able to guarantee that its address change messages are > > understood by the peer. Otherwise an address change may render the > > connection useless, and it is important that both sides realize this as > > early as possible. > > > > Ensuring that the messages are understood can in be arranged either by > > marking some IKEv2 payloads critical so that they are either processed > > or an > > error message is returned, by using Vendor ID payloads or via a Notify. > > > > The first solution approach is to use Vendor ID payloads during the > > initial > > IKEv2 exchange using a specific string denoting MOBIKE to signal the > > support > > of the MOBIKE protocol. This ensures that in all cases a MOBIKE > > capable node > > knows whether its peer supports MOBIKE or not. > > > > The second solution approach uses the Notify payload which is also > > used for > > NAT detection (via NAT_DETECTION_SOURCE_IP and > > NAT_DETECTION_DESTINATION_IP), . > > > > Both, a Vendor ID and a Notify payload, might be used to indicate the > > support of certain extensions. > > > > Note that the node could also attempt MOBIKE optimistically with the > > critical bit set to one when a movement has occurred. The drawback of > > this > > approach is, however, that the an unnecessary MOBIKE message round is > > introduced on the first movement. > > > > ----------------------- > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Tero Kivinen [mailto:kivinen@iki.fi] > > > Sent: Dienstag, 30. November 2004 11:41 > > > To: jari.arkko@piuha.net > > > Cc: MOBIKE Mailing List > > > Subject: [Mobike] issue 4: how to signal support for MOBIKE > > > > > > Jari Arkko writes: > > > > So I would suggest that we use the Vendor ID approach. > > > > > > I would suggest NOTIFY approach. I.e we send notify saying > > > MOBIKE_SUPPORTED and thats it. Similar thatn what is done for > > > the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. > > > > > > In most cases we do not want to fail the negotiation even if > > > the other end does not support MOBIKE, we simply revert back > > > to redoing the authentication every time IP-addresses changes. > > > > > > If our final protocol is going to use notifies to send the > > > IP-addresses, then we can use those notifies to signal the > > > use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. > > > -- > > > 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 > > > _______________________________________________ > 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 Dec 6 13:42:54 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10099 for ; Mon, 6 Dec 2004 13:42:54 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 677A5FB27C; Mon, 6 Dec 2004 18:42:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7BDF8FB266; Mon, 6 Dec 2004 18:42:49 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3EDD4FB26F; Mon, 6 Dec 2004 18:42:48 +0000 (UTC) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by machshav.com (Postfix) with ESMTP id 1156EFB246 for ; Mon, 6 Dec 2004 18:42:47 +0000 (UTC) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iB6IgdW00783; Mon, 6 Dec 2004 13:42:39 -0500 (EST) Received: from [47.16.67.20] (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 WKL3NH0P; Mon, 6 Dec 2004 13:42:39 -0500 Message-ID: <41B4A81D.9030806@nortelnetworks.com> Date: Mon, 06 Dec 2004 13:42:37 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes , jari.arkko@piuha.net Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE (correction) References: <41B4A39C.9060300@nortelnetworks.com> In-Reply-To: <41B4A39C.9060300@nortelnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , 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 Just wanted to note that a clarification might be in order around the "critical bit" usage. That would only be applicable if a new payload type were to be defined for MOBIKE signaling, right? So, are 3 options on the table: 1) new payload type that might be marked critical 2) vendor ID, and 3) notify payloads? I think 2 options: vendor ID and notify payloads, would be sufficient for MOBIKE signaling; there is no need for a new payload type for this! regards, Lakshminath Dondeti, Lakshminath [BL60:1A14:EXCH] wrote: > This sounds good. I was initially leaning toward Notify only, but there > is no harm in allowing Vendor ID. I wouldn't necessarily suggest the > use of "critical bit" here. Clearly, an implementation may choose to > use that feature, but there is no need to make that suggestion in each > context. Thanks. > > regards, > Lakshminath > > Tschofenig Hannes wrote: > > > hi all, > > > > i went thought about the two most important options: notify and > vendor id > > > > they both seem to provide the same capability. notify is used for > > errors but > > also for indicating sender capabilities. the same is true for the > > vendor id. > > > > > > as a text proposal i suggest to enhance the text offered by jari as > > follows: > > > > ----------------------- > > > > X. Indicating Support for MOBIKE > > > > A node needs to be able to guarantee that its address change > messages are > > understood by the peer. Otherwise an address change may render the > > connection useless, and it is important that both sides realize this as > > early as possible. > > > > Ensuring that the messages are understood can in be arranged either by > > marking some IKEv2 payloads critical so that they are either processed > > or an > > error message is returned, by using Vendor ID payloads or via a Notify. > > > > The first solution approach is to use Vendor ID payloads during the > > initial > > IKEv2 exchange using a specific string denoting MOBIKE to signal the > > support > > of the MOBIKE protocol. This ensures that in all cases a MOBIKE > > capable node > > knows whether its peer supports MOBIKE or not. > > > > The second solution approach uses the Notify payload which is also > > used for > > NAT detection (via NAT_DETECTION_SOURCE_IP and > > NAT_DETECTION_DESTINATION_IP), . > > > > Both, a Vendor ID and a Notify payload, might be used to indicate the > > support of certain extensions. > > > > Note that the node could also attempt MOBIKE optimistically with the > > critical bit set to one when a movement has occurred. The drawback of > > this > > approach is, however, that the an unnecessary MOBIKE message round is > > introduced on the first movement. > > > > ----------------------- > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Tero Kivinen [mailto:kivinen@iki.fi] > > > Sent: Dienstag, 30. November 2004 11:41 > > > To: jari.arkko@piuha.net > > > Cc: MOBIKE Mailing List > > > Subject: [Mobike] issue 4: how to signal support for MOBIKE > > > > > > Jari Arkko writes: > > > > So I would suggest that we use the Vendor ID approach. > > > > > > I would suggest NOTIFY approach. I.e we send notify saying > > > MOBIKE_SUPPORTED and thats it. Similar thatn what is done for > > > the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. > > > > > > In most cases we do not want to fail the negotiation even if > > > the other end does not support MOBIKE, we simply revert back > > > to redoing the authentication every time IP-addresses changes. > > > > > > If our final protocol is going to use notifies to send the > > > IP-addresses, then we can use those notifies to signal the > > > use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. > > > -- > > > 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 > > > _______________________________________________ > 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 Dec 6 13:50:37 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10968 for ; Mon, 6 Dec 2004 13:50:36 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 46957FB27C; Mon, 6 Dec 2004 18:50:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 872A4FB266; Mon, 6 Dec 2004 18:50:34 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 823B9FB26F; Mon, 6 Dec 2004 18:50:32 +0000 (UTC) Received: from smtp808.mail.sc5.yahoo.com (smtp808.mail.sc5.yahoo.com [66.163.168.187]) by machshav.com (Postfix) with SMTP id 7E06AFB246 for ; Mon, 6 Dec 2004 18:50:31 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 6 Dec 2004 18:50:31 -0000 Message-ID: <00d201c4dbc4$75590de0$861167c0@adithya> From: "Mohan Parthasarathy" To: "James Kempf" , "Dondeti, Lakshminath" , "Tschofenig Hannes" References: <2A8DB02E3018D411901B009027FD3A3F0542C6B2@mchp905a.mch.sbs.de><41B4A39C.9060300@nortelnetworks.com> <016801c4dbc2$17663890$5d6015ac@dcml.docomolabsusa.com> Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE Date: Mon, 6 Dec 2004 10:50:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: MOBIKE Mailing List , jari.arkko@piuha.net, 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 > I think we ought to choose either Vendor ID or Notify. While I support > Notify (since this is a standardized, and not a vendor specific, option), I Yes. Also, as this is in sync with other features of IKEv2, it makes sense to use NOTIFY. -mohan > would rather go with Vendor ID if that's what a majority of the WG wants > rather than have both. > > jak > > ----- Original Message ----- > From: "Dondeti, Lakshminath" > To: "Tschofenig Hannes" > Cc: "MOBIKE Mailing List" ; ; > "Tero Kivinen" > Sent: Monday, December 06, 2004 10:23 AM > Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE > > > > This sounds good. I was initially leaning toward Notify only, but there > > is no harm in allowing Vendor ID. I wouldn't necessarily suggest the > > use of "critical bit" here. Clearly, an implementation may choose to > > use that feature, but there is no need to make that suggestion in each > > context. Thanks. > > > > regards, > > Lakshminath > > > > Tschofenig Hannes wrote: > > > > > hi all, > > > > > > i went thought about the two most important options: notify and vendor > id > > > > > > they both seem to provide the same capability. notify is used for > > > errors but > > > also for indicating sender capabilities. the same is true for the > > > vendor id. > > > > > > > > > as a text proposal i suggest to enhance the text offered by jari as > > > follows: > > > > > > ----------------------- > > > > > > X. Indicating Support for MOBIKE > > > > > > A node needs to be able to guarantee that its address change messages > are > > > understood by the peer. Otherwise an address change may render the > > > connection useless, and it is important that both sides realize this as > > > early as possible. > > > > > > Ensuring that the messages are understood can in be arranged either by > > > marking some IKEv2 payloads critical so that they are either processed > > > or an > > > error message is returned, by using Vendor ID payloads or via a Notify. > > > > > > The first solution approach is to use Vendor ID payloads during the > > > initial > > > IKEv2 exchange using a specific string denoting MOBIKE to signal the > > > support > > > of the MOBIKE protocol. This ensures that in all cases a MOBIKE > > > capable node > > > knows whether its peer supports MOBIKE or not. > > > > > > The second solution approach uses the Notify payload which is also > > > used for > > > NAT detection (via NAT_DETECTION_SOURCE_IP and > > > NAT_DETECTION_DESTINATION_IP), . > > > > > > Both, a Vendor ID and a Notify payload, might be used to indicate the > > > support of certain extensions. > > > > > > Note that the node could also attempt MOBIKE optimistically with the > > > critical bit set to one when a movement has occurred. The drawback of > > > this > > > approach is, however, that the an unnecessary MOBIKE message round is > > > introduced on the first movement. > > > > > > ----------------------- > > > > > > ciao > > > hannes > > > > > > > > > > -----Original Message----- > > > > From: Tero Kivinen [mailto:kivinen@iki.fi] > > > > Sent: Dienstag, 30. November 2004 11:41 > > > > To: jari.arkko@piuha.net > > > > Cc: MOBIKE Mailing List > > > > Subject: [Mobike] issue 4: how to signal support for MOBIKE > > > > > > > > Jari Arkko writes: > > > > > So I would suggest that we use the Vendor ID approach. > > > > > > > > I would suggest NOTIFY approach. I.e we send notify saying > > > > MOBIKE_SUPPORTED and thats it. Similar thatn what is done for > > > > the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. > > > > > > > > In most cases we do not want to fail the negotiation even if > > > > the other end does not support MOBIKE, we simply revert back > > > > to redoing the authentication every time IP-addresses changes. > > > > > > > > If our final protocol is going to use notifies to send the > > > > IP-addresses, then we can use those notifies to signal the > > > > use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. > > > > -- > > > > 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 > > > > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 14:11:13 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13136 for ; Mon, 6 Dec 2004 14:11:12 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5DF6DFB27A; Mon, 6 Dec 2004 19:11:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8C873FB277; Mon, 6 Dec 2004 19:11:12 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 72F20FB279; Mon, 6 Dec 2004 19:11:10 +0000 (UTC) Received: from smtp813.mail.sc5.yahoo.com (smtp813.mail.sc5.yahoo.com [66.163.170.83]) by machshav.com (Postfix) with SMTP id 71FCFFB266 for ; Mon, 6 Dec 2004 19:11:09 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 6 Dec 2004 18:48:39 -0000 Message-ID: <00c801c4dbc4$32a65110$861167c0@adithya> From: "Mohan Parthasarathy" To: "Bill Sommerfeld" , "Tschofenig Hannes" References: <2A8DB02E3018D411901B009027FD3A3F0542C6B3@mchp905a.mch.sbs.de> <1102352215.7940.69.camel@thunk> Subject: Re: [Mobike] Zero Address Set Date: Mon, 6 Dec 2004 10:48:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.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 Bill, > > i thought about the functionality of the "zero address set". one important > > question is: what is this functionality good for? > > temporary tunnel suspension when the endpoint knows it will be unreachable for a while. > Ok. I can see some use for it. But is zero address set alone sufficient or you also need to tell the other end how long you are not reachable ? Your peer may not want to keep the inactive SAs open for a long time. If you don't specify the time, your peer will delete it anyway after some time. Even if you specify the time, your peer will delete it anyway based on its local configuration (assuming we are not negotiating it). If you don't know how long the SAs will be kept around by your peer, would it still be useful ? -mohan > > i see this issue from a different point of view. > > we have a dead peer detection to provide a mechanism to delete the ike sa > > (and ipsec sas) if the other does not respond anymore. > > well, let's distinguish two cases: > 1) we haven't heard from the peer in a while. > 2) the peer has crashed and forgot about the connection > > For some applications, tearing down state because of (1) may rightly viewed as a bug, not a feature -- but you may want fast recovery from (2) without > tearing down connections merely because of inactivity. > > > if a laptop has establish an ike sa with a gateway, uses dead peer detection > > and goes into the suspend mode then (even after a short amount of time) the > > ike sa will be gone. > > > > the 'zero address set' functionality could possibly be seen as temporarily > > suspending the dead peer protection on a specific address (or path). > > Sorta. > > > > - Bill > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 14:35:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16084 for ; Mon, 6 Dec 2004 14:35:58 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 01BACFB27C; Mon, 6 Dec 2004 19:35:59 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A8BC0FB266; Mon, 6 Dec 2004 19:35:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CA648FB26F; Mon, 6 Dec 2004 19:35:54 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 4D96FFB246 for ; Mon, 6 Dec 2004 19:35:54 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 34D1F8988B; Mon, 6 Dec 2004 21:35:50 +0200 (EET) Message-ID: <41B4B40C.6020109@piuha.net> Date: Mon, 06 Dec 2004 21:33:32 +0200 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 , Hannes Tschofenig , Tero Kivinen Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] new editor for the design draft 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 In IETF-61 we called for a volunteer to become an editor for the design draft. (The current editor, Tero, indicated that he's becoming too busy elsewhere to continue editing.) I am glad to announce that Hannes Tschofenig has agreed to be the new editor. Welcome Hannes, and thanks for taking this task! I would also like to thank Tero for editing the earlier versions. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 14: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 OAA18248 for ; Mon, 6 Dec 2004 14:51:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 327A3FB280; Mon, 6 Dec 2004 19:51:17 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C42A8FB266; Mon, 6 Dec 2004 19:51:13 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 00252FB26F; Mon, 6 Dec 2004 19:51:12 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id C0C36FB246 for ; Mon, 6 Dec 2004 19:51:10 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C50F089883; Mon, 6 Dec 2004 21:51:09 +0200 (EET) Message-ID: <41B4B7A3.4070006@piuha.net> Date: Mon, 06 Dec 2004 21:48:51 +0200 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: Tschofenig Hannes Subject: Re: [Mobike] issue 1: direct or indirect indicators References: <2A8DB02E3018D411901B009027FD3A3F0542C7F9@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0542C7F9@mchp905a.mch.sbs.de> 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 Tschofenig Hannes wrote: > you need to have more than one address anyway to switch to another one. > > it depends which entity detects the problem first. > > if the initiator detects that there is a problem (e.g., on the local link) > then it can switch to a new address. sending an ikev2 notification message > from the new address to the responder is fine and might cause an address > update of the ipsec sa with or without return routability check > (authorization decision). > > if the responder detects that there was a problem (e.g., on its local link) > then it might want to send the initiator a notification that it should use a > different address. if the initiator uses a dead peer detection mechanism he > will also discover the problem (after some time). Right. Given that there are a lot of local mechanisms such as DNA, ND, and L2 that can detect problems, I would support allowing either party to detect a problem. (But it could be that e2e path failure detection is only the initiator's responsibility. In any case the reaction at the MOBIKE layer is similar, letting the peer know that a new address needs to be used.) > as a summary: i am not quite about the possible conclusion of this issue > since the issue description is too fuzzy. When the issue was first discussed, we did not understand quite everything we do now... But I think as far as the original issue goes, I think we can say that both forms of indication need to be supported. For instance, we discussed in IETF-61 about the use of local ND/L2/DNA information, we have earlier agreed on the list that we need to support path failure detection, and we certainly need to be able to act if the peer tells us via MOBIKE that his address has changed. Perhaps the above could be conclusion of this issue and then we can open new ones for the other questions that you had below: > a separate question but also of interest: > - should a peer send an address list in one message or individual messages > (which only contain one address/message)? > (the address list does not work in a nat environment.) > answer: both seems to be desired. That's a good question and observation about NAT. For simplicity, I would actually prefer we just use one address/message... > - should the individual address be part of the protected payload or taken > from info of the header? > answer: both is desired (depending on whether nat traversal is desired or > not) This is also a good question. I agree that both are needed. In this case we can't simplify because we really do want to work with NAT-T, and we also really want to be more secure than NAT-T is when we don't have to use NAT. Or that's at least what I think. > - should the address list be idempotent or not? > answer: this is still an open issue. always resending the full list > (idempotent operation) requires more bandwidth but avoid synchonization > issue which needs to be addressed. , for > example, seems to offer an approach which defines add/delete operations. My personal preference would be always sending the full list. > there is little doubt that a mobike protocol needs some mechanisms that > allows one peer to inform the other peer about address changes. (direct > indications) > > i think think that the term indirect indication has anything todo with > address lists. > for me an indirect indication is a hint provided by other protocols or > mechanisms to switch from one address to another. draft talks about various > hints provided by other protocols which may lead to the conclusion to switch > from one address to another. Right. And I think that in IETF-61 we had general agreement that information from these other protocols needs to be supported by MOBIKE. It would be funny if L2 informed us that the link is down but we still kept trying to get an answer from DPD. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 14:59:02 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19058 for ; Mon, 6 Dec 2004 14:59:01 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id ECF5FFB27A; Mon, 6 Dec 2004 19:59:01 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 56A35FB266; Mon, 6 Dec 2004 19:59:00 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3DAFAFB26F; Mon, 6 Dec 2004 19:58:58 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 366B6FB246 for ; Mon, 6 Dec 2004 19:58:57 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 3F1C889883; Mon, 6 Dec 2004 21:58:56 +0200 (EET) Message-ID: <41B4B976.1080801@piuha.net> Date: Mon, 06 Dec 2004 21:56:38 +0200 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: Tschofenig Hannes Subject: Re: [Mobike] issue 3: nat traversal References: <2A8DB02E3018D411901B009027FD3A3F0542C6FD@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0542C6FD@mchp905a.mch.sbs.de> 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 I agree. The conclusion is that - we need to support MOBIKE in a NAT traversal situation - we need to support MOBIKE moving in and out of a NAT traversal situation - NAT prevention can be provided by MOBIKE if people want to put that in (but that seems to be outside the original scope of this issue) However, I believe part of the reason for the original issue was the "how" part -- the above addresses only the "what" part. I guess one of the questions going forward is whether people think draft-eronen-mobike-mopo-01.txt and draft-dupont-ikev2-addrmgmt-06.txt provide a sufficient coverage of the "what" part and a sufficient answer to the "how" part. --Jari Tschofenig Hannes wrote: > hi all, > > let us try to close the nat traversal issue (issue 3) from > http://www.vpnc.org/ietf-mobike/issue3.txt > > here is what we currently have: > > - charter says that we should not modify the ikev2 nat traversal mechanism. > none of the proposal tries to todo that. > - draft addresses nat traversal. > - draft and > additionally add a mechanism to > indicate nat traversal prevention. > > a number of people pointed to the need to support nat traversal. > > hence, i think that we could have support for > - nat traversal and > - a nat traversal prevention (if you think you don't need it) > without conflicting with the charter. > > to address the scenarios there also needs to support for an end host moving > from not-behind a nat to behind a nat. > > ciao > hannes > > > _______________________________________________ > 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 Dec 6 15:01:56 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19228 for ; Mon, 6 Dec 2004 15:01:55 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D7D42FB279; Mon, 6 Dec 2004 20:01:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2A1E8FB266; Mon, 6 Dec 2004 20:01:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 906C8FB26F; Mon, 6 Dec 2004 20:01:49 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 5D218FB246 for ; Mon, 6 Dec 2004 20:01:47 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 89BC189883; Mon, 6 Dec 2004 22:01:46 +0200 (EET) Message-ID: <41B4BA20.5010208@piuha.net> Date: Mon, 06 Dec 2004 21:59:28 +0200 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: Mohan Parthasarathy Subject: Re: [Mobike] issue 3: nat traversal References: <2A8DB02E3018D411901B009027FD3A3F0542C6FD@mchp905a.mch.sbs.de> <007401c4dbbe$29652460$861167c0@adithya> In-Reply-To: <007401c4dbbe$29652460$861167c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Tschofenig Hannes 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 Mohan Parthasarathy wrote: > The issue is a bit confusing to me. I agree that we don't want to modify > the IKEv2 NAT traversal as specified in the IKEv2 draft. But do we want > MOBIKE to work when moving behind NATs ? I am not sure which > question is being asked here. I think the key question is what do we want MOBIKE to do, i.e., does it need to work when moving behind a NAT? And then answer seems to be yes. Its true that the we have a restriction that we should not modify IKEv2 NAT traversal. My advice is not to focus too much on this question. Lets do what it makes technical sense. I do not think any of the current proposals modify NAT-T, even if we can perhaps provide a new stage in the protocol when it is turned on (not just in the initial contact). So lets not worry about this part. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 15:08:57 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20009 for ; Mon, 6 Dec 2004 15:08:57 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CFCD6FB277; Mon, 6 Dec 2004 20:08:57 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D6CBCFB266; Mon, 6 Dec 2004 20:08:56 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2CA06FB26F; Mon, 6 Dec 2004 20:08:54 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 11EA5FB246 for ; Mon, 6 Dec 2004 20:08:53 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id F22818988B; Mon, 6 Dec 2004 22:08:51 +0200 (EET) Message-ID: <41B4BBC9.1010102@piuha.net> Date: Mon, 06 Dec 2004 22:06:33 +0200 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: James Kempf Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE References: <2A8DB02E3018D411901B009027FD3A3F0542C6B2@mchp905a.mch.sbs.de> <41B4A39C.9060300@nortelnetworks.com> <016801c4dbc2$17663890$5d6015ac@dcml.docomolabsusa.com> In-Reply-To: <016801c4dbc2$17663890$5d6015ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Tero Kivinen , Tschofenig Hannes 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 Yes. We shall only have one. Based on Hannes' analysis, both options seem to provide the same functionality. I am personally fine with either approach. Given that we are writing a design draft, perhaps we should make a design decision and pick one? It seems that a few people preferred the Notify. I'm not sure I understood Tero's objection to Vendor ID, but at least Notify sounds nicer. Pick that and move one to the next issue? --Jari James Kempf wrote: > I think we ought to choose either Vendor ID or Notify. While I support > Notify (since this is a standardized, and not a vendor specific, option), I > would rather go with Vendor ID if that's what a majority of the WG wants > rather than have both. > > jak > > ----- Original Message ----- > From: "Dondeti, Lakshminath" > To: "Tschofenig Hannes" > Cc: "MOBIKE Mailing List" ; ; > "Tero Kivinen" > Sent: Monday, December 06, 2004 10:23 AM > Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE > > > >>This sounds good. I was initially leaning toward Notify only, but there >>is no harm in allowing Vendor ID. I wouldn't necessarily suggest the >>use of "critical bit" here. Clearly, an implementation may choose to >>use that feature, but there is no need to make that suggestion in each >>context. Thanks. >> >>regards, >>Lakshminath >> >>Tschofenig Hannes wrote: >> >> >>>hi all, >>> >>>i went thought about the two most important options: notify and vendor > > id > >>>they both seem to provide the same capability. notify is used for >>>errors but >>>also for indicating sender capabilities. the same is true for the >>>vendor id. >>> >>> >>>as a text proposal i suggest to enhance the text offered by jari as >>>follows: >>> >>>----------------------- >>> >>>X. Indicating Support for MOBIKE >>> >>>A node needs to be able to guarantee that its address change messages > > are > >>>understood by the peer. Otherwise an address change may render the >>>connection useless, and it is important that both sides realize this as >>>early as possible. >>> >>>Ensuring that the messages are understood can in be arranged either by >>>marking some IKEv2 payloads critical so that they are either processed >>>or an >>>error message is returned, by using Vendor ID payloads or via a Notify. >>> >>>The first solution approach is to use Vendor ID payloads during the >>>initial >>>IKEv2 exchange using a specific string denoting MOBIKE to signal the >>>support >>>of the MOBIKE protocol. This ensures that in all cases a MOBIKE >>>capable node >>>knows whether its peer supports MOBIKE or not. >>> >>>The second solution approach uses the Notify payload which is also >>>used for >>>NAT detection (via NAT_DETECTION_SOURCE_IP and >>>NAT_DETECTION_DESTINATION_IP), . >>> >>>Both, a Vendor ID and a Notify payload, might be used to indicate the >>>support of certain extensions. >>> >>>Note that the node could also attempt MOBIKE optimistically with the >>>critical bit set to one when a movement has occurred. The drawback of >>>this >>>approach is, however, that the an unnecessary MOBIKE message round is >>>introduced on the first movement. >>> >>>----------------------- >>> >>>ciao >>>hannes >>> >>> >>> >>>>-----Original Message----- >>>>From: Tero Kivinen [mailto:kivinen@iki.fi] >>>>Sent: Dienstag, 30. November 2004 11:41 >>>>To: jari.arkko@piuha.net >>>>Cc: MOBIKE Mailing List >>>>Subject: [Mobike] issue 4: how to signal support for MOBIKE >>>> >>>>Jari Arkko writes: >>>> >>>>>So I would suggest that we use the Vendor ID approach. >>>> >>>>I would suggest NOTIFY approach. I.e we send notify saying >>>>MOBIKE_SUPPORTED and thats it. Similar thatn what is done for >>>>the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. >>>> >>>>In most cases we do not want to fail the negotiation even if >>>>the other end does not support MOBIKE, we simply revert back >>>>to redoing the authentication every time IP-addresses changes. >>>> >>>>If our final protocol is going to use notifies to send the >>>>IP-addresses, then we can use those notifies to signal the >>>>use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. >>>>-- >>>>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 >>> >> >>_______________________________________________ >>Mobike mailing list >>Mobike@machshav.com >>https://www.machshav.com/mailman/listinfo.cgi/mobike >> > > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 15:48:26 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23639 for ; Mon, 6 Dec 2004 15:48:24 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CD8C0FB27F; Mon, 6 Dec 2004 20:48:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C1AC1FB266; Mon, 6 Dec 2004 20:48:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D1839FB26F; Mon, 6 Dec 2004 20:48:19 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id CF3FAFB246 for ; Mon, 6 Dec 2004 20:48:18 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B9B7189883; Mon, 6 Dec 2004 22:48:12 +0200 (EET) Message-ID: <41B4C502.9080208@piuha.net> Date: Mon, 06 Dec 2004 22:45:54 +0200 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: Tarique Mustafa Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE References: <20041206203405.63723.qmail@web41208.mail.yahoo.com> In-Reply-To: <20041206203405.63723.qmail@web41208.mail.yahoo.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 Tarique Mustafa wrote: > However, just a question or "food for some more thought", here is a > scenario: > > 1) Client Peer establishes a Mobike Session with Remote Peer (or server) > 2) Client Peer moves to a new access point and due to change in the IP > address, re-registers with the Remote Peer (or server) - session type > now however (for ANY reason) is not to be Mobike Session any more :- It > could be anything let's say a simple IKEv1/IKEv2 session > 3) Client Peer moves again causing the IP address change again, > re-registers with Remote Peer (or server) again - BUT the session type > now "for some reason can and should be" a Mobike Session > > How will this scenario be supported with the existing recommendtions in > Mobike? > Will Notification vs. Vendor ID approach have any positive or negative > impact in the afore mentioned scenario? I don't think this particular choice has an effect to your scenario. As far as your scenario goes, switching on and off support for some feature (such as MOBIKE) probably does have some ill effects. In this particular case Step 2 may cause the earlier session to be thrown away, so you have to re-establish everything. But the interesting case is Step 3. The question is *when* do you signal support for MOBIKE? If you did not signal it earlier, can you switch in mid-session? I believe the answer for that should be that you can send the notification at any time. But the notification turns MOBIKE support on -- I don't think we need a notification to turn it off. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 15:51:09 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23893 for ; Mon, 6 Dec 2004 15:51:08 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 97BD0FB279; Mon, 6 Dec 2004 20:51:09 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E3100FB266; Mon, 6 Dec 2004 20:51:08 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A57DAFB26F; Mon, 6 Dec 2004 20:51:06 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 16FEFFB246 for ; Mon, 6 Dec 2004 20:51:06 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1F8A589883; Mon, 6 Dec 2004 22:51:05 +0200 (EET) Message-ID: <41B4C5AE.9080302@piuha.net> Date: Mon, 06 Dec 2004 22:48:46 +0200 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: Tschofenig Hannes Subject: Re: [Mobike] When to do Return Routability Checks References: <2A8DB02E3018D411901B009027FD3A3F0542C72B@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0542C72B@mchp905a.mch.sbs.de> 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 Tschofenig Hannes wrote: > [hannes] the relationship between authorization and the aspect of timing > (WHEN to send return routability checks - if at all) needs to be separated. Yes. For the do it all, I think the answer depends on configured policy, with default being yes. For the when part, I think it should be done prior to moving the SA and the data stream towards that address. > discussions during the ietf meeting (see issue tracker web page) concluded > that it is a policy issue when to perform the return routability checks. > this conclusion seems to be fine with me. i will try to produce a new text > proposal. Ok. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 16:02:51 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24992 for ; Mon, 6 Dec 2004 16:02:48 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 4342FFB27A; Mon, 6 Dec 2004 21:02:47 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 41599FB266; Mon, 6 Dec 2004 21:02:45 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3A1FBFB26F; Mon, 6 Dec 2004 21:02:44 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 3E5CFFB246 for ; Mon, 6 Dec 2004 21:02:43 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4B7E889897; Mon, 6 Dec 2004 23:02:42 +0200 (EET) Message-ID: <41B4C868.7040606@piuha.net> Date: Mon, 06 Dec 2004 23:00:24 +0200 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: Bill Sommerfeld , Tschofenig Hannes Subject: Re: [Mobike] Zero Address Set References: <2A8DB02E3018D411901B009027FD3A3F0542C6B3@mchp905a.mch.sbs.de> <1102352215.7940.69.camel@thunk> <00c801c4dbc4$32a65110$861167c0@adithya> In-Reply-To: <00c801c4dbc4$32a65110$861167c0@adithya> 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 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 guess the key question here is whether there's enough "bang for the buck" in this function for it to be included in MOBIKE. Earlier we didn't see that many people interested, but now we have some. In any case, we need to consider the following: - The benefit this feature offers is about "being a good citizen" (as you Bill put it) and not send unnecessary packets when we know the other end is down. Nevertheless, this is not a functional benefit in the sense that nothing breaks if we don't have it; just that extra packets are sent. - We know we can not use this feature in all cases when the other end is down. We don't always know we are going outside coverage. - We know there's some practical limits to how long this condition can be held and still be considered useful, such as applications on top starting to get timeouts. - There may be some additional complexity for MOBIKE. For instance, assume A and B are talking to each other and that A now informs B that its offline. Now, normally in MOBIKE if B moves it can tell A immediately. But if zero-address set is supported then B must be able to queue this notification. And if all of B's addresses got changed, the situation is not recoverable. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 6 16:14:45 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25725 for ; Mon, 6 Dec 2004 16:14:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 82174FB27A; Mon, 6 Dec 2004 21:14:45 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F1C6EFB266; Mon, 6 Dec 2004 21:14:39 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B08EFFB26F; Mon, 6 Dec 2004 21:14:38 +0000 (UTC) Received: from smtp810.mail.sc5.yahoo.com (smtp810.mail.sc5.yahoo.com [66.163.170.80]) by machshav.com (Postfix) with SMTP id F15C2FB246 for ; Mon, 6 Dec 2004 21:14:37 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 6 Dec 2004 21:14:37 -0000 Message-ID: <018601c4dbd8$962e92b0$861167c0@adithya> From: "Mohan Parthasarathy" To: References: <2A8DB02E3018D411901B009027FD3A3F0542C6FD@mchp905a.mch.sbs.de><007401c4dbbe$29652460$861167c0@adithya> <41B4BA20.5010208@piuha.net> Subject: Re: [Mobike] issue 3: nat traversal Date: Mon, 6 Dec 2004 13:14:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: MOBIKE Mailing List , Tschofenig Hannes 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 > > > The issue is a bit confusing to me. I agree that we don't want to modify > > the IKEv2 NAT traversal as specified in the IKEv2 draft. But do we want > > MOBIKE to work when moving behind NATs ? I am not sure which > > question is being asked here. > > I think the key question is what do we want MOBIKE to do, > i.e., does it need to work when moving behind a NAT? And > then answer seems to be yes. > Okay. Do we want to add the qualifier that MOBIKE needs to work in a "secure" fashion when moving behind a NAT ? (unlike IKEv2 which also supports NAT traversal but susceptible to 3rd party bombing attacks). > Its true that the we have a restriction that we should not modify > IKEv2 NAT traversal. My advice is not to focus too much on this > question. Lets do what it makes technical sense. I do not think > any of the current proposals modify NAT-T, even if we can perhaps > provide a new stage in the protocol when it is turned on (not just > in the initial contact). So lets not worry about this part. > Note that none of the current proposals support NAT traversal. >From what i have read, they only have a prevention mechanism. -mohan > --Jari > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 7 07:04:05 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17157 for ; Tue, 7 Dec 2004 07:04:04 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D8B38FB279; Tue, 7 Dec 2004 12:04:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3508BFB266; Tue, 7 Dec 2004 12:03:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 43F9EFB26F; Mon, 6 Dec 2004 20:34:07 +0000 (UTC) Received: from web41208.mail.yahoo.com (web41208.mail.yahoo.com [66.218.93.41]) by machshav.com (Postfix) with SMTP id 58AC6FB246 for ; Mon, 6 Dec 2004 20:34:06 +0000 (UTC) Received: (qmail 63725 invoked by uid 60001); 6 Dec 2004 20:34:05 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Tjnh/eAyACnWcir4iSG9ni6VuMskDCwJCtwuW6ImCG6Kb/ZQaL/2J+emkF9daknlyJu/AJKHK0Zw5BMZXM74bl6VA+5v/vtCIPLAWNsjBXaYTttnlFcwj3Eu9sECIlzPWt3/SjNqeGtuo+m/cQu/HRTICpoWcW59WSPBDaR5T0E= ; Message-ID: <20041206203405.63723.qmail@web41208.mail.yahoo.com> Received: from [68.123.127.107] by web41208.mail.yahoo.com via HTTP; Mon, 06 Dec 2004 12:34:05 PST Date: Mon, 6 Dec 2004 12:34:05 -0800 (PST) From: Tarique Mustafa Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE To: jari.arkko@piuha.net, James Kempf In-Reply-To: <41B4BBC9.1010102@piuha.net> MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 07 Dec 2004 12:03:52 +0000 Cc: MOBIKE Mailing List , Tero Kivinen , Tschofenig Hannes 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="===============0902679838==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --===============0902679838== Content-Type: multipart/alternative; boundary="0-1457348551-1102365245=:53581" --0-1457348551-1102365245=:53581 Content-Type: text/plain; charset=us-ascii Jari, Tero, Hannes, Kempf and others: I see the benefit of using either of the approaches - Vendor ID vs. Notify and am fine with either one. However, just a question or "food for some more thought", here is a scenario: 1) Client Peer establishes a Mobike Session with Remote Peer (or server) 2) Client Peer moves to a new access point and due to change in the IP address, re-registers with the Remote Peer (or server) - session type now however (for ANY reason) is not to be Mobike Session any more :- It could be anything let's say a simple IKEv1/IKEv2 session 3) Client Peer moves again causing the IP address change again, re-registers with Remote Peer (or server) again - BUT the session type now "for some reason can and should be" a Mobike Session How will this scenario be supported with the existing recommendtions in Mobike? Will Notification vs. Vendor ID approach have any positive or negative impact in the afore mentioned scenario? Regards, -Tarique Mustafa Jari Arkko wrote: Yes. We shall only have one. Based on Hannes' analysis, both options seem to provide the same functionality. I am personally fine with either approach. Given that we are writing a design draft, perhaps we should make a design decision and pick one? It seems that a few people preferred the Notify. I'm not sure I understood Tero's objection to Vendor ID, but at least Notify sounds nicer. Pick that and move one to the next issue? --Jari James Kempf wrote: > I think we ought to choose either Vendor ID or Notify. While I support > Notify (since this is a standardized, and not a vendor specific, option), I > would rather go with Vendor ID if that's what a majority of the WG wants > rather than have both. > > jak > > ----- Original Message ----- > From: "Dondeti, Lakshminath" > To: "Tschofenig Hannes" > Cc: "MOBIKE Mailing List" ; ; > "Tero Kivinen" > Sent: Monday, December 06, 2004 10:23 AM > Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE > > > >>This sounds good. I was initially leaning toward Notify only, but there >>is no harm in allowing Vendor ID. I wouldn't necessarily suggest the >>use of "critical bit" here. Clearly, an implementation may choose to >>use that feature, but there is no need to make that suggestion in each >>context. Thanks. >> >>regards, >>Lakshminath >> >>Tschofenig Hannes wrote: >> >> >>>hi all, >>> >>>i went thought about the two most important options: notify and vendor > > id > >>>they both seem to provide the same capability. notify is used for >>>errors but >>>also for indicating sender capabilities. the same is true for the >>>vendor id. >>> >>> >>>as a text proposal i suggest to enhance the text offered by jari as >>>follows: >>> >>>----------------------- >>> >>>X. Indicating Support for MOBIKE >>> >>>A node needs to be able to guarantee that its address change messages > > are > >>>understood by the peer. Otherwise an address change may render the >>>connection useless, and it is important that both sides realize this as >>>early as possible. >>> >>>Ensuring that the messages are understood can in be arranged either by >>>marking some IKEv2 payloads critical so that they are either processed >>>or an >>>error message is returned, by using Vendor ID payloads or via a Notify. >>> >>>The first solution approach is to use Vendor ID payloads during the >>>initial >>>IKEv2 exchange using a specific string denoting MOBIKE to signal the >>>support >>>of the MOBIKE protocol. This ensures that in all cases a MOBIKE >>>capable node >>>knows whether its peer supports MOBIKE or not. >>> >>>The second solution approach uses the Notify payload which is also >>>used for >>>NAT detection (via NAT_DETECTION_SOURCE_IP and >>>NAT_DETECTION_DESTINATION_IP), . >>> >>>Both, a Vendor ID and a Notify payload, might be used to indicate the >>>support of certain extensions. >>> >>>Note that the node could also attempt MOBIKE optimistically with the >>>critical bit set to one when a movement has occurred. The drawback of >>>this >>>approach is, however, that the an unnecessary MOBIKE message round is >>>introduced on the first movement. >>> >>>----------------------- >>> >>>ciao >>>hannes >>> >>> >>> >>>>-----Original Message----- >>>>From: Tero Kivinen [mailto:kivinen@iki.fi] >>>>Sent: Dienstag, 30. November 2004 11:41 >>>>To: jari.arkko@piuha.net >>>>Cc: MOBIKE Mailing List >>>>Subject: [Mobike] issue 4: how to signal support for MOBIKE >>>> >>>>Jari Arkko writes: >>>> >>>>>So I would suggest that we use the Vendor ID approach. >>>> >>>>I would suggest NOTIFY approach. I.e we send notify saying >>>>MOBIKE_SUPPORTED and thats it. Similar thatn what is done for >>>>the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. >>>> >>>>In most cases we do not want to fail the negotiation even if >>>>the other end does not support MOBIKE, we simply revert back >>>>to redoing the authentication every time IP-addresses changes. >>>> >>>>If our final protocol is going to use notifies to send the >>>>IP-addresses, then we can use those notifies to signal the >>>>use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. >>>>-- >>>>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 >>> >> >>_______________________________________________ >>Mobike mailing list >>Mobike@machshav.com >>https://www.machshav.com/mailman/listinfo.cgi/mobike >> > > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --------------------------------- Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. --0-1457348551-1102365245=:53581 Content-Type: text/html; charset=us-ascii
Jari, Tero, Hannes, Kempf and others:
 
I see the benefit of using either of the approaches - Vendor ID vs. Notify and am fine with either one.
 
However, just a question or "food for some more thought", here is a scenario:
 
1) Client Peer establishes a Mobike Session with Remote Peer (or server)
2) Client Peer moves to a new access point and due to change in the IP address, re-registers with the Remote Peer (or server) - session type now however (for ANY reason) is not to be Mobike Session any more :- It could be anything let's say a simple IKEv1/IKEv2 session
3) Client Peer moves again causing the IP address change again, re-registers with Remote Peer (or server) again - BUT the session type now "for some reason can and should be" a Mobike Session
 
How will this scenario be supported with the existing recommendtions in Mobike?
Will Notification vs. Vendor ID approach have any positive or negative impact in the afore mentioned scenario?
 
Regards,
-Tarique Mustafa
 
 
 


Jari Arkko <jari.arkko@piuha.net> wrote:
Yes. We shall only have one. Based on Hannes' analysis,
both options seem to provide the same functionality.
I am personally fine with either approach. Given that
we are writing a design draft, perhaps we should make
a design decision and pick one? It seems that a few people
preferred the Notify. I'm not sure I understood Tero's
objection to Vendor ID, but at least Notify sounds nicer.
Pick that and move one to the next issue?

--Jari

James Kempf wrote:
> I think we ought to choose either Vendor ID or Notify. While I support
> Notify (since this is a standardized, and not a vendor specific, option), I
> would rather go with Vendor ID if that's what a majority of the WG wants
> rather than have both.
>
> jak
>
> ----- Original Message -----
> From: "Dondeti, Lakshminath"
> To: "Tschofenig Hannes"
> Cc: "MOBIKE Mailing List" ; ;
> "Tero Kivinen"
> Sent: Monday, December 06, 2004 10:23 AM
> Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE
>
>
>
>>This sounds good. I was initially leaning toward Notify only, but there
>>is no harm in allowing Vendor ID. I wouldn't necessarily suggest the
>>use of "critical bit" here. Clearly, an implementation may choose to
>>use that feature, but there is no need to make that suggestion in each
>>context. Thanks.
>>
>>regards,
>>Lakshminath
>>
>>Tschofenig Hannes wrote:
>>
>>
>>>hi all,
>>>
>>>i went thought about the two most important options: notify and vendor
>
> id>
>>>they both seem to provide the same capability. notify is used for
>>>errors but
>>>also for indicating sender capabilities. the same is true for the
>>>vendor id.
>>>
>>>
>>>as a text proposal i suggest to enhance the text offered by jari as
>>>follows:
>>>
>>>-----------------------
>>>
>>>X. Indicating Support for MOBIKE
>>>
>>>A node needs to be able to guarantee that its address change messages
>
> are
>
>>>understood by the peer. Otherwise an address change may render the
>>>connection useless, and it is important that both sides realize this as
>>>early as possible.
>>>
>>>Ensuring that the messages are understood can in be arranged either by
>>>marking some IKEv2 payloads critical so that they are either processed
>>>or an
>>>error message is returned, by using Vendor ID payloads or via a Notify.
>>>
>>>The first solution approach is to use Vendor ID payloads during the
>>>initial
>>>IKEv2 exchange using a specific string denoting MOBIKE to signal the
>>>support
>>>of the MOBIKE protocol. This ensures that in all cases a MOBIKE
>>>capable node
>>>knows whether its peer supports MOBIKE or not.
>>>
>>>The second solution approach uses the Notify payload which is also
>>>used for
>>>NAT detection (via NAT_DETECTION_SOURCE_IP and
>>>NAT_DETECTION_DESTINATION_IP), .
>>>
>>>Both, a Vendor ID and a Notify payload, might be used to indicate the
>>>support of certain extensions.
>>>
>>>Note that the node could also attempt MOBIKE optimistically wit h the
>>>critical bit set to one when a movement has occurred. The drawback of
>>>this
>>>approach is, however, that the an unnecessary MOBIKE message round is
>>>introduced on the first movement.
>>>
>>>-----------------------
>>>
>>>ciao
>>>hannes
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Tero Kivinen [mailto:kivinen@iki.fi]
>>>>Sent: Dienstag, 30. November 2004 11:41
>>>>To: jari.arkko@piuha.net
>>>>Cc: MOBIKE Mailing List
>>>>Subject: [Mobike] issue 4: how to signal support for MOBIKE
>>>>
>>>>Jari Arkko writes:
>>>>
>>>>>So I would suggest that we use the Vendor ID approach.
>>>>
>>>>I would suggest NOTIFY approach. I.e we send notify saying
>>>>MOBIKE_SUPPORTED and thats it. Similar thatn what is done for
>>>>the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc.
>>>>
>>>>In most cases we do not want to fail the negotiation even if
>>>>the other end does not support MOBIKE, we simply revert back
>>>>to redoing the authentication every time IP-addresses changes.
>>>>
>>>>If our final protocol is going to use notifies to send the
>>>>IP-addresses, then we can use those notifies to signal the
>>>>use of MOBIKE instead of separate MOBIKE_SUPPORTED notify.
>>>>--
>>>>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
>>>
>>
>>_______________________________________________
>>Mobike mailing list
>>Mobike@machshav.com
>>https://www.machshav.com/mailman/listinfo.cgi/mobike
>>
>
>
>
> _______________________________________________
> Mobike mailing list
> Mobike@machshav.com
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>
>

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

Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard. --0-1457348551-1102365245=:53581-- --===============0902679838== 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 --===============0902679838==-- From mobike-bounces@machshav.com Wed Dec 8 05:33:27 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10426 for ; Wed, 8 Dec 2004 05:33:26 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8B74DFB280; Wed, 8 Dec 2004 10:33:27 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8440FFB279; Wed, 8 Dec 2004 10:33:26 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2892CFB27F; Wed, 8 Dec 2004 10:33:24 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id 1CC71FB266 for ; Wed, 8 Dec 2004 10:33:23 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iB8AXLUO012742 for ; Wed, 8 Dec 2004 11:33:21 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB8AXKsS021077 for ; Wed, 8 Dec 2004 11:33:21 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Dec 2004 11:33:20 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: MOBIKE Mailing List Date: Wed, 8 Dec 2004 11:33:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Mobike] issue #16 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 hi all, i guess we can close issue # 16: "Can the protocol recover from situations where the only sign of problems is lack of packets from the other end?" http://www.vpnc.org/ietf-mobike/issue16.txt as a conclusion of the discussions we said: - mobike defines a mechanism to test connectivity along paths. - both peers might use input from other sources to detect a failure (e.g., a local link failure) - based on this information mobike might decide to switch to a new address (if available). ciao hannes _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 8 05:34:03 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10473 for ; Wed, 8 Dec 2004 05:34:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B8AD0FB283; Wed, 8 Dec 2004 10:34:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 500C4FB280; Wed, 8 Dec 2004 10:33:56 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 08D92FB281; Wed, 8 Dec 2004 10:33:55 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id AEF31FB266 for ; Wed, 8 Dec 2004 10:33:53 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iB8AXqUO013452; Wed, 8 Dec 2004 11:33:52 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB8AXpsS021524; Wed, 8 Dec 2004 11:33:51 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Dec 2004 11:33:50 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C9A0@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Mohan Parthasarathy , Bill Sommerfeld Subject: RE: [Mobike] Zero Address Set Date: Wed, 8 Dec 2004 11:33:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi mohan, please see my comment below; > Bill, > > > > i thought about the functionality of the "zero address set". one > > > important question is: what is this functionality good for? > > > > temporary tunnel suspension when the endpoint knows it will > be unreachable for a while. > > > Ok. I can see some use for it. But is zero address set alone > sufficient or you also need to tell the other end how long > you are not reachable ? Your peer may not want to keep the > inactive SAs open for a long time. If you don't specify the > time, your peer will delete it anyway after some time. Even > if you specify the time, your peer will delete it anyway > based on its local configuration (assuming we are not > negotiating it). If you don't know how long the SAs will be > kept around by your peer, would it still be useful ? it seems that you would like to add a lifetime parameter to the ike sa (and additionally suspend the dead peer detection for the indicated amount of time). ciao hannes > > -mohan > > > > > > i see this issue from a different point of view. > > > we have a dead peer detection to provide a mechanism to > delete the > > > ike sa (and ipsec sas) if the other does not respond anymore. > > > > well, let's distinguish two cases: > > 1) we haven't heard from the peer in a while. > > 2) the peer has crashed and forgot about the connection > > > > For some applications, tearing down state because of (1) > may rightly > > viewed as a bug, not a feature -- but you may want fast > recovery from (2) without > > tearing down connections merely because of inactivity. > > > > > if a laptop has establish an ike sa with a gateway, uses > dead peer > > > detection and goes into the suspend mode then (even after a short > > > amount of time) the ike sa will be gone. > > > > > > the 'zero address set' functionality could possibly be seen as > > > temporarily suspending the dead peer protection on a > specific address (or path). > > > > Sorta. > > > > > > > > - Bill > > > > > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 8 05:34:13 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10506 for ; Wed, 8 Dec 2004 05:34:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BD5C1FB281; Wed, 8 Dec 2004 10:34:14 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C6830FB28A; Wed, 8 Dec 2004 10:34:08 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E9CDFFB28D; Wed, 8 Dec 2004 10:34:00 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id CDC27FB279 for ; Wed, 8 Dec 2004 10:33:53 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iB8AXq4A014607; Wed, 8 Dec 2004 11:33:52 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB8AXpsS021525; Wed, 8 Dec 2004 11:33:51 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Dec 2004 11:33:50 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C9A2@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: jari.arkko@piuha.net Subject: RE: [Mobike] issue 1: direct or indirect indicators Date: Wed, 8 Dec 2004 11:33:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 i guess we can close issue#1. the listed sub-issues have to be added somewhere else. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Montag, 06. Dezember 2004 20:49 > To: Tschofenig Hannes > Cc: MOBIKE Mailing List > Subject: Re: [Mobike] issue 1: direct or indirect indicators > > Tschofenig Hannes wrote: > > > you need to have more than one address anyway to switch to > another one. > > > > it depends which entity detects the problem first. > > > > if the initiator detects that there is a problem (e.g., on > the local > > link) then it can switch to a new address. sending an ikev2 > > notification message from the new address to the responder > is fine and > > might cause an address update of the ipsec sa with or > without return > > routability check (authorization decision). > > > > if the responder detects that there was a problem (e.g., on > its local > > link) then it might want to send the initiator a > notification that it > > should use a different address. if the initiator uses a dead peer > > detection mechanism he will also discover the problem > (after some time). > > Right. Given that there are a lot of local mechanisms such as > DNA, ND, and L2 that can detect problems, I would support > allowing either party to detect a problem. (But it could be > that e2e path failure detection is only the initiator's > responsibility. In any case the reaction at the MOBIKE layer > is similar, letting the peer know that a new address needs to > be used.) > > > as a summary: i am not quite about the possible conclusion of this > > issue since the issue description is too fuzzy. > > When the issue was first discussed, we did not understand > quite everything we do now... > > But I think as far as the original issue goes, I think we can > say that both forms of indication need to be supported. > For instance, we discussed in IETF-61 about the use of local > ND/L2/DNA information, we have earlier agreed on the list > that we need to support path failure detection, and we > certainly need to be able to act if the peer tells us via > MOBIKE that his address has changed. > > Perhaps the above could be conclusion of this issue and then > we can open new ones for the other questions that you had below: > > > a separate question but also of interest: > > - should a peer send an address list in one message or individual > > messages (which only contain one address/message)? > > (the address list does not work in a nat environment.) > > answer: both seems to be desired. > > That's a good question and observation about NAT. For > simplicity, I would actually prefer we just use one address/message... > > > - should the individual address be part of the protected payload or > > taken from info of the header? > > answer: both is desired (depending on whether nat traversal is > > desired or > > not) > > This is also a good question. I agree that both are needed. > In this case we can't simplify because we really do want to > work with NAT-T, and we also really want to be more secure > than NAT-T is when we don't have to use NAT. Or that's at > least what I think. > > > - should the address list be idempotent or not? > > answer: this is still an open issue. always resending the > full list > > (idempotent operation) requires more bandwidth but avoid > > synchonization issue which needs to be addressed. > > , for example, seems to > offer an approach which defines add/delete operations. > > My personal preference would be always sending the full list. > > > > there is little doubt that a mobike protocol needs some mechanisms > > that allows one peer to inform the other peer about address > changes. > > (direct > > indications) > > > > i think think that the term indirect indication has > anything todo with > > address lists. > > for me an indirect indication is a hint provided by other > protocols or > > mechanisms to switch from one address to another. draft > talks about > > various hints provided by other protocols which may lead to the > > conclusion to switch from one address to another. > > Right. And I think that in IETF-61 we had general agreement > that information from these other protocols needs to be > supported by MOBIKE. It would be funny if L2 informed us that > the link is down but we still kept trying to get an answer from DPD. > > --Jari > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 8 05:34:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10531 for ; Wed, 8 Dec 2004 05:34:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CA12AFB29D; Wed, 8 Dec 2004 10:34:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B103AFB290; Wed, 8 Dec 2004 10:34:09 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1EEB8FB28B; Wed, 8 Dec 2004 10:34:03 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id CEAACFB266 for ; Wed, 8 Dec 2004 10:33:55 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iB8AXqeh008422; Wed, 8 Dec 2004 11:33:52 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB8AXpsS021526; Wed, 8 Dec 2004 11:33:51 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Dec 2004 11:33:50 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C9A1@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Jari Arkko , Bill Sommerfeld Subject: RE: [Mobike] Zero Address Set Date: Wed, 8 Dec 2004 11:33:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi jari, i am not sure that there is sufficient interest for this functionality. i am still not quite sure that we properly understand this issue. i again thought about it and think that technically we need to provide two things: - temporarily suspend dead peer detection (or path connectivity test) - drop traffic (since it cannot be delivered to the end host anyway) ciao hannes > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Montag, 06. Dezember 2004 22:00 > To: Bill Sommerfeld; Tschofenig Hannes > Cc: mobike@machshav.com > Subject: Re: [Mobike] Zero Address Set > > I guess the key question here is whether there's enough "bang > for the buck" in this function for it to be included in > MOBIKE. Earlier we didn't see that many people interested, > but now we have some. In any case, we need to consider the following: > > - The benefit this feature offers is about "being > a good citizen" (as you Bill put it) and not send > unnecessary packets when we know the other end > is down. Nevertheless, this is not a functional > benefit in the sense that nothing breaks if we > don't have it; just that extra packets are sent. > > - We know we can not use this feature in all cases > when the other end is down. We don't always know > we are going outside coverage. > > - We know there's some practical limits to how long > this condition can be held and still be considered > useful, such as applications on top starting to > get timeouts. > > - There may be some additional complexity for MOBIKE. > For instance, assume A and B are talking to each other > and that A now informs B that its offline. Now, > normally in MOBIKE if B moves it can tell A immediately. > But if zero-address set is supported then B must > be able to queue this notification. And if all of > B's addresses got changed, the situation is not > recoverable. > > --Jari > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 8 05:45:03 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11638 for ; Wed, 8 Dec 2004 05:45:01 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 927B5FB285; Wed, 8 Dec 2004 10:45:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7796AFB279; Wed, 8 Dec 2004 10:44:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 67235FB27F; Wed, 8 Dec 2004 10:44:57 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id CF117FB266 for ; Wed, 8 Dec 2004 10:44:56 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id BD78C8989D; Wed, 8 Dec 2004 12:44:52 +0200 (EET) Message-ID: <41B6DA98.8020504@piuha.net> Date: Wed, 08 Dec 2004 12:42:32 +0200 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: Tschofenig Hannes Subject: Re: [Mobike] Zero Address Set References: <2A8DB02E3018D411901B009027FD3A3F0542C9A1@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0542C9A1@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Bill Sommerfeld , 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 Tschofenig Hannes wrote: > hi jari, > > i am not sure that there is sufficient interest for this functionality. i am I have the same doubt. > still not quite sure that we properly understand this issue. i again thought > about it and think that technically we need to provide two things: > > - temporarily suspend dead peer detection (or path connectivity test) > - drop traffic (since it cannot be delivered to the end host anyway) These two and you also need to signal that it should be turned on. I'm not too worried that we understand the basic scheme here, but I'm more worried about how this interacts in more complicated scenarios and with other features. You could also see this function as orthogonal to MOBIKE, i.e., another IKEv2 feature that can be used to temporarily suspend all IKE and payload packet flows. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 8 06:21:30 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10471 for ; Wed, 8 Dec 2004 05:34:02 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7C7A1FB279; Wed, 8 Dec 2004 10:34:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8F9C2FB289; Wed, 8 Dec 2004 10:34:00 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EACC6FB281; Wed, 8 Dec 2004 10:33:55 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id EF054FB27F for ; Wed, 8 Dec 2004 10:33:53 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iB8AXqUO013455; Wed, 8 Dec 2004 11:33:52 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iB8AXpsS021520; Wed, 8 Dec 2004 11:33:51 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Dec 2004 11:33:50 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0542C99F@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Mohan Parthasarathy , jari.arkko@piuha.net Subject: RE: [Mobike] issue 3: nat traversal Date: Wed, 8 Dec 2004 11:33:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi mohan, thanks for your feedback. please see my comment below: ~snip~ > Okay. Do we want to add the qualifier that MOBIKE needs to > work in a "secure" fashion when moving behind a NAT ? > (unlike IKEv2 which also supports NAT traversal but > susceptible to 3rd party bombing attacks). what is a "secure" nat traversal solution for you? > > > Its true that the we have a restriction that we should not modify > > IKEv2 NAT traversal. My advice is not to focus too much on this > > question. Lets do what it makes technical sense. I do not > think any of > > the current proposals modify NAT-T, even if we can perhaps > provide a > > new stage in the protocol when it is turned on (not just in the > > initial contact). So lets not worry about this part. > > > Note that none of the current proposals support NAT traversal. > From what i have read, they only have a prevention mechanism. > i got a different impression. see for example, - - ciao hannes > -mohan > > > --Jari > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 8 07:18:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17517 for ; Wed, 8 Dec 2004 07:18:15 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C78BFFB27F; Wed, 8 Dec 2004 12:18:17 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 42FF1FB266; Wed, 8 Dec 2004 12:18:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9A592FB26F; Wed, 8 Dec 2004 12:18:16 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 47EB9FB262 for ; Wed, 8 Dec 2004 12:18:15 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id iB8CIDEt020281 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Dec 2004 14:18:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id iB8CI7H4020278; Wed, 8 Dec 2004 14:18:07 +0200 (EET) 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: <16822.61695.251487.301966@fireball.kivinen.iki.fi> Date: Wed, 8 Dec 2004 14:18:07 +0200 From: Tero Kivinen To: jari.arkko@piuha.net Subject: Re: [Mobike] Zero Address Set In-Reply-To: <41B6DA98.8020504@piuha.net> References: <2A8DB02E3018D411901B009027FD3A3F0542C9A1@mchp905a.mch.sbs.de> <41B6DA98.8020504@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: Bill Sommerfeld , mobike@machshav.com, Tschofenig Hannes 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 Jari Arkko writes: > You could also see this function as orthogonal to MOBIKE, i.e., > another IKEv2 feature that can be used to temporarily suspend > all IKE and payload packet flows. As the device will quite likely have different IP-address etc when it reconnects, it would not help that much in the base IKEv2. It is only really useful with MOBIKE. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 8 13:28:33 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21907 for ; Wed, 8 Dec 2004 13:28:33 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B3006FB27F; Wed, 8 Dec 2004 18:28:34 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1D7D4FB266; Wed, 8 Dec 2004 18:28:34 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 565C6FB26F; Wed, 8 Dec 2004 18:28:33 +0000 (UTC) Received: from smtp813.mail.sc5.yahoo.com (smtp813.mail.sc5.yahoo.com [66.163.170.83]) by machshav.com (Postfix) with SMTP id B3538FB262 for ; Wed, 8 Dec 2004 18:28:32 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 8 Dec 2004 18:08:14 -0000 Message-ID: <005701c4dd50$e3618dc0$861167c0@adithya> From: "Mohan Parthasarathy" To: "Tschofenig Hannes" , References: <2A8DB02E3018D411901B009027FD3A3F0542C99F@mchp905a.mch.sbs.de> Subject: Re: [Mobike] issue 3: nat traversal Date: Wed, 8 Dec 2004 10:08:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: MOBIKE 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 > > please see my comment below: > > ~snip~ > > Okay. Do we want to add the qualifier that MOBIKE needs to > > work in a "secure" fashion when moving behind a NAT ? > > (unlike IKEv2 which also supports NAT traversal but > > susceptible to 3rd party bombing attacks). > > what is a "secure" nat traversal solution for you? > The one that does not have the 3rd party bombing attack :-) To put in a different way, MOBIKE's security should not be altered, when moving behind a NAT. As we are at the design stage, it might make sense to understand what sort of NAT traversal solution we are going to have. > > > > > > Its true that the we have a restriction that we should not modify > > > IKEv2 NAT traversal. My advice is not to focus too much on this > > > question. Lets do what it makes technical sense. I do not > > think any of > > > the current proposals modify NAT-T, even if we can perhaps > > provide a > > > new stage in the protocol when it is turned on (not just in the > > > initial contact). So lets not worry about this part. > > > > > Note that none of the current proposals support NAT traversal. > > From what i have read, they only have a prevention mechanism. > > > i got a different impression. see for example, > - This one trivially supports it by the virtue of using IKEv2 NAT-T. > - > I have to read this again. But last time i read it, it was not still not completely secure. Perhaps, it is sufficient. But i am not sure we have a consensus on what level of security we want. -mohan > ciao > hannes > > > -mohan > > > > > --Jari > > > _______________________________________________ > > > Mobike mailing list > > > Mobike@machshav.com > > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 8 16:16:45 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04180 for ; Wed, 8 Dec 2004 16:16:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 792C1FB280; Wed, 8 Dec 2004 21:16:44 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E2135FB266; Wed, 8 Dec 2004 21:16:42 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7A0CEFB26F; Wed, 8 Dec 2004 21:16:41 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id CA836FB262 for ; Wed, 8 Dec 2004 21:16:40 +0000 (UTC) Message-ID: <05ad01c4dd6b$57571320$5d6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Tschofenig Hannes" , "Mohan Parthasarathy" , "Bill Sommerfeld" References: <2A8DB02E3018D411901B009027FD3A3F0542C9A0@mchp905a.mch.sbs.de> Subject: Re: [Mobike] Zero Address Set Date: Wed, 8 Dec 2004 13:17:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 > it seems that you would like to add a lifetime parameter to the ike sa (and > additionally suspend the dead peer detection for the indicated amount of > time). Actually, a lifeftime to the SA would be useful for other reasons. Suppose you've got an SA with your Mobile IPv6 Home Agent. It would be nice to know, if you go into dormant mode or shut down for power saving purposes, whether or not you have to re-run IKE when you come back up. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Dec 8 23:20:07 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00377 for ; Wed, 8 Dec 2004 23:20:05 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BA5F0FB281; Thu, 9 Dec 2004 04:20:06 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E325EFB266; Thu, 9 Dec 2004 04:20:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DBEB2FB26F; Thu, 9 Dec 2004 04:20:02 +0000 (UTC) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by machshav.com (Postfix) with ESMTP id 6295DFB262 for ; Thu, 9 Dec 2004 04:20:02 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iB94JxiI011334; Wed, 8 Dec 2004 20:20:00 -0800 (PST) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iB94Ju8p022168; Wed, 8 Dec 2004 23:19:57 -0500 (EST) Subject: Re: [Mobike] Zero Address Set From: Bill Sommerfeld To: jari.arkko@piuha.net In-Reply-To: <41B6DA98.8020504@piuha.net> References: <2A8DB02E3018D411901B009027FD3A3F0542C9A1@mchp905a.mch.sbs.de> <41B6DA98.8020504@piuha.net> Content-Type: text/plain Message-Id: <1102565965.14474.6.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 08 Dec 2004 23:19:26 -0500 Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Tschofenig Hannes 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 Wed, 2004-12-08 at 05:42, Jari Arkko wrote: > You could also see this function as orthogonal to MOBIKE, i.e., > another IKEv2 feature that can be used to temporarily suspend > all IKE and payload packet flows. I think the on-the-wire protocol representation falls out automatically from whatever mobike-defined IKE extension is used to add or delete addresses from the established IKE SA. end systems which don't implement this would treat this as a tunnel tear-down request. end systems which do implement it would "cap" the tunnel until the peer resumed, some implementation-specific timer expired, or administrative action deleted the tunnel. an end system implementing this would need to be able to cope with lost state on the peer anyway. - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 9 03:58:23 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03526 for ; Thu, 9 Dec 2004 03:58:22 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 78155FB27F; Thu, 9 Dec 2004 08:58:22 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D2A71FB266; Thu, 9 Dec 2004 08:58:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 83F85FB26F; Thu, 9 Dec 2004 08:58:19 +0000 (UTC) Received: from p130.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id E3953FB246 for ; Thu, 9 Dec 2004 08:58:18 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D89D689844; Thu, 9 Dec 2004 10:58:12 +0200 (EET) Message-ID: <41B8139D.8020700@piuha.net> Date: Thu, 09 Dec 2004 10:58:05 +0200 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: Mohan Parthasarathy Subject: Re: [Mobike] issue 3: nat traversal References: <2A8DB02E3018D411901B009027FD3A3F0542C99F@mchp905a.mch.sbs.de> <005701c4dd50$e3618dc0$861167c0@adithya> In-Reply-To: <005701c4dd50$e3618dc0$861167c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Tschofenig Hannes 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 Mohan Parthasarathy wrote: >>>Okay. Do we want to add the qualifier that MOBIKE needs to >>>work in a "secure" fashion when moving behind a NAT ? >>>(unlike IKEv2 which also supports NAT traversal but >>>susceptible to 3rd party bombing attacks). >> >>what is a "secure" nat traversal solution for you? >> > > The one that does not have the 3rd party bombing attack :-) > To put in a different way, MOBIKE's security should not > be altered, when moving behind a NAT. As we are > at the design stage, it might make sense to understand > what sort of NAT traversal solution we are going to > have. Right. And I want MOBIKE to be secure in this fashion. However, if we move behind a NAT, and our configuration allows such move, I think we pretty much have to downgrade the security to what NAT-T offers. Or do you see a way around that? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 9 05:59:39 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11779 for ; Thu, 9 Dec 2004 05:59:38 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 1E701FB27F; Thu, 9 Dec 2004 10:59:39 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5048FFB266; Thu, 9 Dec 2004 10:59:38 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A3BDDFB26F; Thu, 9 Dec 2004 10:59:37 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 4583CFB262 for ; Thu, 9 Dec 2004 10:59:36 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iB9AxMd11058; Thu, 9 Dec 2004 11:59:22 +0100 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 iB9AxLSj026596; Thu, 9 Dec 2004 11:59:21 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200412091059.iB9AxLSj026596@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE In-reply-to: Your message of Mon, 06 Dec 2004 10:16:18 +0100. <2A8DB02E3018D411901B009027FD3A3F0542C6B2@mchp905a.mch.sbs.de> Date: Thu, 09 Dec 2004 11:59:21 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , jari.arkko@piuha.net, 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 went thought about the two most important options: notify and vendor id they both seem to provide the same capability. notify is used for errors but also for indicating sender capabilities. the same is true for the vendor id. => it seems the IPsec WG was not in favor of vendor ids so I vote for notify. Note that the node could also attempt MOBIKE optimistically with the critical bit set to one when a movement has occurred. The drawback of this approach is, however, that the an unnecessary MOBIKE message round is introduced on the first movement. => IMHO the critical bit will simply kill the session when it is not supported (i.e., there is no recovery). This is why the idea to negociate MOBIKE support ASAP is the right one. BTW the discussion was between a new payload or a new exchange for SA updates (I believe the best is a new payload but I have no strong argument). 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 Dec 9 06:03:50 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12252 for ; Thu, 9 Dec 2004 06:03:49 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 4CA8DFB279; Thu, 9 Dec 2004 11:03:50 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 704D3FB266; Thu, 9 Dec 2004 11:03:49 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DE0B6FB26F; Thu, 9 Dec 2004 11:03:47 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id D04BDFB262 for ; Thu, 9 Dec 2004 11:03:46 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iB9B3fd11315; Thu, 9 Dec 2004 12:03:41 +0100 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 iB9B3fSj026648; Thu, 9 Dec 2004 12:03:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200412091103.iB9B3fSj026648@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] issue 3: nat traversal In-reply-to: Your message of Mon, 06 Dec 2004 21:56:38 +0200. <41B4B976.1080801@piuha.net> Date: Thu, 09 Dec 2004 12:03:41 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Tschofenig Hannes 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: - NAT prevention can be provided by MOBIKE if people want to put that in (but that seems to be outside the original scope of this issue) => NAT prevention is very useful by its side effect: protect the peer addresses by reflecting them in the content of IKE messages. So this is more important than one can believe reading your mail... 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 Dec 9 07:03:23 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16134 for ; Thu, 9 Dec 2004 07:03:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7C3C7FB280; Thu, 9 Dec 2004 12:03:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C6B00FB266; Thu, 9 Dec 2004 12:03:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 06333FB26F; Thu, 9 Dec 2004 12:03:21 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id E33B0FB262 for ; Thu, 9 Dec 2004 12:03:19 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iB9C3Ieh013850; Thu, 9 Dec 2004 13:03:18 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iB9C3IRt017410; Thu, 9 Dec 2004 13:03:18 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Dec 2004 13:03:17 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550AE27@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Mohan Parthasarathy , jari.arkko@piuha.net Subject: RE: [Mobike] issue 3: nat traversal Date: Thu, 9 Dec 2004 13:03:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi mohan, thanks for your feedback on this isuse. please see my comments inline: ~snip~ > > what is a "secure" nat traversal solution for you? > > > The one that does not have the 3rd party bombing attack :-) > To put in a different way, MOBIKE's security should not be > altered, when moving behind a NAT. please consider the following picture: +------------+ private public +------------+ | Initiator | *~~~~~~~~~* | Responder | | | * NAT * | | | 192.168.1.2+---------+192.<--->3.1 +--Internet+ 4.2 | | | |168. | | | | | | 1.1 | | | | | * * | | +------------+ *~~~~~~~~~* +------------+ if the initiator (who might be behind the nat) has to securely provide the responder with its IP address then the initator needs to securely retrieve its public ip address (and possibly port) from the nat since the initiator cannot add its private ip address to the ikev2/mobike exchange (for obvious reasons). this is the reason why we use the outer ip address header to learn to what ip address the nat has changed the private address of the initiator. protecting the address as part of the ikev2/mobike exchange is the goal to ensure that it cannot be modified by a nat along the path. however, this requires a protocol to securely learn the nat binding from the nat. this is exactly what nsis tries to provide with the nat/firewall nslp. the drawback is that you a) need another protocol b) need the nat to understand nsis (since a regular nat does not provide this functionality). if you, however, know that there will be no nat along the path then you can use the suggested nat prevention mechanism. > As we are at the design > stage, it might make sense to understand what sort of NAT > traversal solution we are going to have. > certainly. i think makes a first step into this direction. i agree that we should spend some more lines to explain these issues. > > > > > > > > > Its true that the we have a restriction that we should > not modify > > > > IKEv2 NAT traversal. My advice is not to focus too much on this > > > > question. Lets do what it makes technical sense. I do not > > > think any of > > > > the current proposals modify NAT-T, even if we can perhaps > > > provide a > > > > new stage in the protocol when it is turned on (not just in the > > > > initial contact). So lets not worry about this part. > > > > > > > Note that none of the current proposals support NAT traversal. > > > From what i have read, they only have a prevention mechanism. > > > > > i got a different impression. see for example, > > - > > This one trivially supports it by the virtue of using IKEv2 NAT-T. which already provides a lot in my opinion! > > > - > > > I have to read this again. But last time i read it, it was > not still not completely secure. Perhaps, it is sufficient. > But i am not sure we have a consensus on what level of > security we want. please send comments to the list if you think that something has to be improved. ciao hannes > > -mohan > > > ciao > > hannes > > > > > -mohan > > > > > > > --Jari > > > > _______________________________________________ > > > > Mobike mailing list > > > > Mobike@machshav.com > > > > https://www.machshav.com/mailman/listinfo.cgi/mobike > > > > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 9 07:43:42 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17736 for ; Thu, 9 Dec 2004 07:43:40 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3BA35FB27F; Thu, 9 Dec 2004 12:43:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 222FFFB266; Thu, 9 Dec 2004 12:43:39 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 39EFDFB26F; Thu, 9 Dec 2004 12:43:38 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id F3DB4FB262 for ; Thu, 9 Dec 2004 12:43:36 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iB9ChVd18309; Thu, 9 Dec 2004 13:43:31 +0100 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 iB9ChVSj026984; Thu, 9 Dec 2004 13:43:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200412091243.iB9ChVSj026984@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] issue 3: nat traversal In-reply-to: Your message of Wed, 08 Dec 2004 10:08:15 PST. <005701c4dd50$e3618dc0$861167c0@adithya> Date: Thu, 09 Dec 2004 13:43:31 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Tschofenig Hannes 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: > what is a "secure" nat traversal solution for you? The one that does not have the 3rd party bombing attack :-) To put in a different way, MOBIKE's security should not be altered, when moving behind a NAT. As we are at the design stage, it might make sense to understand what sort of NAT traversal solution we are going to have. => to avoid the intrinsic security issue (i.e., the 3rd party bombing attack) of NAT traversal is very hard, and IMHO impossible without modifying NATs and/or NAT traversal. > > Note that none of the current proposals support NAT traversal. > > From what i have read, they only have a prevention mechanism. => NAT prevention is important for security as I explained in a previous message, and it "solves" the NAT traversal problem too. IMHO we should only give the choice between NAT traversal and MOBIKE, i.e., MOBIKE should only detect the "just move behind a NAT" case, and should *not* try to handle it (i.e., the case will be considered as misconfiguration). 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 Dec 9 07:50:38 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18281 for ; Thu, 9 Dec 2004 07:50:36 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8C0DCFB283; Thu, 9 Dec 2004 12:50:36 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4663FFB26F; Thu, 9 Dec 2004 12:50:35 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 03E97FB279; Thu, 9 Dec 2004 12:50:34 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id 10960FB266 for ; Thu, 9 Dec 2004 12:50:33 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iB9CoV4A023414; Thu, 9 Dec 2004 13:50:31 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iB9CoURt004648; Thu, 9 Dec 2004 13:50:30 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Dec 2004 13:50:30 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550AE43@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Francis Dupont , Mohan Parthasarathy Subject: RE: [Mobike] issue 3: nat traversal Date: Thu, 9 Dec 2004 13:50:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: jari.arkko@piuha.net, 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 hi francis, ~snip~ > > => NAT prevention is important for security as I explained in > a previous message, and it "solves" the NAT traversal problem too. > IMHO we should only give the choice between NAT traversal and > MOBIKE, i.e., MOBIKE should only detect the "just move behind > a NAT" case, and should *not* try to handle it (i.e., the > case will be considered as misconfiguration). > nat prevention does not solve the nat traversal problem, obviously. we should give people the possibility to (a) allow the responder to use the ip address contained in the ike message AND (b) allow the responder to use ip address information in the header to derive some decisions. detecting only that you are behind a nat is insufficient to address all scenarios people are looking at. ciao hannes _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 9 07:50:45 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18299 for ; Thu, 9 Dec 2004 07:50:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 4F60AFB289; Thu, 9 Dec 2004 12:50:44 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3DFC0FB27F; Thu, 9 Dec 2004 12:50:42 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F417BFB284; Thu, 9 Dec 2004 12:50:39 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 5659EFB279 for ; Thu, 9 Dec 2004 12:50:35 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iB9CoTd18807; Thu, 9 Dec 2004 13:50:29 +0100 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 iB9CoTSj027029; Thu, 9 Dec 2004 13:50:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200412091250.iB9CoTSj027029@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] When to do Return Routability Checks In-reply-to: Your message of Mon, 06 Dec 2004 13:02:57 +0100. <2A8DB02E3018D411901B009027FD3A3F0542C72B@mchp905a.mch.sbs.de> Date: Thu, 09 Dec 2004 13:50:29 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr 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 In your previous mail you wrote: discussions during the ietf meeting (see issue tracker web page) concluded that it is a policy issue when to perform the return routability checks. this conclusion seems to be fine with me. i will try to produce a new text proposal. => this is my position but there is an exception: the update is to an authorized* address but from an unknown address. A RR check should be performed in this case, not because of a security issue, but because the node can have just moved behind a NAT (the RR check for the authorized address fails, the RR check for the unknown (in fact NATed) address succeeds). *I use the term "authorized" in order to keep the policy decision to the peer, i.e., the RR check can be a part of the authorization procedure. 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 Dec 9 07:53:28 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18467 for ; Thu, 9 Dec 2004 07:53:26 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6A505FB283; Thu, 9 Dec 2004 12:53:26 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0C08DFB279; Thu, 9 Dec 2004 12:53:25 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0A8EEFB27F; Thu, 9 Dec 2004 12:53:24 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id EFA84FB266 for ; Thu, 9 Dec 2004 12:53:22 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iB9CrDd18996; Thu, 9 Dec 2004 13:53:13 +0100 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 iB9CrESj027074; Thu, 9 Dec 2004 13:53:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200412091253.iB9CrESj027074@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] When to do Return Routability Checks In-reply-to: Your message of Mon, 06 Dec 2004 22:48:46 +0200. <41B4C5AE.9080302@piuha.net> Date: Thu, 09 Dec 2004 13:53:14 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Tschofenig Hannes 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. For the do it all, I think the answer depends on configured policy, with default being yes. For the when part, I think it should be done prior to moving the SA and the data stream towards that address. => we need more flexibility about moving the SA: to wait the RR check result is fine only when the previous peer address is still usable. 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 Dec 9 07:54:09 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18523 for ; Thu, 9 Dec 2004 07:54:07 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BA569FB27F; Thu, 9 Dec 2004 12:54:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DC0A0FB279; Thu, 9 Dec 2004 12:54:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1AC40FB27F; Thu, 9 Dec 2004 12:54:02 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 31FE1FB266 for ; Thu, 9 Dec 2004 12:54:01 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iB9Crxeh032604; Thu, 9 Dec 2004 13:53:59 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iB9CrxRt009202; Thu, 9 Dec 2004 13:53:59 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Dec 2004 13:53:59 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550AE47@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Francis Dupont Subject: RE: [Mobike] When to do Return Routability Checks Date: Thu, 9 Dec 2004 13:53:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi francis, > In your previous mail you wrote: > > discussions during the ietf meeting (see issue tracker web > page) concluded > that it is a policy issue when to perform the return > routability checks. > this conclusion seems to be fine with me. i will try to > produce a new text > proposal. > > => this is my position but there is an exception: the update > is to an authorized* address but from an unknown address. A > RR check should be performed in this case, not because of a > security issue, but because the node can have just moved > behind a NAT (the RR check for the authorized address fails, > the RR check for the unknown (in fact NATed) address succeeds). i have read this paragraph several times but i am not quite sure that i understood it. a picture might help.... ciao hannes > > *I use the term "authorized" in order to keep the policy > decision to the peer, i.e., the RR check can be a part of the > authorization procedure. > > 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 Dec 9 07:58:52 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18747 for ; Thu, 9 Dec 2004 07:58:51 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 03847FB282; Thu, 9 Dec 2004 12:58:51 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 88E22FB279; Thu, 9 Dec 2004 12:58:50 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C0E71FB27F; Thu, 9 Dec 2004 12:58:48 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id B3836FB266 for ; Thu, 9 Dec 2004 12:58:47 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iB9Cwj4A031638; Thu, 9 Dec 2004 13:58:45 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iB9CwjRt014732; Thu, 9 Dec 2004 13:58:45 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Dec 2004 13:58:45 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550AE4B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Francis Dupont , jari.arkko@piuha.net Subject: RE: [Mobike] When to do Return Routability Checks Date: Thu, 9 Dec 2004 13:58:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi again, this answer is again cryptic. where would you like to see more flexibility? >to wait the > RR check result is fine only when the previous peer address > is still usable. would you like to add some else cases? ciao hannes > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Donnerstag, 09. Dezember 2004 13:53 > To: jari.arkko@piuha.net > Cc: Tschofenig Hannes; mobike@machshav.com > Subject: Re: [Mobike] When to do Return Routability Checks > > In your previous mail you wrote: > > Yes. For the do it all, I think the answer depends on > configured policy, > with default being yes. For the when part, I think it > should be done > prior to moving the SA and the data stream towards that address. > > => we need more flexibility about moving the SA: to wait the > RR check result is fine only when the previous peer address > is still usable. > > 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 Dec 9 08:06:07 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19191 for ; Thu, 9 Dec 2004 08:06:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7A487FB28D; Thu, 9 Dec 2004 13:06:06 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 016F8FB289; Thu, 9 Dec 2004 13:06:06 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 63BCAFB28A; Thu, 9 Dec 2004 13:06:04 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 1346DFB286 for ; Thu, 9 Dec 2004 13:06:03 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iB9D5vd20386; Thu, 9 Dec 2004 14:05:57 +0100 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 iB9D5vSj027166; Thu, 9 Dec 2004 14:05:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200412091305.iB9D5vSj027166@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] issue 1: direct or indirect indicators In-reply-to: Your message of Mon, 06 Dec 2004 17:42:06 +0100. <2A8DB02E3018D411901B009027FD3A3F0542C7F9@mchp905a.mch.sbs.de> Date: Thu, 09 Dec 2004 14:05:57 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr 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 In your previous mail you wrote: a separate question but also of interest: - should a peer send an address list in one message or individual messages (which only contain one address/message)? (the address list does not work in a nat environment.) answer: both seems to be desired. => as I don't like the idea to mix MOBIKE and NAT-T I am in favor of one message which can be submitted to the authorization procedure once and gives less exchanges. Of course this doesn't make the one address/message impossible. - should the individual address be part of the protected payload or taken from info of the header? answer: both is desired (depending on whether nat traversal is desired or not) => from info: the header is not protected... In fact the header is only interesting for indirect indication, for instance using an unknown address in the header... - should the address list be idempotent or not? answer: this is still an open issue. always resending the full list (idempotent operation) requires more bandwidth but avoid synchonization issue which needs to be addressed. , for example, seems to offer an approach which defines add/delete operations. => you already know my opinion (:-). there is little doubt that a mobike protocol needs some mechanisms that allows one peer to inform the other peer about address changes. (direct indications) => I can't parse your idea: it is needed or not? address lists are a separate issue and a performance aspect. with some respect address lists (as traffic selectors are already supported in ikev2) which allow multiple ipsec sas to be established with one child-sa exchange. => this is another issue and depends on the environmen (i.e., not interesting for mobility but very useful for multi-homing and SCTP). if ipsec sas should be modified without using a new child sa exchange then they might use address lists again or one message exchange per traffic selector. => the address update is about peer addresses, *not* traffic selectors. 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 Dec 9 08:16:28 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20221 for ; Thu, 9 Dec 2004 08:16:28 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 038E0FB28A; Thu, 9 Dec 2004 13:16:28 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4DC00FB26F; Thu, 9 Dec 2004 13:16:26 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 531BCFB280; Thu, 9 Dec 2004 13:16:25 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 430C9FB262 for ; Thu, 9 Dec 2004 13:16:24 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iB9DGMeh023140; Thu, 9 Dec 2004 14:16:22 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iB9DGMRt004294; Thu, 9 Dec 2004 14:16:22 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Dec 2004 14:16:22 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550AE5B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Francis Dupont Subject: RE: [Mobike] issue 1: direct or indirect indicators Date: Thu, 9 Dec 2004 14:16:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi francis, thanks for the response. please see my comments below: > In your previous mail you wrote: > > a separate question but also of interest: > - should a peer send an address list in one message or > individual messages > (which only contain one address/message)? > (the address list does not work in a nat environment.) > answer: both seems to be desired. > > => as I don't like the idea to mix MOBIKE and NAT-T I am in > favor of one message which can be submitted to the > authorization procedure once and gives less exchanges. Of > course this doesn't make the one address/message impossible. having an address list in the ike message makes nat handling impossible. > > - should the individual address be part of the protected > payload or taken > from info of the header? > answer: both is desired (depending on whether nat > traversal is desired or > not) > > => from info: the header is not protected... In fact the > header is only interesting for indirect indication, for > instance using an unknown address in the header... we know that the header is not protected. that is the place where the nat handling comes into the picture. we are aware of the limitation (and the same is true for the base ikev2 specification). > > - should the address list be idempotent or not? > answer: this is still an open issue. always resending > the full list > (idempotent operation) requires more bandwidth but avoid > synchonization > issue which needs to be addressed. > , for > example, seems to offer an approach which defines > add/delete operations. > > => you already know my opinion (:-). yes, i do. > > there is little doubt that a mobike protocol needs some > mechanisms that > allows one peer to inform the other peer about address > changes. (direct > indications) > > => I can't parse your idea: it is needed or not? this issue was related to the issue described on the webpage. forget about it. > > address lists are a separate issue and a performance > aspect. with some > respect address lists (as traffic selectors are already > supported in ikev2) > which allow multiple ipsec sas to be established with one > child-sa exchange. > > => this is another issue and depends on the environmen (i.e., > not interesting for mobility but very useful for multi-homing > and SCTP). i know. (see rfc 3554) ciao hannes > > if ipsec sas should be modified without using a new child > sa exchange then > they might use address lists again or one message exchange > per traffic > selector. > > => the address update is about peer addresses, *not* traffic > selectors. > > 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 Dec 9 17:58:52 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24690 for ; Thu, 9 Dec 2004 17:58:51 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6F7F5FB281; Thu, 9 Dec 2004 22:58:52 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6E1CDFB279; Thu, 9 Dec 2004 22:58:51 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6498FFB27F; Thu, 9 Dec 2004 22:58:49 +0000 (UTC) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id C90CDFB266 for ; Thu, 9 Dec 2004 22:58:48 +0000 (UTC) Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iB9MujQ11781; Thu, 9 Dec 2004 14:56:45 -0800 (PST) Message-ID: <41B8D7B3.4040701@isi.edu> Date: Thu, 09 Dec 2004 14:54:43 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes Subject: Re: [Mobike] issue #16 References: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tschofenig Hannes wrote: | hi all, | | i guess we can close issue # 16: | "Can the protocol recover from situations where the only sign of problems is | lack of packets from the other end?" | http://www.vpnc.org/ietf-mobike/issue16.txt Internet paths that are silent aren't problems, IMO. They're just idle network paths. This sounds like a job for a link layer, and I don't think mobike needs to be a link layer. Joe | as a conclusion of the discussions we said: | | - mobike defines a mechanism to test connectivity along paths. | - both peers might use input from other sources to detect a failure (e.g., a | local link failure) | - based on this information mobike might decide to switch to a new address | (if available). | | ciao | hannes | _______________________________________________ | Mobike mailing list | Mobike@machshav.com | https://www.machshav.com/mailman/listinfo.cgi/mobike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBuNezE5f5cImnZrsRAlRKAJ45hue31XWR2Gklfxm13vDYtHVX1QCfU86E SmA7ZmLlf47460z4d07E/OA= =KIh/ -----END PGP SIGNATURE----- _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 9 18:40:10 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28670 for ; Thu, 9 Dec 2004 18:40:09 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7A34FFB285; Thu, 9 Dec 2004 23:40:11 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DED43FB281; Thu, 9 Dec 2004 23:40:10 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EE3EEFB283; Thu, 9 Dec 2004 23:40:09 +0000 (UTC) Received: from smtp819.mail.sc5.yahoo.com (smtp819.mail.sc5.yahoo.com [66.163.170.5]) by machshav.com (Postfix) with SMTP id AB6CAFB27F for ; Thu, 9 Dec 2004 23:40:08 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp819.mail.sc5.yahoo.com with SMTP; 9 Dec 2004 23:40:08 -0000 Message-ID: <00dc01c4de48$69b04db0$861167c0@adithya> From: "Mohan Parthasarathy" To: References: <2A8DB02E3018D411901B009027FD3A3F0542C99F@mchp905a.mch.sbs.de><005701c4dd50$e3618dc0$861167c0@adithya> <41B8139D.8020700@piuha.net> Subject: Re: [Mobike] issue 3: nat traversal Date: Thu, 9 Dec 2004 15:40:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: MOBIKE Mailing List , Tschofenig Hannes 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 wrote: > > >>>Okay. Do we want to add the qualifier that MOBIKE needs to > >>>work in a "secure" fashion when moving behind a NAT ? > >>>(unlike IKEv2 which also supports NAT traversal but > >>>susceptible to 3rd party bombing attacks). > >> > >>what is a "secure" nat traversal solution for you? > >> > > > > The one that does not have the 3rd party bombing attack :-) > > To put in a different way, MOBIKE's security should not > > be altered, when moving behind a NAT. As we are > > at the design stage, it might make sense to understand > > what sort of NAT traversal solution we are going to > > have. > > Right. And I want MOBIKE to be secure in this fashion. > However, if we move behind a NAT, and our configuration > allows such move, I think we pretty much have to downgrade > the security to what NAT-T offers. Or do you see a way > around that? > There may be a way around that. The node that moved behind the NAT should include the NAT public address in the address change message sent to the other end. Then the other end can know what to expect in the IP headers. This is what i presented in IETF 60. There are two ssues here (Perhaps there are more). 1) How does the end node discover the public address securely ? 2) If the public address is known, how does the node communicate this to the other end securely ? I am wondering whether these two things can be seen separately. Let us assume that the NAT discovered the public address securely (either physical security or DHCP security etc.). If not, the attacker can attack anything he wants, not just MOBIKE. In some environments (1) may be easy e.g. i know what public address my NAT uses at home. Or perhaps DHCP can be used to convey this information in a secure way. Perhaps there are others which i am not aware of. Would it make sense to provide a mechanism in MOBIKE to carry the NAT public address assuming it was discovered outside ? If the address is not discovered securely, then it boils down to the same level of security as the current IKEv2 NAT-T. -mohan > --Jari > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Dec 10 04:37:30 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27393 for ; Fri, 10 Dec 2004 04:37:29 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 74C61FB285; Fri, 10 Dec 2004 09:37:30 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8B6A1FB281; Fri, 10 Dec 2004 09:37:29 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0A030FB283; Fri, 10 Dec 2004 09:37:28 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id D234DFB27F for ; Fri, 10 Dec 2004 09:37:26 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iBA9amC25726; Fri, 10 Dec 2004 10:36:48 +0100 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 iBA9afSj030675; Fri, 10 Dec 2004 10:36:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200412100936.iBA9afSj030675@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] issue 3: nat traversal In-reply-to: Your message of Thu, 09 Dec 2004 13:50:28 +0100. <2A8DB02E3018D411901B009027FD3A3F0550AE43@mchp905a.mch.sbs.de> Date: Fri, 10 Dec 2004 10:36:41 +0100 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: > => NAT prevention is important for security as I explained in > a previous message, and it "solves" the NAT traversal problem too. > IMHO we should only give the choice between NAT traversal and > MOBIKE, i.e., MOBIKE should only detect the "just move behind > a NAT" case, and should *not* try to handle it (i.e., the > case will be considered as misconfiguration). nat prevention does not solve the nat traversal problem, obviously. => it depends of your meaning of "solve" as with NAT prevention you can't get a NAT traversal problem... we should give people the possibility to (a) allow the responder to use the ip address contained in the ike message AND (b) allow the responder to use ip address information in the header to derive some decisions. => my opinion is than (b) is restricted to detect spurious NATs in the path: either we use NAT prevention and MOBIKE or we use NAT traversal. I don't believe the MOBIKE WG should invent a new NAT traversal mechanism (note that I am not against the idea of a new and more secure NAT traversal, just that this is not in the scope of the MOBIKE WG). detecting only that you are behind a nat is insufficient to address all scenarios people are looking at. => we have to decide one day if NAT traversal is in the scope: 1- just make NAT traversal and MOBIKE two separate solutions 2- include a new NAT traversal in the charter 3- try to merge current NAT traversal with MOBIKE My opinion is 1- is fine and NAT prevention makes the choice clear, 2- is currently out of the charter and 3- can't work without 2-, so the best solution is 1-. Note that if NAT traversal is not very secure it is reasonably secure when implicit SA update is supported and it was already accepted... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Dec 10 04:52:16 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28168 for ; Fri, 10 Dec 2004 04:52:15 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2B4E6FB286; Fri, 10 Dec 2004 09:52:17 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2FA4EFB281; Fri, 10 Dec 2004 09:52:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E070EFB283; Fri, 10 Dec 2004 09:52:13 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id ADBB3FB27F for ; Fri, 10 Dec 2004 09:52:12 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iBA9q4C26581; Fri, 10 Dec 2004 10:52:04 +0100 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 iBA9q4Sj030758; Fri, 10 Dec 2004 10:52:04 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200412100952.iBA9q4Sj030758@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] When to do Return Routability Checks In-reply-to: Your message of Thu, 09 Dec 2004 13:53:57 +0100. <2A8DB02E3018D411901B009027FD3A3F0550AE47@mchp905a.mch.sbs.de> Date: Fri, 10 Dec 2004 10:52:04 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr 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 In your previous mail you wrote: > => this is my position but there is an exception: the update > is to an authorized* address but from an unknown address. A > RR check should be performed in this case, not because of a > security issue, but because the node can have just moved > behind a NAT (the RR check for the authorized address fails, > the RR check for the unknown (in fact NATed) address succeeds). i have read this paragraph several times but i am not quite sure that i understood it. => I apologize. I tried many times to write a good text but without success. So another tentative: - the peer address set is known, each peer address has been authorized - there are many ways to authorize an address, RR check can be one of these ways - an update can be done only to an authorized peer address (if the peer address is not yet authorized, it must be authorized before the application of the update) - an unknown peer address is an address which is not (was never) in the peer address test - usually the peer registers (i.e., add in its announced peer address set) the address it uses for IKE messages but we can extend the previous statement with "or was never used as the source of an IKE message" So you get an update for an authorized/to-be-authorized peer address in a message from an unknown source address: I argue that both addresses (the one in the header and the one in the message) must be RR checked because the initiator can have just moved behind a NAT. Can you reply if you have understood and propose a better explaination? Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Dec 10 05:05:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28900 for ; Fri, 10 Dec 2004 05:05:29 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 20758FB286; Fri, 10 Dec 2004 10:05:31 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 990CDFB281; Fri, 10 Dec 2004 10:05:29 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 65130FB283; Fri, 10 Dec 2004 10:05:28 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 4CC06FB27F for ; Fri, 10 Dec 2004 10:05:27 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iBAA5FC27602; Fri, 10 Dec 2004 11:05:15 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iBAA5ASj030826; Fri, 10 Dec 2004 11:05:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200412101005.iBAA5ASj030826@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] When to do Return Routability Checks In-reply-to: Your message of Thu, 09 Dec 2004 13:58:43 +0100. <2A8DB02E3018D411901B009027FD3A3F0550AE4B@mchp905a.mch.sbs.de> Date: Fri, 10 Dec 2004 11:05:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, 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: > => we need more flexibility about moving the SA: to wait the > RR check result is fine only when the previous peer address > is still usable. => there are two cases when we move from peer address A to peer address B: - peer address A is still usable: the IKE SA should be updated only after the end of the RR check - peer address A is no more usable (the usual case with mobility): the IKE SA (but not IPsec SAs) should be updated at the reception of the update request Two details: - there is scenario where ASAP update is mandatory: imagine an window of one message is used and there is a pending request to send: if it is sent to the peer address A and this address no more works the exchange will never finish. - now how to know when an address is no more usable: with my address management framework the initiator wll simply remove it from the set. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Dec 10 05:13:37 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29757 for ; Fri, 10 Dec 2004 05:13:36 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 393B6FB289; Fri, 10 Dec 2004 10:13:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0C14EFB283; Fri, 10 Dec 2004 10:13:36 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7B1C9FB284; Fri, 10 Dec 2004 10:13:34 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 5AFD8FB281 for ; Fri, 10 Dec 2004 10:13:33 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iBAADSC28196; Fri, 10 Dec 2004 11:13:28 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iBAADSSj030877; Fri, 10 Dec 2004 11:13:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200412101013.iBAADSSj030877@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tschofenig Hannes Subject: Re: [Mobike] issue 1: direct or indirect indicators In-reply-to: Your message of Thu, 09 Dec 2004 14:16:19 +0100. <2A8DB02E3018D411901B009027FD3A3F0550AE5B@mchp905a.mch.sbs.de> Date: Fri, 10 Dec 2004 11:13:28 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr 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 In your previous mail you wrote: > In your previous mail you wrote: > > a separate question but also of interest: > - should a peer send an address list in one message or > individual messages > (which only contain one address/message)? > (the address list does not work in a nat environment.) > answer: both seems to be desired. > > => as I don't like the idea to mix MOBIKE and NAT-T I am in > favor of one message which can be submitted to the > authorization procedure once and gives less exchanges. Of > course this doesn't make the one address/message impossible. having an address list in the ike message makes nat handling impossible. => now I see: you speak about the first message when I speak about NAT prevention in the first message and address list in the next exchange. I've already explained this but I used NAT prevention for two purposes: - make the choice between either NAT traversal and MOBIKE clear - inject the peer addresses from the header into a protected space BTW the first point is Pasi's idea, and it has the extra advantage to be outside of the NAT traversal IPR. 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 Tue Dec 14 06:52:35 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16086 for ; Tue, 14 Dec 2004 06:52:34 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2ED6EFB291; Tue, 14 Dec 2004 11:52:35 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C6513FB28E; Tue, 14 Dec 2004 11:52:31 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 45CAAFB28F; Tue, 14 Dec 2004 11:52:31 +0000 (UTC) Received: from p130.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 3F530FB28B for ; Tue, 14 Dec 2004 11:52:30 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1BCE58989F; Tue, 14 Dec 2004 13:52:26 +0200 (EET) Message-ID: <41BED3EB.6080304@piuha.net> Date: Tue, 14 Dec 2004 13:52:11 +0200 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 Subject: Re: [Mobike] issue 1: direct or indirect indicators References: <200412101013.iBAADSSj030877@givry.rennes.enst-bretagne.fr> In-Reply-To: <200412101013.iBAADSSj030877@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: > > > In your previous mail you wrote: > > > > a separate question but also of interest: > > - should a peer send an address list in one message or > > individual messages > > (which only contain one address/message)? > > (the address list does not work in a nat environment.) > > answer: both seems to be desired. > > > > => as I don't like the idea to mix MOBIKE and NAT-T I am in > > favor of one message which can be submitted to the > > authorization procedure once and gives less exchanges. Of > > course this doesn't make the one address/message impossible. > > having an address list in the ike message makes nat handling impossible. > > => now I see: you speak about the first message when I speak about > NAT prevention in the first message and address list in the next > exchange. > I've already explained this but I used NAT prevention for two purposes: > - make the choice between either NAT traversal and MOBIKE clear > - inject the peer addresses from the header into a protected space Right. This is very good. > BTW the first point is Pasi's idea, and it has the extra advantage > to be outside of the NAT traversal IPR. (Lets not assume too much about the IPR coverage. That's a tricky field. You never know how broad the IPR claims are, particularly if you consider that not all IPR may be public yet.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 14 09:26:26 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01152 for ; Tue, 14 Dec 2004 09:26:25 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2A43CFB292; Tue, 14 Dec 2004 14:26:22 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 04933FB28E; Tue, 14 Dec 2004 14:26:19 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 75873FB28F; Tue, 14 Dec 2004 14:26:17 +0000 (UTC) Received: from p130.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 94D6BFB28B for ; Tue, 14 Dec 2004 14:26:16 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F264B8989A; Tue, 14 Dec 2004 16:26:12 +0200 (EET) Message-ID: <41BEF7F5.6060409@piuha.net> Date: Tue, 14 Dec 2004 16:25:57 +0200 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 Subject: Re: [Mobike] issue 3: nat traversal References: <200412100936.iBA9afSj030675@givry.rennes.enst-bretagne.fr> In-Reply-To: <200412100936.iBA9afSj030675@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Mohan Parthasarathy , MOBIKE Mailing List , Tschofenig Hannes 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: > nat prevention does not solve the nat traversal problem, obviously. > > => it depends of your meaning of "solve" as with NAT prevention you > can't get a NAT traversal problem... Right. > we should give people the possibility to > (a) allow the responder to use the ip address contained in the ike message > AND > (b) allow the responder to use ip address information in the header > to derive some decisions. > > => my opinion is than (b) is restricted to detect spurious NATs in the path: > either we use NAT prevention and MOBIKE or we use NAT traversal. > I don't believe the MOBIKE WG should invent a new NAT traversal mechanism > (note that I am not against the idea of a new and more secure NAT traversal, > just that this is not in the scope of the MOBIKE WG). > > detecting only that you are behind a nat is insufficient to address all > scenarios people are looking at. > > => we have to decide one day if NAT traversal is in the scope: > 1- just make NAT traversal and MOBIKE two separate solutions > 2- include a new NAT traversal in the charter > 3- try to merge current NAT traversal with MOBIKE > My opinion is 1- is fine and NAT prevention makes the choice clear, > 2- is currently out of the charter and 3- can't work without 2-, > so the best solution is 1-. Note that if NAT traversal is not very > secure it is reasonably secure when implicit SA update is supported > and it was already accepted... I believe we have consensus in the WG that there has to be some level of interworking with MOBIKE and NAT-T beyond complete separation. I wouldn't necessarily worry too much about the charter. It only says that we should not modify NAT-T. We can still work with it. But yes, a new more secure NAT-T is probably outside the charter. As a practical suggestion, MOBIKE could use either NAT-D (NAT Detection) or NAT-P (NAT Prevention) upon attempting to use a new address and if a NAT is detected in the former case, downgrades security (for that movement) to NAT-T. What else do we need? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 14 09:47:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03225 for ; Tue, 14 Dec 2004 09:47:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 120E7FB291; Tue, 14 Dec 2004 14:47:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5476BFB28E; Tue, 14 Dec 2004 14:47:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 74999FB28F; Tue, 14 Dec 2004 14:47:12 +0000 (UTC) Received: from p130.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 6F65DFB28B for ; Tue, 14 Dec 2004 14:47:11 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 853D58989A; Tue, 14 Dec 2004 16:47:10 +0200 (EET) Message-ID: <41BEFCDF.4010402@piuha.net> Date: Tue, 14 Dec 2004 16:46:55 +0200 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: Tschofenig Hannes Subject: Re: [Mobike] issue #16 References: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> 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 This issue is by the way related to #17, where we decided that we do not assume all pairs of addresses have connectivity. I believe the difference between #17 and #16 is that #17 talks about the connectivity upon an address change; #16 talks about whether we test/react if a currently used path goes broken in a silent way. I think what you say below is pretty much correct. I would add that we really have logically two separate tests: (1) The one that we use when we search for a new path; I feel that MOBIKE needs to define this although there was some discussion about whether we should wait for some other WG to develop it for us. But this is in the domain of issue #17 more than for #16. (2) The one that we use to test that the path is still alive. This we already have in IKEv2, its called DPD. Or do you see why DPD could not be used? And yes, we there seemed to be agreement in DC that the path choice decisions of MOBIKE are influenced by multiple sources, such as what DHCP/DNA/ND/L2 tell us, as well as what DPD tells us. --Jari Tschofenig Hannes wrote: > hi all, > > i guess we can close issue # 16: > "Can the protocol recover from situations where the only sign of problems is > lack of packets from the other end?" > http://www.vpnc.org/ietf-mobike/issue16.txt > > as a conclusion of the discussions we said: > > - mobike defines a mechanism to test connectivity along paths. > - both peers might use input from other sources to detect a failure (e.g., a > local link failure) > - based on this information mobike might decide to switch to a new address > (if available). _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 14 09:51:03 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03685 for ; Tue, 14 Dec 2004 09:51:01 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DA32EFB291; Tue, 14 Dec 2004 14:51:01 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ECEBFFB28E; Tue, 14 Dec 2004 14:50:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DC457FB28F; Tue, 14 Dec 2004 14:50:57 +0000 (UTC) Received: from p130.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 54DC8FB28B for ; Tue, 14 Dec 2004 14:50:57 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6A9AC8989A; Tue, 14 Dec 2004 16:50:56 +0200 (EET) Message-ID: <41BEFDC1.8020500@piuha.net> Date: Tue, 14 Dec 2004 16:50:41 +0200 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: Joe Touch Subject: Re: [Mobike] issue #16 References: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> <41B8D7B3.4040701@isi.edu> In-Reply-To: <41B8D7B3.4040701@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Tschofenig Hannes 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 Joe Touch wrote: > Internet paths that are silent aren't problems, IMO. They're just idle > network paths. Yes. > This sounds like a job for a link layer, and I don't think mobike needs > to be a link layer. The link layer certainly has its own mechanisms, as does IP on top of it (e.g. IPv6 NUD). But these are for a link, what we are talking about here is a path through the Internet. More specifically, the question is what to do if IKEv2 DPD tells us that its not getting through. Should we (a) kill the connection or (b) switch to another address we have? I think the latter... --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 14 09:56:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04125 for ; Tue, 14 Dec 2004 09:56:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 567BEFB293; Tue, 14 Dec 2004 14:56:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 19EEAFB28E; Tue, 14 Dec 2004 14:56:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 92003FB28F; Tue, 14 Dec 2004 14:56:12 +0000 (UTC) Received: from p130.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 05BDFFB28B for ; Tue, 14 Dec 2004 14:56:12 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 19F158989A; Tue, 14 Dec 2004 16:56:11 +0200 (EET) Message-ID: <41BEFEFB.3050902@piuha.net> Date: Tue, 14 Dec 2004 16:55:55 +0200 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 Subject: Re: [Mobike] When to do Return Routability Checks References: <200412091253.iB9CrESj027074@givry.rennes.enst-bretagne.fr> In-Reply-To: <200412091253.iB9CrESj027074@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Tschofenig Hannes 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: > > Yes. For the do it all, I think the answer depends on configured policy, > with default being yes. For the when part, I think it should be done > prior to moving the SA and the data stream towards that address. > > => we need more flexibility about moving the SA: to wait the RR check > result is fine only when the previous peer address is still usable. Yes. Or to be more precise, if you are still using the previous address you can delay the check; but if you move the traffic stream to the new address then you should do the check first. (All assuming the check was configured ON in the first place.) And as you wrote in another e-mail, a peer address that appears in a cert or one that was just used one minute ago is already authorized. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 14 14:31:02 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08067 for ; Tue, 14 Dec 2004 14:31:02 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BEC49FB291; Tue, 14 Dec 2004 19:31:01 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CE89BFB28E; Tue, 14 Dec 2004 19:30:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 89B21FB28F; Tue, 14 Dec 2004 19:30:57 +0000 (UTC) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id E520DFB28B for ; Tue, 14 Dec 2004 19:30:56 +0000 (UTC) Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iBEJStQ08646; Tue, 14 Dec 2004 11:28:56 -0800 (PST) Message-ID: <41BF3F71.5090706@isi.edu> Date: Tue, 14 Dec 2004 11:30:57 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: [Mobike] issue #16 References: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> <41B8D7B3.4040701@isi.edu> <41BEFDC1.8020500@piuha.net> In-Reply-To: <41BEFDC1.8020500@piuha.net> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: MOBIKE Mailing List , Tschofenig Hannes 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jari Arkko wrote: | Joe Touch wrote: | |> Internet paths that are silent aren't problems, IMO. They're just idle |> network paths. | | Yes. | |> This sounds like a job for a link layer, and I don't think mobike needs |> to be a link layer. | | The link layer certainly has its own mechanisms, as does IP on | top of it (e.g. IPv6 NUD). But these are for a link, what we are | talking about here is a path through the Internet. More specifically, | the question is what to do if IKEv2 DPD tells us that its not getting | through. Should we (a) kill the connection or (b) switch to another | address we have? I think the latter... Links already react to things coming up and down. Routing already moves things around links that disappear. The key question is whether IKE should be doing something directly involving different addresses. That starts sounding like a routing or link management protocol, and can (and will) interact with link or routing adjustments. While I appreciate that IKE should retry, or allow reconecting, which could involve different addresses (i.e., different source address used on retry/restart), managing the addresses seems like it should be a side-effect of the restart (leave the source address blank, let it be filled in on exit) rather than explicitly managed. The latter is asking for interaction with link/routing reconfiguration, in a bad way, IMO. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBvz9xE5f5cImnZrsRAqF7AJ40E7yWW3vb5SmPQbjrHWeVj9BwnACgkjww +EStuPmCkyvSJ5UIzZJfr2w= =dvur -----END PGP SIGNATURE----- _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 16 07:47:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18848 for ; Thu, 16 Dec 2004 07:47:29 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 16554FB2BD; Thu, 16 Dec 2004 12:47:30 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 05009FB298; Thu, 16 Dec 2004 12:47:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 27FA8FB285; Wed, 15 Dec 2004 05:08:01 +0000 (UTC) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by machshav.com (Postfix) with ESMTP id 9A15FFB280 for ; Wed, 15 Dec 2004 05:08:00 +0000 (UTC) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Dec 2004 21:08:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iBF57vFS005567 for ; Tue, 14 Dec 2004 21:07:58 -0800 (PST) Received: from boraw2k04 (sjc-vpn4-1497.cisco.com [10.21.85.216]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUT59614; Tue, 14 Dec 2004 21:07:56 -0800 (PST) Message-Id: <200412150507.AUT59614@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: Date: Tue, 14 Dec 2004 21:07:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041210120003.2244FFB284@machshav.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcTer9BiwEIMzxO6SD+9dRia27dfrQDs/rHg Subject: [Mobike] Re: Lack of packets from other end 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 > > Message: 1 > Date: Thu, 09 Dec 2004 14:54:43 -0800 > From: Joe Touch > Subject: Re: [Mobike] issue #16 > To: Tschofenig Hannes > Cc: MOBIKE Mailing List > Message-ID: <41B8D7B3.4040701@isi.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Tschofenig Hannes wrote: > | hi all, > | > | i guess we can close issue # 16: > | "Can the protocol recover from situations where the only sign of > problems is > | lack of packets from the other end?" > | http://www.vpnc.org/ietf-mobike/issue16.txt > > Internet paths that are silent aren't problems, IMO. They're > just idle network paths. > > This sounds like a job for a link layer, and I don't think > mobike needs to be a link layer. > > Joe I agree with Joe here. There are legitimate situations where there may be no packets from the other end for a long period of time. We have DPD to detect a dead peer. If a peer moves from one IP addr to another without notifying the security gateway, I don't think it is the SG's job to detect and recover from this. Regards, Bora _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 16 07:47:38 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18868 for ; Thu, 16 Dec 2004 07:47:36 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0EC2CFB2CB; Thu, 16 Dec 2004 12:47:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 28F61FB2A7; Thu, 16 Dec 2004 12:47:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9D1A8FB290; Wed, 15 Dec 2004 13:26:28 +0000 (UTC) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 9890EFB28B for ; Wed, 15 Dec 2004 13:26:27 +0000 (UTC) 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 iBFDQDK27075; Wed, 15 Dec 2004 15:26:14 +0200 (EET) X-Scanned: Wed, 15 Dec 2004 15:24:06 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iBFDO6SA029203; Wed, 15 Dec 2004 15:24:06 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00x0FEsb; Wed, 15 Dec 2004 15:24:04 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iBFDO3309521; Wed, 15 Dec 2004 15:24:03 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Dec 2004 15:23:05 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 15 Dec 2004 15:23:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] issue #16 Date: Wed, 15 Dec 2004 15:23:04 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FE2C@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] issue #16 Thread-Index: AcTeQsmmyi+RWlNuTbKoRjMjyXAiSwEZYnBQ From: To: X-OriginalArrivalTime: 15 Dec 2004 13:23:05.0410 (UTC) FILETIME=[35DAD220:01C4E2A9] 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: quoted-printable Joe Touch wrote: >=20 > Tschofenig Hannes wrote: > | hi all, > | > | i guess we can close issue # 16: > | "Can the protocol recover from situations where the only > | sign of problems is lack of packets from the other end?" > | http://www.vpnc.org/ietf-mobike/issue16.txt >=20 > Internet paths that are silent aren't problems, IMO. They're=20 > just idle network paths. >=20 > This sounds like a job for a link layer, and I don't think=20 > mobike needs to be a link layer. Perhaps the issue was a bit inaccurately named, but it was=20 really about the case where DPD fails: we're sending an IKEv2=20 request, but don't receive a reply from the other end (even=20 after retransmitting the request several times). (This is of course quite different from idle network path.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 16 09:31:24 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26730 for ; Thu, 16 Dec 2004 09:31:22 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2EA00FB297; Thu, 16 Dec 2004 14:31:23 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 34183FB291; Thu, 16 Dec 2004 14:31:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ADAE0FB293; Thu, 16 Dec 2004 14:31:20 +0000 (UTC) Received: from p130.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id AEF23FB290 for ; Thu, 16 Dec 2004 14:31:19 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5102089839; Thu, 16 Dec 2004 16:31:17 +0200 (EET) Message-ID: <41C19C24.8000208@piuha.net> Date: Thu, 16 Dec 2004 16:31:00 +0200 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: Joe Touch Subject: Re: [Mobike] issue #16 References: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> <41B8D7B3.4040701@isi.edu> <41BEFDC1.8020500@piuha.net> <41BF3F71.5090706@isi.edu> In-Reply-To: <41BF3F71.5090706@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Tschofenig Hannes 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 Hi Joe, > While I appreciate that IKE should retry, or allow reconecting, which > could involve different addresses (i.e., different source address used > on retry/restart), managing the addresses seems like it should be a > side-effect of the restart (leave the source address blank, let it be > filled in on exit) rather than explicitly managed. Do I interpret you correctly if I say that (1) You are OK with explicit management of addresses when we have local information from the other parts of the stack that we need to do something, such as when the currently used link went down, ND tells us that we have moved to a new address, and so on. (2) You are NOT OK with explicit management when DPD fails. If this is correct, this would still leave us a few questions, such as o What about other things than direct local knowledge that we may get from the rest of the stack. For instance, would explicit management be OK if you get persistent ICMP errors, do a DPD because of them, and then get a failure? o What does side-effect mean, exactly? Do you mean to say that the sender can choose any source address, as long as the selection is done by something lower in the stack than IKE? Or do you mean that source address selection is OK but destination address selection is not. Or something else? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 16 09:55:09 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01952 for ; Thu, 16 Dec 2004 09:55:07 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DC2A7FB297; Thu, 16 Dec 2004 14:55:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 65387FB291; Thu, 16 Dec 2004 14:55:05 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 367E4FB293; Thu, 16 Dec 2004 14:55:04 +0000 (UTC) Received: from p130.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 9B3F0FB290 for ; Thu, 16 Dec 2004 14:55:03 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 874F689839; Thu, 16 Dec 2004 16:55:02 +0200 (EET) Message-ID: <41C1A1B6.5090808@piuha.net> Date: Thu, 16 Dec 2004 16:54:46 +0200 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 4: how to signal support for MOBIKE (correction) References: <41B4A39C.9060300@nortelnetworks.com> <41B4A81D.9030806@nortelnetworks.com> In-Reply-To: <41B4A81D.9030806@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Tero Kivinen , Tschofenig Hannes 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 Dondeti, Lakshminath wrote: > Just wanted to note that a clarification might be in order around the > "critical bit" usage. That would only be applicable if a new payload > type were to be defined for MOBIKE signaling, right? > So, are 3 options on the table: 1) new payload type that might be marked > critical 2) vendor ID, and 3) notify payloads? I think 2 options: > vendor ID and notify payloads, would be sufficient for MOBIKE signaling; > there is no need for a new payload type for this! Its hard for me to imagine a situation where we'd want to fail the connection if the other end does not support MOBIKE. So for capability discovery we don't want to turn the critical bit on. And after we have discovered the capabilities, we can either use or not use the critical bit, but it should never fail, given a correct implementation. In any case, this issue was about the capability discovery, not about how to represent the other MOBIKE messages. We haven't gone that far yet... --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 16 09:58:48 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02053 for ; Thu, 16 Dec 2004 09:58:46 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 75160FB29E; Thu, 16 Dec 2004 14:58:46 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0AE36FB293; Thu, 16 Dec 2004 14:58:40 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EF1D4FB294; Thu, 16 Dec 2004 14:58:38 +0000 (UTC) Received: from p130.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id CB9CCFB290 for ; Thu, 16 Dec 2004 14:58:37 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id BBE2689839; Thu, 16 Dec 2004 16:58:36 +0200 (EET) Message-ID: <41C1A28C.9080305@piuha.net> Date: Thu, 16 Dec 2004 16:58:20 +0200 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 Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE References: <2A8DB02E3018D411901B009027FD3A3F0542C6B2@mchp905a.mch.sbs.de> <41B4A39C.9060300@nortelnetworks.com> <016801c4dbc2$17663890$5d6015ac@dcml.docomolabsusa.com> <41B4BBC9.1010102@piuha.net> In-Reply-To: <41B4BBC9.1010102@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi Eronen , Tschofenig Hannes 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 My interpretation of this thread is that most people prefer the Notify approach, and it is sufficient for our needs. Based on the question from Tarique, I would add that we need to allow MOBIKE support to be notified at any time (but never turned off, it does not seem to make sense). Pasi, I think you can mark this issue closed on the issues page. Hannes, I think you can use the text that you posted a while ago, updated with the decision to use Notify and a discussion of the timing of this Notify. --Jari Jari Arkko wrote: > Yes. We shall only have one. Based on Hannes' analysis, > both options seem to provide the same functionality. > I am personally fine with either approach. Given that > we are writing a design draft, perhaps we should make > a design decision and pick one? It seems that a few people > preferred the Notify. I'm not sure I understood Tero's > objection to Vendor ID, but at least Notify sounds nicer. > Pick that and move one to the next issue? > > --Jari > > James Kempf wrote: > >> I think we ought to choose either Vendor ID or Notify. While I support >> Notify (since this is a standardized, and not a vendor specific, >> option), I >> would rather go with Vendor ID if that's what a majority of the WG wants >> rather than have both. >> >> jak >> >> ----- Original Message ----- From: "Dondeti, Lakshminath" >> >> To: "Tschofenig Hannes" >> Cc: "MOBIKE Mailing List" ; ; >> "Tero Kivinen" >> Sent: Monday, December 06, 2004 10:23 AM >> Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE >> >> >> >>> This sounds good. I was initially leaning toward Notify only, but there >>> is no harm in allowing Vendor ID. I wouldn't necessarily suggest the >>> use of "critical bit" here. Clearly, an implementation may choose to >>> use that feature, but there is no need to make that suggestion in each >>> context. Thanks. >>> >>> regards, >>> Lakshminath >>> >>> Tschofenig Hannes wrote: >>> >>> >>>> hi all, >>>> >>>> i went thought about the two most important options: notify and vendor >> >> >> id >> >>>> they both seem to provide the same capability. notify is used for >>>> errors but >>>> also for indicating sender capabilities. the same is true for the >>>> vendor id. >>>> >>>> >>>> as a text proposal i suggest to enhance the text offered by jari as >>>> follows: >>>> >>>> ----------------------- >>>> >>>> X. Indicating Support for MOBIKE >>>> >>>> A node needs to be able to guarantee that its address change messages >> >> >> are >> >>>> understood by the peer. Otherwise an address change may render the >>>> connection useless, and it is important that both sides realize this as >>>> early as possible. >>>> >>>> Ensuring that the messages are understood can in be arranged either by >>>> marking some IKEv2 payloads critical so that they are either processed >>>> or an >>>> error message is returned, by using Vendor ID payloads or via a Notify. >>>> >>>> The first solution approach is to use Vendor ID payloads during the >>>> initial >>>> IKEv2 exchange using a specific string denoting MOBIKE to signal the >>>> support >>>> of the MOBIKE protocol. This ensures that in all cases a MOBIKE >>>> capable node >>>> knows whether its peer supports MOBIKE or not. >>>> >>>> The second solution approach uses the Notify payload which is also >>>> used for >>>> NAT detection (via NAT_DETECTION_SOURCE_IP and >>>> NAT_DETECTION_DESTINATION_IP), . >>>> >>>> Both, a Vendor ID and a Notify payload, might be used to indicate the >>>> support of certain extensions. >>>> >>>> Note that the node could also attempt MOBIKE optimistically with the >>>> critical bit set to one when a movement has occurred. The drawback of >>>> this >>>> approach is, however, that the an unnecessary MOBIKE message round is >>>> introduced on the first movement. >>>> >>>> ----------------------- >>>> >>>> ciao >>>> hannes >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Tero Kivinen [mailto:kivinen@iki.fi] >>>>> Sent: Dienstag, 30. November 2004 11:41 >>>>> To: jari.arkko@piuha.net >>>>> Cc: MOBIKE Mailing List >>>>> Subject: [Mobike] issue 4: how to signal support for MOBIKE >>>>> >>>>> Jari Arkko writes: >>>>> >>>>>> So I would suggest that we use the Vendor ID approach. >>>>> >>>>> >>>>> I would suggest NOTIFY approach. I.e we send notify saying >>>>> MOBIKE_SUPPORTED and thats it. Similar thatn what is done for >>>>> the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. >>>>> >>>>> In most cases we do not want to fail the negotiation even if >>>>> the other end does not support MOBIKE, we simply revert back >>>>> to redoing the authentication every time IP-addresses changes. >>>>> >>>>> If our final protocol is going to use notifies to send the >>>>> IP-addresses, then we can use those notifies to signal the >>>>> use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. >>>>> -- >>>>> 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 >>>> >>> >>> _______________________________________________ >>> Mobike mailing list >>> Mobike@machshav.com >>> https://www.machshav.com/mailman/listinfo.cgi/mobike >>> >> >> >> >> _______________________________________________ >> Mobike mailing list >> Mobike@machshav.com >> https://www.machshav.com/mailman/listinfo.cgi/mobike >> >> > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 16 21:14:49 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11671 for ; Thu, 16 Dec 2004 21:14:48 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E418BFB298; Fri, 17 Dec 2004 02:14:47 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ED6D1FB291; Fri, 17 Dec 2004 02:14:45 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C8873FB293; Fri, 17 Dec 2004 02:14:43 +0000 (UTC) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by machshav.com (Postfix) with ESMTP id 42465FB290 for ; Fri, 17 Dec 2004 02:14:43 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iBH2EfVu012523; Thu, 16 Dec 2004 19:14:42 -0700 (MST) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iBH2Ee8p009924; Thu, 16 Dec 2004 21:14:40 -0500 (EST) Subject: Re: [Mobike] Re: Lack of packets from other end From: Bill Sommerfeld To: Bora Akyol In-Reply-To: <200412150507.AUT59614@mira-sjc5-e.cisco.com> References: <200412150507.AUT59614@mira-sjc5-e.cisco.com> Content-Type: text/plain Message-Id: <1103216898.1434.9.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Thu, 16 Dec 2004 21:14:01 -0500 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 Wed, 2004-12-15 at 00:07, Bora Akyol wrote: > I agree with Joe here. There are legitimate situations where there may > be no packets from the other end for a long period of time. We have DPD > to detect a dead peer. If a peer moves from one IP addr to another > without notifying the security gateway, I don't think it is the SG's job > to detect and recover from this. this is an somewhat akin to path mtu blackhole detection; inter-layer side channels could well allow an upper-layers repeated RTO to trigger a hunt for a better path. it's not the sort of thing which will be as immediately effective as a link-down indication from L2 but it's not something that we should explicitly declare out of spec. - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Dec 16 23:04:21 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19262 for ; Thu, 16 Dec 2004 23:04:21 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0020AFB29B; Fri, 17 Dec 2004 04:04:21 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 221E0FB291; Fri, 17 Dec 2004 04:04:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 547A3FB293; Fri, 17 Dec 2004 04:04:15 +0000 (UTC) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id ADDFFFB290 for ; Fri, 17 Dec 2004 04:04:14 +0000 (UTC) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Dec 2004 21:11:14 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iBH44Bsv008214; Thu, 16 Dec 2004 20:04:12 -0800 (PST) Received: from boraw2k04 (sjc-vpn2-675.cisco.com [10.21.114.163]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUV43399; Thu, 16 Dec 2004 20:04:10 -0800 (PST) Message-Id: <200412170404.AUV43399@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'Bill Sommerfeld'" Subject: RE: [Mobike] Re: Lack of packets from other end Date: Thu, 16 Dec 2004 20:04:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 In-Reply-To: <1103216898.1434.9.camel@unknown.hamachi.org> Thread-Index: AcTj3i2R4bM/wolERLeGBn1WGlkNwwADosRg 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 Bill Can you please expand on "inter-layer side channels" and what you mean by that? If a security gateway is supporting, say a million users, what kind of processing do you envision by the SG to detect an path change vs a client that has disappeared. Since mobile IP is explicitly out of scope, all we have is the IP address of the end node, other than DPD how can the SG detect a change of address of the client when the client has moved to a different address. I think for the first version of the MOBIKE specifications, we should focus on getting something that is: a) Scalable b) Works c) Simple and do this quickly. This to me dictates a mostly client side notification mechanism with a very simple code base on the server, and a small state machine on the client. Next phase, we can focus on work that is combines faculties of link layer with the network layer. Regards, Bora > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@sun.com] > Sent: Thursday, December 16, 2004 6:14 PM > To: Bora Akyol > Cc: mobike@machshav.com > Subject: Re: [Mobike] Re: Lack of packets from other end > > On Wed, 2004-12-15 at 00:07, Bora Akyol wrote: > > > I agree with Joe here. There are legitimate situations > where there may > > be no packets from the other end for a long period of time. We have > > DPD to detect a dead peer. If a peer moves from one IP addr > to another > > without notifying the security gateway, I don't think it is > the SG's > > job to detect and recover from this. > > this is an somewhat akin to path mtu blackhole detection; > inter-layer side channels could well allow an upper-layers > repeated RTO to trigger a hunt for a better path. it's not > the sort of thing which will be as immediately effective as a > link-down indication from L2 but it's not something that we > should explicitly declare out of spec. > > - Bill > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Dec 17 18:44:53 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06436 for ; Fri, 17 Dec 2004 18:44:52 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BC4D6FB2A7; Fri, 17 Dec 2004 23:44:53 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F02CBFB2A2; Fri, 17 Dec 2004 23:44:51 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7EAB8FB2A3; Fri, 17 Dec 2004 23:44:50 +0000 (UTC) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id 8E39CFB29B for ; Fri, 17 Dec 2004 23:44:49 +0000 (UTC) Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iBHNhMQ08547; Fri, 17 Dec 2004 15:43:22 -0800 (PST) Message-ID: <41C36F16.5060706@isi.edu> Date: Fri, 17 Dec 2004 15:43:18 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: [Mobike] issue #16 References: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> <41B8D7B3.4040701@isi.edu> <41BEFDC1.8020500@piuha.net> <41BF3F71.5090706@isi.edu> <41C19C24.8000208@piuha.net> In-Reply-To: <41C19C24.8000208@piuha.net> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: MOBIKE Mailing List , Tschofenig Hannes 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jari Arkko wrote: | Hi Joe, | |> While I appreciate that IKE should retry, or allow reconecting, which |> could involve different addresses (i.e., different source address used |> on retry/restart), managing the addresses seems like it should be a |> side-effect of the restart (leave the source address blank, let it be |> filled in on exit) rather than explicitly managed. | | Do I interpret you correctly if I say that | | (1) You are OK with explicit management of addresses | when we have local information from the other | parts of the stack that we need to do something, | such as when the currently used link went down, | ND tells us that we have moved to a new address, | and so on. Not quite - I don't buy the part about the 'link going down'. All you know is that the other end isn't reachable. Reacting to links is what dynamic routing does; if this layer does it as well, there's liable to be interactions (in a bad way). | (2) You are NOT OK with explicit management when | DPD fails. DPD failing means you can't talk to the other end, which means - IMO - that the mapping you used before (name -> addr) is no longer working. Trying a new mapping, or cycling among alternate names ought to happen when IKE starts anyway (at the app layer). | If this is correct, this would still leave us a | few questions, such as | | o What about other things than direct local knowledge | that we may get from the rest of the stack. For instance, | would explicit management be OK if you get persistent | ICMP errors, do a DPD because of them, and then get | a failure? It depends on what the errors are. Some warrant a restart, some do not. But, IMO, they warrant restart of the IKE. | o What does side-effect mean, exactly? Do you mean to | say that the sender can choose any source address, as | long as the selection is done by something lower in the | stack than IKE? Or do you mean that source address | selection is OK but destination address selection is not. | Or something else? More that cycling among alternate addrs is something that ought to happen on start anyway - side-effect isn't quite the right term; it's more like 'already included explicit mechanism'. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBw28WE5f5cImnZrsRAsICAKCx1zU1gHQODPfXQURRowQNDTUpRQCgqlUu XfipqdYdADQSK3UTfkQGt4A= =u2kr -----END PGP SIGNATURE----- _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Dec 18 03:47:06 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01531 for ; Sat, 18 Dec 2004 03:47:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 43CD0FB2A7; Sat, 18 Dec 2004 08:47:06 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 94C52FB293; Sat, 18 Dec 2004 08:47:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 999C2FB2A1; Sat, 18 Dec 2004 08:46:59 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 8F7A7FB280 for ; Sat, 18 Dec 2004 08:46:58 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 98F958989F; Sat, 18 Dec 2004 10:46:54 +0200 (EET) Message-ID: <41C3EE6E.4000803@piuha.net> Date: Sat, 18 Dec 2004 10:46:38 +0200 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: Joe Touch Subject: Re: [Mobike] issue #16 References: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> <41B8D7B3.4040701@isi.edu> <41BEFDC1.8020500@piuha.net> <41BF3F71.5090706@isi.edu> <41C19C24.8000208@piuha.net> <41C36F16.5060706@isi.edu> In-Reply-To: <41C36F16.5060706@isi.edu> 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 Joe Touch wrote: > | (1) You are OK with explicit management of addresses > | when we have local information from the other > | parts of the stack that we need to do something, > | such as when the currently used link went down, > | ND tells us that we have moved to a new address, > | and so on. > > Not quite - I don't buy the part about the 'link going down'. All you > know is that the other end isn't reachable. Reacting to links is what > dynamic routing does; if this layer does it as well, there's liable to > be interactions (in a bad way). Maybe I described it too vaguely... I did not mean just any links -- that's in the routing domain. If the WLAN interface of my laptop goes down there's nothing in the routing system that reacts to this. A host is no longer reachable at that address. End of story. But perhaps you are thinking of links within the routing system, such as between routers? I agree that its definately out of scope for MOBIKE. The end hosts running IKE would not even see this. But they would see their own interface go down, which I think is in scope. > Trying a new mapping, or cycling among alternate names ought to happen > when IKE starts anyway (at the app layer). ... > It depends on what the errors are. Some warrant a restart, some do not. > But, IMO, they warrant restart of the IKE. ... > More that cycling among alternate addrs is something that ought to > happen on start anyway - side-effect isn't quite the right term; it's > more like 'already included explicit mechanism'. Its unclear to me what you mean by IKE "start" or "restart". The purpose of MOBIKE is precisely to avoid having to re-run IKE from the beginning for a mere address change. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Dec 18 04:56:07 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05363 for ; Sat, 18 Dec 2004 04:56:06 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B7B85FB2A8; Sat, 18 Dec 2004 09:56:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D12A1FB29B; Sat, 18 Dec 2004 09:56:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EC8FFFB2A3; Sat, 18 Dec 2004 09:55:59 +0000 (UTC) Received: from web41214.mail.yahoo.com (web41214.mail.yahoo.com [66.218.93.47]) by machshav.com (Postfix) with SMTP id 44DDEFB297 for ; Sat, 18 Dec 2004 09:55:59 +0000 (UTC) Received: (qmail 62768 invoked by uid 60001); 18 Dec 2004 09:55:58 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=HayzGDQUk22uuule3A4wQm4M096WgYsAxvHXx6Ws9YORtPiLY93nAWsxpZFvh03VAK+z7LxwAxkaSTrGQNhB0jxdOxv9O3AJKzI2U9iXbXqJN1+HXfzqux7rcuRfHW4oo+LatmTbnlATNm8kWes9no+iWRJtEFPJYJCUKOr+X6I= ; Message-ID: <20041218095558.62766.qmail@web41214.mail.yahoo.com> Received: from [64.164.3.246] by web41214.mail.yahoo.com via HTTP; Sat, 18 Dec 2004 01:55:58 PST Date: Sat, 18 Dec 2004 01:55:58 -0800 (PST) From: Tarique Mustafa Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE To: jari.arkko@piuha.net, MOBIKE Mailing List MIME-Version: 1.0 Cc: Pasi Eronen , Tschofenig Hannes 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="===============1116224445==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --===============1116224445== Content-Type: multipart/alternative; boundary="0-675526068-1103363758=:62323" --0-675526068-1103363758=:62323 Content-Type: text/plain; charset=us-ascii Jari, My original set of questions regarding this issue somehow did not get sent on the group so I am including here my questions again for everybody's input. (See below) -Tarique ======= Jari, Tero, Hannes, Kempf and others: I see the benefit of using either of the approaches - Vendor ID vs. Notify and am fine with either one. However, just a question or "food for some more thought", here is a scenario: 1) Client Peer establishes a Mobike Session with Remote Peer (or server) 2) Client Peer moves to a new access point and due to change in the IP address, re-registers with the Remote Peer (or server) - session type now however (for ANY reason) is not to be Mobike Session any more :- It could be anything let's say a simple IKEv1/IKEv2 session 3) Client Peer moves again causing the IP address change again, re-registers with Remote Peer (or server) again - BUT the session type now "for some reason can and should be" a Mobike Session How will this scenario be supported with the existing recommendtions in Mobike? Will Notification vs. Vendor ID approach have any positive or negative impact in the afore mentioned scenario? Regards, -Tarique Mustafa Jari Arkko wrote: My interpretation of this thread is that most people prefer the Notify approach, and it is sufficient for our needs. Based on the question from Tarique, I would add that we need to allow MOBIKE support to be notified at any time (but never turned off, it does not seem to make sense). Pasi, I think you can mark this issue closed on the issues page. Hannes, I think you can use the text that you posted a while ago, updated with the decision to use Notify and a discussion of the timing of this Notify. --Jari Jari Arkko wrote: > Yes. We shall only have one. Based on Hannes' analysis, > both options seem to provide the same functionality. > I am personally fine with either approach. Given that > we are writing a design draft, perhaps we should make > a design decision and pick one? It seems that a few people > preferred the Notify. I'm not sure I understood Tero's > objection to Vendor ID, but at least Notify sounds nicer. > Pick that and move one to the next issue? > > --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --------------------------------- Do you Yahoo!? The all-new My Yahoo! – What will yours do? --------------------------------- Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. Learn more. --0-675526068-1103363758=:62323 Content-Type: text/html; charset=us-ascii
Jari,
My original set of questions regarding this issue somehow did not get sent on the group so I am including here my questions again for everybody's input. (See  below)
-Tarique
=======
Jari, Tero, Hannes, Kempf and others:
 
I see the benefit of using either of the approaches - Vendor ID vs. Notify and am fine with either one.
 
However, just a question or "food for some more thought", here is a scenario:
 
1) Client Peer establishes a Mobike Session with Remote Peer (or server)
2) Client Peer moves to a new access point and due to change in the IP address, re-registers with the Remote Peer (or server) - session type now however (for ANY reason) is not to be Mobike Session any more :- It could be anything let's say a simple IKEv1/IKEv2 session
3) Client Peer moves again causing the IP address change again, re-registers with Remote Peer (or server) again - BUT the session type now "for some reason can and should be" a Mobike Session
 
How will this scenario be supported with the existing recommendtions in Mobike?
Will Notification vs. Vendor ID approach have any positive or negative impact in the afore mentioned scenario?
 
Regards,
-Tarique Mustafa

Jari Arkko <jari.arkko@piuha.net> wrote:
My interpretation of this thread is that most people
prefer the Notify approach, and it is sufficient for
our needs. Based on the question from Tarique, I would
add that we need to allow MOBIKE support to be notified
at any time (but never turned off, it does not seem
to make sense).

Pasi, I think you can mark this issue closed on the issues
page.

Hannes, I think you can use the text that you posted
a while ago, updated with the decision to use Notify
and a discussion of the timing of this Notify.

--Jari

Jari Arkko wrote:
> Yes. We shall only have one. Based on Hannes' analysis,
> both options seem to provide the same functionality.
> I am personally fine with either approach. Given that
> we are writing a design draft, perhaps we should make
> a design decision and pick one? It seems that a few people
> preferred the Notify. I'm not sure I understood Tero's
> objection to Vendor ID, but at least Notify sounds nicer.
> Pick that and move one to the next issue?
>
> --Jari

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

Do you Yahoo!?
The all-new My Yahoo! – What will yours do?

Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search. Learn more. --0-675526068-1103363758=:62323-- --===============1116224445== 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 --===============1116224445==-- From mobike-bounces@machshav.com Sun Dec 19 13:07:19 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18618 for ; Sun, 19 Dec 2004 13:07:18 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 13421FB2B5; Sun, 19 Dec 2004 18:07:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 01341FB293; Sun, 19 Dec 2004 18:07:12 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AFF16FB2A1; Sat, 18 Dec 2004 09:19:56 +0000 (UTC) Received: from web41208.mail.yahoo.com (web41208.mail.yahoo.com [66.218.93.41]) by machshav.com (Postfix) with SMTP id 6F9F7FB297 for ; Sat, 18 Dec 2004 09:19:50 +0000 (UTC) Received: (qmail 97255 invoked by uid 60001); 18 Dec 2004 09:19:49 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=M1zVBpaavzNd3kI9Iu2vUcsc1QN75WGpdDi2nSlkvlNb0cMCuetiE3vpR+4D809oSFa7pUEYic+Pkuzl49eysXEmQQkEvAtt17gb75Cfi2BbtjmHXUrVt/fV1LWPCXjN4f+pc0OIeToImoAutOTn8F2xlffDA7SIVw762govC5c= ; Message-ID: <20041218091949.97253.qmail@web41208.mail.yahoo.com> Received: from [64.164.3.246] by web41208.mail.yahoo.com via HTTP; Sat, 18 Dec 2004 01:19:49 PST Date: Sat, 18 Dec 2004 01:19:49 -0800 (PST) From: Tarique Mustafa Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE To: jari.arkko@piuha.net, MOBIKE Mailing List In-Reply-To: <41C1A28C.9080305@piuha.net> MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 19 Dec 2004 18:07:10 +0000 Cc: Pasi Eronen , Tschofenig Hannes 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="===============1890070609==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --===============1890070609== Content-Type: multipart/alternative; boundary="0-1280247815-1103361589=:96689" --0-1280247815-1103361589=:96689 Content-Type: text/plain; charset=us-ascii Jari, My original set of questions regarding this issue somehow did not get sent on the group so I am including here my questions again for everybody's input. ======= Jari, Tero, Hannes, Kempf and others: I see the benefit of using either of the approaches - Vendor ID vs. Notify and am fine with either one. However, just a question or "food for some more thought", here is a scenario: 1) Client Peer establishes a Mobike Session with Remote Peer (or server) 2) Client Peer moves to a new access point and due to change in the IP address, re-registers with the Remote Peer (or server) - session type now however (for ANY reason) is not to be Mobike Session any more :- It could be anything let's say a simple IKEv1/IKEv2 session 3) Client Peer moves again causing the IP address change again, re-registers with Remote Peer (or server) again - BUT the session type now "for some reason can and should be" a Mobike Session How will this scenario be supported with the existing recommendtions in Mobike? Will Notification vs. Vendor ID approach have any positive or negative impact in the afore mentioned scenario? Regards, -Tarique Mustafa Jari Arkko wrote: My interpretation of this thread is that most people prefer the Notify approach, and it is sufficient for our needs. Based on the question from Tarique, I would add that we need to allow MOBIKE support to be notified at any time (but never turned off, it does not seem to make sense). Pasi, I think you can mark this issue closed on the issues page. Hannes, I think you can use the text that you posted a while ago, updated with the decision to use Notify and a discussion of the timing of this Notify. --Jari Jari Arkko wrote: > Yes. We shall only have one. Based on Hannes' analysis, > both options seem to provide the same functionality. > I am personally fine with either approach. Given that > we are writing a design draft, perhaps we should make > a design decision and pick one? It seems that a few people > preferred the Notify. I'm not sure I understood Tero's > objection to Vendor ID, but at least Notify sounds nicer. > Pick that and move one to the next issue? > > --Jari > > James Kempf wrote: > >> I think we ought to choose either Vendor ID or Notify. While I support >> Notify (since this is a standardized, and not a vendor specific, >> option), I >> would rather go with Vendor ID if that's what a majority of the WG wants >> rather than have both. >> >> jak >> >> ----- Original Message ----- From: "Dondeti, Lakshminath" >> >> To: "Tschofenig Hannes" >> Cc: "MOBIKE Mailing List" ; ; >> "Tero Kivinen" >> Sent: Monday, December 06, 2004 10:23 AM >> Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE >> >> >> >>> This sounds good. I was initially leaning toward Notify only, but there >>> is no harm in allowing Vendor ID. I wouldn't necessarily suggest the >>> use of "critical bit" here. Clearly, an implementation may choose to >>> use that feature, but there is no need to make that suggestion in each >>> context. Thanks. >>> >>> regards, >>> Lakshminath >>> >>> Tschofenig Hannes wrote: >>> >>> >>>> hi all, >>>> >>>> i went thought about the two most important options: notify and vendor >> >> >> id >> >>>> they both seem to provide the same capability. notify is used for >>>> errors but >>>> also for indicating sender capabilities. the same is true for the >>>> vendor id. >>>> >>>> >>>> as a text proposal i suggest to enhance the text offered by jari as >>>> follows: >>>> >>>> ----------------------- >>>> >>>> X. Indicating Support for MOBIKE >>>> >>>> A node needs to be able to guarantee that its address change messages >> >> >> are >> >>>> understood by the peer. Otherwise an address change may render the >>>> connection useless, and it is important that both sides realize this as >>>> early as possible. >>>> >>>> Ensuring that the messages are understood can in be arranged either by >>>> marking some IKEv2 payloads critical so that they are either processed >>>> or an >>>> error message is returned, by using Vendor ID payloads or via a Notify. >>>> >>>> The first solution approach is to use Vendor ID payloads during the >>>> initial >>>> IKEv2 exchange using a specific string denoting MOBIKE to signal the >>>> support >>>> of the MOBIKE protocol. This ensures that in all cases a MOBIKE >>>> capable node >>>> knows whether its peer supports MOBIKE or not. >>>> >>>> The second solution approach uses the Notify payload which is also >>>> used for >>>> NAT detection (via NAT_DETECTION_SOURCE_IP and >>>> NAT_DETECTION_DESTINATION_IP), . >>>> >>>> Both, a Vendor ID and a Notify payload, might be used to indicate the >>>> support of certain extensions. >>>> >>>> Note that the node could also attempt MOBIKE optimistically with the >>>> critical bit set to one when a movement has occurred. The drawback of >>>> this >>>> approach is, however, that the an unnecessary MOBIKE message round is >>>> introduced on the first movement. >>>> >>>> ----------------------- >>>> >>>> ciao >>>> hannes >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Tero Kivinen [mailto:kivinen@iki.fi] >>>>> Sent: Dienstag, 30. November 2004 11:41 >>>>> To: jari.arkko@piuha.net >>>>> Cc: MOBIKE Mailing List >>>>> Subject: [Mobike] issue 4: how to signal support for MOBIKE >>>>> >>>>> Jari Arkko writes: >>>>> >>>>>> So I would suggest that we use the Vendor ID approach. >>>>> >>>>> >>>>> I would suggest NOTIFY approach. I.e we send notify saying >>>>> MOBIKE_SUPPORTED and thats it. Similar thatn what is done for >>>>> the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. >>>>> >>>>> In most cases we do not want to fail the negotiation even if >>>>> the other end does not support MOBIKE, we simply revert back >>>>> to redoing the authentication every time IP-addresses changes. >>>>> >>>>> If our final protocol is going to use notifies to send the >>>>> IP-addresses, then we can use those notifies to signal the >>>>> use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. >>>>> -- >>>>> 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 >>>> >>> >>> _______________________________________________ >>> Mobike mailing list >>> Mobike@machshav.com >>> https://www.machshav.com/mailman/listinfo.cgi/mobike >>> >> >> >> >> _______________________________________________ >> Mobike mailing list >> Mobike@machshav.com >> https://www.machshav.com/mailman/listinfo.cgi/mobike >> >> > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --------------------------------- Do you Yahoo!? The all-new My Yahoo! – What will yours do? --0-1280247815-1103361589=:96689 Content-Type: text/html; charset=us-ascii
Jari,
My original set of questions regarding this issue somehow did not get sent on the group so I am including here my questions again for everybody's input.

=======
Jari, Tero, Hannes, Kempf and others:
 
I see the benefit of using either of the approaches - Vendor ID vs. Notify and am fine with either one.
 
However, just a question or "food for some more thought", here is a scenario:
 
1) Client Peer establishes a Mobike Session with Remote Peer (or server)
2) Client Peer moves to a new access point and due to change in the IP address, re-registers with the Remote Peer (or server) - session type now however (for ANY reason) is not to be Mobike Session any more :- It could be anything let's say a simple IKEv1/IKEv2 session
3) Client Peer moves again causing the IP address change again, re-registers with Remote Peer (or server) again - BUT the session type now "for some reason can and should be" a Mobike Session
 
How will this scenario be supported with the existing recommendtions in Mobike?
Will Notification vs. Vendor ID approach have any positive or negative impact in the afore mentioned scenario?
 
Regards,
-Tarique Mustafa

 
Jari Arkko <jari.arkko@piuha.net> wrote:
My interpretation of this thread is that most people
prefer the Notify approach, and it is sufficient for
our needs. Based on the question from Tarique, I would
add that we need to allow MOBIKE support to be notified
at any time (but never turned off, it does not seem
to make sense).

Pasi, I think you can mark this issue closed on the issues
page.

Hannes, I think you can use the text that you posted
a while ago, updated with the decision to use Notify
and a discussion of the timing of this Notify.

--Jari

Jari Arkko wrote:
> Yes. We shall only have one. Based on Hannes' analysis,
> both options seem to provide the same functionality.
> I am personally fine with either approach. Given that
> we are writing a design draft, perhaps we should make
> a design decision and pick one? It seems that a few people
> preferred the Notify. I'm not sure I understood Tero's
> objection to Vendor ID, but at least Notify sounds nicer.
> Pick that and move one to the next issue?
>
> --Jari
>
> James Kempf wrote:
>
>> I think we ought to choose either Vendor ID or Notify. While I support
>> Notify (since this is a standardized, and not a vendor specific,
>> option), I
>> would rather go with Vendor ID if that's what a majority of the WG wants
>> rather than have both.
>>
>> jak
>>
>> ----- Original Message ----- From: "Dondeti, Lakshminath"
>>
>> To: "Tschofenig Hannes"
>> Cc: "MOBIKE Mailing List" ; ;
>> "Tero Kivinen"
>> Sent: Monday, December 06, 2004 10:23 AM
>> Subject: Re: [M obike] issue 4: how to signal support for MOBIKE
>>
>>
>>
>>> This sounds good. I was initially leaning toward Notify only, but there
>>> is no harm in allowing Vendor ID. I wouldn't necessarily suggest the
>>> use of "critical bit" here. Clearly, an implementation may choose to
>>> use that feature, but there is no need to make that suggestion in each
>>> context. Thanks.
>>>
>>> regards,
>>> Lakshminath
>>>
>>> Tschofenig Hannes wrote:
>>>
>>>
>>>> hi all,
>>>>
>>>> i went thought about the two most important options: notify and vendor
>>
>>
>> id
>>
>>>> they both seem to provide the same capability. notify is used for
>>>> errors but
>>>> also for indicating sender capabilities. the sam e is true for the
>>>> vendor id.
>>>>
>>>>
>>>> as a text proposal i suggest to enhance the text offered by jari as
>>>> follows:
>>>>
>>>> -----------------------
>>>>
>>>> X. Indicating Support for MOBIKE
>>>>
>>>> A node needs to be able to guarantee that its address change messages
>>
>>
>> are
>>
>>>> understood by the peer. Otherwise an address change may render the
>>>> connection useless, and it is important that both sides realize this as
>>>> early as possible.
>>>>
>>>> Ensuring that the messages are understood can in be arranged either by
>>>> marking some IKEv2 payloads critical so that they are either processed
>>>> or an
>>>> error message is return ed, by using Vendor ID payloads or via a Notify.
>>>>
>>>> The first solution approach is to use Vendor ID payloads during the
>>>> initial
>>>> IKEv2 exchange using a specific string denoting MOBIKE to signal the
>>>> support
>>>> of the MOBIKE protocol. This ensures that in all cases a MOBIKE
>>>> capable node
>>>> knows whether its peer supports MOBIKE or not.
>>>>
>>>> The second solution approach uses the Notify payload which is also
>>>> used for
>>>> NAT detection (via NAT_DETECTION_SOURCE_IP and
>>>> NAT_DETECTION_DESTINATION_IP), .
>>>>
>>>> Both, a Vendor ID and a Notify payload, might be used to indicate the
>>>> support of certain extensions.
>>>>
>>>> Note that the node could also attempt MOBIKE optimist ically with the
>>>> critical bit set to one when a movement has occurred. The drawback of
>>>> this
>>>> approach is, however, that the an unnecessary MOBIKE message round is
>>>> introduced on the first movement.
>>>>
>>>> -----------------------
>>>>
>>>> ciao
>>>> hannes
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Tero Kivinen [mailto:kivinen@iki.fi]
>>>>> Sent: Dienstag, 30. November 2004 11:41
>>>>> To: jari.arkko@piuha.net
>>>>> Cc: MOBIKE Mailing List
>>>>> Subject: [Mobike] issue 4: how to signal support for MOBIKE
>>>>>
>>>>> Jari Arkko writes:
>>>>>
>>>>>> So I would suggest that we use the Vendor I D approach.
>>>>>
>>>>>
>>>>> I would suggest NOTIFY approach. I.e we send notify saying
>>>>> MOBIKE_SUPPORTED and thats it. Similar thatn what is done for
>>>>> the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc.
>>>>>
>>>>> In most cases we do not want to fail the negotiation even if
>>>>> the other end does not support MOBIKE, we simply revert back
>>>>> to redoing the authentication every time IP-addresses changes.
>>>>>
>>>>> If our final protocol is going to use notifies to send the
>>>>> IP-addresses, then we can use those notifies to signal the
>>>>> use of MOBIKE instead of separate MOBIKE_SUPPORTED notify.
>>>>> --
>>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
&g t;
> _______________________________________________
> 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

Do you Yahoo!?
The all-new My Yahoo! – What will yours do? --0-1280247815-1103361589=:96689-- --===============1890070609== 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 --===============1890070609==-- From mobike-bounces@machshav.com Mon Dec 20 03:25:27 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10222 for ; Mon, 20 Dec 2004 03:25:27 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 23F7FFB2BA; Mon, 20 Dec 2004 08:25:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C10AFFB2B5; Mon, 20 Dec 2004 08:25:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CDCB2FB2BC; Mon, 20 Dec 2004 08:25:13 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id 60694FB2B5 for ; Mon, 20 Dec 2004 08:25:09 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iBK8P7Yq005825; Mon, 20 Dec 2004 09:25:07 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iBK8P7Zn019552; Mon, 20 Dec 2004 09:25:07 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Dec 2004 09:25:06 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B515@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Francis Dupont Subject: RE: [Mobike] issue 1: direct or indirect indicators Date: Mon, 20 Dec 2004 09:25:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi francis, please see my comment below: > In your previous mail you wrote: > > > In your previous mail you wrote: > > > > a separate question but also of interest: > > - should a peer send an address list in one message or > > individual messages > > (which only contain one address/message)? > > (the address list does not work in a nat environment.) > > answer: both seems to be desired. > > > > => as I don't like the idea to mix MOBIKE and NAT-T I am in > > favor of one message which can be submitted to the > > authorization procedure once and gives less exchanges. Of > > course this doesn't make the one address/message impossible. > > having an address list in the ike message makes nat > handling impossible. i need to correct myself here: i shouldn't say impossible. i should say 'impossible without using an additional protocol which allows to learn the public ip address+ possible port' > > => now I see: you speak about the first message when I speak > about NAT prevention in the first message and address list in > the next exchange. does this make a difference. > I've already explained this but I used NAT prevention for two > purposes: > - make the choice between either NAT traversal and MOBIKE clear > - inject the peer addresses from the header into a protected > space that's fine. it is certainly good to have an indication in the first message exchange to tell the other peer whether to enable/disable nat handling support. the second issue is fine with me. BTW the first point is Pasi's idea, and it has the > extra advantage to be outside of the NAT traversal IPR. very good. to come back to the original issue: if you have don't send a nat prevention payload (notification or vendor id) in the first few messages and if you have a nat somewhere along the path (at least between some src/dst address pairs) then you cannot send an address list (expect if you use another protocol which allows you to learn your public ip address + port). > > Thanks ciao hannes > > 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 Dec 20 03:25:37 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10264 for ; Mon, 20 Dec 2004 03:25:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0B843FB2D8; Mon, 20 Dec 2004 08:25:36 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BAA89FB2B4; Mon, 20 Dec 2004 08:25:24 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9D427FB2BB; Mon, 20 Dec 2004 08:25:15 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id 5E7C9FB2B4 for ; Mon, 20 Dec 2004 08:25:09 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iBK8P7Yq005826; Mon, 20 Dec 2004 09:25:07 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iBK8P6Zn019544; Mon, 20 Dec 2004 09:25:06 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Dec 2004 09:25:06 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B511@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Mohan Parthasarathy , jari.arkko@piuha.net Subject: RE: [Mobike] issue 3: nat traversal Date: Mon, 20 Dec 2004 09:25:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi mohan, please see my comment below: > > Mohan Parthasarathy wrote: > > > > >>>Okay. Do we want to add the qualifier that MOBIKE needs > to work in > > >>>a "secure" fashion when moving behind a NAT ? > > >>>(unlike IKEv2 which also supports NAT traversal but > susceptible to > > >>>3rd party bombing attacks). > > >> > > >>what is a "secure" nat traversal solution for you? > > >> > > > > > > The one that does not have the 3rd party bombing attack > :-) To put > > > in a different way, MOBIKE's security should not be altered, when > > > moving behind a NAT. As we are at the design stage, it might make > > > sense to understand what sort of NAT traversal solution > we are going > > > to have. > > > > Right. And I want MOBIKE to be secure in this fashion. > > However, if we move behind a NAT, and our configuration allows such > > move, I think we pretty much have to downgrade the security to what > > NAT-T offers. Or do you see a way around that? it is true that you can certainly do better than nat-t. i remember your proposal and it has certainly some drawbacks as well. in fact i was asking my questions in such a way to see this answer from you: this is not an advertisement but nsis is currently the only protocol that allows you to securely obtain a nat binding in arbitrary complex network topologies. you could also use stun (or turn) to learn your publically visible ip address (and port). luckily this issue is orthogonal to the problems addressed in mobike. mobike should allow you to communicate (via some message that has to be defined) the addresses that are available at a peer. you might obtain these addresses by querying your interface cards, based on pre-configuration or even based on the usage of a signaling protocol (such as nsis, midcom or stun). > > > There may be a way around that. The node that moved behind > the NAT should include the NAT public address in the address > change message sent to the other end. Then the other end can > know what to expect in the IP headers. This is what i > presented in IETF 60. There are two ssues here (Perhaps there > are more). > > 1) How does the end node discover the public address securely ? > 2) If the public address is known, how does the node communicate this > to the other end securely ? > i agree with your observation. > I am wondering whether these two things can be seen separately. i think they are. if they are we can treat them as a separate problem and try to move forward within mobike working group. i think that this is good news. > > Let us assume that the NAT discovered the public address > securely (either physical security or DHCP security etc.). If > not, the attacker can attack anything he wants, not just MOBIKE. > > In some environments (1) may be easy e.g. i know what public > address my NAT uses at home. Or perhaps DHCP can be used to > convey this information in a secure way. Perhaps there are > others which i am not aware of. Would it make sense to > provide a mechanism in MOBIKE to carry the NAT public address > assuming it was discovered outside ? If the address is not > discovered securely, then it boils down to the same level of > security as the current IKEv2 NAT-T. (1) is not entirely easy as various work in the ietf shows. there is plenty of literature on this issue. nsis is a good place to start reading. ciao hannes > > -mohan > > > > > --Jari > > _______________________________________________ > > Mobike mailing list > > Mobike@machshav.com > > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 20 03:25:41 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10285 for ; Mon, 20 Dec 2004 03:25:41 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0ECF3FB2B9; Mon, 20 Dec 2004 08:25:42 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8CE99FB2C3; Mon, 20 Dec 2004 08:25:27 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C64F4FB2BB; Mon, 20 Dec 2004 08:25:17 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id 9806BFB2A3 for ; Mon, 20 Dec 2004 08:25:10 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iBK8P7tr030414; Mon, 20 Dec 2004 09:25:07 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iBK8P6Zn019535; Mon, 20 Dec 2004 09:25:06 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Dec 2004 09:25:06 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B510@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Joe Touch Subject: RE: [Mobike] issue #16 Date: Mon, 20 Dec 2004 09:25:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi joe, please see my comment below: > Tschofenig Hannes wrote: > | hi all, > | > | i guess we can close issue # 16: > | "Can the protocol recover from situations where the only sign of > problems is > | lack of packets from the other end?" > | http://www.vpnc.org/ietf-mobike/issue16.txt > > Internet paths that are silent aren't problems, IMO. They're > just idle network paths. based on a previous discussion we observed that we can have network failures which are either on the local link or somewhere along the path between a source and a destination. observing the local link only addresses only some problems - not all. a number of other working groups have made similar observations. > > This sounds like a job for a link layer, and I don't think > mobike needs to be a link layer. we also agreed that mobike depends on information from a number of other protocols (including link layer protocols). these protocols provide hints to mobike. you are right: mobike is certainly not a link layer protocol. no disagreement about it. > > Joe ciao hannes > > | as a conclusion of the discussions we said: > | > | - mobike defines a mechanism to test connectivity along paths. > | - both peers might use input from other sources to detect a failure > (e.g., a > | local link failure) > | - based on this information mobike might decide to switch to a new > | address (if available). > | > | ciao > | hannes > | _______________________________________________ > | Mobike mailing list > | Mobike@machshav.com > | https://www.machshav.com/mailman/listinfo.cgi/mobike > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFBuNezE5f5cImnZrsRAlRKAJ45hue31XWR2Gklfxm13vDYtHVX1QCfU86E > SmA7ZmLlf47460z4d07E/OA= > =KIh/ > -----END PGP SIGNATURE----- > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Dec 20 03:25:51 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10315 for ; Mon, 20 Dec 2004 03:25:50 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DDC5BFB2BE; Mon, 20 Dec 2004 08:25:51 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C5A9EFB2CB; Mon, 20 Dec 2004 08:25:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2B38CFB2BB; Mon, 20 Dec 2004 08:25:20 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id 3FEFEFB2B1 for ; Mon, 20 Dec 2004 08:25:09 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iBK8P7tr030705; Mon, 20 Dec 2004 09:25:07 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iBK8P7Zn019546; Mon, 20 Dec 2004 09:25:07 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Dec 2004 09:25:06 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B512@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Francis Dupont Subject: RE: [Mobike] issue 3: nat traversal Date: Mon, 20 Dec 2004 09:25:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: MOBIKE Mailing List , Mohan Parthasarathy , 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 hi francis, please see my comments below: > In your previous mail you wrote: > > > => NAT prevention is important for security as I explained in > > a previous message, and it "solves" the NAT traversal > problem too. > > IMHO we should only give the choice between NAT traversal and > > MOBIKE, i.e., MOBIKE should only detect the "just move behind > > a NAT" case, and should *not* try to handle it (i.e., the > > case will be considered as misconfiguration). > > nat prevention does not solve the nat traversal problem, > obviously. > > => it depends of your meaning of "solve" as with NAT > prevention you can't get a NAT traversal problem... my impression so far was that we cannot assume that there are some protocols which allow to securely obtain a nat binding. if we manage it to update existing nats to provide this type of protocol support then i would be very happy. however, we would liket to have a protocol which can be deployed today (even if there are some limitations). > > we should give people the possibility to > (a) allow the responder to use the ip address contained in > the ike message > AND > (b) allow the responder to use ip address information in > the header > to derive some decisions. > > => my opinion is than (b) is restricted to detect spurious > NATs in the path: > either we use NAT prevention and MOBIKE or we use NAT traversal. > I don't believe the MOBIKE WG should invent a new NAT > traversal mechanism (note that I am not against the idea of a > new and more secure NAT traversal, just that this is not in > the scope of the MOBIKE WG). that's the place where a number of folks disagree with you. the mobike working group is not inventing a new nat traversal mechanism. we just use what we have in ikev2. > > detecting only that you are behind a nat is insufficient > to address all > scenarios people are looking at. > > => we have to decide one day if NAT traversal is in the scope: > 1- just make NAT traversal and MOBIKE two separate solutions > 2- include a new NAT traversal in the charter > 3- try to merge current NAT traversal with MOBIKE My opinion > is 1- is fine and NAT prevention makes the choice clear, > 2- is currently out of the charter and 3- can't work without > 2-, so the best solution is 1-. Note that if NAT traversal is > not very secure it is reasonably secure when implicit SA > update is supported and it was already accepted... i don't see why nat traversal is outside the scope of the mobike charter. could you elaborate a little bit more about (1) to make sure whether we have a disagreement here. ciao hannes > > 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 Mon Dec 20 03:25:52 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10335 for ; Mon, 20 Dec 2004 03:25:52 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B0470FB2BC; Mon, 20 Dec 2004 08:25:52 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5C113FB2C8; Mon, 20 Dec 2004 08:25:28 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 442BDFB2BD; Mon, 20 Dec 2004 08:25:17 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 8B2E2FB2B6 for ; Mon, 20 Dec 2004 08:25:09 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iBK8P7Vi027563; Mon, 20 Dec 2004 09:25:08 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iBK8P7Zn019545; Mon, 20 Dec 2004 09:25:07 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Dec 2004 09:25:06 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B513@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Francis Dupont Subject: RE: [Mobike] When to do Return Routability Checks Date: Mon, 20 Dec 2004 09:25:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi francis, please see my comments below: > In your previous mail you wrote: > > > => this is my position but there is an exception: the update > > is to an authorized* address but from an unknown address. A > > RR check should be performed in this case, not because of a > > security issue, but because the node can have just moved > > behind a NAT (the RR check for the authorized address fails, > > the RR check for the unknown (in fact NATed) address succeeds). > > i have read this paragraph several times but i am not > quite sure that i > understood it. > > => I apologize. I tried many times to write a good text but > without success. thanks for your patience with me. i try hard to understand the arguments of everyone else. > So another tentative: > - the peer address set is known, each peer address has been > authorized i would phrase it a bit different. let us assume that the addresses available to a peer is called peer address set. i guess we also assume that these addresses are exchanged somehow i.e., each peer (initiator and responder of the mobike exchange) communicates its peer address set to the other peer. the peer address set might change over time and might therfore involve further communication between the peers. > - there are many ways to authorize an address, RR check can be one of > these ways ii can agree with this statement. > - an update can be done only to an authorized peer address > (if the peer > address is not yet authorized, it must be authorized before the > application of the update) i am not sure that this statement is correct. to explain what i have in mind i need to introduce another term: the preferred address the preferred address is used by mobike to send messages to the other peer. each peer needs to select a preferred address for communication. before an address is used as a preferred address it needs to be authorized. a peer might only have one address: the preferred address however, if it has more than one address (which is, for example, the case if it is multi-homed) then the other addresses might not be authorized (for example because they are in the queue to be experience the return-routability check). if i want to delete one of these addresses (for whatever reason) then why shouldn't i am allowed todo it? it is not used anyway. tbd: we need proper names for these individual addresses. jari provided some input on these addresses. i suggest to reuse whatever he suggested (i might have misused some terms already). > - an unknown peer address is an address which is not (was > never) in the > peer address test > - usually the peer registers (i.e., add in its announced > peer address set) > the address it uses for IKE messages but we can extend the previous > statement with "or was never used as the source of an IKE message" > So you get an update for an authorized/to-be-authorized peer > address in a message from an unknown source address: I argue > that both addresses (the one in the header and the one in the > message) must be RR checked because the initiator can have > just moved behind a NAT. let me rephrase this paragraph: a mobike peer receives a message which says: 'add ip abc to the peer address set.' additionally the mobike message was sent with a source address that the other peer has never seen before. this might, for example, the case in a break-before-make scenario. the ip address (abc in our example) might be the same as in the ip header (in some cases). now, it depends whether we would like to use the address 'abc' as the new preferred address. if so, then we should authorize it. which address should we test? - 'abc' (as indicated in the mobike message) or - source ip address the answer is: it depends whether we support nat traversal or not. if we use a nat prevention mechanism then the address 'abc' needs to be authorized. if we use nat-t then we should authorize the source ip address (in this case the address in the payload and 'abc' does not match). the answer which address we would like to test > > Can you reply if you have understood and propose a better > explaination? sure. see above. > ciao hannes > 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 Dec 20 04:14:30 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10221 for ; Mon, 20 Dec 2004 03:25:26 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6CDBEFB2BE; Mon, 20 Dec 2004 08:25:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 03CA1FB2B8; Mon, 20 Dec 2004 08:25:12 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 760CAFB2B8; Mon, 20 Dec 2004 08:25:10 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id 3E1A2FB2A3 for ; Mon, 20 Dec 2004 08:25:09 +0000 (UTC) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iBK8P7tr030703; Mon, 20 Dec 2004 09:25:07 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iBK8P7Zn019547; Mon, 20 Dec 2004 09:25:07 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Dec 2004 09:25:06 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B514@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Francis Dupont Subject: RE: [Mobike] When to do Return Routability Checks Date: Mon, 20 Dec 2004 09:25:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: mobike@machshav.com, 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 hi francis, this is issue is interesting. in a previous mail i had the impression that you argued that only an authorized address can be used for communication (non-return-routability-test messages). if you have an unauthorized address you need to perform some authorization check (which might require a return routability check) to turn this address into an authorized address which can subsequently be used. if my observation is correct then you also suggest to have a window larger than one in order for the protocol to work. is this correct? ciao hannes > > In your previous mail you wrote: > > > => we need more flexibility about moving the SA: to wait the > > RR check result is fine only when the previous peer address > > is still usable. > > => there are two cases when we move from peer address A to > peer address B: > - peer address A is still usable: the IKE SA should be updated > only after the end of the RR check > - peer address A is no more usable (the usual case with mobility): > the IKE SA (but not IPsec SAs) should be updated at the reception > of the update request > Two details: > - there is scenario where ASAP update is mandatory: imagine an window > of one message is used and there is a pending request to send: if > it is sent to the peer address A and this address no more works > the exchange will never finish. > - now how to know when an address is no more usable: with my address > management framework the initiator wll simply remove it > from the set. > > 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 Dec 20 12:08:47 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16281 for ; Mon, 20 Dec 2004 12:08:47 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 16919FB2B6; Mon, 20 Dec 2004 17:08:48 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 80326FB2B1; Mon, 20 Dec 2004 17:08:45 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 627DFFB2B1; Mon, 20 Dec 2004 17:08:43 +0000 (UTC) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id A3853FB291 for ; Mon, 20 Dec 2004 17:08:42 +0000 (UTC) Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iBKH5PQ20399; Mon, 20 Dec 2004 09:05:25 -0800 (PST) Message-ID: <41C7064A.9030203@isi.edu> Date: Mon, 20 Dec 2004 09:05:14 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: [Mobike] issue #16 References: <2A8DB02E3018D411901B009027FD3A3F0542C99A@mchp905a.mch.sbs.de> <41B8D7B3.4040701@isi.edu> <41BEFDC1.8020500@piuha.net> <41BF3F71.5090706@isi.edu> <41C19C24.8000208@piuha.net> <41C36F16.5060706@isi.edu> <41C3EE6E.4000803@piuha.net> In-Reply-To: <41C3EE6E.4000803@piuha.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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="===============0920710991==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0920710991== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig35EBC6EC4606CB20224F9DE5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig35EBC6EC4606CB20224F9DE5 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Joe Touch wrote: > >> | (1) You are OK with explicit management of addresses >> | when we have local information from the other >> | parts of the stack that we need to do something, >> | such as when the currently used link went down, >> | ND tells us that we have moved to a new address, >> | and so on. >> >> Not quite - I don't buy the part about the 'link going down'. All you >> know is that the other end isn't reachable. Reacting to links is what >> dynamic routing does; if this layer does it as well, there's liable to >> be interactions (in a bad way). > > > Maybe I described it too vaguely... I did not mean just > any links -- that's in the routing domain. > > If the WLAN interface of my laptop goes down there's nothing > in the routing system that reacts to this. On which end? On your end, there is. On the other end, there may or may not be depending on the level to which dynamic routing changes are propagated. > A host is no > longer reachable at that address. End of story. Agnosticism is useful here; just because you can't reach the other end does't mean you know ANYTHING for sure about why. Any link on the path could have gone down, or any routing on the path could have failed. > But perhaps > you are thinking of links within the routing system, such > as between routers? I agree that its definately out of scope > for MOBIKE. The end hosts running IKE would not even see > this. But they would see their own interface go down, which > I think is in scope. Seeing your own interface change and doing something seems OK - though I still feel it encourages YOUR IKE to interfere with YOUR dynamic routing (some people run that on the end host too). >> Trying a new mapping, or cycling among alternate names ought to happen >> when IKE starts anyway (at the app layer). > > ... > >> It depends on what the errors are. Some warrant a restart, some do not. >> But, IMO, they warrant restart of the IKE. > > ... > >> More that cycling among alternate addrs is something that ought to >> happen on start anyway - side-effect isn't quite the right term; it's >> more like 'already included explicit mechanism'. > > Its unclear to me what you mean by IKE "start" or "restart". The > purpose of MOBIKE is precisely to avoid having to re-run IKE from > the beginning for a mere address change. "mere" address change is the issue. It's fine to say that MOBIKE should cycle through equivalent addresses for the same endpoint; the question is WHEN, and how to avoid interference between dynamic routing and MOBIKE. Joe --------------enig35EBC6EC4606CB20224F9DE5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBxwZPE5f5cImnZrsRAgjKAJ0SV87coq2UGZM8F3KisJivJ/PbaQCgrQJf An/49m6kwjgZpKWtT8YnvQk= =LISF -----END PGP SIGNATURE----- --------------enig35EBC6EC4606CB20224F9DE5-- --===============0920710991== 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 --===============0920710991==-- From mobike-bounces@machshav.com Tue Dec 21 07:45:16 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03729 for ; Tue, 21 Dec 2004 07:45:14 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0E9C1FB281; Tue, 21 Dec 2004 12:45:14 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3AAC7FB27C; Tue, 21 Dec 2004 12:45:12 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 329CAFB27D; Tue, 21 Dec 2004 12:45:10 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id 354EFFB27A for ; Tue, 21 Dec 2004 12:45:09 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iBLCiutr029425; Tue, 21 Dec 2004 13:44:56 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iBLCitmC017649; Tue, 21 Dec 2004 13:44:55 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Dec 2004 13:44:55 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B675@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Bora Akyol , mobike@machshav.com Subject: RE: [Mobike] Re: Lack of packets from other end Date: Tue, 21 Dec 2004 13:44:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi bora, please see my comment below: > > Tschofenig Hannes wrote: > > | hi all, > > | > > | i guess we can close issue # 16: > > | "Can the protocol recover from situations where the only sign of > > problems is > > | lack of packets from the other end?" > > | http://www.vpnc.org/ietf-mobike/issue16.txt > > > > Internet paths that are silent aren't problems, IMO. > They're just idle > > network paths. > > > > This sounds like a job for a link layer, and I don't think mobike > > needs to be a link layer. > > > > Joe > > I agree with Joe here. There are legitimate situations where > there may be no packets from the other end for a long period > of time. We have DPD to detect a dead peer. If a peer moves > from one IP addr to another without notifying the security > gateway, I don't think it is the SG's job to detect and > recover from this. please note that we are addressing the issue of address changes for ikev2 peers only. we are not talking about fixing problems for entities which do not interact using ike. at the last ietf pasi presented a nice slide which showed the large number of protocols and entities involved in a network. he showed us that we are only addressing a subset of the problems and i agree with him. ciao hannes > > Regards, > > Bora > _______________________________________________ > 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 Dec 21 07:47:00 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03833 for ; Tue, 21 Dec 2004 07:46:59 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A3171FB281; Tue, 21 Dec 2004 12:46:59 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 60A94FB27C; Tue, 21 Dec 2004 12:46:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0FDAFFB27D; Tue, 21 Dec 2004 12:46:57 +0000 (UTC) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by machshav.com (Postfix) with ESMTP id 94DC6FB27A for ; Tue, 21 Dec 2004 12:46:55 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iBLCkqYq016602; Tue, 21 Dec 2004 13:46:52 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iBLCkqmC019923; Tue, 21 Dec 2004 13:46:52 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Dec 2004 13:46:51 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B679@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: jari.arkko@piuha.net, Joe Touch Subject: RE: [Mobike] issue #16 Date: Tue, 21 Dec 2004 13:46:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi jari, please see a small comment below: > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Dienstag, 14. Dezember 2004 15:51 > To: Joe Touch > Cc: MOBIKE Mailing List; Tschofenig Hannes > Subject: Re: [Mobike] issue #16 > > Joe Touch wrote: > > > Internet paths that are silent aren't problems, IMO. > They're just idle > > network paths. > > Yes. > > > This sounds like a job for a link layer, and I don't think mobike > > needs to be a link layer. > > The link layer certainly has its own mechanisms, as does IP > on top of it (e.g. IPv6 NUD). But these are for a link, what > we are talking about here is a path through the Internet. > More specifically, the question is what to do if IKEv2 DPD > tells us that its not getting through. Should we (a) kill the > connection or (b) switch to another address we have? I think > the latter... i also agree with you here and i think that this is pretty much in line with the approach taken by sctp. even if a problem is detected locally (e.g., problem with the network card) then sctp does not delete the ip address but changes the preferred address. the problem might soon go away . ciao hannes > > --Jari > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 21 07:48:22 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03916 for ; Tue, 21 Dec 2004 07:48:22 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6B403FB280; Tue, 21 Dec 2004 12:48:22 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6BFACFB27C; Tue, 21 Dec 2004 12:48:20 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1DCECFB27D; Tue, 21 Dec 2004 12:48:19 +0000 (UTC) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by machshav.com (Postfix) with ESMTP id EEB3AFB27A for ; Tue, 21 Dec 2004 12:48:17 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iBLCmAtr001916; Tue, 21 Dec 2004 13:48:10 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iBLCmAmC021655; Tue, 21 Dec 2004 13:48:10 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Dec 2004 13:48:09 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B67A@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Joe Touch , jari.arkko@piuha.net Subject: RE: [Mobike] issue #16 Date: Tue, 21 Dec 2004 13:48:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi all, maybe we get a little bit lost on this particular issue. what are we discussing here? here is my short summary: a) mobike might get information from other protocols. this might indicate that there is something wrong with the currently selected preferred address. mobike does not specify with which protocols it needs to interact and it does not specify the policy for changing the preferred address. this is implementation dependent. b) there is also a mechanism to detect that something happened along the path between the ikev2 initiator and the ikev2 responder using some sort of message exchange (we called it dead-peer detection - which is not the best name for it; sctp folks called it heartbeat). this message exchange might reveal that something is wrong along the path between from a given source address towards a destination address. this might require a new preferred address to be selected. this new preferred address needs to be communicated to the other ikev2 peer. the format of these messages will be found in a mobike specification. btw, we are not the first discussing this area. there has been a lot of work in the context of sctp on this issue. i have the impression that they have the same view on it. hence, i think that there are not particular problems here (except that we are a little bit struggling with terminology issues). ciao hannes Jari Arkko wrote: > Joe Touch wrote: > >> | (1) You are OK with explicit management of addresses >> | when we have local information from the other >> | parts of the stack that we need to do something, >> | such as when the currently used link went down, >> | ND tells us that we have moved to a new address, >> | and so on. >> >> Not quite - I don't buy the part about the 'link going down'. All you >> know is that the other end isn't reachable. Reacting to links is what >> dynamic routing does; if this layer does it as well, there's liable to >> be interactions (in a bad way). > > > Maybe I described it too vaguely... I did not mean just > any links -- that's in the routing domain. > > If the WLAN interface of my laptop goes down there's nothing > in the routing system that reacts to this. On which end? On your end, there is. On the other end, there may or may not be depending on the level to which dynamic routing changes are propagated. > A host is no > longer reachable at that address. End of story. Agnosticism is useful here; just because you can't reach the other end does't mean you know ANYTHING for sure about why. Any link on the path could have gone down, or any routing on the path could have failed. > But perhaps > you are thinking of links within the routing system, such > as between routers? I agree that its definately out of scope > for MOBIKE. The end hosts running IKE would not even see > this. But they would see their own interface go down, which > I think is in scope. Seeing your own interface change and doing something seems OK - though I still feel it encourages YOUR IKE to interfere with YOUR dynamic routing (some people run that on the end host too). >> Trying a new mapping, or cycling among alternate names ought to happen >> when IKE starts anyway (at the app layer). > > ... > >> It depends on what the errors are. Some warrant a restart, some do not. >> But, IMO, they warrant restart of the IKE. > > ... > >> More that cycling among alternate addrs is something that ought to >> happen on start anyway - side-effect isn't quite the right term; it's >> more like 'already included explicit mechanism'. > > Its unclear to me what you mean by IKE "start" or "restart". The > purpose of MOBIKE is precisely to avoid having to re-run IKE from > the beginning for a mere address change. "mere" address change is the issue. It's fine to say that MOBIKE should cycle through equivalent addresses for the same endpoint; the question is WHEN, and how to avoid interference between dynamic routing and MOBIKE. Joe _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 21 07:56:52 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04276 for ; Tue, 21 Dec 2004 07:56:51 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E9885FB27A; Tue, 21 Dec 2004 12:56:50 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1D6BBFB27C; Tue, 21 Dec 2004 12:56:47 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4CDCCFB27D; Tue, 21 Dec 2004 12:56:45 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 483FFFB27A for ; Tue, 21 Dec 2004 12:56:44 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E1C4089856; Tue, 21 Dec 2004 14:56:41 +0200 (EET) Message-ID: <41C81D73.2010403@piuha.net> Date: Tue, 21 Dec 2004 14:56:19 +0200 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: Tschofenig Hannes Subject: Re: [Mobike] Re: Lack of packets from other end References: <2A8DB02E3018D411901B009027FD3A3F0550B675@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0550B675@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Bora Akyol 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 Tschofenig Hannes wrote: > please note that we are addressing the issue of address changes for ikev2 peers only. we are not talking about fixing problems for entities which do not interact using ike. at the last ietf pasi presented a nice slide which showed the large number of protocols and entities involved in a network. he showed us that we are only addressing a subset of the problems and i agree with him. I agree with this too. And Bora wrote: > I agree with Joe here. There are legitimate situations where > there may be no packets from the other end for a long period > of time. We have DPD to detect a dead peer. If a peer moves > from one IP addr to another without notifying the security > gateway, I don't think it is the SG's job to detect and > recover from this. In fact, it would be *impossible* for the SG to recover from it, because it has no other address for the peer in the case that you mention above. The only question we have on the table is whether an indication from the DPD causes a change in the currently preferred address, *if* the peer has previously indicated that it has several addresses. Past practise (SCTP) and ongoing designs (HIP, MULTI6) all have the approach where the preferred address would be changed in a situation like that. (Another question would be whether the client or the SG needs is responsible for detecting and correcting a choice. I don't want to open that discussion yet, but in general I like the client or the initiator to be responsible for as much as possible, unless protocol symmetry requires otherwise.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 21 08:00:00 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04380 for ; Tue, 21 Dec 2004 07:59:58 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 945ACFB281; Tue, 21 Dec 2004 12:59:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DF427FB27C; Tue, 21 Dec 2004 12:59:56 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 62B9BFB27D; Tue, 21 Dec 2004 12:59:55 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 4B5EBFB27A for ; Tue, 21 Dec 2004 12:59:54 +0000 (UTC) Received: from piuha.net (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7FBE889856; Tue, 21 Dec 2004 14:59:53 +0200 (EET) Message-ID: <41C81E33.7060005@piuha.net> Date: Tue, 21 Dec 2004 14:59:31 +0200 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: Tschofenig Hannes Subject: Re: [Mobike] issue #16 References: <2A8DB02E3018D411901B009027FD3A3F0550B67A@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0550B67A@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Joe Touch 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 Hi Hannes, and thanks for summarizing! Inline: > a) mobike might get information from other protocols. this might indicate > that there is something wrong with the currently selected preferred address. > mobike does not specify with which protocols it needs to interact and it > does not specify the policy for changing the preferred address. this is > implementation dependent. Right. > b) there is also a mechanism to detect that something happened along the > path between the ikev2 initiator and the ikev2 responder using some sort of > message exchange (we called it dead-peer detection - which is not the best > name for it; sctp folks called it heartbeat). > this message exchange might reveal that something is wrong along the path > between from a given source address towards a destination address. this > might require a new preferred address to be selected. this new preferred Yes. > address needs to be communicated to the other ikev2 peer. Note: this might also be an address that both peers already know about, but they have been using the one that is now in trouble, according to DPD. > the format of these messages will be found in a mobike specification. > > btw, we are not the first discussing this area. there has been a lot of work > in the context of sctp on this issue. i have the impression that they have > the same view on it. Yes. > hence, i think that there are not particular problems here I agree. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 21 12:25:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00433 for ; Tue, 21 Dec 2004 12:25:18 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 56240FB280; Tue, 21 Dec 2004 17:25:17 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E587BFB26F; Tue, 21 Dec 2004 17:25:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B2A58FB27A; Tue, 21 Dec 2004 17:25:12 +0000 (UTC) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id EA725FB266 for ; Tue, 21 Dec 2004 17:25:11 +0000 (UTC) Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iBLHNVQ14275; Tue, 21 Dec 2004 09:23:31 -0800 (PST) Message-ID: <41C85C08.6010605@isi.edu> Date: Tue, 21 Dec 2004 09:23:20 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes Subject: Re: [Mobike] issue #16 References: <2A8DB02E3018D411901B009027FD3A3F0550B67A@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0550B67A@mchp905a.mch.sbs.de> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu 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: , Content-Type: multipart/mixed; boundary="===============0258249917==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0258249917== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAA77F3499A9DDFA94D4AC27C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAA77F3499A9DDFA94D4AC27C Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > hi all, > > maybe we get a little bit lost on this particular issue. what are we > discussing here? here is my short summary: ... > btw, we are not the first discussing this area. there has been a lot of work > in the context of sctp on this issue. i have the impression that they have > the same view on it. That is not necessarily a good thing. Multi6 decided to avoid encouraging higher layers handling multihoming for several reasons: - need to reinvent the wheel for every layer above network - interactions between network layer solutions and upper layer solutions It would be useful to at least review their progress on this issue. Joe --------------enigAA77F3499A9DDFA94D4AC27C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFByFwOE5f5cImnZrsRAtPrAJ0ZLiWQJMnjTKbo1jBnMo1szrk61gCg68PK qMiFy3nfOCkvzRbC5aKbfV4= =Gl1P -----END PGP SIGNATURE----- --------------enigAA77F3499A9DDFA94D4AC27C-- --===============0258249917== 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 --===============0258249917==-- From mobike-bounces@machshav.com Tue Dec 21 18:51:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21576 for ; Tue, 21 Dec 2004 18:51:16 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id AF8CFFB281; Tue, 21 Dec 2004 23:51:12 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 11289FB27A; Tue, 21 Dec 2004 23:51:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5F37AFB27C; Tue, 21 Dec 2004 23:51:09 +0000 (UTC) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by machshav.com (Postfix) with ESMTP id DDD39FB26F for ; Tue, 21 Dec 2004 23:51:08 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iBLNp0pv026523; Tue, 21 Dec 2004 15:51:01 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iBLNoxJd015802; Tue, 21 Dec 2004 18:50:59 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iBLNoxMH009511; Tue, 21 Dec 2004 18:50:59 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iBLNosQq009509; Tue, 21 Dec 2004 18:50:54 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: [Mobike] issue 3: nat traversal From: Bill Sommerfeld To: Tschofenig Hannes In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F0550B512@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F0550B512@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1103673053.7998.58.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Tue, 21 Dec 2004 18:50:54 -0500 Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Mohan Parthasarathy , Francis Dupont 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, 2004-12-20 at 03:25, Tschofenig Hannes wrote: > my impression so far was that we cannot assume that there are some protocols > which allow to securely obtain a nat binding. if we manage it to update > existing nats to provide this type of protocol support then i would be very > happy. however, we would liket to have a protocol which can be deployed > today (even if there are some limitations). In the meantime, I wonder if we could get any leverage out of a "NAT expected" bit -- carried in a secured part of the protocol. This would need to be administratively configured. It would probably have to default to "on". If both peers have that bit cleared you would do NAT prevention; otherwise, you would do NAT traversal if a NAT is detected. - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 21 19:41:22 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26884 for ; Tue, 21 Dec 2004 19:41:20 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8925FFB285; Wed, 22 Dec 2004 00:41:21 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 23AD3FB27F; Wed, 22 Dec 2004 00:41:20 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ED407FB280; Wed, 22 Dec 2004 00:41:18 +0000 (UTC) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id 5F06AFB27A for ; Wed, 22 Dec 2004 00:41:18 +0000 (UTC) Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBM0f2Uq039927; Tue, 21 Dec 2004 16:41:05 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1103673053.7998.58.camel@thunk> References: <2A8DB02E3018D411901B009027FD3A3F0550B512@mchp905a.mch.sbs.de> <1103673053.7998.58.camel@thunk> Date: Tue, 21 Dec 2004 16:41:05 -0800 To: Bill Sommerfeld , Tschofenig Hannes From: Paul Hoffman / VPNC Subject: RE: [Mobike] issue 3: nat traversal Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: jari.arkko@piuha.net, Mohan Parthasarathy , MOBIKE Mailing List , Francis Dupont 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 6:50 PM -0500 12/21/04, Bill Sommerfeld wrote: >In the meantime, I wonder if we could get any leverage out of a "NAT expected" >bit -- carried in a secured part of the protocol. This would need to be >administratively configured. It would probably have to default to "on". How would an administrator know how to set that bit? Is the expectation they would do so by testing first? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 21 20:37:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01802 for ; Tue, 21 Dec 2004 20:37:57 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 93CF1FB28B; Wed, 22 Dec 2004 01:37:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 624B5FB27F; Wed, 22 Dec 2004 01:37:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A7369FB280; Wed, 22 Dec 2004 01:37:50 +0000 (UTC) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by machshav.com (Postfix) with ESMTP id 2E8DAFB27A for ; Wed, 22 Dec 2004 01:37:50 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iBM1bjiI016037; Tue, 21 Dec 2004 17:37:46 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iBM1bj8p014427; Tue, 21 Dec 2004 20:37:45 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iBM1bjnd009874; Tue, 21 Dec 2004 20:37:45 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iBM1bj9q009873; Tue, 21 Dec 2004 20:37:45 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: [Mobike] issue 3: nat traversal From: Bill Sommerfeld To: Paul Hoffman / VPNC In-Reply-To: References: <2A8DB02E3018D411901B009027FD3A3F0550B512@mchp905a.mch.sbs.de> <1103673053.7998.58.camel@thunk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1103679460.7998.152.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Tue, 21 Dec 2004 20:37:41 -0500 Cc: MOBIKE Mailing List , Mohan Parthasarathy , jari.arkko@piuha.net, Francis Dupont , Tschofenig Hannes 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, 2004-12-21 at 19:41, Paul Hoffman / VPNC wrote: > At 6:50 PM -0500 12/21/04, Bill Sommerfeld wrote: > >In the meantime, I wonder if we could get any leverage out of a "NAT expected" > >bit -- carried in a secured part of the protocol. This would need to be > >administratively configured. It would probably have to default to "on". > > How would an administrator know how to set that bit? First off, it's only interesting to people who want to do (selective) nat prevention. To clarify, "nat expected" false means "I don't expect *my* address to be rewritten by a NAT". So an administrator who assigned systems globally unique globally routed ipv4 addresses, who wanted to avoid nat-like attacks when talking to other systems with globally unique globally routed addresses, could clear the "nat expected" bit for those addresses on those systems. - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 21 20:45:16 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02163 for ; Tue, 21 Dec 2004 20:45:14 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C21C8FB28A; Wed, 22 Dec 2004 01:45:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E16C0FB282; Wed, 22 Dec 2004 01:45:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 28977FB284; Wed, 22 Dec 2004 01:45:11 +0000 (UTC) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id B19B9FB281 for ; Wed, 22 Dec 2004 01:45:10 +0000 (UTC) Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBM1j1Cb056424; Tue, 21 Dec 2004 17:45:02 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1103679460.7998.152.camel@thunk> References: <2A8DB02E3018D411901B009027FD3A3F0550B512@mchp905a.mch.sbs.de> <1103673053.7998.58.camel@thunk> <1103679460.7998.152.camel@thunk> Date: Tue, 21 Dec 2004 17:45:05 -0800 To: Bill Sommerfeld From: Paul Hoffman / VPNC Subject: RE: [Mobike] issue 3: nat traversal Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: MOBIKE Mailing List , Mohan Parthasarathy , jari.arkko@piuha.net, Francis Dupont , Tschofenig Hannes 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:37 PM -0500 12/21/04, Bill Sommerfeld wrote: >To clarify, "nat expected" false means "I don't expect *my* address >to be rewritten by a NAT". Ah! That's good, because it is certainly more predictable. >So an administrator who assigned systems globally unique globally routed ipv4 >addresses, who wanted to avoid nat-like attacks when talking to other systems >with globally unique globally routed addresses, could clear the "nat expected" >bit for those addresses on those systems. That makes it much easier to predict. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 21 22:25:34 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12523 for ; Tue, 21 Dec 2004 22:25:33 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CD221FB281; Wed, 22 Dec 2004 03:25:33 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2F600FB26F; Wed, 22 Dec 2004 03:25:29 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DA3A6FB27A; Wed, 22 Dec 2004 03:25:26 +0000 (UTC) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id 5F985FB266 for ; Wed, 22 Dec 2004 03:25:26 +0000 (UTC) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Dec 2004 20:33:26 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iBM3PAo9029252; Tue, 21 Dec 2004 19:25:21 -0800 (PST) Received: from boraw2k04 ([10.32.241.194]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUY34413; Tue, 21 Dec 2004 19:25:12 -0800 (PST) Message-Id: <200412220325.AUY34413@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: , "'Tschofenig Hannes'" Subject: RE: [Mobike] Re: Lack of packets from other end Date: Tue, 21 Dec 2004 19:24:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcTnyHGYB0it9eP7SoyRiGnlJmeGXgADRz2A In-Reply-To: <41C81D73.2010403@piuha.net> 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 > > In fact, it would be *impossible* for the SG to recover from > it, because it has no other address for the peer in the case > that you mention above. The only question we have on the > table is whether an indication from the DPD causes a change > in the currently preferred address, > *if* the peer has previously indicated that it has several > addresses. Past practise (SCTP) and ongoing designs (HIP, > MULTI6) all have the approach where the preferred address > would be changed in a situation like that. > > (Another question would be whether the client or the SG needs > is responsible for detecting and correcting a choice. > I don't want to open that discussion yet, but in general I > like the client or the initiator to be responsible for as > much as possible, unless protocol symmetry requires > otherwise.) > > --Jari > > Jari, I think we are in agreement, I would like to keep the SG as simple as possible. It needs to have enough smarts to clean-up garbage state, but if the client has switched to an alternate address, I think it should __really__ let the SG know. We may need some logic to do Make-before-break type switch like is common on cell phone networks. Thanks Bora _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 21 22:37:04 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13583 for ; Tue, 21 Dec 2004 22:37:03 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 81EA6FB281; Wed, 22 Dec 2004 03:37:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6724CFB27A; Wed, 22 Dec 2004 03:37:02 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4B76CFB27C; Wed, 22 Dec 2004 03:37:01 +0000 (UTC) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by machshav.com (Postfix) with ESMTP id A8DBCFB266 for ; Wed, 22 Dec 2004 03:37:00 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iBM3ardt011288; Tue, 21 Dec 2004 20:36:54 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iBM3arJd015980; Tue, 21 Dec 2004 22:36:53 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iBM3arka010393; Tue, 21 Dec 2004 22:36:53 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iBM3aeV9010392; Tue, 21 Dec 2004 22:36:40 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: [Mobike] Re: Lack of packets from other end From: Bill Sommerfeld To: Bora Akyol In-Reply-To: <200412220325.AUY34413@mira-sjc5-e.cisco.com> References: <200412220325.AUY34413@mira-sjc5-e.cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1103686600.7998.206.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Tue, 21 Dec 2004 22:36:40 -0500 Cc: mobike@machshav.com, jari.arkko@piuha.net, "'Tschofenig Hannes'" 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, 2004-12-21 at 22:24, Bora Akyol wrote: > We may need some > logic to do Make-before-break type switch like is common on cell phone > networks. that's the entire point of attaching sctp-like multiple addresses to IKE and IPsec SA's. anyhow, to respond to an earlier question of yours: - if the SG's peer has given us multiple addresses - and the SG is also a stateful firewall of some sort then it should be capable of noticing that traffic to the peer *should* have provoked a response (e.g., any non-pure-ACK TCP segment) but *didn't*. if the SG is not acting as a stateful firewall I wouldn't expect it to do this sort of thing. decouple the source of the hints that all is not well from the action taken when you notice all is not well, and leave which hints to use open-ended for now.. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 21 22:56:10 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14913 for ; Tue, 21 Dec 2004 22:56:09 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 52133FB27C; Wed, 22 Dec 2004 03:56:11 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 34D72FB246; Wed, 22 Dec 2004 03:56:09 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 019FFFB27F; Wed, 22 Dec 2004 03:56:07 +0000 (UTC) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id 497A0FB27A for ; Wed, 22 Dec 2004 03:56:06 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Dec 2004 21:04:05 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iBM3trdP004506; Tue, 21 Dec 2004 19:55:54 -0800 (PST) Received: from boraw2k04 ([10.32.241.194]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AUY35414; Tue, 21 Dec 2004 19:55:57 -0800 (PST) Message-Id: <200412220355.AUY35414@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'Bill Sommerfeld'" Subject: RE: [Mobike] Re: Lack of packets from other end Date: Tue, 21 Dec 2004 19:55:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcTn14GC8e378b38S36GuZHE2hTHiAAAO+1Q In-Reply-To: <1103686600.7998.206.camel@thunk> Cc: mobike@machshav.com, jari.arkko@piuha.net, "'Tschofenig Hannes'" 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 > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@sun.com] > Sent: Tuesday, December 21, 2004 7:37 PM > To: Bora Akyol > Cc: jari.arkko@piuha.net; 'Tschofenig Hannes'; mobike@machshav.com > Subject: RE: [Mobike] Re: Lack of packets from other end > > On Tue, 2004-12-21 at 22:24, Bora Akyol wrote: > > We may need some > > logic to do Make-before-break type switch like is common on > cell phone > > networks. > > that's the entire point of attaching sctp-like multiple > addresses to IKE and IPsec SA's. > > anyhow, to respond to an earlier question of yours: > > - if the SG's peer has given us multiple addresses > - and the SG is also a stateful firewall of some sort > > then it should be capable of noticing that traffic to the peer > *should* have provoked a response (e.g., any non-pure-ACK TCP > segment) but *didn't*. > > if the SG is not acting as a stateful firewall I wouldn't > expect it to do this sort of thing. decouple the source of > the hints that all is not well from the action taken when you > notice all is not well, and leave which hints to use > open-ended for now.. Bill While I see your point, IMHO, I think we should keep the functionality required on both the SG and the client as simple as possible for now. The fact that the client may have multiple addresses is __nice__ but realistically, how many of the enterprise, home, or public Internet access networks can guarantee that the client will have the same address for an extended period of time. Yes, this is doable via DHCP (and other means like static addresses), but it remains an assumption. By the way, clearly I don't want to exclude IPv4 and IPv6 coexisting for the same client. This is one case that (IMHO) would be really nice to support (although it may play funny games with the SP implementation). I believe the existing version of the draft defines several workable scenarios, I think we should find the minimum required functionality, and work towards that as the goal for v1 of MOBIKE. With generic goals I would add as: 1) Scalable (say up to 1000000 clients per node) 2) Brain-dead simple to implement with as little as possible "optional", "SHALL", "MAY" wording as possible. As little exceptions, omitted functionality etc for special kinds of devices. 3) Supporting the minimal required scenario as I eluded to below. I think once there is agreement (and I acknowledge that I am a latecomer to the process and apologize for it here) on the minimum acceptable set of requirements, we can quickly move towards the solutions. Thank you for your comments, Bora _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Dec 28 08:21:45 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25376 for ; Tue, 28 Dec 2004 08:21:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id F1FBDFB2A3; Tue, 28 Dec 2004 13:21:44 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3986DFB28B; Tue, 28 Dec 2004 13:21:44 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 84F42FB2A0; Tue, 28 Dec 2004 13:21:42 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by machshav.com (Postfix) with ESMTP id 9A6C4FB27D for ; Tue, 28 Dec 2004 13:21:41 +0000 (UTC) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iBSDLbVi015385; Tue, 28 Dec 2004 14:21:37 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iBSDLbmC009252; Tue, 28 Dec 2004 14:21:37 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Dec 2004 14:21:36 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B8A0@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Joe Touch Subject: RE: [Mobike] issue #16 Date: Tue, 28 Dec 2004 14:21:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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 hi joe, please see my comment inline. > Tschofenig Hannes wrote: > > hi all, > > > > maybe we get a little bit lost on this particular issue. > what are we > > discussing here? here is my short summary: > ... > > btw, we are not the first discussing this area. there has > been a lot > > of work in the context of sctp on this issue. i have the impression > > that they have the same view on it. > > That is not necessarily a good thing. Multi6 decided to avoid > encouraging higher layers handling multihoming for several reasons: > > - need to reinvent the wheel for every layer above network > - interactions between network layer solutions and upper layer > solutions > > It would be useful to at least review their progress on this issue. actually, i was trying to emphasis that we should also take a look at other working groups (particularly those that dealt with some aspects of the problem already). i think that this is a different issue than encouraging higher layer protocols to perform multihoming handling. (btw, i bet that the sctp folks just think the other way around. hence, if we try to address this religious aspects then we are lost anyway. i would like to avoid this discussion. they are just different areas with a different set of scenarios.) ciao hannes > > Joe > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mailman-bounces@machshav.com Sat Jan 1 00:02:15 2005 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15513 for ; Sat, 1 Jan 2005 00:02:14 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6A317FB281; Sat, 1 Jan 2005 05:02:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CCEEDFB2EB for ; Sat, 1 Jan 2005 05:01:10 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: machshav.com mailing list memberships reminder From: mailman-owner@machshav.com To: mobike-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:00:15 +0000 Precedence: bulk X-BeenThere: mailman@machshav.com X-Mailman-Version: 2.1.4 List-Id: mailman.machshav.com X-List-Administrivia: yes Sender: mailman-bounces@machshav.com Errors-To: mailman-bounces@machshav.com Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your machshav.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@machshav.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@machshav.com. Thanks! Passwords for mobike-archive@lists.ietf.org: List Password // URL ---- -------- mobike@machshav.com behoef https://www.machshav.com/mailman/options.cgi/mobike/mobike-archive%40lists.ietf.org