From mailman-bounces@machshav.com Fri Oct 1 01:02:01 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06575 for ; Fri, 1 Oct 2004 01:01:59 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 44010FB286; Fri, 1 Oct 2004 01:01:59 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 53E56FB348 for ; Fri, 1 Oct 2004 01:00:47 -0400 (EDT) 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: Fri, 01 Oct 2004 05:00:12 +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 From mobike-bounces@machshav.com Mon Oct 11 09:02:32 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03896 for ; Mon, 11 Oct 2004 09:02:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8CA25FB2B9; Mon, 11 Oct 2004 13:02:31 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EC038FB2B7; Mon, 11 Oct 2004 13:01:27 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2A99EFB251; Mon, 11 Oct 2004 09:28:51 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 81C23FB23E for ; Mon, 11 Oct 2004 09:28:50 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 489F789877; Mon, 11 Oct 2004 12:28:48 +0300 (EEST) Message-ID: <416A51FC.8060007@piuha.net> Date: Mon, 11 Oct 2004 12:27:24 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 17: Full connectivity References: <052E0C61B69C3741AFA5FE88ACC775A6010C3C0E@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3C0E@esebe023.ntc.nokia.com> 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 While the discussion in this thread wondered into some related subjects as well, it seems that everyone supported not assuming full connectivity between all (operational) addresses. Can we close this issue? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 09:02:39 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03914 for ; Mon, 11 Oct 2004 09:02:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5358FFB2FC; Mon, 11 Oct 2004 13:02:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 39E0CFB2BA; Mon, 11 Oct 2004 13:01:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 90312FB251; Mon, 11 Oct 2004 10:15:46 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 50960FB23E for ; Mon, 11 Oct 2004 10:15:45 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 3402189880; Mon, 11 Oct 2004 13:15:44 +0300 (EEST) Message-ID: <416A5CFC.8070107@piuha.net> Date: Mon, 11 Oct 2004 13:14:20 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mobike] New issue 16: No packets from other end? References: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com> <41214396.4010803@iprg.nokia.com> In-Reply-To: <41214396.4010803@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.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 Vijay Devarapalli wrote: > I am not sure how you can do that. what if the application > prefers "failing" to using an expensive link? > > for example, lets assume my mobile device has a low bandwidth > GPRS link (address IP1 on that link) and a high bandwidth WLAN > link (address IP2 on that link). I have set it up so that my > email is downloaded only when I connect to my Enterprise > through a VPN connection when I have the WLAN link. if the > WLAN link is not available, I dont want the email client to > download email. lets assume I am in the middle of downloading > email. I lose WLAN coverage. with your proposal, the MOBIKE > protocol switches to using IP1. I dont want that. I agree with your scenario. > IMHO, I prefer "something in the Mobile Node" telling MOBIKE, > "switch to using this address with this VPN GW". then a MOBIKE > update should be sent. this is the model I had in my mind. > > for "something in the Mobile Node" I had assumed DNA, MIP6, > Multi6, new address configuration, default router change, etc... I believe there's two levels of issue involved here. On the first level, I think we have consensus that "something in the mobile node" should be able to tell MOBIKE that there's a new address or that a particular interface and its addresses are no longer usable because the router went down. I also think that we have consensus that at least most of this is outside MOBIKE protocol and WG scope. They are better handled in IPv6/DNA/DHC/MIP6 WGs. Finally, I believe your policy issue about which interface should be used is also at this level. And like I said, I agree with your requirement that it should be possible to express such policies. I think the others will agree too. However, that's the part that the rest of the stack is telling MOBIKE. The second level is what happens after MOBIKE has been told something. For instance, lets say that it has been told that there's two usable addresses at this end and one at the other end; that's two possible address pairs. Now we get a problem -- ESP tells IKE that there's no packets, IKE attempts DPD which fails. There's no information coming from IPv6/DNA/DHC/MIP6 (and presumably there will not be any information coming soon either, because the DPD process took a while). Now what? Are people saying that (1) Its okay for the MOBIKE peers to attempt recovery at the MOBIKE level by switching to another address pair. (2) Its not okay. MOBIKE/IKEv2/IPsec should fail and wait for the rest of the stack to inform when there's again an operational address. If problems on the path need to be handled, this would imply the development of a new, separate protocol for testing paths. Note that ICMP/TCP/app may already have told us of a problem with the current communications just as DPD did. But what we need is finding _another_ pair that works. No protocol that I know does that right now. Most of what we have in IPv6/DNA etc is focused on local issues, such as availability of the router. (Assuming the "first level" is handled as explained earlier -- outside MOBIKE -- my personal preference would be #1.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 09:02:46 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03933 for ; Mon, 11 Oct 2004 09:02:45 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5ABC3FB2BB; Mon, 11 Oct 2004 13:02:46 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 10ABAFB27A; Mon, 11 Oct 2004 13:01:36 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C67E5FB251; Mon, 11 Oct 2004 11:14:34 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 8A0A1FB23E for ; Mon, 11 Oct 2004 11:14:33 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 8DCEC89860; Mon, 11 Oct 2004 14:14:31 +0300 (EEST) Message-ID: <416A6AC3.9060503@piuha.net> Date: Mon, 11 Oct 2004 14:13:07 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atul.Sharma@nokia.com Subject: Re: [Mobike] New issue 18: Threat discussion References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Francis Dupont 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 think we already agreed that (say) AH can be used to fight this in general. However, I wanted to make a couple of additional points. First, this type of packet modification vulnerabilities appear to come in two variants: those where you have to be a mitm during the beginning of a session vs. you can change the addresses at any time. I believe IKEv2 situation is of the latter type, as long as some NAT was discovered initially. Plain IP traffic is however typically of the former type: changing an address in a packet would not redirect a TCP stream in middle of a session. Secondly, the AH protection that Francis mentioned is obviously for "other" protocols and for payload packets. The protocol that creates the SAs for this protection can, however, also have the vulnerability. I think that's the issue that we are talking about here... --Jari Atul.Sharma@nokia.com wrote: > Actually, let me rephrase: > > I do not want to imply that "transient pseudo-NAT" attack has no > relevance for MOBIKE. MOBIKE is all about authenticated management > of (change of) address. And "pseudo-NAT" is about malicious change > of address. > > So there is definite relevance there. > > The issue is that problem can be manifested in several scenarios > other than just IKE. It may make sense to either do a general solution > (else where?) or if we do MOBIKE-specific solution, we should let > other affected working groups be made aware of it. > > Atul > > >>-----Original Message----- >>From: mobike-bounces@machshav.com >>[mailto:mobike-bounces@machshav.com]On >>Behalf Of ext >>Sent: Thursday, September 02, 2004 2:24 PM >>To: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com >>Subject: RE: [Mobike] New issue 18: Threat discussion >> >> >> >>Hi Pasi, >> >>Why are we in MOBIKE trying to solve "transient pseudo-NAT" attack? >>The problem is of general nature, and will impact IP, IPsec traffic >>as much as (MOB)IKE traffic. >> >>Any solution to this attack has to be of general nature rather than >>MOBIKE-specific solution just working for MOBIKE. >> >>Just trying to understand.... >> >>Best, >>Atul >> >> >> >>>-----Original Message----- >>>From: mobike-bounces@machshav.com >>>[mailto:mobike-bounces@machshav.com]On >>>Behalf Of ext >>>Sent: Tuesday, August 24, 2004 11:30 AM >>>To: mobike@machshav.com >>>Subject: [Mobike] New issue 18: Threat discussion >>> >>> >>>At the San Diego meeting I promised to create a new issue >>>about the various threats the protocol should consider. >>> >>>So far, we have at least the following (notation: the IKE >>>peers are A and B; C is an innocent victim). >>> >>> 1) Unauthenticated attacker directs the traffic stream >>> from B to a third party C, with the intent flooding C >>> with unwanted traffic. >>> >>> 2) Authenticated peer A directs the traffic stream from B >>> to a third party C, with the intent of flooding C with >>> unwanted traffic. >>> >>> 3) Unauthenticated attacker directs the traffic stream >>> from B to somewhere (perhaps to the attacker or /dev/null), >>> with the intent of preventing the legitimate peers from >>> communicating. >>> >>> 4) Unauthenticated attacker causes the IKE_SA to be >>> closed by modifying just one or two IKE packets (if >>> attacker can modify all packets, he can of course DoS). >>> >>>Do we have any other threats, assuming we don't need to >>>repeat those where MOBIKE doesn't change anything in >>>normal IKEv2? Should we add some discussion about these >>>to the design document and/or protocol proposals? >>> >>>(BTW, a comment about terminology: Francis has quite >>>consistently called case 1 "transient pseudo-NAT attack" >>>and case 2 "third party bombing". I (and several others) >>>have sometimes called both 1 and 2 third party bombing.) >>> >>>Cheers, >>>Pasi >>>_______________________________________________ >>>Mobike mailing list >>>Mobike@machshav.com >>>https://www.machshav.com/mailman/listinfo.cgi/mobike >>> >> >>_______________________________________________ >>Mobike mailing list >>Mobike@machshav.com >>https://www.machshav.com/mailman/listinfo.cgi/mobike >> > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 09:02:50 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03951 for ; Mon, 11 Oct 2004 09:02:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 65B17FB291; Mon, 11 Oct 2004 13:02:49 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A1882FB2BC; Mon, 11 Oct 2004 13:01:38 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 012F0FB251; Mon, 11 Oct 2004 11:20:33 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id EF739FB23E for ; Mon, 11 Oct 2004 11:20:31 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id DD72C89877; Mon, 11 Oct 2004 14:20:30 +0300 (EEST) Message-ID: <416A6C2A.9060403@piuha.net> Date: Mon, 11 Oct 2004 14:19:06 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 18: Threat discussion References: <052E0C61B69C3741AFA5FE88ACC775A6010C3C10@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3C10@esebe023.ntc.nokia.com> 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 I think we concluded in this threat that your original list of four threats should become three, by merging threats 1 and 3. Francis made the point that the level of authentication makes a difference. Mohan made the point that there's a difference between packet modification (on-path) vs. independent (off-path) attacks. Atul asked about the need for more general protection of the threat 1 than what can be done in MOBIKE; I think we concluded that AH or something similar is sufficient for other protocols but people wanted MOBIKE to provide security against the attack. Taking this all into account, I think we have: 1) Unauthenticated attacker directs the traffic stream from B to a third party C, with the intent flooding C with unwanted traffic. The attacker can be either on-path or off-path. The latter is of course more serious, but easier defended attack. 2) Authenticated peer A directs the traffic stream from B to a third party C, with the intent of flooding C with unwanted traffic. The "authenticated peer" is the one that performed the initial IKE authentication. A request to update an address could be either unauthenticated, authenticated but leaving the actual address vulnerable for MITM modification. The validity of the new address could either be implied by the request or be independently verified; this verification could again require either no authentication at all, full authentication, or participation of the authenticated peer but leaving the address part unprotected. 3) Unauthenticated attacker causes the IKE_SA to be closed by modifying just one or two IKE packets (if attacker can modify all packets, he can of course DoS). --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 09:02:55 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03969 for ; Mon, 11 Oct 2004 09:02:54 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C1BC1FB2BF; Mon, 11 Oct 2004 13:02:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B0FC8FB277; Mon, 11 Oct 2004 13:01:44 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2C66EFB251; Mon, 11 Oct 2004 12:25:20 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 94613FB23E for ; Mon, 11 Oct 2004 12:25:19 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 8796D89860; Mon, 11 Oct 2004 15:25:18 +0300 (EEST) Message-ID: <416A7B5A.9040108@piuha.net> Date: Mon, 11 Oct 2004 15:23:54 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] transport mode document as WG item References: <200409261736.i8QHaXSj077621@givry.rennes.enst-bretagne.fr> In-Reply-To: <200409261736.i8QHaXSj077621@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I think there's agreement that the base Mobike should focus only on tunnel mode. In addition, it seems that there's interest (at least I personally feel so) on an extension that covers transport mode and helps applications such as SCTP or Mobile IPv6. But given that we still don't have a base Mobike specification done or even a WG document for the protocol, perhaps we should wait until IETF-61 before deciding to change Francis' document into a WG item. By then we should have more information on what the Mobike protocol does. (Everyone: lets work to move the base forward so we can get to the extensions too!) In the meanwhile, I think it would be very useful if additional people reviewed the transport mode document and Francis would post a revised version based on those reviews. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 09:02:56 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03984 for ; Mon, 11 Oct 2004 09:02:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 69677FB2B4; Mon, 11 Oct 2004 13:02:56 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 25A9AFB28A; Mon, 11 Oct 2004 13:01:40 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EB75FFB251; Mon, 11 Oct 2004 12:17:49 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id BC551FB23E for ; Mon, 11 Oct 2004 12:17:48 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E188C89877; Mon, 11 Oct 2004 15:17:46 +0300 (EEST) Message-ID: <416A7996.3040300@piuha.net> Date: Mon, 11 Oct 2004 15:16:22 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont , MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman / VPNC Subject: [Mobike] comments on draft-dupont-mobike-transport-00.txt 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 general, I find the function proposed by this draft very useful. Although its clear that more work is needed. In particular, we can be more concrete when the Mobike base protocol exists. Some comments below: > 3. Two examples I did not understand the SCTP example. Can you expand on it? > IKEv2 and Mobike mechanisms do verify that the primary peer address > (for IKEv2) and further alternate peer address (for Mobike > mechanisms) are correctly authenticated and authorized, so they MAY > safely be used for transport mode IPsec security associations as > endpoint addresses. I'd like to understand this better. Is it correct to say that the folllowing issues are involved: o Verification that the claimed IP address actually exists. FOr instance, the peer has not just manufactured a bogus address. The IKE negotiations and/or address tests take care of this. o Verification that its really this peer that is behind this IP address. It would be bad if I could grab someone else's IP address because, say, if that someone else needed to communicate with the node in future but couldn't do so because I already had a connection open with that address pair. o Verification that a number of different addresses A, B, C, etc. all are the same entity. This is actually the main issue, right? > 2. Transport mode and addresses Maybe I'm missing something obvious but I think we also need a discussion on how this impacts upper layer protocols. I can see how SCTP and Mobile IPv6 can survive address changes, but is the proposal to limit this function to those two examples, or be more generic? Some nits: > But transport mode IPsec security associations are end-to-end and > have no outer addresses: they cannot be managed by Mobike, for > instance, they cannot be updated. Perhaps s/they cannot be managed by Mobike/current designs for Mobike do not support their management/ > This document uses the standard keywords > [keywords] to indicate requirement levels. Move this to its own section or subsection. > to put transport mode ouside of its immediate scope. But as s/ouside/outside/ > Using a Mobike peer address management (as in [ADDRMGT]) a mobile Pending the appearance of a WG draft for the base MOBIKE solution, I think it would be appropriate to list a couple of other alternative address management protocol proposals too, just to make it clear that what you say in this draft is not bound to [ADDRMGT] but could also be used with the other drafts. > A > multi-homed peer can register using a Mobike mechanism its addresses > as peer addresses and is authorized to use them to build transport > mode IPsec security associations using only one IKE session, aka IKE > security association. Maybe say instead: "Using Mobike, a multi-homed peer can register its addresses as peer addresses. It is then also authorized to use them to build multiple transport mode IPsec security associations within the same IKEv2 security association." --Jari P.S. Is anyone else having trouble with the mobike mailing list? I've sent several e-mails today and at least for now they are not getting through, nor is there anything in the archive for October. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 13:08:11 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22821 for ; Mon, 11 Oct 2004 13:08:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 79210FB27C; Mon, 11 Oct 2004 17:08:12 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 75ADCFB277; Mon, 11 Oct 2004 17:08:09 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 05C90FB279; Mon, 11 Oct 2004 17:08:08 +0000 (UTC) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by machshav.com (Postfix) with ESMTP id A89C5FB262 for ; Mon, 11 Oct 2004 17:08:06 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9BH7tc08683; Mon, 11 Oct 2004 19:07:56 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9BH7qSj049616; Mon, 11 Oct 2004 19:07:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410111707.i9BH7qSj049616@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net In-reply-to: Your message of Mon, 11 Oct 2004 15:16:22 +0300. <416A7996.3040300@piuha.net> Date: Mon, 11 Oct 2004 19:07:52 +0200 Cc: MOBIKE Mailing List , Paul Hoffman / VPNC Subject: [Mobike] Re: comments on draft-dupont-mobike-transport-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: In general, I find the function proposed by this draft very useful. Although its clear that more work is needed. => I know but I believe only the form (i.e., better wording, clarifications, etc) needs to be improved. In particular, we can be more concrete when the Mobike base protocol exists. => IMHO we need only few properties of it, not a concrete proposal. Some comments below: > 3. Two examples I did not understand the SCTP example. Can you expand on it? => I'll rework it (followup in private). > IKEv2 and Mobike mechanisms do verify that the primary peer address > (for IKEv2) and further alternate peer address (for Mobike > mechanisms) are correctly authenticated and authorized, so they MAY > safely be used for transport mode IPsec security associations as > endpoint addresses. I'd like to understand this better. Is it correct to say that the folllowing issues are involved: => note that the verification is done by the Mobike protocol and the details are not *relevant*. o Verification that the claimed IP address actually exists. FOr instance, the peer has not just manufactured a bogus address. The IKE negotiations and/or address tests take care of this. o Verification that its really this peer that is behind this IP address. It would be bad if I could grab someone else's IP address because, say, if that someone else needed to communicate with the node in future but couldn't do so because I already had a connection open with that address pair. o Verification that a number of different addresses A, B, C, etc. all are the same entity. This is actually the main issue, right? => these are details so these are irrelevant: the Mobike protocol is supposed to be safe. > 2. Transport mode and addresses Maybe I'm missing something obvious but I think we also need a discussion on how this impacts upper layer protocols. => until an upper layer protocol will fully survive to address changes we can assume there is no interest to transport mode to survive to address changes. I can see how SCTP and Mobile IPv6 can survive address changes, => note this is not really true for SCTP: SCTP has only limited readdressing support. but is the proposal to limit this function to those two examples, or be more generic? => the proposal is to do nothing today to solve the issue, i.e., to put transport mode stuff out of the immediate scope of Mobike. > Using a Mobike peer address management (as in [ADDRMGT]) a mobile Pending the appearance of a WG draft for the base MOBIKE solution, I think it would be appropriate to list a couple of other alternative address management protocol proposals too, just to make it clear that what you say in this draft is not bound to [ADDRMGT] but could also be used with the other drafts. => I give the reference only as an example, or in other words the reference is here to avoid a long explaination about what I mean by "peer address management". 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 Oct 11 14:46:21 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02695 for ; Mon, 11 Oct 2004 14:46:21 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 39037FB27C; Mon, 11 Oct 2004 18:46:21 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 28A34FB277; Mon, 11 Oct 2004 18:46:20 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D5914FB279; Mon, 11 Oct 2004 18:46:18 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id C3B70FB240 for ; Mon, 11 Oct 2004 18:46:17 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9BIk8r11409; Mon, 11 Oct 2004 20:46:08 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9BIk8Sj049958; Mon, 11 Oct 2004 20:46:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410111846.i9BIk8Sj049958@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 18: Threat discussion In-reply-to: Your message of Mon, 11 Oct 2004 14:19:06 +0300. <416A6C2A.9060403@piuha.net> Date: Mon, 11 Oct 2004 20:46:08 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.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: 3) Unauthenticated attacker causes the IKE_SA to be closed by modifying just one or two IKE packets (if attacker can modify all packets, he can of course DoS). => I have a concern with this because it is not a MOBIKE threat but an IKE one. I propose to rewrite it, adding for example that MOBIKE should not add a new vulnerability (i.e., MOBIKE should be as resillient as IKE, BTW this should be easy to do). 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 Oct 11 15:01:20 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04196 for ; Mon, 11 Oct 2004 15:01:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7C7DCFB27A; Mon, 11 Oct 2004 19:01:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CB4A5FB277; Mon, 11 Oct 2004 19:01:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4F49AFB279; Mon, 11 Oct 2004 19:01: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 24239FB246 for ; Mon, 11 Oct 2004 19:01: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 i9BJ11r12737; Mon, 11 Oct 2004 21:01:01 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9BJ11Sj050009; Mon, 11 Oct 2004 21:01:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410111901.i9BJ11Sj050009@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Mon, 11 Oct 2004 13:14:20 +0300. <416A5CFC.8070107@piuha.net> Date: Mon, 11 Oct 2004 21:01:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, Vijay Devarapalli , 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: (2) Its not okay. MOBIKE/IKEv2/IPsec should fail and wait for the rest of the stack to inform when there's again an operational address. If problems on the path need to be handled, this would imply the development of a new, separate protocol for testing paths. Note that ICMP/TCP/app may already have told us of a problem with the current communications just as DPD did. But what we need is finding _another_ pair that works. No protocol that I know does that right now. Most of what we have in IPv6/DNA etc is focused on local issues, such as availability of the router. => this is true only because you take all your examples from the mobility world, not from the multi-homing one which is some years late compared to mobility. So IMHO your argument is wrong and there will be an external mechanism which is able to find another pair that works, ... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 15:01:50 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAB04261 for ; Mon, 11 Oct 2004 15:01:49 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 048D8FB27F; Mon, 11 Oct 2004 19:01:50 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 070CDFB277; Mon, 11 Oct 2004 19:01:48 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 74ECDFB279; Mon, 11 Oct 2004 19:01:46 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id EABB2FB246 for ; Mon, 11 Oct 2004 19:01:45 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E218089889; Mon, 11 Oct 2004 22:01:43 +0300 (EEST) Message-ID: <416AD843.1060706@piuha.net> Date: Mon, 11 Oct 2004 22:00:19 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] New issue 18: Threat discussion References: <200410111846.i9BIk8Sj049958@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410111846.i9BIk8Sj049958@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.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 Francis Dupont wrote: > In your previous mail you wrote: > > 3) Unauthenticated attacker causes the IKE_SA to be > closed by modifying just one or two IKE packets (if > attacker can modify all packets, he can of course DoS). > > => I have a concern with this because it is not a MOBIKE threat > but an IKE one. I propose to rewrite it, adding for example > that MOBIKE should not add a new vulnerability (i.e., MOBIKE > should be as resillient as IKE, BTW this should be easy to do). Ok. Do you have suggested text? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 15:34:43 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08751 for ; Mon, 11 Oct 2004 15:34:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 81C13FB27A; Mon, 11 Oct 2004 19:34:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 99323FB277; Mon, 11 Oct 2004 19:34:39 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 56DE6FB279; Mon, 11 Oct 2004 19:34:38 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 75D10FB257 for ; Mon, 11 Oct 2004 19:34:37 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6C85A89883; Mon, 11 Oct 2004 22:34:36 +0300 (EEST) Message-ID: <416ADFF8.9020606@piuha.net> Date: Mon, 11 Oct 2004 22:33:12 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] New issue 16: No packets from other end? References: <200410111901.i9BJ11Sj050009@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410111901.i9BJ11Sj050009@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, Vijay Devarapalli , 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 Hi Francis, > (2) Its not okay. MOBIKE/IKEv2/IPsec should fail and > wait for the rest of the stack to inform when there's > again an operational address. > > If problems on the path need to be handled, this would > imply the development of a new, separate protocol for > testing paths. Note that ICMP/TCP/app may already have > told us of a problem with the current communications just > as DPD did. But what we need is finding _another_ pair > that works. No protocol that I know does that right now. > Most of what we have in IPv6/DNA etc is focused on local > issues, such as availability of the router. > > => this is true only because you take all your examples from > the mobility world, not from the multi-homing one which is > some years late compared to mobility. So IMHO your argument Lets see.. hmm... you are right that I was thinking too much about the mobility world. But on the other hand, do we have a multihoming protocol _right now_ that does this? I think SCTP does it, but that would limit the ability of MOBIKE to survive problems on the path only if SCTP was used -- which seems pretty hard requirement to me. Plus it wouldn't work with SGWs as far as I can see, because there wouldn't be any SCTP in the endpoints. I happen to know also that the MULTI6 protocol that is being worked on includes will include a new protocol for this purpose. But like SCTP, it only works as an integral part of MULTI6, its not a standalone protocol. Plus it doesn't work for IPv4, despite my requests to make it so :-( > is wrong and there will be an external mechanism which is able > to find another pair that works, ... All I was saying is that there isn't one now :-) I forgot SCTP, but OTOH that doesn't work for everything. And I'm not aware of anyone developing a protocol that would cover all the main requirements, and be usable together with MOBIKE. But you are right -- this could change. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 16:38:38 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21044 for ; Mon, 11 Oct 2004 16:38:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D409EFB279; Mon, 11 Oct 2004 20:38:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3DC2BFB277; Mon, 11 Oct 2004 20:38:32 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D5E6BFB279; Mon, 11 Oct 2004 20:38:29 +0000 (UTC) Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by machshav.com (Postfix) with SMTP id 19B70FB257 for ; Mon, 11 Oct 2004 20:38:29 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 11 Oct 2004 20:38:28 -0000 Message-ID: <00ca01c4afd2$422217a0$861167c0@adithya> From: "Mohan Parthasarathy" To: , "Vijay Devarapalli" References: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com><41214396.4010803@iprg.nokia.com> <416A5CFC.8070107@piuha.net> Subject: Re: [Mobike] New issue 16: No packets from other end? Date: Mon, 11 Oct 2004 13:38:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: Pasi.Eronen@nokia.com, 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 Jari, > > I am not sure how you can do that. what if the application > > prefers "failing" to using an expensive link? > > > > for example, lets assume my mobile device has a low bandwidth > > GPRS link (address IP1 on that link) and a high bandwidth WLAN > > link (address IP2 on that link). I have set it up so that my > > email is downloaded only when I connect to my Enterprise > > through a VPN connection when I have the WLAN link. if the > > WLAN link is not available, I dont want the email client to > > download email. lets assume I am in the middle of downloading > > email. I lose WLAN coverage. with your proposal, the MOBIKE > > protocol switches to using IP1. I dont want that. > > I agree with your scenario. > > > IMHO, I prefer "something in the Mobile Node" telling MOBIKE, > > "switch to using this address with this VPN GW". then a MOBIKE > > update should be sent. this is the model I had in my mind. > > > > for "something in the Mobile Node" I had assumed DNA, MIP6, > > Multi6, new address configuration, default router change, etc... > > I believe there's two levels of issue involved here. On > the first level, I think we have consensus that "something > in the mobile node" should be able to tell MOBIKE that > there's a new address or that a particular interface and > its addresses are no longer usable because the router went > down. I also think that we have consensus that at least most > of this is outside MOBIKE protocol and WG scope. They are > better handled in IPv6/DNA/DHC/MIP6 WGs. Finally, I believe > your policy issue about which interface should be used > is also at this level. And like I said, I agree with your > requirement that it should be possible to express such > policies. I think the others will agree too. > > However, that's the part that the rest of the stack is > telling MOBIKE. The second level is what happens after > MOBIKE has been told something. For instance, lets say > that it has been told that there's two usable addresses > at this end and one at the other end; that's two possible > address pairs. Now we get a problem -- ESP tells IKE > that there's no packets, IKE attempts DPD which fails. > There's no information coming from IPv6/DNA/DHC/MIP6 > (and presumably there will not be any information coming > soon either, because the DPD process took a while). > Now what? Are people saying that > > (1) Its okay for the MOBIKE peers to attempt recovery > at the MOBIKE level by switching to another address > pair. > > (2) Its not okay. MOBIKE/IKEv2/IPsec should fail and > wait for the rest of the stack to inform when there's > again an operational address. > > If problems on the path need to be handled, this would > imply the development of a new, separate protocol for > testing paths. Note that ICMP/TCP/app may already have > told us of a problem with the current communications just > as DPD did. But what we need is finding _another_ pair > that works. No protocol that I know does that right now. > Most of what we have in IPv6/DNA etc is focused on local > issues, such as availability of the router. > > (Assuming the "first level" is handled as explained earlier -- > outside MOBIKE -- my personal preference would be #1.) It looks like the options are not very good :-) If we choose (1) then we end up doing what MULTI6 (or something else) within MOBIKE. If we choose (2), we don't know who will provide the information to MOBIKE. Perhaps, option (1) seems to make more sense in the immediate term as there is no other protocol or effort going on now. -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 Oct 11 17:06:58 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28207 for ; Mon, 11 Oct 2004 17:06:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3B45AFB282; Mon, 11 Oct 2004 21:06:57 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 63BC6FB279; Mon, 11 Oct 2004 21:06:54 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 936F2FB27C; Mon, 11 Oct 2004 21:06:52 +0000 (UTC) Received: from smtp814.mail.sc5.yahoo.com (smtp814.mail.sc5.yahoo.com [66.163.170.84]) by machshav.com (Postfix) with SMTP id 96909FB277 for ; Mon, 11 Oct 2004 21:06:51 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 11 Oct 2004 21:06:49 -0000 Message-ID: <00e401c4afd6$38b143e0$861167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" , References: <200410111707.i9BH7qSj049616@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] Re: comments on draft-dupont-mobike-transport-00.txt Date: Mon, 11 Oct 2004 14:06:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Francis, > but is the proposal to limit this function to > those two examples, or be more generic? > > => the proposal is to do nothing today to solve the issue, i.e., > to put transport mode stuff out of the immediate scope of Mobike. > The draft talks about how MOBIKE can be used with MIPv6 (BU) and SCTP which are both transport mode SAs. I don't know where in the document it says that transport mode stuff should be put outside of MOBIKE. Also, the charter includes SCTP also. So, are you saying that this should be changed ? I am a bit confused. -mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 17: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 RAA01792 for ; Mon, 11 Oct 2004 17:42:22 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 61345FB279; Mon, 11 Oct 2004 21:42:22 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 004B3FB277; Mon, 11 Oct 2004 21:42:18 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2C0CFFB279; Mon, 11 Oct 2004 21:42:17 +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 007ACFB257 for ; Mon, 11 Oct 2004 21:42:15 +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 i9BLfxQ31653; Mon, 11 Oct 2004 23:41:59 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9BLfwSj051114; Mon, 11 Oct 2004 23:41:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410112141.i9BLfwSj051114@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] Re: comments on draft-dupont-mobike-transport-00.txt In-reply-to: Your message of Mon, 11 Oct 2004 14:06:46 PDT. <00e401c4afd6$38b143e0$861167c0@adithya> Date: Mon, 11 Oct 2004 23:41:58 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > but is the proposal to limit this function to > those two examples, or be more generic? > > => the proposal is to do nothing today to solve the issue, i.e., > to put transport mode stuff out of the immediate scope of Mobike. The draft talks about how MOBIKE can be used with MIPv6 (BU) and SCTP which are both transport mode SAs. => perhaps you are confused because you've forgotten that neither MIPv6 (BU) or SCTP need address changes for these transport mode SAs? For instance MIPv6 (BU) uses the home address... And SCTP uses different streams for different paths. I don't know where in the document it says that transport mode stuff should be put outside of MOBIKE. => the document puts the transport mode stuff outside of MOBIKE. Can you propose some text to explain why? (I believe it was known but obviously a rationale is needed). Also, the charter includes SCTP also. => yes and this is a good thing. But the SCTP model doesn't require address changes, it only requires multiple integrated address management (integrated = as a set vs. one by one). So, are you saying that this should be changed ? => no but direct address changes for transport mode are so complex that their study should be postponed at least... 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 Oct 11 19:38:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10668 for ; Mon, 11 Oct 2004 19:38:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 99741FB27A; Mon, 11 Oct 2004 23:38:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A2DD6FB262; Mon, 11 Oct 2004 23:38:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 31541FB266; Mon, 11 Oct 2004 23:38:15 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 052D9FB257 for ; Mon, 11 Oct 2004 23:38:14 +0000 (UTC) Message-ID: <015001c4afeb$7f1192d0$496015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mohan Parthasarathy" , , "Vijay Devarapalli" References: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com><41214396.4010803@iprg.nokia.com><416A5CFC.8070107@piuha.net> <00ca01c4afd2$422217a0$861167c0@adithya> Subject: Re: [Mobike] New issue 16: No packets from other end? Date: Mon, 11 Oct 2004 16:38:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.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 Mohan, I can't see how having MOBIKE detect the failure and repair would work with SCTP or TCP. With SCTP, the transport layer is already managing failover, so having MOBIKE try to do it too seems like it might result in some kind of conflict. I don't know how SCTP is matched to IPsec now, but I'd like to know why that isn't sufficient, since I assume it would allow the SCTP layer to switch to whichever address it wanted with proper SA protection. With TCP, the session is bound to the IP address, so if the address fails, then the session must be terminated, by the TCP semantics. Having MOBIKE try to change this would require some kind of cross-layer violation to tell TCP to change. As difficult and unpleasent as it seems, I can't see any way around just letting the session fail if the address ceases to work. The IPSec layer doesn't seem the right one to me to solve this problem. jak ----- Original Message ----- From: "Mohan Parthasarathy" To: ; "Vijay Devarapalli" Cc: ; Sent: Monday, October 11, 2004 1:38 PM Subject: Re: [Mobike] New issue 16: No packets from other end? > Jari, > > > > I am not sure how you can do that. what if the application > > > prefers "failing" to using an expensive link? > > > > > > for example, lets assume my mobile device has a low bandwidth > > > GPRS link (address IP1 on that link) and a high bandwidth WLAN > > > link (address IP2 on that link). I have set it up so that my > > > email is downloaded only when I connect to my Enterprise > > > through a VPN connection when I have the WLAN link. if the > > > WLAN link is not available, I dont want the email client to > > > download email. lets assume I am in the middle of downloading > > > email. I lose WLAN coverage. with your proposal, the MOBIKE > > > protocol switches to using IP1. I dont want that. > > > > I agree with your scenario. > > > > > IMHO, I prefer "something in the Mobile Node" telling MOBIKE, > > > "switch to using this address with this VPN GW". then a MOBIKE > > > update should be sent. this is the model I had in my mind. > > > > > > for "something in the Mobile Node" I had assumed DNA, MIP6, > > > Multi6, new address configuration, default router change, etc... > > > > I believe there's two levels of issue involved here. On > > the first level, I think we have consensus that "something > > in the mobile node" should be able to tell MOBIKE that > > there's a new address or that a particular interface and > > its addresses are no longer usable because the router went > > down. I also think that we have consensus that at least most > > of this is outside MOBIKE protocol and WG scope. They are > > better handled in IPv6/DNA/DHC/MIP6 WGs. Finally, I believe > > your policy issue about which interface should be used > > is also at this level. And like I said, I agree with your > > requirement that it should be possible to express such > > policies. I think the others will agree too. > > > > However, that's the part that the rest of the stack is > > telling MOBIKE. The second level is what happens after > > MOBIKE has been told something. For instance, lets say > > that it has been told that there's two usable addresses > > at this end and one at the other end; that's two possible > > address pairs. Now we get a problem -- ESP tells IKE > > that there's no packets, IKE attempts DPD which fails. > > There's no information coming from IPv6/DNA/DHC/MIP6 > > (and presumably there will not be any information coming > > soon either, because the DPD process took a while). > > Now what? Are people saying that > > > > (1) Its okay for the MOBIKE peers to attempt recovery > > at the MOBIKE level by switching to another address > > pair. > > > > (2) Its not okay. MOBIKE/IKEv2/IPsec should fail and > > wait for the rest of the stack to inform when there's > > again an operational address. > > > > If problems on the path need to be handled, this would > > imply the development of a new, separate protocol for > > testing paths. Note that ICMP/TCP/app may already have > > told us of a problem with the current communications just > > as DPD did. But what we need is finding _another_ pair > > that works. No protocol that I know does that right now. > > Most of what we have in IPv6/DNA etc is focused on local > > issues, such as availability of the router. > > > > (Assuming the "first level" is handled as explained earlier -- > > outside MOBIKE -- my personal preference would be #1.) > > It looks like the options are not very good :-) If we choose (1) then we > end up doing what MULTI6 (or something else) within MOBIKE. If we > choose (2), we don't know who will provide the information to MOBIKE. > Perhaps, option (1) seems to make more sense in the immediate term as > there is no other protocol or effort going on now. > > -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 Mon Oct 11 19:57:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11769 for ; Mon, 11 Oct 2004 19:57:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9BCBAFB257; Mon, 11 Oct 2004 23:57:57 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BE83BFB262; Mon, 11 Oct 2004 23:57:53 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 28179FB266; Mon, 11 Oct 2004 23:57:52 +0000 (UTC) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [205.150.200.161]) by machshav.com (Postfix) with ESMTP id 5C917FB257 for ; Mon, 11 Oct 2004 23:57:51 +0000 (UTC) Received: from road.marajade.sandelman.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i9BNvd918669 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 11 Oct 2004 19:57:39 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by road.marajade.sandelman.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i9BNvd76023995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2004 19:57:39 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i9BNvclq023992; Mon, 11 Oct 2004 19:57:39 -0400 To: "James Kempf" Subject: Re: [Mobike] New issue 16: No packets from other end? In-Reply-To: Message from "James Kempf" of "Mon, 11 Oct 2004 16:38:59 PDT." <015001c4afeb$7f1192d0$496015ac@dcml.docomolabsusa.com> References: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com><41214396.4010803@iprg.nokia.com><416A5CFC.8070107@piuha.net> <00ca01c4afd2$422217a0$861167c0@adithya> <015001c4afeb$7f1192d0$496015ac@dcml.docomolabsusa.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Oct 2004 19:57:38 -0400 Message-ID: <23991.1097539058@marajade.sandelman.ottawa.on.ca> From: Michael Richardson 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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "James" == James Kempf writes: James> With TCP, the session is bound to the IP address, so if the James> address fails, then the session must be terminated, by the James> TCP semantics. Having MOBIKE try to change this would require James> some kind of cross-layer violation to tell TCP to change. Typically, in RW scenarioes, an IP address is "extruded" through the IPsec tunnel, and is bound to a virtual address on the end host. Think of this as being like MobileIP's Home-Address. So, if you fix the tunnel, then the stuff inside continues unchanged. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQWsd8YqHRg3pndX9AQFFHwP9FNTJm2SMiEdqNNe2bpWPzK8nDNbJeLYQ 7qkEUBGYhngtSqmyFqBxnYvPWfOZWntMtATreEazF5PJuSlaLOVXT3YPXYPf9ht+ 4V608AAQ90Ye92n2MlR/bsP93H4bWNASlJE3HJADp7+shSzDg0UiRlQULfMG6yGs W1tK8ngZs38= =atzH -----END PGP SIGNATURE----- _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 21:52:39 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19887 for ; Mon, 11 Oct 2004 21:52:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3634BFB27D; Tue, 12 Oct 2004 01:52:38 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 18C6CFB262; Tue, 12 Oct 2004 01:52:34 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 05BD3FB266; Tue, 12 Oct 2004 01:52:33 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 0886AFB257 for ; Tue, 12 Oct 2004 01:52:32 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9C1PU114235; Mon, 11 Oct 2004 18:25:30 -0700 X-mProtect: <200410120125> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141210.americas.nokia.com (172.18.141.210, claiming to be "[172.18.141.210]") by darkstar.iprg.nokia.com smtpdAIwB4R; Mon, 11 Oct 2004 18:11:03 PDT Message-ID: <416B356D.4050905@iprg.nokia.com> Date: Mon, 11 Oct 2004 18:37:49 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 16: No packets from other end? References: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com> <41214396.4010803@iprg.nokia.com> <416A5CFC.8070107@piuha.net> In-Reply-To: <416A5CFC.8070107@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.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 hi Jari, I dont agree with your conclusions. more below. Jari Arkko wrote: > Vijay Devarapalli wrote: > >> I am not sure how you can do that. what if the application >> prefers "failing" to using an expensive link? >> >> for example, lets assume my mobile device has a low bandwidth >> GPRS link (address IP1 on that link) and a high bandwidth WLAN >> link (address IP2 on that link). I have set it up so that my >> email is downloaded only when I connect to my Enterprise >> through a VPN connection when I have the WLAN link. if the >> WLAN link is not available, I dont want the email client to >> download email. lets assume I am in the middle of downloading >> email. I lose WLAN coverage. with your proposal, the MOBIKE >> protocol switches to using IP1. I dont want that. > > > I agree with your scenario. > >> IMHO, I prefer "something in the Mobile Node" telling MOBIKE, >> "switch to using this address with this VPN GW". then a MOBIKE >> update should be sent. this is the model I had in my mind. >> >> for "something in the Mobile Node" I had assumed DNA, MIP6, >> Multi6, new address configuration, default router change, etc... > > > I believe there's two levels of issue involved here. On > the first level, I think we have consensus that "something > in the mobile node" should be able to tell MOBIKE that > there's a new address or that a particular interface and > its addresses are no longer usable because the router went > down. I also think that we have consensus that at least most > of this is outside MOBIKE protocol and WG scope. They are > better handled in IPv6/DNA/DHC/MIP6 WGs. Finally, I believe > your policy issue about which interface should be used > is also at this level. And like I said, I agree with your > requirement that it should be possible to express such > policies. I think the others will agree too. > > However, that's the part that the rest of the stack is > telling MOBIKE. The second level is what happens after > MOBIKE has been told something. For instance, lets say > that it has been told that there's two usable addresses > at this end and one at the other end; that's two possible > address pairs. Now we get a problem -- ESP tells IKE > that there's no packets, IKE attempts DPD which fails. > There's no information coming from IPv6/DNA/DHC/MIP6 > (and presumably there will not be any information coming > soon either, because the DPD process took a while). I dont agree with this statement. IMHO, if IPv6/DNA/DHC/MIP6 are not able to figure out what happened, MOBIKE should just keep quiet. > Now what? Are people saying that > > (1) Its okay for the MOBIKE peers to attempt recovery > at the MOBIKE level by switching to another address > pair. > > (2) Its not okay. MOBIKE/IKEv2/IPsec should fail and > wait for the rest of the stack to inform when there's > again an operational address. I think (2) is the way to go. I dont want MOBIKE making a decision that conflicts with IPv6/DNA/DHC/MIP6/SCTP/whatever. Vijay > > If problems on the path need to be handled, this would > imply the development of a new, separate protocol for > testing paths. Note that ICMP/TCP/app may already have > told us of a problem with the current communications just > as DPD did. But what we need is finding _another_ pair > that works. No protocol that I know does that right now. > Most of what we have in IPv6/DNA etc is focused on local > issues, such as availability of the router. > > (Assuming the "first level" is handled as explained earlier -- > outside MOBIKE -- my personal preference would be #1.) > > --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 21:53:34 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19953 for ; Mon, 11 Oct 2004 21:53:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6B7B6FB27C; Tue, 12 Oct 2004 01:53:35 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B0C89FB277; Tue, 12 Oct 2004 01:53:32 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 501A2FB279; Tue, 12 Oct 2004 01:53:31 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id BE0EEFB262 for ; Tue, 12 Oct 2004 01:53:29 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9C1QKi21270; Mon, 11 Oct 2004 18:26:20 -0700 X-mProtect: <200410120126> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141210.americas.nokia.com (172.18.141.210, claiming to be "[172.18.141.210]") by darkstar.iprg.nokia.com smtpdVCs2Gn; Mon, 11 Oct 2004 18:15:14 PDT Message-ID: <416B3667.5090308@iprg.nokia.com> Date: Mon, 11 Oct 2004 18:41:59 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Subject: Re: [Mobike] New issue 16: No packets from other end? References: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com><41214396.4010803@iprg.nokia.com><416A5CFC.8070107@piuha.net> <00ca01c4afd2$422217a0$861167c0@adithya> <015001c4afeb$7f1192d0$496015ac@dcml.docomolabsusa.com> <23991.1097539058@m In-Reply-To: <23991.1097539058@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: James Kempf , 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 Michael Richardson wrote: > >>>>>>"James" == James Kempf writes: > > James> With TCP, the session is bound to the IP address, so if the > James> address fails, then the session must be terminated, by the > James> TCP semantics. Having MOBIKE try to change this would require > James> some kind of cross-layer violation to tell TCP to change. > > Typically, in RW scenarioes, an IP address is "extruded" through the > IPsec tunnel, and is bound to a virtual address on the end host. > Think of this as being like MobileIP's Home-Address. > > So, if you fix the tunnel, then the stuff inside continues unchanged. MOBIKE should be used to fix the tunnel, but, in IMHO, MOBIKE shouldnt decide when to fix the tunnel or what address to use to fix the tunnel. the IP stack (which might include MIP6/DNA) should tell the MOBIKE protocol what IP address to use to fix the tunnel. Vijay > > - -- > ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ > ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ > ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBQWsd8YqHRg3pndX9AQFFHwP9FNTJm2SMiEdqNNe2bpWPzK8nDNbJeLYQ > 7qkEUBGYhngtSqmyFqBxnYvPWfOZWntMtATreEazF5PJuSlaLOVXT3YPXYPf9ht+ > 4V608AAQ90Ye92n2MlR/bsP93H4bWNASlJE3HJADp7+shSzDg0UiRlQULfMG6yGs > W1tK8ngZs38= > =atzH > -----END PGP SIGNATURE----- > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 11 23:13:36 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25139 for ; Mon, 11 Oct 2004 23:13:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D3728FB281; Tue, 12 Oct 2004 03:13:34 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EDA9FFB279; Tue, 12 Oct 2004 03:13:32 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 152C2FB27C; Tue, 12 Oct 2004 03:13:31 +0000 (UTC) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [205.150.200.161]) by machshav.com (Postfix) with ESMTP id 074C5FB277 for ; Tue, 12 Oct 2004 03:13:30 +0000 (UTC) Received: from road.marajade.sandelman.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i9C3DF919941 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 11 Oct 2004 23:13:15 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by road.marajade.sandelman.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i9C3DFM7030127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2004 23:13:15 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.11/8.12.3/Debian-6.6) with ESMTP id i9C3DE6e030124; Mon, 11 Oct 2004 23:13:14 -0400 To: Vijay Devarapalli Subject: Re: [Mobike] New issue 16: No packets from other end? In-Reply-To: Message from Vijay Devarapalli of "Mon, 11 Oct 2004 18:41:59 PDT." <416B3667.5090308@iprg.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com><41214396.4010803@iprg.nokia.com><416A5CFC.8070107@piuha.net> <00ca01c4afd2$422217a0$861167c0@adithya> <015001c4afeb$7f1192d0$496015ac@dcml.docomolabsusa.com> <23991.1097539058@m <416B3667.5090308@iprg.nokia.com> X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 15) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Oct 2004 23:13:14 -0400 Message-ID: <30123.1097550794@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Cc: James Kempf , 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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Vijay" == Vijay Devarapalli writes: James> With TCP, the session is bound to the IP address, so if the James> address fails, then the session must be terminated, by the James> TCP semantics. Having MOBIKE try to change this would require James> some kind of cross-layer violation to tell TCP to change. >> Typically, in RW scenarioes, an IP address is "extruded" through >> the IPsec tunnel, and is bound to a virtual address on the end >> host. Think of this as being like MobileIP's Home-Address. So, >> if you fix the tunnel, then the stuff inside continues unchanged. Vijay> MOBIKE should be used to fix the tunnel, but, in IMHO, MOBIKE Vijay> shouldnt decide when to fix the tunnel or what address to use Vijay> to fix the tunnel. the IP stack (which might include Vijay> MIP6/DNA) should tell the MOBIKE protocol what IP address to Vijay> use to fix the tunnel. That's fine. But the hint that address (A) works while (B) is now broken is an attribute of the *outside* of the tunnel. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQWtLyYqHRg3pndX9AQG/WQQAhDmO46xK8vipO9Jni19gouM5wzXIKZXF /RB8uC06v0KXqbPjz9ys1oTNZFTR05CKdULW48FegK7yymkAlgXAWD0/c0Ngqivr 5r90Y2ZbCpVqu/bhrXP2E5cwWwVR2TpJXciL1/VAG+KYyyZ0oMvQQpKdn+XPPOq7 qcJ8euf9aUA= =1Ltp -----END PGP SIGNATURE----- _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 00:34:50 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29877 for ; Tue, 12 Oct 2004 00:34:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DD0E8FB27C; Tue, 12 Oct 2004 04:34:51 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 280B5FB266; Tue, 12 Oct 2004 04:34:49 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3B26AFB277; Tue, 12 Oct 2004 04:34:47 +0000 (UTC) Received: from smtp805.mail.sc5.yahoo.com (smtp805.mail.sc5.yahoo.com [66.163.168.184]) by machshav.com (Postfix) with SMTP id A05BEFB240 for ; Tue, 12 Oct 2004 04:34:46 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@67.123.82.106 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 12 Oct 2004 04:34:46 -0000 Message-ID: <001601c4b014$cc902610$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" References: <200410112141.i9BLfwSj051114@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] Re: comments on draft-dupont-mobike-transport-00.txt Date: Mon, 11 Oct 2004 21:34:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: jari.arkko@piuha.net, MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > > > but is the proposal to limit this function to > > those two examples, or be more generic? > > > > => the proposal is to do nothing today to solve the issue, i.e., > > to put transport mode stuff out of the immediate scope of Mobike. > > The draft talks about how MOBIKE can be used with MIPv6 (BU) and SCTP > which are both transport mode SAs. > > => perhaps you are confused because you've forgotten that neither MIPv6 > (BU) or SCTP need address changes for these transport mode SAs? > For instance MIPv6 (BU) uses the home address... And SCTP uses > different streams for different paths. > I have not forgotten. That is what i understood from "section 3". > I don't know where in the document it says > that transport mode stuff should be put outside of MOBIKE. > > => the document puts the transport mode stuff outside of MOBIKE. > Can you propose some text to explain why? (I believe it was known > but obviously a rationale is needed). > I am fine with the decision. But i don't know what part of your document says that. You keep saying that you want keep it outside and i thought your document says so. I could never find it. > Also, the charter includes SCTP also. > > => yes and this is a good thing. But the SCTP model doesn't require > address changes, it only requires multiple integrated address management > (integrated = as a set vs. one by one). > > So, are you saying that this should be changed ? > > => no but direct address changes for transport mode are so complex > that their study should be postponed at least... > What do you mean by "direct" address change ? thanks mohan > Thanks > > Francis.Dupont@enst-bretagne.fr > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 01:03:15 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01754 for ; Tue, 12 Oct 2004 01:03:14 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C765DFB27F; Tue, 12 Oct 2004 05:03:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AED9CFB279; Tue, 12 Oct 2004 05:03:09 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 886D4FB27C; Tue, 12 Oct 2004 05:03:07 +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 8B8FAFB277 for ; Tue, 12 Oct 2004 05:03:06 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@67.123.82.106 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 12 Oct 2004 05:03:05 -0000 Message-ID: <002201c4b018$c17c9ed0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "James Kempf" , , "Vijay Devarapalli" References: <052E0C61B69C3741AFA5FE88ACC775A60227C164@esebe023.ntc.nokia.com><41214396.4010803@iprg.nokia.com><416A5CFC.8070107@piuha.net><00ca01c4afd2$422217a0$861167c0@adithya> <015001c4afeb$7f1192d0$496015ac@dcml.docomolabsusa.com> Subject: Re: [Mobike] New issue 16: No packets from other end? Date: Mon, 11 Oct 2004 22:03:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: Pasi.Eronen@nokia.com, 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 James, > I can't see how having MOBIKE detect the failure and repair would work with > SCTP or TCP. > I was mainly assuming tunnel mode. The address change is concerned with the outer header and not the inner header (i.e. traffic selector). I thought we are not concerned about transport mode at all. The charter says this clearly. > With SCTP, the transport layer is already managing failover, so having > MOBIKE try to do it too seems like it might result in some kind of conflict. > I don't know how SCTP is matched to IPsec now, but I'd like to know why that > isn't sufficient, since I assume it would allow the SCTP layer to switch to > whichever address it wanted with proper SA protection. > RFC 3554 is the attempt to map multiple addresses to a single SA. Having said that, i don't know what MOBIKE is planning to provide. The charter does talk about modification of SCTP endpoints without renegotiating the SA. The charter says: An explicit non-goal is the construction of a fully fledged mobility protocol. In particular, the WG shall NOT develop mechanisms for the following functions: o Hiding of mobility from transport layer protocols or applications (beyond what already exists through the use of the tunnel mode). In this respect MOBIKE is different from Mobile IP, HIP, and other mobility protocols. Though SCTP is a transport layer protocol, it is included for the multi-homing part i guess. > With TCP, the session is bound to the IP address, so if the address fails, > then the session must be terminated, by the TCP semantics. Having MOBIKE try > to change this would require some kind of cross-layer violation to tell TCP > to change. > > As difficult and unpleasent as it seems, I can't see any way around just > letting the session fail if the address ceases to work. The IPSec layer > doesn't seem the right one to me to solve this problem. > Correct. But this affects only transport mode. -mohan > jak > > > ----- Original Message ----- > From: "Mohan Parthasarathy" > To: ; "Vijay Devarapalli" > Cc: ; > Sent: Monday, October 11, 2004 1:38 PM > Subject: Re: [Mobike] New issue 16: No packets from other end? > > > > Jari, > > > > > > I am not sure how you can do that. what if the application > > > > prefers "failing" to using an expensive link? > > > > > > > > for example, lets assume my mobile device has a low bandwidth > > > > GPRS link (address IP1 on that link) and a high bandwidth WLAN > > > > link (address IP2 on that link). I have set it up so that my > > > > email is downloaded only when I connect to my Enterprise > > > > through a VPN connection when I have the WLAN link. if the > > > > WLAN link is not available, I dont want the email client to > > > > download email. lets assume I am in the middle of downloading > > > > email. I lose WLAN coverage. with your proposal, the MOBIKE > > > > protocol switches to using IP1. I dont want that. > > > > > > I agree with your scenario. > > > > > > > IMHO, I prefer "something in the Mobile Node" telling MOBIKE, > > > > "switch to using this address with this VPN GW". then a MOBIKE > > > > update should be sent. this is the model I had in my mind. > > > > > > > > for "something in the Mobile Node" I had assumed DNA, MIP6, > > > > Multi6, new address configuration, default router change, etc... > > > > > > I believe there's two levels of issue involved here. On > > > the first level, I think we have consensus that "something > > > in the mobile node" should be able to tell MOBIKE that > > > there's a new address or that a particular interface and > > > its addresses are no longer usable because the router went > > > down. I also think that we have consensus that at least most > > > of this is outside MOBIKE protocol and WG scope. They are > > > better handled in IPv6/DNA/DHC/MIP6 WGs. Finally, I believe > > > your policy issue about which interface should be used > > > is also at this level. And like I said, I agree with your > > > requirement that it should be possible to express such > > > policies. I think the others will agree too. > > > > > > However, that's the part that the rest of the stack is > > > telling MOBIKE. The second level is what happens after > > > MOBIKE has been told something. For instance, lets say > > > that it has been told that there's two usable addresses > > > at this end and one at the other end; that's two possible > > > address pairs. Now we get a problem -- ESP tells IKE > > > that there's no packets, IKE attempts DPD which fails. > > > There's no information coming from IPv6/DNA/DHC/MIP6 > > > (and presumably there will not be any information coming > > > soon either, because the DPD process took a while). > > > Now what? Are people saying that > > > > > > (1) Its okay for the MOBIKE peers to attempt recovery > > > at the MOBIKE level by switching to another address > > > pair. > > > > > > (2) Its not okay. MOBIKE/IKEv2/IPsec should fail and > > > wait for the rest of the stack to inform when there's > > > again an operational address. > > > > > > If problems on the path need to be handled, this would > > > imply the development of a new, separate protocol for > > > testing paths. Note that ICMP/TCP/app may already have > > > told us of a problem with the current communications just > > > as DPD did. But what we need is finding _another_ pair > > > that works. No protocol that I know does that right now. > > > Most of what we have in IPv6/DNA etc is focused on local > > > issues, such as availability of the router. > > > > > > (Assuming the "first level" is handled as explained earlier -- > > > outside MOBIKE -- my personal preference would be #1.) > > > > It looks like the options are not very good :-) If we choose (1) then we > > end up doing what MULTI6 (or something else) within MOBIKE. If we > > choose (2), we don't know who will provide the information to MOBIKE. > > Perhaps, option (1) seems to make more sense in the immediate term as > > there is no other protocol or effort going on now. > > > > -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 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 08:39:19 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15469 for ; Tue, 12 Oct 2004 08:39:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F064BFB27D; Tue, 12 Oct 2004 12:39:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A8284FB266; Tue, 12 Oct 2004 12:39:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BC1A2FB277; Tue, 12 Oct 2004 12:39:13 +0000 (UTC) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id A531CFB257 for ; Tue, 12 Oct 2004 12:39:12 +0000 (UTC) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CCd9W00594; Tue, 12 Oct 2004 15:39:09 +0300 (EET DST) X-Scanned: Tue, 12 Oct 2004 15:33:22 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9CCXMrD012865; Tue, 12 Oct 2004 15:33:22 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00h0cSbQ; Tue, 12 Oct 2004 15:33:21 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CCXDS04873; Tue, 12 Oct 2004 15:33:13 +0300 (EET DST) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 15:33:03 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 15:33:03 +0300 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] New issue 16: No packets from other end? Date: Tue, 12 Oct 2004 15:33:03 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178370@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] New issue 16: No packets from other end? Thread-Index: AcSv/iLfxvQjjuDsT8yiqcyE0u4DXQAV2qjQ From: To: , X-OriginalArrivalTime: 12 Oct 2004 12:33:03.0484 (UTC) FILETIME=[9E2143C0:01C4B057] 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 Vijay Devarapalli writes: > >=20 > > However, that's the part that the rest of the stack is > > telling MOBIKE. The second level is what happens after > > MOBIKE has been told something. For instance, lets say > > that it has been told that there's two usable addresses > > at this end and one at the other end; that's two possible > > address pairs. Now we get a problem -- ESP tells IKE > > that there's no packets, IKE attempts DPD which fails. > > There's no information coming from IPv6/DNA/DHC/MIP6 > > (and presumably there will not be any information coming > > soon either, because the DPD process took a while). >=20 > I dont agree with this statement. IMHO, if IPv6/DNA/DHC/MIP6=20 > are not able to figure out what happened, MOBIKE should just=20 > keep quiet. > ... > I think (2) is the way to go. I dont want MOBIKE making a > decision that conflicts with IPv6/DNA/DHC/MIP6/SCTP/whatever. I think we need to clearly separate host-internal implementation issues and specifying interoperability-enabling protocols here. This issue was not about whether the "MOBIKE module" should keep=20 quiet or decide something or conflict with someone else; it was whether we should make it possible for a _host_ to recover from=20 a situation where its IKE endpoint and the peer IKE endpoint=20 cannot communicate using the current addresses. Whether that recovery is "controlled" by the "MOBIKE module", or perhaps some "general mobility/multihoming module" (possibly=20 using information from some "DNA module") in the host is=20 completely besides the point. I do agree that actual implementations might work e.g. so that=20 when DPD seems to fail, the "MOBIKE module" notifies the "mobility and multihoming control module" that "we seem to have a problem; but the peer said it also has addresses B2,B3,B4; please tell=20 me what to do". The control module could then tell MOBIKE module=20 that "based on your report, and information I may have received=20 from other modules, my decision is to start using local address A2 and remote address B3". The interface between those modules is of course not MOBIKE WG's business, but I hope you're not opposing that we allow such interfaces to be built? BTW, if we were adding MOBIKE to IKEv1, nothing extra would be=20 needed in the protocol to allow hosts to handle this "no packet=20 from other end" case; the R-U-THERE dead peer detection messages=20 [RFC3706] would be enough. But currently it seems (to me at least) that in IKEv2, the ability=20 to send some kind of R-U-THERE/Hello/Ping/Heartbeat/Path test messages outside the IKEv2 window would be necessary, or at=20 would simplify the protocol considerably. (And since we decided=20 not to assume full connectivity, something like that message may=20 be needed anyway.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 10:45:41 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25921 for ; Tue, 12 Oct 2004 10:45:40 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id ABBF5FB280; Tue, 12 Oct 2004 14:45:39 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8A206FB266; Tue, 12 Oct 2004 14:45:35 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8AB0CFB277; Tue, 12 Oct 2004 14:45:34 +0000 (UTC) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 8BAA8FB255 for ; Tue, 12 Oct 2004 14:45:33 +0000 (UTC) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CEieF01632; Tue, 12 Oct 2004 17:44:40 +0300 (EET DST) X-Scanned: Tue, 12 Oct 2004 17:40:19 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9CEeJKQ000662; Tue, 12 Oct 2004 17:40:19 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00eHMttc; Tue, 12 Oct 2004 17:40:10 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CEe9S07998; Tue, 12 Oct 2004 17:40:09 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 09:40:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Re: comments on draft-dupont-mobike-transport-00.txt Date: Tue, 12 Oct 2004 10:40:07 -0400 Message-ID: Thread-Topic: [Mobike] Re: comments on draft-dupont-mobike-transport-00.txt thread-index: AcSvtS1dLhkKV8FdSPW9figPJgfOGgAs9ESQ From: To: , X-OriginalArrivalTime: 12 Oct 2004 14:40:08.0555 (UTC) FILETIME=[5F06C3B0:01C4B069] Cc: mobike@machshav.com, paul.hoffman@vpnc.org X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable If we want to keep transport mode out of MOBIKE scope right now, why are we requesting it to be a working group item? Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext Francis Dupont > Sent: Monday, October 11, 2004 1:08 PM > To: jari.arkko@piuha.net > Cc: MOBIKE Mailing List; Paul Hoffman / VPNC > Subject: [Mobike] Re: comments on=20 > draft-dupont-mobike-transport-00.txt=20 >=20 >=20 > =3D> the proposal is to do nothing today to solve the issue, i.e., > to put transport mode stuff out of the immediate scope of Mobike. >=20 >=20 > Francis.Dupont@enst-bretagne.fr > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike >=20 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 11:02:16 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27873 for ; Tue, 12 Oct 2004 11:02:14 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D5E23FB27D; Tue, 12 Oct 2004 15:02:14 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 94DECFB266; Tue, 12 Oct 2004 15:02:13 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 67450FB277; Tue, 12 Oct 2004 15:02:12 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 4ADD3FB255 for ; Tue, 12 Oct 2004 15:02:11 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9CF21800374; Tue, 12 Oct 2004 17:02:01 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9CF21Sj054485; Tue, 12 Oct 2004 17:02:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410121502.i9CF21Sj054485@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 18: Threat discussion In-reply-to: Your message of Mon, 11 Oct 2004 22:00:19 +0300. <416AD843.1060706@piuha.net> Date: Tue, 12 Oct 2004 17:02:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.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: > 3) Unauthenticated attacker causes the IKE_SA to be > closed by modifying just one or two IKE packets (if > attacker can modify all packets, he can of course DoS). > > => I have a concern with this because it is not a MOBIKE threat > but an IKE one. I propose to rewrite it, adding for example > that MOBIKE should not add a new vulnerability (i.e., MOBIKE > should be as resillient as IKE, BTW this should be easy to do). Ok. Do you have suggested text? => I have a simpler (simplest :-) proposal: this attack doesn't work because an unauthenticated attacker cannot produce valid IKE messages after the IKE_SA_INIT exchange, i.e., only a brute force DoS can cause the IKE_SA to be closed. Thanks Francis.Dupont@enst-bretagne.fr PS: the key word is "unauthenticated". _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 11:13:11 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29246 for ; Tue, 12 Oct 2004 11:13:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DB8EEFB27D; Tue, 12 Oct 2004 15:13:10 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 45FB2FB266; Tue, 12 Oct 2004 15:13:09 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5ACC5FB277; Tue, 12 Oct 2004 15:13:08 +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 40EF8FB257 for ; Tue, 12 Oct 2004 15:13:07 +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 i9CFCo801763; Tue, 12 Oct 2004 17:12:50 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9CFCnSj054611; Tue, 12 Oct 2004 17:12:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410121512.i9CFCnSj054611@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] Re: comments on draft-dupont-mobike-transport-00.txt In-reply-to: Your message of Mon, 11 Oct 2004 21:34:44 PDT. <001601c4b014$cc902610$6401a8c0@adithya> Date: Tue, 12 Oct 2004 17:12:49 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: jari.arkko@piuha.net, MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > So, are you saying that this should be changed ? > > => no but direct address changes for transport mode are so complex > that their study should be postponed at least... What do you mean by "direct" address change ? => by a 100% IPsec mechanism. BTW I've seen other messages about this issue expressing the same kind of ideas with other terms. 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 Oct 12 12:16:32 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04916 for ; Tue, 12 Oct 2004 12:16:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AE5EFFB27C; Tue, 12 Oct 2004 16:16:31 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 97276FB266; Tue, 12 Oct 2004 16:16:29 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C6EC3FB277; Tue, 12 Oct 2004 16:16: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 AA501FB257 for ; Tue, 12 Oct 2004 16:16: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 i9CGG7W11688; Tue, 12 Oct 2004 18:16:07 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9CGG7Sj055119; Tue, 12 Oct 2004 18:16:07 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410121616.i9CGG7Sj055119@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Atul.Sharma@nokia.com Subject: Re: [Mobike] Re: comments on draft-dupont-mobike-transport-00.txt In-reply-to: Your message of Tue, 12 Oct 2004 10:40:07 EDT. Date: Tue, 12 Oct 2004 18:16:07 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, jari.arkko@piuha.net, paul.hoffman@vpnc.org X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: If we want to keep transport mode out of MOBIKE scope right now, why are we requesting it to be a working group item? => the document which puts it out of the scope, not the transport mode itself. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 13:50:56 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13753 for ; Tue, 12 Oct 2004 13:50:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 93E0AFB27D; Tue, 12 Oct 2004 17:50:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4C468FB266; Tue, 12 Oct 2004 17:50:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9A264FB277; Tue, 12 Oct 2004 17:50:50 +0000 (UTC) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id 843BBFB257 for ; Tue, 12 Oct 2004 17:50:49 +0000 (UTC) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CHoiW02811; Tue, 12 Oct 2004 20:50:44 +0300 (EET DST) X-Scanned: Tue, 12 Oct 2004 20:49:21 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9CHnLl6016780; Tue, 12 Oct 2004 20:49:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00o2DEpB; Tue, 12 Oct 2004 20:49:20 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CHnJa13488; Tue, 12 Oct 2004 20:49:19 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 20:49:19 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 20:49:19 +0300 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] New issue 16: No packets from other end? Date: Tue, 12 Oct 2004 20:49:19 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] New issue 16: No packets from other end? Thread-Index: AcSwc0A2q2SR9Ak1SvSmaDHujGPJggADskEw From: To: , X-OriginalArrivalTime: 12 Oct 2004 17:49:19.0013 (UTC) FILETIME=[CC6D3550:01C4B083] 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 Francis.Dupont@enst-bretagne.fr writes: >>=20 >> BTW, if we were adding MOBIKE to IKEv1, nothing extra would be=20 >> needed in the protocol to allow hosts to handle this "no packet=20 >> from other end" case; the R-U-THERE dead peer detection messages=20 >> [RFC3706] would be enough. >> =20 >> But currently it seems (to me at least) that in IKEv2, the ability=20 >> to send some kind of R-U-THERE/Hello/Ping/Heartbeat/Path test >> messages outside the IKEv2 window would be necessary, or at=20 >> would simplify the protocol considerably. (And since we decided=20 >> not to assume full connectivity, something like that message may=20 >> be needed anyway.) > =20 > Pasi, I understand your reasonning but not its conclusion. I'm not totally sure about the conclusion myself, but I'll try=20 to clarify my reasoning a bit. Consider the following situation: - Both peers (A and B) have several addresses (A1,A2,...An, B1,B2,...Bn) - We don't have full connectivity: there are some (i,j)=20 for which using Ai,Bj does not provide connectivity =20 between the IKEv2 endpoints (that is, IKEv2=20 implementations running on hosts A and B). - Host A receives some kind of indication (beyond the scope=20 of MOBIKE) that its current address (say, A1) is likely to=20 stop working soon. - Since we don't have full connectivity, A's "mobility and=20 multihoming control module" would like to find the best=20 working (Ai,Bj) before the current one stops working. - In general, lower-layer mechanisms cannot tell whether pair (Ai,Bj) provides connectivity between the IKEv2 endpoints: only an IKEv2 message exchange can tell that. - If we have a separate R-U-THERE message (without window size restrictions), A's "mobility and multihoming control=20 module" could just ask the "MOBIKE module" to try whether some (Ai,Bj) works without worrying about interfering with anything else IKEv2 might be doing. - We can't in general just send a new IKEv2 informational=20 exchange request, because there might be a pending request already (and this is the crucial difference=20 to IKEv1). And just waiting until we get a reply to=20 the pending request does not work either if getting a reply depends on us doing something before that. - In some earlier protocol sketch I suggested just sending the most recent IKE request as a test packet: the other=20 end will retransmit its reply if that (Ai,Bj) works. But it turned out that this can in fact interfere with other functionality, such as return routability=20 checks and "NAT prevention" payloads in some circumstances=20 (if the original request packet got lost). It's possible that this icould be solved by some other means than introducing a "non-window-restricted" message... but it might be the simplest solution. (In particular, I'm not happy with the idea of assuming ---=20 totally contrary to the end-to-end principles --- that the=20 "mobility and multihoming module" knows or can figure out=20 connectivity between IKEv2 endpoints without sending IKEv2 messages.) =20 Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 16:00:06 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26793 for ; Tue, 12 Oct 2004 16:00:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 300C6FB284; Tue, 12 Oct 2004 20:00:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 601B0FB279; Tue, 12 Oct 2004 19:59:59 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E7BE0FB27C; Tue, 12 Oct 2004 19:59:57 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id B496EFB266 for ; Tue, 12 Oct 2004 19:59:56 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6259C8987C for ; Tue, 12 Oct 2004 22:59:54 +0300 (EEST) Message-ID: <416C3764.4030304@piuha.net> Date: Tue, 12 Oct 2004 22:58:28 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobike@machshav.com Subject: Some definitions (Was: Re: [Mobike] New issue 16: No packets from other end?) References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Hello all, While we have not found agreement yet, I think this is a very useful discussion. I believe that when we come to the conclusion we have come a long way towards agreeing what MOBIKE protocol is... Let me attempt a few definitions that may ease the discussion. Here's an overview, details at the end of the mail: Basically, I think that we have something called Available Addresses, delivered to MOBIKE from IPv6/DNA etc. As far as I can see, no one in the WG is thinking of using MOBIKE mechanisms for this. I'd also like to distinguish between locally operational and non-operational addresses; you can have an address but for some reason you know that it isn't working. For instance, the default router is down. I don't see MOBIKE doing anything for this either, we already IPv6 and other mechanisms for this. Finally, what really matters for MOBIKE is an address pair, and whether communication using that address pair is possible. This is only possible if the two addresses are locally operational AND there's IP connectivity between them. The latter is what we are currently debating: do we expect the connectivity to be tested and the best pair chosen by MOBIKE or something else? Details: 1. Available Addresses MOBIKE nodes need to be aware of what addresses they themselves have. If a node loses the address it is currently using for communications, another address must replace this address. And if a node loses an address that the node's peer knows about, the peer must be informed. Similarly, when a node acquires a new address it may generally wish the peer to know about it. Definition. Available address. An address is said to be available if the following conditions are fulfilled: o The address has been assigned to an interface of the node. o If the address is an IPv6 address, we additionally require that (a) the address is valid in the sense of RFC 2461, and that (b) the address is not tentative in the sense of RFC 2462. In other words, the address assignment is complete so that communications can be started. Note this explicitly allows an address to be optimistic in the sense of [draft-ietf-ipv6-optimistic-dad] even though implementations are probably better off using other addresses as long as there is an alternative. o The address is a global unicast or unique site-local address [draft-ietf-ipv6-unique-local-addr]. That is, it is not an IPv6 link-local or site-local address. Where IPv4 is considered, it is not an RFC 1918 address. Available addresses are discovered and monitored through mechanisms outside the scope of MOBIKE. These mechanisms include IPv6 Neighbor Discovery and Address Autoconfiguration [RFC 2461-2462], DHCP [RFC 3315], enhanced network detection mechanisms detected by the DNA working group, and corresponding IPv4 mechanisms, such as [draft-ietf-dhc-dna-ipv4]. 2. Locally Operational Addresses Definition. Locally Operational Address. An available address is said to be locally operational when its use is known to be possible locally: the interface is up and the relevant default router (if applicable) is known to be reachable. Locally operational addresses are discovered and monitored through mechanisms outside MOBIKE. These mechanisms include IPv6 Neighbor Discovery [RFC 2461], corresponding IPv4 mechanisms, and link layer specific mechanisms. 3. Operational Address Pairs 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 sending of packets. For this reason we need the definition of a second level of granularity, for pairs addresses: Definition. Bidirectionally operational address pair. A pair of locally operational addresses are said to be an operational address pair, iff bidirectional connectivity can be shown between the addresses. That is, a packet sent with one of the addresses in the source field and the other in the destination field reaches the destination, and vice versa. Unfortunately, there are scenarios where bidirectionally operational address pairs do not exist. For instance, ingress filtering or network failures may result in one address pair being operational in one direction while another one is operational from the other direction. The following definition captures this general situation: Definition. Undirectionally operational address pair. A pair of locally operational addresses are said to be an unidirectionally operational address pair, iff packets sent with the first address as the source and the second address as the destination can be shown to reach the destination. Both types of operational pairs are discovered and monitored through the following mechanisms: o Positive feedback from upper layer protocols. For instance, TCP can indicate to the IP layer that it is making progress. This is similar to how IPv6 Neighbor Unreachability Detection can in some cases be avoided when upper layers provide information about bidirectional connectivity [RFC 2461]. In the case of unidirectional connectivity, the upper layer protocol responses come back using another address pair, but show that the messages sent using the first address pair have been received. o Explicit reachability tests. For instance, the IKEv2 keepalive mechanism can be used to test that the current pair of addresses is operational. o ICMP error messages. Given the ease of spoofing ICMP messages, one should be careful to not trust these blindly, however. One suggestion is to use ICMP error messages only as a hint to perform an explicit reachability test, but not as a reason to disrupt ongoing communications without other indications of problems. 4. Primary Address Pair Contrary to SCTP which has a specific congestion avoidance design suitable for multi-homing, IP-layer solutions need to avoid sending packets concurrently over multiple paths; TCP behaves rather poorly in such circumstances. For this reason it is necessary to choose a particular pair of addresses as the primary address pair which is used until problems occur, at least for the same session. A primary address pair need not be operational at all times. If there is no traffic to send, we may not know if the primary address pair is operational. Neverthless, it makes sense to assume that the address pair that worked in some time ago continues to work for new communications as well. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 16:04:54 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27361 for ; Tue, 12 Oct 2004 16:04:54 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B5EC7FB27D; Tue, 12 Oct 2004 20:04:53 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6B7B5FB27D; Tue, 12 Oct 2004 20:04:48 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C14A4FB27F; Tue, 12 Oct 2004 20:04:46 +0000 (UTC) Received: from smtp803.mail.sc5.yahoo.com (smtp803.mail.sc5.yahoo.com [66.163.168.182]) by machshav.com (Postfix) with SMTP id 0D560FB266 for ; Tue, 12 Oct 2004 20:04:46 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 12 Oct 2004 20:04:45 -0000 Message-ID: <00d601c4b096$b71339d0$861167c0@adithya> From: "Mohan Parthasarathy" To: , , "MOBIKE Mailing List" References: <00be01c4b088$1fa53ca0$861167c0@adithya> Subject: Re: [Mobike] New issue 16: No packets from other end? Date: Tue, 12 Oct 2004 13:04:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.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 Pasi, Couple of questions.. > >> > >> BTW, if we were adding MOBIKE to IKEv1, nothing extra would be > >> needed in the protocol to allow hosts to handle this "no packet > >> from other end" case; the R-U-THERE dead peer detection messages > >> [RFC3706] would be enough. > >> > >> But currently it seems (to me at least) that in IKEv2, the ability > >> to send some kind of R-U-THERE/Hello/Ping/Heartbeat/Path test > >> messages outside the IKEv2 window would be necessary, or at > >> would simplify the protocol considerably. (And since we decided > >> not to assume full connectivity, something like that message may > >> be needed anyway.) > > > > Pasi, I understand your reasonning but not its conclusion. > > I'm not totally sure about the conclusion myself, but I'll try > to clarify my reasoning a bit. Consider the following situation: > > - Both peers (A and B) have several addresses (A1,A2,...An, > B1,B2,...Bn) > > - We don't have full connectivity: there are some (i,j) > for which using Ai,Bj does not provide connectivity > between the IKEv2 endpoints (that is, IKEv2 > implementations running on hosts A and B). > > - Host A receives some kind of indication (beyond the scope > of MOBIKE) that its current address (say, A1) is likely to > stop working soon. > > - Since we don't have full connectivity, A's "mobility and > multihoming control module" would like to find the best > working (Ai,Bj) before the current one stops working. > As Jari pointed out, currently we don't know of a protocol that the multihoming control module could use. > - In general, lower-layer mechanisms cannot tell whether pair > (Ai,Bj) provides connectivity between the IKEv2 endpoints: > only an IKEv2 message exchange can tell that. > Do you mean to say only IKEv2 can discover whether the path works or not in a secure way ? i.e even if there is a protocol discovered tomorrow that is not secure, it may not be sufficient. Is that what you are trying to say ? Because you said "only IKEv2 message can tell that" ? -thanks mohan > - If we have a separate R-U-THERE message (without window > size restrictions), A's "mobility and multihoming control > module" could just ask the "MOBIKE module" to try whether > some (Ai,Bj) works without worrying about interfering with > anything else IKEv2 might be doing. > > - We can't in general just send a new IKEv2 informational > exchange request, because there might be a pending > request already (and this is the crucial difference > to IKEv1). And just waiting until we get a reply to > the pending request does not work either if getting > a reply depends on us doing something before that. > > - In some earlier protocol sketch I suggested just sending > the most recent IKE request as a test packet: the other > end will retransmit its reply if that (Ai,Bj) works. > But it turned out that this can in fact interfere > with other functionality, such as return routability > checks and "NAT prevention" payloads in some circumstances > (if the original request packet got lost). > > It's possible that this icould be solved by some other > means than introducing a "non-window-restricted" message... > but it might be the simplest solution. > > (In particular, I'm not happy with the idea of assuming --- > totally contrary to the end-to-end principles --- that the > "mobility and multihoming module" knows or can figure out > connectivity between IKEv2 endpoints without sending IKEv2 > messages.) > > Best regards, > Pasi > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 17:32:15 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15797 for ; Tue, 12 Oct 2004 17:32:15 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B81F1FB282; Tue, 12 Oct 2004 21:32:14 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A13DEFB27D; Tue, 12 Oct 2004 21:32:13 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4501EFB27F; Tue, 12 Oct 2004 21:32:12 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id D6969FB27C for ; Tue, 12 Oct 2004 21:32:10 +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 i9CLVxQ18272; Tue, 12 Oct 2004 23:31:59 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9CLVxSj056244; Tue, 12 Oct 2004 23:31:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410122131.i9CLVxSj056244@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Tue, 12 Oct 2004 20:49:19 +0300. <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> Date: Tue, 12 Oct 2004 23:31:59 +0200 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: > Pasi, I understand your reasonning but not its conclusion. I'm not totally sure about the conclusion myself, but I'll try to clarify my reasoning a bit. Consider the following situation: - Both peers (A and B) have several addresses (A1,A2,...An, B1,B2,...Bn) => you assume a peer address set management (OK). - We don't have full connectivity: there are some (i,j) for which using Ai,Bj does not provide connectivity between the IKEv2 endpoints (that is, IKEv2 implementations running on hosts A and B). => some kind of loose pairing is needed if the knowledge is a priori (OK but this can be a strong assumption). - Host A receives some kind of indication (beyond the scope of MOBIKE) that its current address (say, A1) is likely to stop working soon. => OK - Since we don't have full connectivity, A's "mobility and multihoming control module" would like to find the best working (Ai,Bj) before the current one stops working. => OK (usually the module tries to get this knowledge as soon as possible but there is no general solution to provide this). - In general, lower-layer mechanisms cannot tell whether pair (Ai,Bj) provides connectivity between the IKEv2 endpoints: only an IKEv2 message exchange can tell that. => I disagree: the lower-layer here is the IP layer, and it is the layer which can get the information. I don't believe in IP connectivity without UDP connectivity even this is possible in theory. - If we have a separate R-U-THERE message (without window size restrictions), A's "mobility and multihoming control module" could just ask the "MOBIKE module" to try whether some (Ai,Bj) works without worrying about interfering with anything else IKEv2 might be doing. => ask the MOBIKE module should be only an option. - We can't in general just send a new IKEv2 informational exchange request, because there might be a pending request already (and this is the crucial difference to IKEv1). And just waiting until we get a reply to the pending request does not work either if getting a reply depends on us doing something before that. => this is why I said "should be only an option": the R-U-THERE of IKEv2 is not well suited for parallel probing because of the window issue. IMHO the real problem is that probes should be at the IP layer not at the IKEv2 layer: one tries to probe the IP paths, not the peer IKEv2. - In some earlier protocol sketch I suggested just sending the most recent IKE request as a test packet: the other end will retransmit its reply if that (Ai,Bj) works. But it turned out that this can in fact interfere with other functionality, such as return routability checks and "NAT prevention" payloads in some circumstances (if the original request packet got lost). => another issue but IMHO the return routability checks and NAT prevention stuff should be done before. Of course this is true only in an ideal world. It's possible that this icould be solved by some other means than introducing a "non-window-restricted" message... but it might be the simplest solution. => we can use the fact the peer addresses are not part (if one doesn't put them inside explicitely) of IKE messages, i.e., the same request can be sent using different addresses and each eventual reply has the addresses reversed. (In particular, I'm not happy with the idea of assuming --- totally contrary to the end-to-end principles --- that the "mobility and multihoming module" knows or can figure out connectivity between IKEv2 endpoints without sending IKEv2 messages.) => IMHO the problem is about the "connectivity" term: it can be either IP path availability or peer IKEv2 live check. The dead peer detection is explicitely about the second case but what we want here is the first one. 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 Oct 12 18:08:02 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20903 for ; Tue, 12 Oct 2004 18:08:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 911AEFB27D; Tue, 12 Oct 2004 22:08:02 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 13806FB27F; Tue, 12 Oct 2004 22:07:57 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2BDDAFB280; Tue, 12 Oct 2004 22:07:56 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 47105FB27D for ; Tue, 12 Oct 2004 22:07:54 +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 i9CM7dQ21336; Wed, 13 Oct 2004 00:07:39 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9CM7dSj056471; Wed, 13 Oct 2004 00:07:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410122207.i9CM7dSj056471@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: Some definitions (Was: Re: [Mobike] New issue 16: No packets from other end?) In-reply-to: Your message of Tue, 12 Oct 2004 22:58:28 +0300. <416C3764.4030304@piuha.net> Date: Wed, 13 Oct 2004 00:07:39 +0200 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: Finally, what really matters for MOBIKE is an address pair, and whether communication using that address pair is possible. This is only possible if the two addresses are locally operational AND there's IP connectivity between them. The latter is what we are currently debating: do we expect the connectivity to be tested and the best pair chosen by MOBIKE or something else? => IMHO the local choice should be done by a general module and the role of the MOBIKE protocol is to inform the other peer. Details: 1. Available Addresses MOBIKE nodes need to be aware of what addresses they themselves have. => it seems you are in favor of the "set" style. If a node loses the address it is currently using for communications, another address must replace this address. => in the "set" style this another address MAY be known before. And if a node loses an address that the node's peer knows about, the peer must be informed. => IMHO this is one part (what I call "address management") of the MOBIKE protocol. Similarly, when a node acquires a new address it may generally wish the peer to know about it. => more, it should wish the peer to accept it. Definition. Available address. An address is said to be available if the following conditions are fulfilled: o The address has been assigned to an interface of the node. o If the address is an IPv6 address, we additionally require that (a) the address is valid in the sense of RFC 2461, and that (b) the address is not tentative in the sense of RFC 2462. In other words, the address assignment is complete so that communications can be started. Note this explicitly allows an address to be optimistic in the sense of [draft-ietf-ipv6-optimistic-dad] even though implementations are probably better off using other addresses as long as there is an alternative. => we can simply ask the address is usable for communication and if we want to be strict we can ask the address is usable for IKEv2 communication (obviously when it is not the case we'll be in trouble). o The address is a global unicast or unique site-local address [draft-ietf-ipv6-unique-local-addr]. => I object: a link-local address should be available when the peer is on the same link. That is, it is not an IPv6 link-local or site-local address. Where IPv4 is considered, it is not an RFC 1918 address. => I strongly object: a private address must be available when the peer is in the same RFC 1918 "realm". Available addresses are discovered and monitored through mechanisms outside the scope of MOBIKE. => so the previous discussion doesn't make sense. These mechanisms include IPv6 Neighbor Discovery and Address Autoconfiguration [RFC 2461-2462], DHCP [RFC 3315], enhanced network detection mechanisms detected by the DNA working group, and corresponding IPv4 mechanisms, such as [draft-ietf-dhc-dna-ipv4]. => don't forget routing protocols when the node is a router (common with SGs :-). 2. Locally Operational Addresses Definition. Locally Operational Address. An available address is said to be locally operational when its use is known to be possible locally: the interface is up and the relevant default router (if applicable) is known to be reachable. => this is too strict: the peer can be on the same link so reachable without a default router. Locally operational addresses are discovered and monitored through mechanisms outside MOBIKE. These mechanisms include IPv6 Neighbor Discovery [RFC 2461], corresponding IPv4 mechanisms, and link layer specific mechanisms. => don't forget source address selection (RFC 3484). 3. Operational Address Pairs 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 sending of packets. For this reason we need the definition of a second level of granularity, for pairs addresses: => you are trying to reinvent RFC 3484... Definition. Bidirectionally operational address pair. A pair of locally operational addresses are said to be an operational address pair, iff bidirectional connectivity can be shown between the addresses. That is, a packet sent with one of the addresses in the source field and the other in the destination field reaches the destination, and vice versa. => note this restricts MOBIKE to symmetrical connectivity. IMHO this is a reasonnable constraint as IKEv2 requires it (PS: does the constraint applies only to the IKE SA or to both the IKE SA and the IPsec SA pairs?) Unfortunately, there are scenarios where bidirectionally operational address pairs do not exist. For instance, ingress filtering or network failures may result in one address pair being operational in one direction while another one is operational from the other direction. The following definition captures this general situation: Definition. Undirectionally operational address pair. A pair of locally operational addresses are said to be an unidirectionally operational address pair, iff packets sent with the first address as the source and the second address as the destination can be shown to reach the destination. Both types of operational pairs are discovered and monitored through the following mechanisms: => this is clearly outside the scope of MOBIKE IMHO! o Positive feedback from upper layer protocols. For instance, TCP can indicate to the IP layer that it is making progress. This is similar to how IPv6 Neighbor Unreachability Detection can in some cases be avoided when upper layers provide information about bidirectional connectivity [RFC 2461]. In the case of unidirectional connectivity, the upper layer protocol responses come back using another address pair, but show that the messages sent using the first address pair have been received. => is IPsec an upper layer protocol for this? o Explicit reachability tests. For instance, the IKEv2 keepalive mechanism can be used to test that the current pair of addresses is operational. => this is an application layer positive feedback when what it is needed is at the network layer. o ICMP error messages. Given the ease of spoofing ICMP messages, one should be careful to not trust these blindly, however. One suggestion is to use ICMP error messages only as a hint to perform an explicit reachability test, but not as a reason to disrupt ongoing communications without other indications of problems. => I propose to use exactly what it was specified for transport protocols like TCP which share the issue. 4. Primary Address Pair Contrary to SCTP which has a specific congestion avoidance design suitable for multi-homing, IP-layer solutions need to avoid sending packets concurrently over multiple paths; TCP behaves rather poorly in such circumstances. For this reason it is necessary to choose a particular pair of addresses as the primary address pair which is used until problems occur, at least for the same session. => there is a simpler reason: the IKE SA uses *one* address pair. A primary address pair need not be operational at all times. If there is no traffic to send, we may not know if the primary address pair is operational. Neverthless, it makes sense to assume that the address pair that worked in some time ago continues to work for new communications as well. => communications? Perhaps you mean IKEv2 messages because other meanings can be outside the scope of MOBIKE. Regards Francis.Dupont@enst-bretagne.fr PS: if you remove every item outside of the scope of MOBIKE, you get something very close to my "peer address management", don't you? _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 18:12:13 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21451 for ; Tue, 12 Oct 2004 18:12:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5B98DFB283; Tue, 12 Oct 2004 22:12:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BBB6DFB27D; Tue, 12 Oct 2004 22:12:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5EA99FB27F; Tue, 12 Oct 2004 22:12:10 +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 4A2DCFB279 for ; Tue, 12 Oct 2004 22:12:09 +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 i9CMC1Q21633; Wed, 13 Oct 2004 00:12:01 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9CMC1Sj056494; Wed, 13 Oct 2004 00:12:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410122212.i9CMC1Sj056494@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Tue, 12 Oct 2004 13:04:42 PDT. <00d601c4b096$b71339d0$861167c0@adithya> Date: Wed, 13 Oct 2004 00:12:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Pasi.Eronen@nokia.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: > - Since we don't have full connectivity, A's "mobility and > multihoming control module" would like to find the best > working (Ai,Bj) before the current one stops working. > As Jari pointed out, currently we don't know of a protocol that the multihoming control module could use. => there will be one: this is not the job of MOBIKE to specify one, but this is the job of MULTI6 and MIP6. 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 Oct 12 18:39:27 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24087 for ; Tue, 12 Oct 2004 18:39:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 85ACDFB284; Tue, 12 Oct 2004 22:39:26 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 67E3FFB27D; Tue, 12 Oct 2004 22:39:23 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 76683FB27F; Tue, 12 Oct 2004 22:39:22 +0000 (UTC) Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by machshav.com (Postfix) with SMTP id B8B3FFB27C for ; Tue, 12 Oct 2004 22:39:21 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 12 Oct 2004 22:39:21 -0000 Message-ID: <00ec01c4b0ac$4f6c0800$861167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" References: <200410122212.i9CMC1Sj056494@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] New issue 16: No packets from other end? Date: Tue, 12 Oct 2004 15:39:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: Pasi.Eronen@nokia.com, MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit > In your previous mail you wrote: > > > - Since we don't have full connectivity, A's "mobility and > > multihoming control module" would like to find the best > > working (Ai,Bj) before the current one stops working. > > > As Jari pointed out, currently we don't know of a protocol that > the multihoming control module could use. > > => there will be one: this is not the job of MOBIKE to specify one, > but this is the job of MULTI6 and MIP6. > And for IPv4 ? How can MIP6 tell me that the (src, dst) pair is working or not ? -mohan > Thanks > > Francis.Dupont@enst-bretagne.fr > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 18:46:41 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24553 for ; Tue, 12 Oct 2004 18:46:39 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9C01FFB282; Tue, 12 Oct 2004 22:46:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6C39DFB27C; Tue, 12 Oct 2004 22:46:38 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7DEFCFB27D; Tue, 12 Oct 2004 22:46:36 +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 5BF33FB252 for ; Tue, 12 Oct 2004 22:46: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 i9CMkRQ24731; Wed, 13 Oct 2004 00:46:27 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9CMkSSj056792; Wed, 13 Oct 2004 00:46:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410122246.i9CMkSSj056792@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Tue, 12 Oct 2004 15:39:18 PDT. <00ec01c4b0ac$4f6c0800$861167c0@adithya> Date: Wed, 13 Oct 2004 00:46:28 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, 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: > => there will be one: this is not the job of MOBIKE to specify one, > but this is the job of MULTI6 and MIP6. > And for IPv4 ? How can MIP6 tell me that the (src, dst) pair is working or not ? => and MIP4 (unfortunately either IPv4 multi-homing uses a PI address or uses a MULTI6-like mechanism without specs...). Note for interesting cases MIP6 includes MIP4 (this is why I've forgotten it). Thanks Francis.Dupont@enst-bretagne.fr PS: the real issue is to do the job of MULTI6 in MOBIKE... Mobility cases are well understood and even already implemented! _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 20:14:41 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00710 for ; Tue, 12 Oct 2004 20:14:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id ADBF0FB283; Wed, 13 Oct 2004 00:14:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EC086FB279; Wed, 13 Oct 2004 00:14:36 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 808A4FB27C; Wed, 13 Oct 2004 00:14:35 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 8A5AFFB266 for ; Wed, 13 Oct 2004 00:14:34 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9CNlVr04522; Tue, 12 Oct 2004 16:47:31 -0700 X-mProtect: <200410122347> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14195.americas.nokia.com (172.18.141.95, claiming to be "[172.18.141.95]") by darkstar.iprg.nokia.com smtpdrbqzSa; Tue, 12 Oct 2004 16:47:29 PDT Message-ID: <416C7358.9040802@iprg.nokia.com> Date: Tue, 12 Oct 2004 17:14:16 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 16: No packets from other end? References: <125EA890549C8641A72F3809CB80DCCD178370@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD178370@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Vijay Devarapalli writes: > >>>However, that's the part that the rest of the stack is >>>telling MOBIKE. The second level is what happens after >>>MOBIKE has been told something. For instance, lets say >>>that it has been told that there's two usable addresses >>>at this end and one at the other end; that's two possible >>>address pairs. Now we get a problem -- ESP tells IKE >>>that there's no packets, IKE attempts DPD which fails. >>>There's no information coming from IPv6/DNA/DHC/MIP6 >>>(and presumably there will not be any information coming >>>soon either, because the DPD process took a while). >> >>I dont agree with this statement. IMHO, if IPv6/DNA/DHC/MIP6 >>are not able to figure out what happened, MOBIKE should just >>keep quiet. >>... >>I think (2) is the way to go. I dont want MOBIKE making a >>decision that conflicts with IPv6/DNA/DHC/MIP6/SCTP/whatever. > > > I think we need to clearly separate host-internal implementation > issues and specifying interoperability-enabling protocols here. okay. > This issue was not about whether the "MOBIKE module" should keep > quiet or decide something or conflict with someone else; it was > whether we should make it possible for a _host_ to recover from > a situation where its IKE endpoint and the peer IKE endpoint > cannot communicate using the current addresses. agree. > > Whether that recovery is "controlled" by the "MOBIKE module", > or perhaps some "general mobility/multihoming module" (possibly > using information from some "DNA module") in the host is > completely besides the point. this is where my concern is. > > I do agree that actual implementations might work e.g. so that > when DPD seems to fail, the "MOBIKE module" notifies the "mobility > and multihoming control module" that "we seem to have a problem; > but the peer said it also has addresses B2,B3,B4; please tell > me what to do". The control module could then tell MOBIKE module > that "based on your report, and information I may have received > from other modules, my decision is to start using local address > A2 and remote address B3". right. my concern is only about MOBIKE going off and making the decision by itself. > > The interface between those modules is of course not MOBIKE WG's > business, but I hope you're not opposing that we allow such > interfaces to be built? ofcourse not. > > BTW, if we were adding MOBIKE to IKEv1, nothing extra would be > needed in the protocol to allow hosts to handle this "no packet > from other end" case; the R-U-THERE dead peer detection messages > [RFC3706] would be enough. > > But currently it seems (to me at least) that in IKEv2, the ability > to send some kind of R-U-THERE/Hello/Ping/Heartbeat/Path test > messages outside the IKEv2 window would be necessary, or at > would simplify the protocol considerably. (And since we decided > not to assume full connectivity, something like that message may > be needed anyway.) until this I agree, but not with the last paragraph. if the mobility/multi-homing module is not able to verify IP connectivity how will the MOBIKE module do it? Vijay _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 20:19:06 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01231 for ; Tue, 12 Oct 2004 20:19:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7DC65FB27F; Wed, 13 Oct 2004 00:19:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E4F6AFB279; Wed, 13 Oct 2004 00:19:02 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 93822FB27C; Wed, 13 Oct 2004 00:19:01 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 71058FB266 for ; Wed, 13 Oct 2004 00:18:49 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9CNpPm08374; Tue, 12 Oct 2004 16:51:25 -0700 X-mProtect: <200410122351> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14195.americas.nokia.com (172.18.141.95, claiming to be "[172.18.141.95]") by darkstar.iprg.nokia.com smtpdjsGyzF; Tue, 12 Oct 2004 16:51:23 PDT Message-ID: <416C7442.8020102@iprg.nokia.com> Date: Tue, 12 Oct 2004 17:18:10 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] New issue 16: No packets from other end? References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Francis.Dupont@enst-bretagne.fr 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 Pasi.Eronen@nokia.com wrote: > Francis.Dupont@enst-bretagne.fr writes: > >>>BTW, if we were adding MOBIKE to IKEv1, nothing extra would be >>>needed in the protocol to allow hosts to handle this "no packet >>>from other end" case; the R-U-THERE dead peer detection messages >>>[RFC3706] would be enough. >>> >>>But currently it seems (to me at least) that in IKEv2, the ability >>>to send some kind of R-U-THERE/Hello/Ping/Heartbeat/Path test >>>messages outside the IKEv2 window would be necessary, or at >>>would simplify the protocol considerably. (And since we decided >>>not to assume full connectivity, something like that message may >>>be needed anyway.) >> >> >>Pasi, I understand your reasonning but not its conclusion. > > > I'm not totally sure about the conclusion myself, but I'll try > to clarify my reasoning a bit. Consider the following situation: > > - Both peers (A and B) have several addresses (A1,A2,...An, > B1,B2,...Bn) > > - We don't have full connectivity: there are some (i,j) > for which using Ai,Bj does not provide connectivity > between the IKEv2 endpoints (that is, IKEv2 > implementations running on hosts A and B). > > - Host A receives some kind of indication (beyond the scope > of MOBIKE) that its current address (say, A1) is likely to > stop working soon. > > - Since we don't have full connectivity, A's "mobility and > multihoming control module" would like to find the best > working (Ai,Bj) before the current one stops working. > > - In general, lower-layer mechanisms cannot tell whether pair > (Ai,Bj) provides connectivity between the IKEv2 endpoints: > only an IKEv2 message exchange can tell that. totally disagree with this particular statement. assuming the IP stack is the lower layer (with might include MIP6/MULTI6), why would MOBIKE be able to figure out something the IP stack couldnt? UDP is a transport protocol on top of IP, right? or am I missing the whole thing? Vijay > > - If we have a separate R-U-THERE message (without window > size restrictions), A's "mobility and multihoming control > module" could just ask the "MOBIKE module" to try whether > some (Ai,Bj) works without worrying about interfering with > anything else IKEv2 might be doing. > > - We can't in general just send a new IKEv2 informational > exchange request, because there might be a pending > request already (and this is the crucial difference > to IKEv1). And just waiting until we get a reply to > the pending request does not work either if getting > a reply depends on us doing something before that. > > - In some earlier protocol sketch I suggested just sending > the most recent IKE request as a test packet: the other > end will retransmit its reply if that (Ai,Bj) works. > But it turned out that this can in fact interfere > with other functionality, such as return routability > checks and "NAT prevention" payloads in some circumstances > (if the original request packet got lost). > > It's possible that this icould be solved by some other > means than introducing a "non-window-restricted" message... > but it might be the simplest solution. > > (In particular, I'm not happy with the idea of assuming --- > totally contrary to the end-to-end principles --- that the > "mobility and multihoming module" knows or can figure out > connectivity between IKEv2 endpoints without sending IKEv2 > messages.) > > Best regards, > Pasi > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 21:23:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05897 for ; Tue, 12 Oct 2004 21:23:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BB749FB280; Wed, 13 Oct 2004 01:23:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 869BBFB279; Wed, 13 Oct 2004 01:23:57 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CD8E4FB27C; Wed, 13 Oct 2004 01:23:55 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 046F5FB266 for ; Wed, 13 Oct 2004 01:23:55 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9D0urg22407; Tue, 12 Oct 2004 17:56:53 -0700 X-mProtect: <200410130056> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14195.americas.nokia.com (172.18.141.95, claiming to be "[172.18.141.95]") by darkstar.iprg.nokia.com smtpdeKINCP; Tue, 12 Oct 2004 17:56:51 PDT Message-ID: <416C839B.8090106@iprg.nokia.com> Date: Tue, 12 Oct 2004 18:23:39 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: Some definitions (Was: Re: [Mobike] New issue 16: No packets from other end?) References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> <416C3764.4030304@piuha.net> In-Reply-To: <416C3764.4030304@piuha.net> 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 Hello Jari, a nice writeup. thanks. one comment below. Jari Arkko wrote: > Details: > > 1. Available Addresses > > MOBIKE nodes need to be aware of what addresses they themselves have. > If a node loses the address it is currently using for communications, > another address must replace this address. And if a node loses an > address that the node's peer knows about, the peer must be informed. > Similarly, when a node acquires a new address it may generally wish > the peer to know about it. > > Definition. Available address. An address is said to be available if > the following conditions are fulfilled: > > o The address has been assigned to an interface of the node. > > o If the address is an IPv6 address, we additionally require that > (a) the address is valid in the sense of RFC 2461, and that > (b) the address is not tentative in the sense of RFC 2462. In > other words, the address assignment is complete so that > communications can be started. > > Note this explicitly allows an address to be optimistic in the > sense of [draft-ietf-ipv6-optimistic-dad] even though > implementations are probably better off using other > addresses as long as there is an alternative. > > o The address is a global unicast or unique site-local address > [draft-ietf-ipv6-unique-local-addr]. > > That is, it is not an IPv6 link-local or site-local address. > Where IPv4 is considered, it is not an RFC 1918 address. > > Available addresses are discovered and monitored through mechanisms > outside the scope of MOBIKE. These mechanisms include IPv6 > Neighbor Discovery and Address Autoconfiguration [RFC 2461-2462], > DHCP [RFC 3315], enhanced network detection mechanisms detected by > the DNA working group, and corresponding IPv4 mechanisms, such as > [draft-ietf-dhc-dna-ipv4]. this doesnt take into account some addresses that satisfy the above conditions, but are restricted by certain policies on the MN. for example, in an earlier mail, I had explained a scenario where I didnt want MOBIKE to use an address configured from a low bandwidth GPRS link to download email through a VPN tunnel. Vijay _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 22:43:25 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11402 for ; Tue, 12 Oct 2004 22:43:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5841DFB286; Wed, 13 Oct 2004 02:43:25 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BD8AFFB27F; Wed, 13 Oct 2004 02:43:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BF4D7FB280; Wed, 13 Oct 2004 02:43:19 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 18615FB27C for ; Wed, 13 Oct 2004 02:43:19 +0000 (UTC) Message-ID: <030f01c4b0ce$84746a70$496015ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> <416C3764.4030304@piuha.net> Subject: Re: Some definitions (Was: Re: [Mobike] New issue 16: No packets fromother end?) Date: Tue, 12 Oct 2004 19:44:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 ----- > 4. Primary Address Pair > > Contrary to SCTP which has a specific congestion avoidance design > suitable for multi-homing, IP-layer solutions need to avoid sending > packets concurrently over multiple paths; TCP behaves rather poorly > in such circumstances. For this reason it is necessary to choose a > particular pair of addresses as the primary address pair which is > used until problems occur, at least for the same session. > Actually, SCTP doesn't send packets over multiple paths either. It uses the addresses only for failover, that is when it detects a failure, it switches to another address. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 12 23:06:05 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12851 for ; Tue, 12 Oct 2004 23:06:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 15B2DFB289; Wed, 13 Oct 2004 03:06:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 87A18FB282; Wed, 13 Oct 2004 03:06:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D8447FB283; Wed, 13 Oct 2004 03:06:01 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 37D0DFB280 for ; Wed, 13 Oct 2004 03:06:01 +0000 (UTC) Message-ID: <031f01c4b0d1$b092ca40$496015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Francis Dupont" , References: <200410122131.i9CLVxSj056244@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] New issue 16: No packets from other end? Date: Tue, 12 Oct 2004 20:06:46 -0700 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 Francis, > => this is why I said "should be only an option": the R-U-THERE > of IKEv2 is not well suited for parallel probing because of > the window issue. IMHO the real problem is that probes should > be at the IP layer not at the IKEv2 layer: one tries to probe > the IP paths, not the peer IKEv2. > So is IP reachability both necessary and sufficient for "IKE-reachability"? jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 13 00:06:25 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17404 for ; Wed, 13 Oct 2004 00:06:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 91DB0FB282; Wed, 13 Oct 2004 04:06:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9BFB7FB282; Wed, 13 Oct 2004 04:06:23 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B8C8CFB283; Wed, 13 Oct 2004 04:06:21 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 27D61FB24D for ; Wed, 13 Oct 2004 04:06:21 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B06BD89860; Wed, 13 Oct 2004 07:06:18 +0300 (EEST) Message-ID: <416CA964.8040203@piuha.net> Date: Wed, 13 Oct 2004 07:04:52 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: Some definitions (Was: Re: [Mobike] New issue 16: No packets from other end?) References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> <416C3764.4030304@piuha.net> <416C839B.8090106@iprg.nokia.com> In-Reply-To: <416C839B.8090106@iprg.nokia.com> 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 Vijay Devarapalli wrote: >> Available addresses are discovered and monitored through mechanisms >> outside the scope of MOBIKE. These mechanisms include IPv6 >> Neighbor Discovery and Address Autoconfiguration [RFC 2461-2462], >> DHCP [RFC 3315], enhanced network detection mechanisms detected by >> the DNA working group, and corresponding IPv4 mechanisms, such as >> [draft-ietf-dhc-dna-ipv4]. > > > this doesnt take into account some addresses that satisfy the above > conditions, but are restricted by certain policies on the MN. for > example, in an earlier mail, I had explained a scenario where I didnt > want MOBIKE to use an address configured from a low bandwidth GPRS > link to download email through a VPN tunnel. Right. Yes, I forgot that. Policy indeed needs to be taken into account. Thanks for spotting this. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 13 00:08:33 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17634 for ; Wed, 13 Oct 2004 00:08:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3B750FB289; Wed, 13 Oct 2004 04:08:33 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EA93BFB282; Wed, 13 Oct 2004 04:08:31 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9DDC2FB283; Wed, 13 Oct 2004 04:08:30 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 1077FFB24D for ; Wed, 13 Oct 2004 04:08:30 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2CB9E89860; Wed, 13 Oct 2004 07:08:29 +0300 (EEST) Message-ID: <416CA9E7.7080907@piuha.net> Date: Wed, 13 Oct 2004 07:07:03 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: Some definitions (Was: Re: [Mobike] New issue 16: No packets fromother end?) References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> <416C3764.4030304@piuha.net> <030f01c4b0ce$84746a70$496015ac@dcml.docomolabsusa.com> In-Reply-To: <030f01c4b0ce$84746a70$496015ac@dcml.docomolabsusa.com> 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 James Kempf wrote: > ----- > 4. Primary Address Pair > >> Contrary to SCTP which has a specific congestion avoidance design >> suitable for multi-homing, IP-layer solutions need to avoid sending >> packets concurrently over multiple paths; TCP behaves rather poorly >> in such circumstances. For this reason it is necessary to choose a >> particular pair of addresses as the primary address pair which is >> used until problems occur, at least for the same session. >> > > > Actually, SCTP doesn't send packets over multiple paths either. It uses the > addresses only for failover, that is when it detects a failure, it switches > to another address. Yes, I think you are right about the usage of just one path at a time. Question: does SCTP still have some specific congestion avoidance for multi-homing, such as going back to slow start upon changing to a different path? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 13 00:29:41 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18916 for ; Wed, 13 Oct 2004 00:29:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 88B14FB283; Wed, 13 Oct 2004 04:29:42 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A8E1DFB266; Wed, 13 Oct 2004 04:29:41 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 085EDFB279; Wed, 13 Oct 2004 04:29:40 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 22CE0FB252 for ; Wed, 13 Oct 2004 04:29:39 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 064CE89860; Wed, 13 Oct 2004 07:29:37 +0300 (EEST) Message-ID: <416CAEDB.6000501@piuha.net> Date: Wed, 13 Oct 2004 07:28:11 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Can lower layer tell there's connectivity? (Was: Re: [Mobike] New issue 16: No packets from other end?) References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> <416C7442.8020102@iprg.nokia.com> In-Reply-To: <416C7442.8020102@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Francis.Dupont@enst-bretagne.fr 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 Vijay Devarapalli wrote: >> - In general, lower-layer mechanisms cannot tell whether pair >> (Ai,Bj) provides connectivity between the IKEv2 endpoints: >> only an IKEv2 message exchange can tell that. > > totally disagree with this particular statement. assuming the IP > stack is the lower layer (with might include MIP6/MULTI6), why > would MOBIKE be able to figure out something the IP stack couldnt? > > UDP is a transport protocol on top of IP, right? There appears to be several questions here. What Pasi is stating need to made more specific before we can find agreement. I think we are talking about: (1) Difference wrt IP layer connectivity and the ability to talk between the IKEv2 peers. There is indeed a difference, the IKEv2 module could suddenly die... or the client could have been disconnected and the address recycled to someone else. Personally, I'm not sure this is worth covering. IP connectivity should be enough. But see (2) below. (2) Ensuring that a given address really is the same node. When probing for the correctness of a claimed address, we may want to ensure that its indeed the same IKEv2 node at this address. It seems that the only way to do this is an IKEv2 message. But note that we are talking about address update, not failure recovery here. So failure recovery might still work using only IP layer connectivity tests. (3) What current lower layers are able to tell to MOBIKE. This is what I have been saying, that as far as I know, current lower layer support in IPv6, DNA, DHC, etc. only provides support for the discovery of available addresses and locally operational addresses. Not the discovery operational address pairs. I'm not saying that it wouldn't be possible to develop one, just that one doesn't exist now. But I could be missing something, I'm sure you guys will tell me what... --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 13 00:44:29 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19958 for ; Wed, 13 Oct 2004 00:44:27 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CD127FB283; Wed, 13 Oct 2004 04:44:28 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 359EFFB27C; Wed, 13 Oct 2004 04:44:25 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AFF04FB27D; Wed, 13 Oct 2004 04:44:23 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id AD62BFB279 for ; Wed, 13 Oct 2004 04:44:22 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9E9F089860; Wed, 13 Oct 2004 07:44:21 +0300 (EEST) Message-ID: <416CB24F.9080404@piuha.net> Date: Wed, 13 Oct 2004 07:42:55 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] New issue 16: No packets from other end? References: <200410122212.i9CMC1Sj056494@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410122212.i9CMC1Sj056494@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, Mohan Parthasarathy , 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: > => there will be one: this is not the job of MOBIKE to specify one, > but this is the job of MULTI6 and MIP6. Re: MIP6. There's been a draft or two about extending Mobile IPv6 to support multihoming (parallel addresses as opposed to serial ones). However, this does not appear to be a work item in any of the current IETF working groups related to Mobile IPv6. Re: MULTI6. This is being worked on. But there are a couple of issues. First, MULTI6 explicitly decided to handled the pure IPv6 problem only. It seems that the solution their design team is thinking of is going to work only for IPv6 without an easy extension to IPv4. Secondly, since there are no detailed or official solution drafts yet available for the failure detection part, its kind of hard to tell whether it could be ripped out of MULTI6 and used for supporting MOBIKE. Maybe. But probably more as an idea rather than relying on what the MULTI6 module is telling MOBIKE. In fact, if you had MULTI6 running and you were satisfied with the limitation to IPv6, you would not need MOBIKE, right? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 13 04:29:19 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01838 for ; Wed, 13 Oct 2004 04:29:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 404A8FB280; Wed, 13 Oct 2004 08:29:14 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5488EFB27C; Wed, 13 Oct 2004 08:29:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2001BFB27D; Wed, 13 Oct 2004 08:29:09 +0000 (UTC) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id CAE7CFB279 for ; Wed, 13 Oct 2004 08:29:07 +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 i9D8Sj08023111 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Oct 2004 11:28:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i9D8ShEq023108; Wed, 13 Oct 2004 11:28:43 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16748.59195.255358.548764@fireball.kivinen.iki.fi> Date: Wed, 13 Oct 2004 11:28:43 +0300 From: Tero Kivinen To: Vijay Devarapalli Subject: Re: [Mobike] New issue 16: No packets from other end? In-Reply-To: <416C7442.8020102@iprg.nokia.com> References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> <416C7442.8020102@iprg.nokia.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 6 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com, Francis.Dupont@enst-bretagne.fr 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 Vijay Devarapalli writes: > > - In general, lower-layer mechanisms cannot tell whether pair > > (Ai,Bj) provides connectivity between the IKEv2 endpoints: > > only an IKEv2 message exchange can tell that. > > totally disagree with this particular statement. assuming the IP > stack is the lower layer (with might include MIP6/MULTI6), why > would MOBIKE be able to figure out something the IP stack couldnt? Because MOBIKE is the only one that can really say if there is connection that is good enough for him. For the IP point of view the connection between two IP-addresses might work even when there is NAT between, which eats all UDP port 500/4500 packets. For MOBIKE point of view the connection is broken. > UDP is a transport protocol on top of IP, right? yes. And TCP is over IP, and even when TCP works it does not give us any indication that UDP will really work. Also even if UDP for port x works, it does not say anything whether UDP on port y will work. This is because of firewalls, nats and similar things. Also sending one ICMP message might make IP layer to think that the connection is broken, and we propably do not want to allow that easy DoS attacks. I think MOBIKE should get use and try to get as much information from outside as possible, but in the end it still needs to test the possible address pairs by itself to get positive feedback that the address pair works. The other layers can give lots all kind of hints, and most likely it can give quite reliable negative feedback, i.e. it can say that this address cannot work anymore as the interface used was removed from the machine, or the DHCP server gave me new address etc. We can belive some of that information but it might also give information saying this IP-address is not working, as I got ICMP host unreachable back to my ICMP ping message, and we propably should not belive that information. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 13 05: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 FAA05302 for ; Wed, 13 Oct 2004 05:21:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 73404FB284; Wed, 13 Oct 2004 09:21:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 54DA8FB27F; Wed, 13 Oct 2004 09:21:42 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8345DFB280; Wed, 13 Oct 2004 09:21:40 +0000 (UTC) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by machshav.com (Postfix) with ESMTP id 1A5D3FB27C for ; Wed, 13 Oct 2004 09:21:39 +0000 (UTC) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9D9Lbh18387; Wed, 13 Oct 2004 12:21:37 +0300 (EET DST) X-Scanned: Wed, 13 Oct 2004 12:19:15 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9D9JFBD001356; Wed, 13 Oct 2004 12:19:15 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00phdixq; Wed, 13 Oct 2004 12:19:13 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9D9J2a01511; Wed, 13 Oct 2004 12:19:02 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 12:17:49 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 12:17:47 +0300 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] New issue 16: No packets from other end? Date: Wed, 13 Oct 2004 12:17:48 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD28@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] New issue 16: No packets from other end? Thread-Index: AcSwluIozwEHIH/oQ9OlYr0KAm2X4gAbIu6Q From: To: , X-OriginalArrivalTime: 13 Oct 2004 09:17:47.0721 (UTC) FILETIME=[81677390:01C4B105] 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 Mohan Parthasarathy writes: > > > > - Since we don't have full connectivity, A's "mobility and=20 > > multihoming control module" would like to find the best=20 > > working (Ai,Bj) before the current one stops working. > >=20 > As Jari pointed out, currently we don't know of a protocol=20 > that the multihoming control module could use. We don't need a protocol (between hosts A and B) to have=20 such a control module. A local API would be quite=20 sufficient for many cases. > > - In general, lower-layer mechanisms cannot tell whether pair > > (Ai,Bj) provides connectivity between the IKEv2 endpoints: > > only an IKEv2 message exchange can tell that. > >=20 > Do you mean to say only IKEv2 can discover whether the path > works or not in a secure way ? i.e even if there is a protocol > discovered tomorrow that is not secure, it may not be sufficient. > Is that what you are trying to say ? Because you said "only IKEv2 > message can tell that" ? Security is one aspect of it, but that was not I meant. What I meant was that if we have (or do not have) connectivity=20 between some other protocol endpoints on A and B (say, ICMP with=20 Echo Request/Reply), that doesn't automatically mean that we have=20 (or do not have) connectivity between the IKEv2 endpoints (and by endpoints, I mean the IKEv2 software, not the host). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 13 05:37:34 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06348 for ; Wed, 13 Oct 2004 05:37:33 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E1CAEFB284; Wed, 13 Oct 2004 09:37:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 26C4AFB280; Wed, 13 Oct 2004 09:37:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1E6A6FB282; Wed, 13 Oct 2004 09:37:28 +0000 (UTC) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 0D137FB27F for ; Wed, 13 Oct 2004 09:37:27 +0000 (UTC) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9D9bPF12306 for ; Wed, 13 Oct 2004 12:37:25 +0300 (EET DST) X-Scanned: Wed, 13 Oct 2004 12:34:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9D9Y1RS013949 for ; Wed, 13 Oct 2004 12:34:02 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00qI2IBS; Wed, 13 Oct 2004 12:33:46 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9D9Xga15023 for ; Wed, 13 Oct 2004 12:33:42 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 12:33:14 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 12:33:14 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 12:33:14 +0300 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] New issue 16: No packets from other end? Date: Wed, 13 Oct 2004 12:33:14 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD29@esebe056.ntc.nokia.com> Thread-Topic: [Mobike] New issue 16: No packets from other end? Thread-Index: AcSw/wc/V5dEwcBxSqGi0GZ8ESdWQwACHITw From: To: X-OriginalArrivalTime: 13 Oct 2004 09:33:14.0659 (UTC) FILETIME=[A9E6F730:01C4B107] 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 Thanks, Tero; this was exactly what I meant, but your explanation is certainly much more understandable :-) Best regards, Pasi > -----Original Message----- > From: ext Tero Kivinen > Sent: Wednesday, October 13, 2004 11:29 AM > To: Vijay Devarapalli > Cc: Eronen Pasi (Nokia-NRC/Helsinki); mobike@machshav.com; > Francis.Dupont@enst-bretagne.fr > Subject: Re: [Mobike] New issue 16: No packets from other end? >=20 >=20 > Vijay Devarapalli writes: > > > - In general, lower-layer mechanisms cannot tell whether pair > > > (Ai,Bj) provides connectivity between the IKEv2 endpoints: > > > only an IKEv2 message exchange can tell that. > >=20 > > totally disagree with this particular statement. assuming the IP > > stack is the lower layer (with might include MIP6/MULTI6), why > > would MOBIKE be able to figure out something the IP stack couldnt? >=20 > Because MOBIKE is the only one that can really say if there is > connection that is good enough for him. For the IP point of view the > connection between two IP-addresses might work even when there is NAT > between, which eats all UDP port 500/4500 packets. For MOBIKE point of > view the connection is broken.=20 >=20 > > UDP is a transport protocol on top of IP, right? >=20 > yes. And TCP is over IP, and even when TCP works it does not give us > any indication that UDP will really work. Also even if UDP for port x > works, it does not say anything whether UDP on port y will work. This > is because of firewalls, nats and similar things. Also sending one > ICMP message might make IP layer to think that the connection is > broken, and we propably do not want to allow that easy DoS attacks. >=20 > I think MOBIKE should get use and try to get as much information from > outside as possible, but in the end it still needs to test the > possible address pairs by itself to get positive feedback that the > address pair works. >=20 > The other layers can give lots all kind of hints, and most likely it > can give quite reliable negative feedback, i.e. it can say that this > address cannot work anymore as the interface used was removed from the > machine, or the DHCP server gave me new address etc. We can belive > some of that information but it might also give information saying > this IP-address is not working, as I got ICMP host unreachable back > to my ICMP ping message, and we propably should not belive that > information.=20 > --=20 > kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 13 13:56:26 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19706 for ; Wed, 13 Oct 2004 13:56:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1CF45FB284; Wed, 13 Oct 2004 17:56:21 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BF2BEFB27F; Wed, 13 Oct 2004 17:56:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 009D6FB280; Wed, 13 Oct 2004 17:56:16 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 3DE86FB279 for ; Wed, 13 Oct 2004 17:56:15 +0000 (UTC) Message-ID: <001001c4b14e$0e305330$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> <416C3764.4030304@piuha.net> <030f01c4b0ce$84746a70$496015ac@dcml.docomolabsusa.com> <416CA9E7.7080907@piuha.net> Subject: Re: Some definitions (Was: Re: [Mobike] New issue 16: No packets fromother end?) Date: Wed, 13 Oct 2004 10:57:03 -0700 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 > > Actually, SCTP doesn't send packets over multiple paths either. It uses the > > addresses only for failover, that is when it detects a failure, it switches > > to another address. > > Yes, I think you are right about the usage of just one path at a > time. Question: does SCTP still have > some specific congestion avoidance for multi-homing, such as > going back to slow start upon changing to a different path? > Depends on the amount of time the particular address pair is idle. This from Section 7.2.1 of RFC 2960: Beginning data transmission into a network with unknown conditions or after a sufficiently long idle period requires SCTP to probe the network to determine the available capacity. The slow start algorithm is used for this purpose at the beginning of a transfer, or after repairing loss detected by the retransmission timer. o The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be <= 2*MTU. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 13 14:05:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20406 for ; Wed, 13 Oct 2004 14:05:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AF588FB286; Wed, 13 Oct 2004 18:05:14 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 503A8FB27F; Wed, 13 Oct 2004 18:05:12 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5A625FB280; Wed, 13 Oct 2004 18:05:11 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id B151AFB279 for ; Wed, 13 Oct 2004 18:05:10 +0000 (UTC) Message-ID: <001601c4b14f$4dbc3810$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "Vijay Devarapalli" References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com><416C7442.8020102@iprg.nokia.com> <416CAEDB.6000501@piuha.net> Subject: Re: Can lower layer tell there's connectivity? (Was: Re: [Mobike] Newissue 16: No packets from other end?) Date: Wed, 13 Oct 2004 11:05:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, mobike@machshav.com, Francis.Dupont@enst-bretagne.fr 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 > (2) Ensuring that a given address really is the same > node. When probing for the correctness of a claimed > address, we may want to ensure that its indeed the > same IKEv2 node at this address. > > It seems that the only way to do this is an IKEv2 > message. But note that we are talking about address > update, not failure recovery here. So failure recovery > might still work using only IP layer connectivity > tests. > I assume that could only be determined by authentication, so an IKEv2 message with proper ESP Auth header (or AH if that will be supported by MOBIKE). > (3) What current lower layers are able to tell to MOBIKE. > This is what I have been saying, that as far as I know, > current lower layer support in IPv6, DNA, DHC, etc. > only provides support for the discovery of available > addresses and locally operational addresses. Not the > discovery operational address pairs. > > I'm not saying that it wouldn't be possible to develop > one, just that one doesn't exist now. But I could be > missing something, I'm sure you guys will tell me what... > Base reachability is determined by 2461 NUD (modulo the DNA work which is still underway). I think RFC 2461 says that NUD can and should be supplemented by upper layer reachability information. So from that standpoint, MOBIKE could be considered an "upper layer" protocol that could contribute to the NUD decision. The issue, as I see it, is whether MOBIKE should make the decision or not. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 13 20:59:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00341 for ; Wed, 13 Oct 2004 20:59:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DA1D9FB27C; Thu, 14 Oct 2004 00:59:14 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BEFA2FB27C; Thu, 14 Oct 2004 00:59:10 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D70EFFB282; Thu, 14 Oct 2004 00:59:09 +0000 (UTC) Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by machshav.com (Postfix) with ESMTP id D0888FB279 for ; Thu, 14 Oct 2004 00:59:08 +0000 (UTC) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LG0OXMJCIC8ZE922@vaxc.its.monash.edu.au> for mobike@machshav.com; Thu, 14 Oct 2004 10:48:23 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8BA09AB54C; Thu, 14 Oct 2004 10:48:21 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 5788B4FB02; Thu, 14 Oct 2004 10:48:21 +1000 (EST) Date: Thu, 14 Oct 2004 10:48:21 +1000 From: Greg Daley Subject: Re: Can lower layer tell there's connectivity? (Was: Re: [Mobike] New issue 16: No packets from other end?) In-reply-to: <416CAEDB.6000501@piuha.net> To: jari.arkko@piuha.net Message-id: <416DCCD5.9020200@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> <416C7442.8020102@iprg.nokia.com> <416CAEDB.6000501@piuha.net> Cc: Pasi.Eronen@nokia.com, Vijay Devarapalli , mobike@machshav.com, Francis.Dupont@enst-bretagne.fr X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7BIT Hi Jari, Jari Arkko wrote: > Vijay Devarapalli wrote: > >>> - In general, lower-layer mechanisms cannot tell whether pair >>> (Ai,Bj) provides connectivity between the IKEv2 endpoints: >>> only an IKEv2 message exchange can tell that. >> >> >> totally disagree with this particular statement. assuming the IP >> stack is the lower layer (with might include MIP6/MULTI6), why >> would MOBIKE be able to figure out something the IP stack couldnt? >> >> UDP is a transport protocol on top of IP, right? > > > There appears to be several questions here. What Pasi is stating > need to made more specific before we can find agreement. > I think we are talking about: > > (1) Difference wrt IP layer connectivity and the ability to > talk between the IKEv2 peers. > > There is indeed a difference, the IKEv2 module could > suddenly die... or the client could have been disconnected > and the address recycled to someone else. > > Personally, I'm not sure this is worth covering. IP > connectivity should be enough. But see (2) below. > > (2) Ensuring that a given address really is the same > node. When probing for the correctness of a claimed > address, we may want to ensure that its indeed the > same IKEv2 node at this address. > > It seems that the only way to do this is an IKEv2 > message. But note that we are talking about address > update, not failure recovery here. So failure recovery > might still work using only IP layer connectivity > tests. > > (3) What current lower layers are able to tell to MOBIKE. > This is what I have been saying, that as far as I know, > current lower layer support in IPv6, DNA, DHC, etc. > only provides support for the discovery of available > addresses and locally operational addresses. Not the > discovery operational address pairs. > > I'm not saying that it wouldn't be possible to develop > one, just that one doesn't exist now. But I could be > missing something, I'm sure you guys will tell me what... It's possible that using DNA techniques, it may be possible to tell when a path is not there for a subset of the cases (based on local knowledge). Mobile IPv6 is similar if there's knowledge that another trusted address (for example a home address used in the IKE conversation) is not available. In this case, the knowledge about the availability of the MIPv6 address is an extension of trust to another location on the path. It looks like a local address to the peer though, since it's used in end-to-end communication. With non-local or non end-to-end information it's going to be difficult to test unavailability unless there's preexisting or verifiable trust from informants on the path. (for example if ICMPv6 destination unreachable messages had authorization similar to that provided to SEND (CGA) Routers). If we can't trust indications from the network, we're stuck waiting for IKE messages. Greg _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 18 01:04:14 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28589 for ; Mon, 18 Oct 2004 01:04:14 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DC931FB293; Mon, 18 Oct 2004 05:04:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C0CEBFB281; Mon, 18 Oct 2004 05:04:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 19C4DFB283; Mon, 18 Oct 2004 05:04:00 +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 7EAB0FB27C for ; Mon, 18 Oct 2004 05:03:59 +0000 (UTC) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.213.45 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 18 Oct 2004 05:03:58 -0000 Message-ID: <00c401c4b4cf$e005c140$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "MOBIKE Mailing List" References: <200410122131.i9CLVxSj056244@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] New issue 16: No packets from other end? Date: Sun, 17 Oct 2004 22:03:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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 am not sure whether there is a consensus for this issue or not. But the arguments are convincing (at least for me) that we need some IKEv2 message to find the working pair of source and destination address. To make sure i understand how this message is used, let me consider the following three cases. 1) Mobility without multi-homing: In this case a single pair of address exists between the two nodes. When one of the node moves, MOBIKE detects at some point in time that there is a change at layer 3 e.g. using DNA/MIP6. MOBIKE learns about the new address using whatever mechanism the local OS provides, and sends an address update to the other end. In this case, there is no need for any extra probing to look for a working pair. 2) Multi-homing without mobility : In this case there are multiple pair of addresses between the two nodes (Si, Dj). IKEv2 starts off with some address pair (S1, D1). At the end of successful IKE SA establishment, IKE knows the working pair of address which will be used for the further communication. MOBIKE kicks in at some point and each node updates the known local addresses with the other node. Whenever a new address is obtained e.g. a link to the ISP becomes UP, the other end is updated with this new address (it is really a matter of policy whether it is updated or not). Whenever an address ceases to work (hints from outside of MOBIKE), and that address is part of the current working pair, each end discovers this independently and starts to find a working pair. This is when you need a message at the IKEv2 level to find which address pair (Si, Dj) works. (I still don't understand the details of how both ends agree on a single pair of address. But that detail can be discussed later i guess) 3) Multi-homing with mobility: In this case there are multiple pair of addresses between the two nodes (Si, Dj) and one of the end is mobile. This case is not much different from (2). Mobility makes an address disappear or a new address appear. Whenever the node moves, an existing address becomes invalid. And if it is part of the existing working pair of address, MOBIKE can try and choose a new address by probing the other end (using the new IKEv2 message) or just update the other end with the new address just obtained (and only when that fails, start finding a different working pair). Does this make sense ? -mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 22 03:56:57 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10119 for ; Fri, 22 Oct 2004 03:56:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0D9F7FB27A; Fri, 22 Oct 2004 07:55:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 68808FB256; Fri, 22 Oct 2004 07:55:31 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3A6FBFB257; Fri, 22 Oct 2004 07:55:29 +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 1CA92FB255 for ; Fri, 22 Oct 2004 07:55:28 +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 i9M7sts22236; Fri, 22 Oct 2004 09:54:55 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9M7srSj099440; Fri, 22 Oct 2004 09:54:53 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410220754.i9M7srSj099440@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net In-reply-to: Your message of Mon, 11 Oct 2004 15:16:22 +0300. <416A7996.3040300@piuha.net> Date: Fri, 22 Oct 2004 09:54:53 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman / VPNC Subject: [Mobike] Re: comments on draft-dupont-mobike-transport-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: > Using a Mobike peer address management (as in [ADDRMGT]) a mobile Pending the appearance of a WG draft for the base MOBIKE solution, I think it would be appropriate to list a couple of other alternative address management protocol proposals too, just to make it clear that what you say in this draft is not bound to [ADDRMGT] but could also be used with the other drafts. => is there another proposal using sets? As I'll submit soon a new version of my transport mode draft, I'd like to fix this point! Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 27 20:08:43 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29954 for ; Wed, 27 Oct 2004 20:08:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F0481FB291; Thu, 28 Oct 2004 00:08:42 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 71B8CFB28D; Thu, 28 Oct 2004 00:08:39 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 83B95FB28F; Thu, 28 Oct 2004 00:08:38 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id A84E4FB28B for ; Thu, 28 Oct 2004 00:08:37 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9RNfEM17938; Wed, 27 Oct 2004 16:41:14 -0700 X-mProtect: <200410272341> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdVPkFtC; Wed, 27 Oct 2004 16:41:13 PDT Message-ID: <41803883.3040106@iprg.nokia.com> Date: Wed, 27 Oct 2004 17:08:35 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] New issue 16: No packets from other end? References: <125EA890549C8641A72F3809CB80DCCD16FD26@esebe056.ntc.nokia.com> <416C7442.8020102@iprg.nokia.com> <16748.59195.255358.548764@fireball.kivinen.iki.fi> In-Reply-To: <16748.59195.255358.548764@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.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 sorry for the late reply. I agree that while the IP stack (MIP6 or multi6) can determine if there is a pair of addresses that the IP stack can use, we still need an IKE message to figure out if the IKE endpoints have a pair of addresses that they can use. and if the IP stack (or a policy on the mobile node) tells MOBIKE to use a particular address, that address should be tried first always. Vijay Tero Kivinen wrote: > Vijay Devarapalli writes: > >>>- In general, lower-layer mechanisms cannot tell whether pair >>> (Ai,Bj) provides connectivity between the IKEv2 endpoints: >>> only an IKEv2 message exchange can tell that. >> >>totally disagree with this particular statement. assuming the IP >>stack is the lower layer (with might include MIP6/MULTI6), why >>would MOBIKE be able to figure out something the IP stack couldnt? > > > Because MOBIKE is the only one that can really say if there is > connection that is good enough for him. For the IP point of view the > connection between two IP-addresses might work even when there is NAT > between, which eats all UDP port 500/4500 packets. For MOBIKE point of > view the connection is broken. > > >>UDP is a transport protocol on top of IP, right? > > > yes. And TCP is over IP, and even when TCP works it does not give us > any indication that UDP will really work. Also even if UDP for port x > works, it does not say anything whether UDP on port y will work. This > is because of firewalls, nats and similar things. Also sending one > ICMP message might make IP layer to think that the connection is > broken, and we propably do not want to allow that easy DoS attacks. > > I think MOBIKE should get use and try to get as much information from > outside as possible, but in the end it still needs to test the > possible address pairs by itself to get positive feedback that the > address pair works. > > The other layers can give lots all kind of hints, and most likely it > can give quite reliable negative feedback, i.e. it can say that this > address cannot work anymore as the interface used was removed from the > machine, or the DHCP server gave me new address etc. We can belive > some of that information but it might also give information saying > this IP-address is not working, as I got ICMP host unreachable back > to my ICMP ping message, and we propably should not belive that > information. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:05:20 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25855 for ; Thu, 28 Oct 2004 06:05:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F3805FB28D; Thu, 28 Oct 2004 10:05:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1A375FB28B; Thu, 28 Oct 2004 10:05:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B89C2FB28D; Thu, 28 Oct 2004 10:05:12 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 852E0FB289 for ; Thu, 28 Oct 2004 10:05:11 +0000 (UTC) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9SA52S16928; Thu, 28 Oct 2004 12:05:02 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9SA50Sj029988; Thu, 28 Oct 2004 12:05:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410281005.i9SA50Sj029988@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Tue, 12 Oct 2004 20:06:46 PDT. <031f01c4b0d1$b092ca40$496015ac@dcml.docomolabsusa.com> Date: Thu, 28 Oct 2004 12:05:00 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.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 why I said "should be only an option": the R-U-THERE > of IKEv2 is not well suited for parallel probing because of > the window issue. IMHO the real problem is that probes should > be at the IP layer not at the IKEv2 layer: one tries to probe > the IP paths, not the peer IKEv2. > So is IP reachability both necessary and sufficient for "IKE-reachability"? => of course only necessary but what we need is not IKE reachability but IPsec reachability. Francis.Dupont@enst-bretagne.fr PS: IMHO the IKE-reachability is already handled by IKEv2 itself, i.e., MOBIKE can add new failure cases but should not introduce its own new mechanism. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:10:11 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26409 for ; Thu, 28 Oct 2004 06:10:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B24F5FB290; Thu, 28 Oct 2004 10:10:10 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D1918FB28D; Thu, 28 Oct 2004 10:10:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 29428FB28F; Thu, 28 Oct 2004 10:10:03 +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 D92D4FB28B for ; Thu, 28 Oct 2004 10:10:01 +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 i9SA9oS17573; Thu, 28 Oct 2004 12:09:50 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9SA9nSj030021; Thu, 28 Oct 2004 12:09:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410281009.i9SA9nSj030021@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Wed, 13 Oct 2004 07:42:55 +0300. <416CB24F.9080404@piuha.net> Date: Thu, 28 Oct 2004 12:09:49 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, 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: > => there will be one: this is not the job of MOBIKE to specify one, > but this is the job of MULTI6 and MIP6. Re: MIP6. There's been a draft or two about extending Mobile IPv6 to support multihoming (parallel addresses as opposed to serial ones). However, this does not appear to be a work item in any of the current IETF working groups related to Mobile IPv6. Re: MULTI6. This is being worked on. But there are a couple of issues. First, MULTI6 explicitly decided to handled the pure IPv6 problem only. It seems that the solution their design team is thinking of is going to work only for IPv6 without an easy extension to IPv4. Secondly, since there are no detailed or official solution drafts yet available for the failure detection part, its kind of hard to tell whether it could be ripped out of MULTI6 and used for supporting MOBIKE. Maybe. But probably more as an idea rather than relying on what the MULTI6 module is telling MOBIKE. In fact, if you had MULTI6 running and you were satisfied with the limitation to IPv6, you would not need MOBIKE, right? => you don't believe what you wrote (RFC 1918 is cited in your MULTI6 DT draft :-). My concern is clear: MOBIKE should not be a substitute of the whole OS, even on a SG it can become the central task. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:12:43 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26734 for ; Thu, 28 Oct 2004 06:12:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 82A86FB292; Thu, 28 Oct 2004 10:12:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F1BD5FB28D; Thu, 28 Oct 2004 10:12:41 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 85169FB28F; Thu, 28 Oct 2004 10:12:40 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 6F521FB28B for ; Thu, 28 Oct 2004 10:12:39 +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 i9SACUS17871; Thu, 28 Oct 2004 12:12:30 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9SACUSj030040; Thu, 28 Oct 2004 12:12:30 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410281012.i9SACUSj030040@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Wed, 13 Oct 2004 11:28:43 +0300. <16748.59195.255358.548764@fireball.kivinen.iki.fi> Date: Thu, 28 Oct 2004 12:12:30 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Vijay Devarapalli , Pasi.Eronen@nokia.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: I think MOBIKE should get use and try to get as much information from outside as possible, but in the end it still needs to test the possible address pairs by itself to get positive feedback that the address pair works. => this is (check the address pair works) the job of the IPsec module, not MOBIKE, at the exception of primary peer addresses for IKE messages. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:15:33 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26990 for ; Thu, 28 Oct 2004 06:15:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6B8C7FB297; Thu, 28 Oct 2004 10:15:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C1DB3FB28F; Thu, 28 Oct 2004 10:15:28 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BF0B2FB290; Thu, 28 Oct 2004 10:15:27 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 38F3CFB28D for ; Thu, 28 Oct 2004 10:15:27 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 32CFA89830; Thu, 28 Oct 2004 13:15:25 +0300 (EEST) Message-ID: <4180C657.7020803@piuha.net> Date: Thu, 28 Oct 2004 13:13:43 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] New issue 16: No packets from other end? References: <200410281009.i9SA9nSj030021@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410281009.i9SA9nSj030021@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: > => you don't believe what you wrote (RFC 1918 is cited in your MULTI6 DT > draft :-). What I write is my own opinion, and if I look at complicated things like multihoming failure detection I don't want to look only at IPv6. However, my understanding is still that the MULTI6 WG will only work on an IPv6 solution, so whatever is the final MULTI6 RFC, it will not have IPv4 stuff... > My concern is clear: MOBIKE should not be a substitute of the whole OS, > even on a SG it can become the central task. I agree with this. But I guess the devil is in the details... --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:15:53 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27046 for ; Thu, 28 Oct 2004 06:15:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E00E6FB299; Thu, 28 Oct 2004 10:15:53 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DAD90FB28F; Thu, 28 Oct 2004 10:15:50 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1BDD8FB290; Thu, 28 Oct 2004 10:15:50 +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 CDD80FB28D for ; Thu, 28 Oct 2004 10:15:48 +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 i9SAFdS18082; Thu, 28 Oct 2004 12:15:39 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9SAFcSj030059; Thu, 28 Oct 2004 12:15:38 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410281015.i9SAFcSj030059@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Sun, 17 Oct 2004 22:03:56 PDT. <00c401c4b4cf$e005c140$6401a8c0@adithya> Date: Thu, 28 Oct 2004 12:15:38 +0200 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: I am not sure whether there is a consensus for this issue or not. But the arguments are convincing (at least for me) that we need some IKEv2 message to find the working pair of source and destination address. To make sure i understand how this message is used, let me consider the following three cases. 1) Mobility without multi-homing: In this case a single pair of address exists be tween the two nodes. When one of the node moves, MOBIKE detects at some point in time that there is a change at layer 3 e.g. using DNA/MIP6. MOBIKE learns about the new address using whatever mechanism the local OS provides, and sends an address update to the other end. In this case, there is no need for any extra probing to look for a working pair. 2) Multi-homing without mobility : In this case there are multiple pair of addres ses between the two nodes (Si, Dj). IKEv2 starts off with some address pair (S1, D1). At the end of successful IKE SA establishment, IKE knows the workin g pair of address which will be used for the further communication. MOBIKE kick s in at some point and each node updates the known local addresses with the oth er node. Whenever a new address is obtained e.g. a link to the ISP becomes UP, the oth er end is updated with this new address (it is really a matter of policy whethe r it is updated or not). Whenever an address ceases to work (hints from outside of M OBIKE), and that address is part of the current working pair, each end discovers thi s independently and starts to find a working pair. This is when you need a message at the IK Ev2 level to find which address pair (Si, Dj) works. (I still don't understand the detail s of how both ends agree on a single pair of address. But that detail can be discussed later i guess) 3) Multi-homing with mobility: In this case there are multiple pair of addresses between the two nodes (Si, Dj) and one of the end is mobile. This case is not much di fferent from (2). Mobility makes an address disappear or a new address appear. Whenev er the node moves, an existing address becomes invalid. And if it is part of the existing working pair of address, MOBIKE can try and choose a new address by probing the other end (using the new IKEv2 message) or just update the other end with the new addres s just obtained (and only when that fails, start finding a different working pair). Does this make sense ? => none: MOBIKE is the tool to control, not the controling tool: if you remove MOBIKE the mobile and/or multi-homed node should be still able to run without the security. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:18:41 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27442 for ; Thu, 28 Oct 2004 06:18:39 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B2D62FB293; Thu, 28 Oct 2004 10:18:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 88A51FB28F; Thu, 28 Oct 2004 10:18:38 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4EEE2FB290; Thu, 28 Oct 2004 10:18:36 +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 36F51FB28D for ; Thu, 28 Oct 2004 10:18: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 i9SAHaS18507; Thu, 28 Oct 2004 12:17:36 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9SAHaSj030098; Thu, 28 Oct 2004 12:17:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410281017.i9SAHaSj030098@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli Subject: Re: [Mobike] New issue 16: No packets from other end? In-reply-to: Your message of Wed, 27 Oct 2004 17:08:35 PDT. <41803883.3040106@iprg.nokia.com> Date: Thu, 28 Oct 2004 12:17:36 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Pasi.Eronen@nokia.com, mobike@machshav.com, Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com In your previous mail you wrote: I agree that while the IP stack (MIP6 or multi6) can determine if there is a pair of addresses that the IP stack can use, we still need an IKE message to figure out if the IKE endpoints have a pair of addresses that they can use. and if the IP stack (or a policy on the mobile node) tells MOBIKE to use a particular address, that address should be tried first always. => can you define "MOBIKE to use a particular address"? Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:22:48 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27662 for ; Thu, 28 Oct 2004 06:22:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4CC2FFB297; Thu, 28 Oct 2004 10:22:48 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CDEE0FB28F; Thu, 28 Oct 2004 10:22:46 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C5DB2FB290; Thu, 28 Oct 2004 10:22:45 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 2BE6EFB28D for ; Thu, 28 Oct 2004 10:22:45 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 3055589830; Thu, 28 Oct 2004 13:22:44 +0300 (EEST) Message-ID: <4180C80E.3050604@piuha.net> Date: Thu, 28 Oct 2004 13:21:02 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] New issue 16: No packets from other end? References: <200410281012.i9SACUSj030040@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410281012.i9SACUSj030040@givry.rennes.enst-bretagne.fr> 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 Hi Francis, > I think MOBIKE should get use and try to get as much information from > outside as possible, but in the end it still needs to test the > possible address pairs by itself to get positive feedback that the > address pair works. > > => this is (check the address pair works) the job of the IPsec module, > not MOBIKE, at the exception of primary peer addresses for IKE messages. Let me try to understand this statement better. Are you saying that testing an address pair is the job of the ESP/AH module, or that it belongs to the IKEv2 functionality already specified (even without MOBIKE extension)? I think you must mean the latter. Here's why: the current IKEv2 approach to this appears to be DPD, which works through IKEv2 messages, right? Or am I missing something? (Certainly the lack of ESP packets might be a HINT that something is wrong, but you wouldn't know if it was due to lack of need to send packets until you try with DPD.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:27:03 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28102 for ; Thu, 28 Oct 2004 06:27:03 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 49FDAFB29F; Thu, 28 Oct 2004 10:27:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4D198FB290; Thu, 28 Oct 2004 10:26:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5574BFB292; Thu, 28 Oct 2004 10:26:57 +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 0AAC3FB28D for ; Thu, 28 Oct 2004 10:26:56 +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 i9SAQiS19643; Thu, 28 Oct 2004 12:26:44 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9SAQjSj030154; Thu, 28 Oct 2004 12:26:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410281026.i9SAQjSj030154@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: Can lower layer tell there's connectivity? (Was: Re: [Mobike] New issue 16: No packets from other end?) In-reply-to: Your message of Wed, 13 Oct 2004 07:28:11 +0300. <416CAEDB.6000501@piuha.net> Date: Thu, 28 Oct 2004 12:26:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Vijay Devarapalli , Pasi.Eronen@nokia.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: There appears to be several questions here. What Pasi is stating need to made more specific before we can find agreement. I think we are talking about: (1) Difference wrt IP layer connectivity and the ability to talk between the IKEv2 peers. There is indeed a difference, the IKEv2 module could suddenly die... or the client could have been disconnected and the address recycled to someone else. Personally, I'm not sure this is worth covering. IP connectivity should be enough. But see (2) below. => we need both: IP connectivity and IKEv2 dead peer detection. None is really a part of MOBIKE. (2) Ensuring that a given address really is the same node. When probing for the correctness of a claimed address, we may want to ensure that its indeed the same IKEv2 node at this address. => I agree: RR checks are the job of MOBIKE. It seems that the only way to do this is an IKEv2 message. But note that we are talking about address update, not failure recovery here. So failure recovery might still work using only IP layer connectivity tests. => IMHO recovery should have the priority over RR checks. Note this doesn't introduce a security issue because recovery is local and will happen without RR checks in a non-IPsec context. (3) What current lower layers are able to tell to MOBIKE. This is what I have been saying, that as far as I know, current lower layer support in IPv6, DNA, DHC, etc. only provides support for the discovery of available addresses and locally operational addresses. Not the discovery operational address pairs. => this is clearly the main job of a multi-homing control and without it multi-homing is not really usable (*). I'm not saying that it wouldn't be possible to develop one, just that one doesn't exist now. But I could be missing something, I'm sure you guys will tell me what... => the question is more who should develop one. Regards Francis.Dupont@enst-bretagne.fr PS (*): two remarks: - as there is currently no specified multi-homing control mechanism we are in trouble, with and without IPsec. - IMHO this is not the job of MOBIKE to provide this function, nor the job of the MOBIKE WG to specify one in place of the MULTI6 WG. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:35:44 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28669 for ; Thu, 28 Oct 2004 06:35:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 37DCDFB29E; Thu, 28 Oct 2004 10:35:44 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 01A37FB292; Thu, 28 Oct 2004 10:35:42 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 581C5FB299; Thu, 28 Oct 2004 10:35:40 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id BBFD8FB28D for ; Thu, 28 Oct 2004 10:35:39 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id C9F4389830 for ; Thu, 28 Oct 2004 13:35:38 +0300 (EEST) Message-ID: <4180CB15.3070304@piuha.net> Date: Thu, 28 Oct 2004 13:33:57 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] possibly related 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 Hi, Francis' e-mail reminded me that I may need to point also other folks to a possibly related draft. One of the issues that we have been discussing is the way how MOBIKE gets to know that it needs to use a new address from a lower layer and how it can detect whether a pair of addresses actually works or not. This is not something that only we are looking at. SCTP has specified its own way for this and HIP and MULTI6 protocols need solutions like that as well. As a member of the MULTI6 design team I wrote some thoughts on the matter from the point of view of MULTI6. If you take a look it may give you some ideas for the MOBIKE space too. I don't know about the solutions presented in the draft, but I'm hoping that the draft might be helpful at least in defining a few terms so that we can discuss this matter more precisely. Here's the draft: http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-00.txt --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:43:20 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29041 for ; Thu, 28 Oct 2004 06:43:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E5CBBFB299; Thu, 28 Oct 2004 10:43:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6B21DFB28D; Thu, 28 Oct 2004 10:43:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EB59DFB291; Thu, 28 Oct 2004 10:43:15 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 5F181FB28B for ; Thu, 28 Oct 2004 10:43:15 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6422489882; Thu, 28 Oct 2004 13:43:14 +0300 (EEST) Message-ID: <4180CCDC.3050906@piuha.net> Date: Thu, 28 Oct 2004 13:41:32 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] New issue 16: No packets from other end? References: <200410281017.i9SAHaSj030098@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410281017.i9SAHaSj030098@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Vijay Devarapalli , 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 Francis Dupont wrote: > In your previous mail you wrote: > > I agree that while the IP stack (MIP6 or multi6) can determine > if there is a pair of addresses that the IP stack can use, we > still need an IKE message to figure out if the IKE endpoints > have a pair of addresses that they can use. and if the IP > stack (or a policy on the mobile node) tells MOBIKE to use a > particular address, that address should be tried first always. > > => can you define "MOBIKE to use a particular address"? I think that when Vijay said "MOBIKE" he meant the system composed of IPsec, IKEv2, and MOBIKE. Essentially, its the IKEv2 messages and IPsec AH/ESP packets that need to use an address. There may be some MOBIKE control messages too, but those are carried on top of IKEv2. And MOBIKE exists for the reason that it should help IKEv2 and IPsec traffic to go to the right address. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 06:48:32 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29235 for ; Thu, 28 Oct 2004 06:48:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 17568FB29B; Thu, 28 Oct 2004 10:48:33 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E96CEFB28D; Thu, 28 Oct 2004 10:48:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 79E18FB291; Thu, 28 Oct 2004 10:48:29 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 8F7DEFB28B for ; Thu, 28 Oct 2004 10:48:28 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5362589830; Thu, 28 Oct 2004 13:48:27 +0300 (EEST) Message-ID: <4180CE15.9040004@piuha.net> Date: Thu, 28 Oct 2004 13:46:45 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: Can lower layer tell there's connectivity? (Was: Re: [Mobike] New issue 16: No packets from other end?) References: <200410281026.i9SAQjSj030154@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410281026.i9SAQjSj030154@givry.rennes.enst-bretagne.fr> 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 Hi Francis, > (1) Difference wrt IP layer connectivity and the ability to > talk between the IKEv2 peers. > > There is indeed a difference, the IKEv2 module could > suddenly die... or the client could have been disconnected > and the address recycled to someone else. > > Personally, I'm not sure this is worth covering. IP > connectivity should be enough. But see (2) below. > > => we need both: IP connectivity and IKEv2 dead peer detection. > None is really a part of MOBIKE. I think I agree with this too, now... > (2) Ensuring that a given address really is the same > node. When probing for the correctness of a claimed > address, we may want to ensure that its indeed the > same IKEv2 node at this address. > > => I agree: RR checks are the job of MOBIKE. Ok. > It seems that the only way to do this is an IKEv2 > message. But note that we are talking about address > update, not failure recovery here. So failure recovery > might still work using only IP layer connectivity > tests. > > => IMHO recovery should have the priority over RR checks. Note this > doesn't introduce a security issue because recovery is local and > will happen without RR checks in a non-IPsec context. The distinction between a probe to test whether an address is usable for failover and whether its the same node in the RR sense is a fine one. With proper protocol design, we could actually achieve both in the same message. But I'm also open to doing them separately. For instance, when I tell you that I have address A, B, and C, you could verify them at that time. Then when you get a problem with address A, you could switch to B without any RR test. Nevertheless, "switching to B" might imply a round of messages to B, so this might not optimize very much. > (3) What current lower layers are able to tell to MOBIKE. > This is what I have been saying, that as far as I know, > current lower layer support in IPv6, DNA, DHC, etc. > only provides support for the discovery of available > addresses and locally operational addresses. Not the > discovery operational address pairs. > > => this is clearly the main job of a multi-homing control and > without it multi-homing is not really usable (*). > > I'm not saying that it wouldn't be possible to develop > one, just that one doesn't exist now. But I could be > missing something, I'm sure you guys will tell me what... > > => the question is more who should develop one. I agree. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 12:45:27 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15744 for ; Thu, 28 Oct 2004 12:45:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 968D4FB292; Thu, 28 Oct 2004 16:45:23 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 59CB7FB28D; Thu, 28 Oct 2004 16:45:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2B1AEFB28F; Thu, 28 Oct 2004 16:45:20 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 87BD1FB28B for ; Thu, 28 Oct 2004 16:45:19 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id BC2A689830 for ; Thu, 28 Oct 2004 19:45:17 +0300 (EEST) Message-ID: <418121B7.5010506@piuha.net> Date: Thu, 28 Oct 2004 19:43:35 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List References: <200410281451.KAA20033@ietf.org> In-Reply-To: <200410281451.KAA20033@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] Fwd: I-D ACTION:draft-eronen-mobike-mopo-01.txt 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 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Mobility Protocol Options for IKEv2 (MOPO-IKE) > Author(s) : P. Eronen > Filename : draft-eronen-mobike-mopo-01.txt > Pages : 11 > Date : 2004-10-27 > > This document describes a mobility and multihoming extension to the > IKEv2 protocol. The main purpose of this extension is to update the > (outer) addresses associated with IKE and IPsec Security > Associations. The extension also includes features that assist in > selecting which addresses to use, and verify return routability > during and after updates. It is also able to work together with NAT > Traversal in some scenarios. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-eronen-mobike-mopo-01.txt _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 14: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 OAA08472 for ; Thu, 28 Oct 2004 14:23:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 31A9EFB293; Thu, 28 Oct 2004 18:23:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 91E00FB28D; Thu, 28 Oct 2004 18:23:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0EAD4FB290; Thu, 28 Oct 2004 18:23:02 +0000 (UTC) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by machshav.com (Postfix) with ESMTP id 883D4FB28B for ; Thu, 28 Oct 2004 18:23:01 +0000 (UTC) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9SHtXY01689; Thu, 28 Oct 2004 10:55:33 -0700 X-mProtect: <200410281755> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdhsyNbG; Thu, 28 Oct 2004 10:55:32 PDT Message-ID: <4181390E.2020706@iprg.nokia.com> Date: Thu, 28 Oct 2004 11:23:10 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mobike] New issue 16: No packets from other end? References: <200410281017.i9SAHaSj030098@givry.rennes.enst-bretagne.fr> In-Reply-To: <200410281017.i9SAHaSj030098@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, mobike@machshav.com, 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 Francis Dupont wrote: > In your previous mail you wrote: > > I agree that while the IP stack (MIP6 or multi6) can determine > if there is a pair of addresses that the IP stack can use, we > still need an IKE message to figure out if the IKE endpoints > have a pair of addresses that they can use. and if the IP > stack (or a policy on the mobile node) tells MOBIKE to use a > particular address, that address should be tried first always. > > => can you define "MOBIKE to use a particular address"? I should have used better text. Jari clarified this. Vijay > > Thanks > > Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 28 18:29:53 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29979 for ; Thu, 28 Oct 2004 18:29:53 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 44066FB294; Thu, 28 Oct 2004 22:29:53 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 58824FB291; Thu, 28 Oct 2004 22:29:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AAE3FFB292; Thu, 28 Oct 2004 22:29:50 +0000 (UTC) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id A5137FB28D for ; Thu, 28 Oct 2004 22:29:49 +0000 (UTC) Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i9SMRhi06112; Thu, 28 Oct 2004 15:27:43 -0700 (PDT) Message-ID: <4181725B.80309@isi.edu> Date: Thu, 28 Oct 2004 15:27:39 -0700 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] possibly related draft References: <4180CB15.3070304@piuha.net> In-Reply-To: <4180CB15.3070304@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="===============2144638991==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2144638991== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig237478329FB5CF22340BCF5A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig237478329FB5CF22340BCF5A Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am concerned about the use of some of this inferred information from the link layer or transport layer to decide connectivity at the network layer. Notably, failure of TCP to make forward progress - e.g., lack of ACKs - is not an indication of a network layer connectivity failure. It can be a deliberate decision of the TCP implementation to limit processing associated with a connection, or can represent a security firewall being enabled. Similarly, we've had related dicussions in TCPM regarding the use of ICMP unreachable messages to tickle more rapid attempts to use alternate addresses, e.g., for v4/v6 selection. Unfortunately, these messages, as noted, are not secure, and so relying on them presents a DOS opportunity; it is not clear that there is a significant benefit in 'believing' these messages that is not undermined by this lack of security. Although it may be useful to consider direct evidence of connectivity, e.g., linkup/linkdown interface notification via an API, it is not clear yet that there is a protocol-related variant that can be appropriately applied, IMO. Joe Jari Arkko wrote: > > Hi, > > Francis' e-mail reminded me that I may need to point > also other folks to a possibly related draft. > > One of the issues that we have been discussing is the > way how MOBIKE gets to know that it needs to use a new > address from a lower layer and how it can detect whether > a pair of addresses actually works or not. > > This is not something that only we are looking at. SCTP > has specified its own way for this and HIP and MULTI6 > protocols need solutions like that as well. As a member > of the MULTI6 design team I wrote some thoughts on the > matter from the point of view of MULTI6. If you take > a look it may give you some ideas for the MOBIKE space > too. I don't know about the solutions presented in the > draft, but I'm hoping that the draft might be helpful > at least in defining a few terms so that we can discuss > this matter more precisely. > > Here's the draft: > > > http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-00.txt > > > --Jari > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike --------------enig237478329FB5CF22340BCF5A 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 iD8DBQFBgXJbE5f5cImnZrsRAgUkAKD9aLKEv1bbUgG3j554AGuJPwSR2ACghxYP MLslxnDH+VYsNkEqOCVQBO4= =qmON -----END PGP SIGNATURE----- --------------enig237478329FB5CF22340BCF5A-- --===============2144638991== 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 --===============2144638991==-- From mobike-bounces@machshav.com Thu Oct 28 21:44:09 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14076 for ; Thu, 28 Oct 2004 21:44:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0383EFB299; Fri, 29 Oct 2004 01:44:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A1059FB291; Fri, 29 Oct 2004 01:44:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1842FFB292; Fri, 29 Oct 2004 01:44:00 +0000 (UTC) Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by machshav.com (Postfix) with ESMTP id 5CC06FB28D for ; Fri, 29 Oct 2004 01:43:59 +0000 (UTC) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGLP148GJ68X7YR2@vaxh.its.monash.edu.au> for mobike@machshav.com; Fri, 29 Oct 2004 11:37:49 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C071680009; Fri, 29 Oct 2004 11:37:48 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 931CB3C006; Fri, 29 Oct 2004 11:37:48 +1000 (EST) Date: Fri, 29 Oct 2004 11:37:48 +1000 From: Greg Daley Subject: Re: [Mobike] possibly related draft In-reply-to: <4181725B.80309@isi.edu> To: Joe Touch Message-id: <41819EEC.1000108@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <4180CB15.3070304@piuha.net> <4181725B.80309@isi.edu> Cc: MOBIKE Mailing List , jari.arkko@piuha.net X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7BIT Hi Joe, Joe Touch wrote: > I am concerned about the use of some of this inferred information from > the link layer or transport layer to decide connectivity at the network > layer. > > Notably, failure of TCP to make forward progress - e.g., lack of ACKs - > is not an indication of a network layer connectivity failure. It can be > a deliberate decision of the TCP implementation to limit processing > associated with a connection, or can represent a security firewall being > enabled. > > Similarly, we've had related dicussions in TCPM regarding the use of > ICMP unreachable messages to tickle more rapid attempts to use alternate > addresses, e.g., for v4/v6 selection. Unfortunately, these messages, as > noted, are not secure, and so relying on them presents a DOS > opportunity; it is not clear that there is a significant benefit in > 'believing' these messages that is not undermined by this lack of security. > > Although it may be useful to consider direct evidence of connectivity, > e.g., linkup/linkdown interface notification via an API, it is not clear > yet that there is a protocol-related variant that can be appropriately > applied, IMO. At this stage there's no work done within DNA WG on APIs but we're looking at getting indications of local connectivity from L2 into L3 within DNA WG. Similar work has been going on with DNAv4 in DHC. I'd guess that once the DNA system is able to indicate that an IP configuration (addresses,local routers) is invalidated, or had a connection discontinuity (e.g. link-layer only base station change) This information could be passed to the upper layer protocols or IP subsystems, in a similar fashion to a subset of the trigtran work (but with only adjacent layer violations). Hysteresis and security of the change discovery would probably exist within the DNA subsystem, but information about trust could be passed around too. I'm not proposing this as a work item for DNA, but it's intertesting for that group to see what people are really interested in. Please tell me if this is the right path to look down for local connectivity indications (or not). Greg D. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 29 00:08:38 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06167 for ; Fri, 29 Oct 2004 00:08:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A01F5FB294; Fri, 29 Oct 2004 04:08:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2A569FB289; Fri, 29 Oct 2004 04:08:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 957B8FB28B; Fri, 29 Oct 2004 04:08:31 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 6D3D5FB279 for ; Fri, 29 Oct 2004 04:08:30 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6CFE089830; Fri, 29 Oct 2004 07:08:28 +0300 (EEST) Message-ID: <4181C1D5.60900@piuha.net> Date: Fri, 29 Oct 2004 07:06:45 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch Subject: Re: [Mobike] possibly related draft References: <4180CB15.3070304@piuha.net> <4181725B.80309@isi.edu> In-Reply-To: <4181725B.80309@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 Hi Joe, Thanks for raising these issues. Some further discussion inline: > I am concerned about the use of some of this inferred information from > the link layer or transport layer to decide connectivity at the network > layer. > > Notably, failure of TCP to make forward progress - e.g., lack of ACKs - > is not an indication of a network layer connectivity failure. It can be > a deliberate decision of the TCP implementation to limit processing > associated with a connection, or can represent a security firewall being > enabled. Yes. Although -- given that we are talking about TCP that runs over our IKEv2/IPsec connection -- the firewall will also block all other traffic from the same connection, at least if non-null encryption and ESP are used. I believe we have several types of connectivity: - network layer connectivity - IKE/IPsec connectivity - transport or application connectivity With ALGs and other kinds of interesting devices, you could actually have a situation where you have application connectivity but no network or IPsec connectivity. SImilarly, network connectivity does not imply that IKE/IPsec gets through. > Similarly, we've had related dicussions in TCPM regarding the use of > ICMP unreachable messages to tickle more rapid attempts to use alternate > addresses, e.g., for v4/v6 selection. Unfortunately, these messages, as > noted, are not secure, and so relying on them presents a DOS > opportunity; it is not clear that there is a significant benefit in > 'believing' these messages that is not undermined by this lack of security. Right. The way that I want to see this is that anything like an ICMP error would at best be a hint that now it would be a good time to do another DPD round. > Although it may be useful to consider direct evidence of connectivity, > e.g., linkup/linkdown interface notification via an API, it is not clear > yet that there is a protocol-related variant that can be appropriately > applied, IMO. Yes. Or at least the security/semantics impacts of the protocol related variants need to be considered. I think this means that we have three classes of notifications: - Those that came through an API. However, most of the time the API-based indications are really initiated by (possibly insecure) protocol exchanges. For instance, the reception of an RA. In some cases there's security available (if in use) for these protocols, such as for ND we have SEND. However, I'd still feel uncomfortable if MOBIKE did NOT believe everything it hears from the API. We can't have a situation where ND decides something but the MOBIKE/IKEv2/IPsec system does not believe it and continues to use a bad address, for instance. - Those that came through an external protocol, such as TCP. The considerations that you Joe raised apply here. - Those that came through the MOBIKE/IKEv2/IPsec system itself. These I believe we *can* believe, and with some assumptions about the cryptographic primitives that are being used, this really represents the connectivity that MOBIKE is concerned about. Or does at least as long as one would test both IKEv2 and ESP connectivity... in NAT-T case IKEv2 over UDP test would probably suffice. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 29 00:09:32 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06209 for ; Fri, 29 Oct 2004 00:09:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C0CAEFB298; Fri, 29 Oct 2004 04:09:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 12EE7FB28B; Fri, 29 Oct 2004 04:09:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D80F4FB28D; Fri, 29 Oct 2004 04:09:27 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 40563FB289 for ; Fri, 29 Oct 2004 04:09:27 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7847489830; Fri, 29 Oct 2004 07:09:26 +0300 (EEST) Message-ID: <4181C20F.30106@piuha.net> Date: Fri, 29 Oct 2004 07:07:43 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Subject: Re: [Mobike] possibly related draft References: <4180CB15.3070304@piuha.net> <4181725B.80309@isi.edu> <41819EEC.1000108@eng.monash.edu.au> In-Reply-To: <41819EEC.1000108@eng.monash.edu.au> 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 Greg Daley wrote: > At this stage there's no work done within DNA WG on APIs but we're > looking at getting indications of local connectivity from L2 into L3 > within DNA WG. > Similar work has been going on with DNAv4 in DHC. > > I'd guess that once the DNA system is able to indicate that an IP > configuration (addresses,local routers) is invalidated, or had > a connection discontinuity (e.g. link-layer only base station change) > This information could be passed to the upper layer protocols or IP > subsystems, in a similar fashion to a subset of the trigtran work > (but with only adjacent layer violations). > > Hysteresis and security of the change discovery would probably exist > within the DNA subsystem, but information about trust could be > passed around too. I'm not proposing this as a work item for DNA, > but it's intertesting for that group to see what people are really > interested in. > > Please tell me if this is the right path to look down for local > connectivity indications (or not). I think it is. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 29 00:56:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08916 for ; Fri, 29 Oct 2004 00:56:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 444F3FB292; Fri, 29 Oct 2004 04:56:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9D0A0FB28B; Fri, 29 Oct 2004 04:56:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 42B2AFB28D; Fri, 29 Oct 2004 04:56:29 +0000 (UTC) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id 4BF7AFB289 for ; Fri, 29 Oct 2004 04:56:28 +0000 (UTC) Received: from [192.168.123.143] (lsanca1-ar42-4-61-184-049.lsanca1.dsl-verizon.net [4.61.184.49]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i9T4tSi15489; Thu, 28 Oct 2004 21:55:28 -0700 (PDT) Message-ID: <4181CD41.5020307@isi.edu> Date: Thu, 28 Oct 2004 21:55:29 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Subject: Re: [Mobike] possibly related draft References: <4180CB15.3070304@piuha.net> <4181725B.80309@isi.edu> <41819EEC.1000108@eng.monash.edu.au> In-Reply-To: <41819EEC.1000108@eng.monash.edu.au> 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: 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: , Content-Type: multipart/mixed; boundary="===============2086570058==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2086570058== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6218440274CBB2696AA8214B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6218440274CBB2696AA8214B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greg Daley wrote: > Hi Joe, > > Joe Touch wrote: > >> I am concerned about the use of some of this inferred information from >> the link layer or transport layer to decide connectivity at the >> network layer. >> >> Notably, failure of TCP to make forward progress - e.g., lack of ACKs >> - is not an indication of a network layer connectivity failure. It can >> be a deliberate decision of the TCP implementation to limit processing >> associated with a connection, or can represent a security firewall >> being enabled. >> >> Similarly, we've had related dicussions in TCPM regarding the use of >> ICMP unreachable messages to tickle more rapid attempts to use >> alternate addresses, e.g., for v4/v6 selection. Unfortunately, these >> messages, as noted, are not secure, and so relying on them presents a >> DOS opportunity; it is not clear that there is a significant benefit >> in 'believing' these messages that is not undermined by this lack of >> security. >> >> Although it may be useful to consider direct evidence of connectivity, >> e.g., linkup/linkdown interface notification via an API, it is not >> clear yet that there is a protocol-related variant that can be >> appropriately applied, IMO. > > > At this stage there's no work done within DNA WG on APIs but we're > looking at getting indications of local connectivity from L2 into L3 > within DNA WG. > Similar work has been going on with DNAv4 in DHC. > > I'd guess that once the DNA system is able to indicate that an IP > configuration (addresses,local routers) is invalidated, or had > a connection discontinuity (e.g. link-layer only base station change) > This information could be passed to the upper layer protocols or IP > subsystems, in a similar fashion to a subset of the trigtran work > (but with only adjacent layer violations). The similarity of this work to trigtran is what concerns me. If the information is direct and immediate - e.g., from an interface that loses signal to the OS (via an API), it seems reasonable. If the information is inferred from packet data or the loss thereof (inferred, rather than explicit), then there are substantial hazards, and it isn't clear that there is a feasible variant. This was the case with trigtran, as I recall. > Hysteresis and security of the change discovery would probably exist > within the DNA subsystem, but information about trust could be > passed around too. I'm not proposing this as a work item for DNA, > but it's intertesting for that group to see what people are really > interested in. > > Please tell me if this is the right path to look down for local > connectivity indications (or not). I think it is, but there be dragons here. Joe --------------enig6218440274CBB2696AA8214B 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 iD8DBQFBgc1CE5f5cImnZrsRAgUSAJ4ljJaqANnKKKE0XVe1KnyR4JkTzACgxO1r Tud8im+bxF+p8GP5+nfxO/Y= =Me90 -----END PGP SIGNATURE----- --------------enig6218440274CBB2696AA8214B-- --===============2086570058== 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 --===============2086570058==-- From mobike-bounces@machshav.com Fri Oct 29 01:03:25 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09273 for ; Fri, 29 Oct 2004 01:03:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D7036FB294; Fri, 29 Oct 2004 05:03:22 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9A1F5FB27F; Fri, 29 Oct 2004 05:03:19 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 058F1FB280; Fri, 29 Oct 2004 05:03:18 +0000 (UTC) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id F23AFFB27A for ; Fri, 29 Oct 2004 05:03:16 +0000 (UTC) Received: from [192.168.123.143] (lsanca1-ar42-4-61-184-049.lsanca1.dsl-verizon.net [4.61.184.49]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i9T52Ti17000; Thu, 28 Oct 2004 22:02:29 -0700 (PDT) Message-ID: <4181CEE6.4040500@isi.edu> Date: Thu, 28 Oct 2004 22:02:30 -0700 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] possibly related draft References: <4180CB15.3070304@piuha.net> <4181725B.80309@isi.edu> <4181C1D5.60900@piuha.net> In-Reply-To: <4181C1D5.60900@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="===============1928371592==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1928371592== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6CDB56C15AB04009B4547D15" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6CDB56C15AB04009B4547D15 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Hi Joe, > > Thanks for raising these issues. Some further discussion inline: > >> I am concerned about the use of some of this inferred information from >> the link layer or transport layer to decide connectivity at the >> network layer. >> >> Notably, failure of TCP to make forward progress - e.g., lack of ACKs >> - is not an indication of a network layer connectivity failure. It can >> be a deliberate decision of the TCP implementation to limit processing >> associated with a connection, or can represent a security firewall >> being enabled. > > Yes. Although -- given that we are talking about TCP that runs over our > IKEv2/IPsec connection -- the firewall will also block all other traffic > from the same connection, at least if non-null encryption and ESP are used. > I believe we have several types of connectivity: > > - network layer connectivity > - IKE/IPsec connectivity > - transport or application connectivity > > With ALGs and other kinds of interesting devices, you could > actually have a situation where you have application > connectivity but no network or IPsec connectivity. Can you clarify this? it doesn't make sense to me. Sure, the network connectivity may be at multiple layers - the IP that carries the IPsec, the IP inside the IPsec (e.g., tunnel), etc., but I can't see how an application can connect in the absence of network connectivity. > SImilarly, > network connectivity does not imply that IKE/IPsec gets > through. Agreed. >> Similarly, we've had related dicussions in TCPM regarding the use of >> ICMP unreachable messages to tickle more rapid attempts to use >> alternate addresses, e.g., for v4/v6 selection. Unfortunately, these >> messages, as noted, are not secure, and so relying on them presents a >> DOS opportunity; it is not clear that there is a significant benefit >> in 'believing' these messages that is not undermined by this lack of >> security. > > Right. The way that I want to see this is that anything like an > ICMP error would at best be a hint that now it would be a good > time to do another DPD round. It's not yet clear that such hints should be acted on, or could trigger behavior that is unintended. The latter needs to be considered before assuming opportunistic reaction. >> Although it may be useful to consider direct evidence of connectivity, >> e.g., linkup/linkdown interface notification via an API, it is not >> clear yet that there is a protocol-related variant that can be >> appropriately applied, IMO. > > Yes. Or at least the security/semantics impacts of the protocol > related variants need to be considered. I think this means that > we have three classes of notifications: > > - Those that came through an API. However, most of the time the > API-based indications are really initiated by (possibly insecure) > protocol exchanges. For instance, the reception of an RA. > In some cases there's security available (if in use) for these > protocols, such as for ND we have SEND. I was thinking more of non-protocol API signals, e.g., that a wireless card loses the carrier. I agree that protocol-based signals of link failure are worrisome - for many reasons, not just security. > However, I'd still feel uncomfortable if MOBIKE did NOT believe > everything it hears from the API. We can't have a situation > where ND decides something but the MOBIKE/IKEv2/IPsec system > does not believe it and continues to use a bad address, for > instance. It makes more sense to create a system with keepalives that tears down the IKE or somesuch when they are not received, rather than to 'infer' anything based on hearing indirect information from an API. I.e., it is safe (IMO) to react to direct-connect API signals (carriers on cards on your box) or to signals you create for this purpose (e.g., keepalives inside an IKE association), but not to infer them from other protocols. > - Those that came through an external protocol, such as TCP. > The considerations that you Joe raised apply here. > > - Those that came through the MOBIKE/IKEv2/IPsec system itself. > These I believe we *can* believe, and with some assumptions > about the cryptographic primitives that are being used, this > really represents the connectivity that MOBIKE is concerned > about. Or does at least as long as one would test both IKEv2 > and ESP connectivity... in NAT-T case IKEv2 over UDP test > would probably suffice. Presumably this would be akin to the keepalives noted above; if so, agreed. > > --Jari --------------enig6CDB56C15AB04009B4547D15 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 iD8DBQFBgc7mE5f5cImnZrsRAux3AKCnEfxCqbgF05U3olAAspLA4rYfdwCgqGop JrkOhlPr43Z1M+iGZ7k8p+A= =vGpq -----END PGP SIGNATURE----- --------------enig6CDB56C15AB04009B4547D15-- --===============1928371592== 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 --===============1928371592==-- From mobike-bounces@machshav.com Fri Oct 29 02:05:50 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18064 for ; Fri, 29 Oct 2004 02:05:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2744CFB289; Fri, 29 Oct 2004 06:05:50 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 831AAFB27C; Fri, 29 Oct 2004 06:05:46 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0E651FB27F; Fri, 29 Oct 2004 06:05:44 +0000 (UTC) Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by machshav.com (Postfix) with ESMTP id AA0A7FB279 for ; Fri, 29 Oct 2004 06:05:42 +0000 (UTC) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGLYE1XQTM8X2NWA@vaxh.its.monash.edu.au> for mobike@machshav.com; Fri, 29 Oct 2004 16:05:33 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 94AA5AB543; Fri, 29 Oct 2004 16:05:32 +1000 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 053804FB10; Fri, 29 Oct 2004 16:05:32 +1000 (EST) Date: Fri, 29 Oct 2004 16:05:31 +1000 From: Greg Daley Subject: Re: [Mobike] possibly related draft In-reply-to: <4181CD41.5020307@isi.edu> To: Joe Touch Message-id: <4181DDAB.1070506@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <4180CB15.3070304@piuha.net> <4181725B.80309@isi.edu> <41819EEC.1000108@eng.monash.edu.au> <4181CD41.5020307@isi.edu> Cc: MOBIKE Mailing List , jari.arkko@piuha.net X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7BIT Hi Joe, Joe Touch wrote: > > > Greg Daley wrote: > >> Hi Joe, >> >> Joe Touch wrote: >> >>> I am concerned about the use of some of this inferred information >>> from the link layer or transport layer to decide connectivity at the >>> network layer. >>> >>> Notably, failure of TCP to make forward progress - e.g., lack of ACKs >>> - is not an indication of a network layer connectivity failure. It >>> can be a deliberate decision of the TCP implementation to limit >>> processing associated with a connection, or can represent a security >>> firewall being enabled. >>> >>> Similarly, we've had related dicussions in TCPM regarding the use of >>> ICMP unreachable messages to tickle more rapid attempts to use >>> alternate addresses, e.g., for v4/v6 selection. Unfortunately, these >>> messages, as noted, are not secure, and so relying on them presents a >>> DOS opportunity; it is not clear that there is a significant benefit >>> in 'believing' these messages that is not undermined by this lack of >>> security. >>> >>> Although it may be useful to consider direct evidence of >>> connectivity, e.g., linkup/linkdown interface notification via an >>> API, it is not clear yet that there is a protocol-related variant >>> that can be appropriately applied, IMO. >> >> >> >> At this stage there's no work done within DNA WG on APIs but we're >> looking at getting indications of local connectivity from L2 into L3 >> within DNA WG. >> Similar work has been going on with DNAv4 in DHC. >> >> I'd guess that once the DNA system is able to indicate that an IP >> configuration (addresses,local routers) is invalidated, or had >> a connection discontinuity (e.g. link-layer only base station change) >> This information could be passed to the upper layer protocols or IP >> subsystems, in a similar fashion to a subset of the trigtran work >> (but with only adjacent layer violations). > > > The similarity of this work to trigtran is what concerns me. If the > information is direct and immediate - e.g., from an interface that loses > signal to the OS (via an API), it seems reasonable. If the information > is inferred from packet data or the loss thereof (inferred, rather than > explicit), then there are substantial hazards, and it isn't clear that > there is a feasible variant. This was the case with trigtran, as I recall. DNA is only concerned with things it knows internally or verifiably from (first hop) routing infrastructure which can be trusted, or checked. I can understand the concerns though. There were some ideas in trigtran which weren't explicitly known by the host receiving the information: Out of band messages (ICMPv6), remote indications in TCP..., DNA's not really interested in event notifications except from its own NIC (link up/link down). It is able to infer configuration state from neighbour/router discovery (using SEND, if available) messaging. Once it knows about changes and events, it could provide indications to the already mentioned services, but this is still out of scope. >> Hysteresis and security of the change discovery would probably exist >> within the DNA subsystem, but information about trust could be >> passed around too. I'm not proposing this as a work item for DNA, >> but it's intertesting for that group to see what people are really >> interested in. >> >> Please tell me if this is the right path to look down for local >> connectivity indications (or not). > > > I think it is, but there be dragons here. I understand (or think I do). We're really interested in making something work which a) doesn't cause security headaches b) doesn't get killed in IESG/IETF last call.. The API/upper layer indications stuff is currently out of scope for DNA, but the change detection is there. If you're interested, please have a look at some of the work going on in DNA, because we'd certainly be interested in feedback. Greg _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 29 03:57:16 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04624 for ; Fri, 29 Oct 2004 03:57:15 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 54730FB291; Fri, 29 Oct 2004 07:57:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 99180FB280; Fri, 29 Oct 2004 07:57:13 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AB6A6FB289; Fri, 29 Oct 2004 07:57:12 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 8F0C9FB27C for ; Fri, 29 Oct 2004 07:57:11 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9754789860; Fri, 29 Oct 2004 10:57:09 +0300 (EEST) Message-ID: <4181F76E.9060806@piuha.net> Date: Fri, 29 Oct 2004 10:55:26 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch Subject: Re: [Mobike] possibly related draft References: <4180CB15.3070304@piuha.net> <4181725B.80309@isi.edu> <4181C1D5.60900@piuha.net> <4181CEE6.4040500@isi.edu> In-Reply-To: <4181CEE6.4040500@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 Hi Joe, >> I believe we have several types of connectivity: >> >> - network layer connectivity >> - IKE/IPsec connectivity >> - transport or application connectivity >> >> With ALGs and other kinds of interesting devices, you could >> actually have a situation where you have application >> connectivity but no network or IPsec connectivity. > > Can you clarify this? it doesn't make sense to me. Sure, the network > connectivity may be at multiple layers - the IP that carries the IPsec, > the IP inside the IPsec (e.g., tunnel), etc., but I can't see how an > application can connect in the absence of network connectivity. Anything that uses a proxy would be an example of a situation where there's application layer connectivity but no lower layer connectivity (to the peer). Anyway, maybe that is not so important from the point of view of our discussion. What's perhaps more important is that having network layer connectivity does not imply IPsec/IKE gets through. And having transport layer connectivity without IPsec/IKE at the bottom does not imply that you would have IPsec/IKE connectivity. Pretty much nothing else than IPsec/IKE can ensure that there's IPsec/IKE connectivity... >> Right. The way that I want to see this is that anything like an >> ICMP error would at best be a hint that now it would be a good >> time to do another DPD round. > > > It's not yet clear that such hints should be acted on, or could trigger > behavior that is unintended. The latter needs to be considered before > assuming opportunistic reaction. I agree, but the way that I wanted to look at this is that a hint leads to an activity that attempts to verify the hint using a more secure mechanism (such as DPD). If this secure mechanism reports that there is a problem, THEN we act, not sooner. So the hint never directly leads to an actual change in the IPsec/IKE addressing behavior. >> However, I'd still feel uncomfortable if MOBIKE did NOT believe >> everything it hears from the API. We can't have a situation >> where ND decides something but the MOBIKE/IKEv2/IPsec system >> does not believe it and continues to use a bad address, for >> instance. > > It makes more sense to create a system with keepalives that tears down > the IKE or somesuch when they are not received, rather than to 'infer' > anything based on hearing indirect information from an API. I.e., it is > safe (IMO) to react to direct-connect API signals (carriers on cards on > your box) or to signals you create for this purpose (e.g., keepalives > inside an IKE association), but not to infer them from other protocols. I believe many people on this list have expressed the desire to rely (at least partially) on other modules whose tasks include things like verifying connectivity to the local router, or change of on-link prefixes. I take it that you feel uneasy with this. But let me point out a few things: (1) There's a difference between local information and global connectivity. I too would be hesitant to trust other protocols for the latter. But for the former I see little alternatives. (2) Some of these other modules have security support. ND has SEND, for instance. And DHCP has some security tools too, although in many cases these tools aren't used. (3) I can in a way understand your reluctance to use a particular insecure information piece from other modules. However, it seems that you MUST rely on it at least in some cases. For instance, when you boot your computer and get an IP address from the local network (possibly using an insecure version of ND or DHCP), there's really nothing that you could do in IPsec/IKE to avoid this. IPsec/IKE does not include the DHCP functionality. So it seems that you are stuck with the insecure modules/protocols at least for getting information about new addresses and connections. Presumably you could stick to these (despite advice from the other modules) until you have verified in the IPsec/IKE layer that they no longer work. But I think it doesn't help much, and could break other things. For instance, if ND says the link has changed and old addresses are gone, you should not continue to use your old address because it might collide with someone else's address on the new link. >> - Those that came through an external protocol, such as TCP. >> The considerations that you Joe raised apply here. >> >> - Those that came through the MOBIKE/IKEv2/IPsec system itself. >> These I believe we *can* believe, and with some assumptions >> about the cryptographic primitives that are being used, this >> really represents the connectivity that MOBIKE is concerned >> about. Or does at least as long as one would test both IKEv2 >> and ESP connectivity... in NAT-T case IKEv2 over UDP test >> would probably suffice. > > > Presumably this would be akin to the keepalives noted above; if so, agreed. Yes. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 29 11:47:12 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10294 for ; Fri, 29 Oct 2004 11:47:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 51A15FB298; Fri, 29 Oct 2004 15:47:12 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 23ACFFB285; Fri, 29 Oct 2004 15:47:06 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EBF78FB28D; Fri, 29 Oct 2004 15:47:04 +0000 (UTC) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 2AF2DFB27C for ; Fri, 29 Oct 2004 15:47:04 +0000 (UTC) Message-ID: <002e01c4bdce$a90bec20$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Joe Touch" , References: <4180CB15.3070304@piuha.net> <4181725B.80309@isi.edu><41819EEC.1000108@eng.monash.edu.au> <4181CD41.5020307@isi.edu> Subject: Re: [Mobike] possibly related draft Date: Fri, 29 Oct 2004 08:47:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Joe, >The similarity of this work to trigtran is what concerns me. If the >information is direct and immediate - e.g., from an interface that loses >signal to the OS (via an API), it seems reasonable. If the information >is inferred from packet data or the loss thereof (inferred, rather than >explicit), then there are substantial hazards, and it isn't clear that >there is a feasible variant. This was the case with trigtran, as I recall. My recollection is that Trigtran was derailed by the security issue. How can I know that the ICMP message I've just received indicating a link is down wasn't sent by an attacker wanting to DoS me? Regarding inference from upper layers, RFC 2461 has this to say about using upper layer information for NUD (Section 3): Neighbor Unreachability Detection detects the failure of a neighbor or the failure of the forward path to the neighbor. Doing so requires positive confirmation that packets sent to a neighbor are actually reaching that neighbor and being processed properly by its IP layer. Neighbor Unreachability Detection uses confirmation from two sources. When possible, upper-layer protocols provide a positive confirmation that a connection is making "forward progress", that is, previously sent data is known to have been delivered correctly (e.g., new acknowledgments were received recently). When positive confirmation is not forthcoming through such "hints", a node sends unicast Neighbor Solicitation messages that solicit Neighbor Advertisements as reachability confirmation from the next hop. To reduce unnecessary network traffic, probe messages are only sent to neighbors to which the node is actively sending packets. This is meant to apply only to the local link (thus the phrasing of "neighbor" which typically means a node on the local link), but since one of those nodes is the last hop router, the implication here is that forward progress from upper layers can be used to infer whether the node's connection off the local link is active, and thus whether IP needs to do NUD. This would indicate that, at least in IPv6, upper layers are expected to participate in determining whether connectivity is available. I'm not sure how that impacts MOBIKE, but I would expect lack of an upper layer positive confirmation of "forward progress" might trigger MOBIKE to test for activity, or select another SA if another address is available, in addition to triggering NUD. I don't think the statement in RFC 2461 explicitly contradicts your assertion about what kind of information could be used by lower layers, but it is suitably vague enough that it might be so construed. Perhaps the DNA WG will help to clarify this in the end. jak _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 31 10:50:13 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08172 for ; Sun, 31 Oct 2004 10:50:12 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 69E17FB27C; Sun, 31 Oct 2004 15:50:12 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 60614FB262; Sun, 31 Oct 2004 15:50:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 91EC3FB266; Sun, 31 Oct 2004 15:50:10 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id ED71FFB257 for ; Sun, 31 Oct 2004 15:50:09 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 73C56898A3 for ; Sun, 31 Oct 2004 17:50:05 +0200 (EET) Message-ID: <41850943.1090107@piuha.net> Date: Sun, 31 Oct 2004 17:48: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: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 12: interaction with other protocols doing RR 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 Background: a number of protocols employ return routability tests. In the mobility space we have this at least in MOBIKE, Mobile IPv6, MULTI6, and HIP. Tero's design document discusses some differences these tests have in different contexts; not all do exactly the same thing even if all at least verify there's someone willing to respond on the path towards the tested address. I would like to suggest that we do our own specific type of test, but allow same tests to be "reused" across protocols where this makes sense. That is, in MOBIKE we do our own test that verifies liveness of the address and that the peer is indeed still the same IKEv2 node and has knowledge of some secret keying material. In addition, we add a note saying that the use of the results of this test may be possible in other protocol layers*. Ok for everyone? --Jari *) The example that comes to my mind is that since the mobile node - home agent interface in mobile IPv6 runs with IPsec, then the use of MOBIKE in that context would provide an RR test to home registrations. That does not exist in Mobile IPv6 at the moment, but if it were included then Mobile IPv6 home agent service could easier be offered to "unknown" peers. Currently "unknown" peers are only support as correspondent nodes. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 31 11:03:31 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09254 for ; Sun, 31 Oct 2004 11:03:30 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id F3A0BFB27C; Sun, 31 Oct 2004 16:03:31 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7DC68FB266; Sun, 31 Oct 2004 16:03:29 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5E6E0FB279; Sun, 31 Oct 2004 16:03:28 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 492F3FB262 for ; Sun, 31 Oct 2004 16:03:27 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5E6DB898A3 for ; Sun, 31 Oct 2004 18:03:26 +0200 (EET) Message-ID: <41850C64.6030004@piuha.net> Date: Sun, 31 Oct 2004 18:01:40 +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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 14 - path testing and congestion 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'd like to close this issue based on what Bill Sommerfeld said about it: While there may be situations where you can ignore congestion control best practices and get excellent benchmark results under carefully controlled conditions, such environments tend to be unstable under load and are therefore unsuitable for production use. Path failover is likely to be triggered in as the result of packet loss. Packet loss is often caused by congestion. Sending a burst of packets when you detect an event which may be the result of congestion has been considered a really bad idea for about two decades now. We MUST NOT produce a spec which, if deployed, would force router vendors to produce countermeasures to protect the rest of the network from us. As a result, I'd like to suggest that when peers test candidate addresses (or pairs), they SHOULD attempt testing all of them, but MUST do this sequentially (based on an implementation-dependent priority order) and using an exponential back-off procedure. Ok for everyone? I'll assume so unless I hear from you in the next couple of days. Note that the unpleasant but necessary side-effect is that only a small set of multihoming addresses on both sides is practical. On larger sets, testing takes too long. Some math about this in http://www.arkko.com/publications/multi6/faildet.html#anchor9 --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 31 13:09:02 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18260 for ; Sun, 31 Oct 2004 13:09:01 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E352BFB266; Sun, 31 Oct 2004 18:08:59 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 08BB3FB266; Sun, 31 Oct 2004 18:08:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 53B3AFB279; Sun, 31 Oct 2004 18:08:56 +0000 (UTC) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id B78ADFB257 for ; Sun, 31 Oct 2004 18:08:55 +0000 (UTC) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B49C1898A5 for ; Sun, 31 Oct 2004 20:08:53 +0200 (EET) Message-ID: <418529CB.4030601@piuha.net> Date: Sun, 31 Oct 2004 20:07:07 +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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] issue 6: scope of SA changes 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 Lets have a consensus call on this. From the list discussion so far I don't see enough people commenting on this that would enable us to make decision. For a more accurate decision, I have broken the issue down into three questions. 1. Would it be useful to treat different flows or applications in a different manner with regards to their multihoming behaviour? For instance, keep one flow always in GPRS but allow another flow to use LAN where available. Yes, mandatory [ ] Yes, optional [ ] No [ ] 2. Would you like to provide this functionality through Separate IPsec SAs and their independent addresses [ ] Separate IKE SAs and their independent addresses [ ] 3. If you prefer the use of IPsec SAs for this purpose, would you like always manage each SA separately [ ] provide a default where all SAs are moved [ ] Send your answers by Wednesday, Nov 3rd, 2004. The rationale behind your answers will help others form their opinions, so please state also why you are answering in a particular way. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 31 18:01:35 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11961 for ; Sun, 31 Oct 2004 18:01:34 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id ED6CFFB27A; Sun, 31 Oct 2004 23:01:34 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 10CD3FB255; Sun, 31 Oct 2004 23:01:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 88175FB257; Sun, 31 Oct 2004 23:01:31 +0000 (UTC) Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by machshav.com (Postfix) with ESMTP id 29121FB252 for ; Sun, 31 Oct 2004 23:01:30 +0000 (UTC) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LGPSGAGRUK8ZEY91@vaxh.its.monash.edu.au> for mobike@machshav.com; Mon, 1 Nov 2004 09:58:44 +1100 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5367480003; Mon, 01 Nov 2004 09:58:43 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 238DD3C009; Mon, 01 Nov 2004 09:58:43 +1100 (EST) Date: Mon, 01 Nov 2004 09:58:42 +1100 From: Greg Daley Subject: Re: [Mobike] possibly related draft In-reply-to: <002e01c4bdce$a90bec20$656115ac@dcml.docomolabsusa.com> To: James Kempf Message-id: <41856E22.5000309@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us References: <4180CB15.3070304@piuha.net> <4181725B.80309@isi.edu> <41819EEC.1000108@eng.monash.edu.au> <4181CD41.5020307@isi.edu> <002e01c4bdce$a90bec20$656115ac@dcml.docomolabsusa.com> Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Joe Touch X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7BIT Hi James, James Kempf wrote: > Joe, > > >>The similarity of this work to trigtran is what concerns me. If the >>information is direct and immediate - e.g., from an interface that loses >>signal to the OS (via an API), it seems reasonable. If the information >>is inferred from packet data or the loss thereof (inferred, rather than >>explicit), then there are substantial hazards, and it isn't clear that >>there is a feasible variant. This was the case with trigtran, as I recall. > > > My recollection is that Trigtran was derailed by the security issue. How can > I know that the ICMP message I've just received indicating a link is down > wasn't sent by an attacker wanting to DoS me? > > Regarding inference from upper layers, RFC 2461 has this to say about using > upper layer information for NUD (Section 3): > > Neighbor Unreachability Detection detects the failure of a neighbor > or the failure of the forward path to the neighbor. Doing so > requires positive confirmation that packets sent to a neighbor are > actually reaching that neighbor and being processed properly by its > IP layer. Neighbor Unreachability Detection uses confirmation from > two sources. When possible, upper-layer protocols provide a positive > confirmation that a connection is making "forward progress", that is, > previously sent data is known to have been delivered correctly (e.g., > new acknowledgments were received recently). When positive > confirmation is not forthcoming through such "hints", a node sends > unicast Neighbor Solicitation messages that solicit Neighbor > Advertisements as reachability confirmation from the next hop. To > reduce unnecessary network traffic, probe messages are only sent to > neighbors to which the node is actively sending packets. > > This is meant to apply only to the local link (thus the phrasing of > "neighbor" which typically means a node on the local link), but since one of > those nodes is the last hop router, the implication here is that forward > progress from upper layers can be used to infer whether the node's > connection off the local link is active, and thus whether IP needs to do > NUD. > > This would indicate that, at least in IPv6, upper layers are expected to > participate in determining whether connectivity is available. I'm not sure > how that impacts MOBIKE, but I would expect lack of an upper layer positive > confirmation of "forward progress" might trigger MOBIKE to test for > activity, or select another SA if another address is available, in addition > to triggering NUD. > > I don't think the statement in RFC 2461 explicitly contradicts your > assertion about what kind of information could be used by lower layers, but > it is suitably vague enough that it might be so construed. Perhaps the DNA > WG will help to clarify this in the end. We've tried to touch on this in draft-narayanan-dna-bcp-01.txt . Sections 7.2 and 7.3 (both on page 17-18) are about processing hints from other layers and timers. The hints may or may not be used to initiate change and reachability detection, based on hysteresis. Section 7.5 on hysteresis describes the threat of processing hints which originate from protocol messages (page 19). If there's need for more specificity regarding NCE state (considering 2461's vagueness) or concerns about the security of this approach (for example, with mobike), please let us know. Greg _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike