From mobike-bounces@machshav.com Wed Sep 06 11:47:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKzcz-0001nR-8r for mobike-archive@lists.ietf.org; Wed, 06 Sep 2006 11:47:49 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKzcu-0000BX-TL for mobike-archive@lists.ietf.org; Wed, 06 Sep 2006 11:47:49 -0400 Received: by machshav.com (Postfix, from userid 512) id 76449FB2B9; Wed, 6 Sep 2006 15:47:35 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D0902FB2B0; Wed, 6 Sep 2006 15:47:32 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 59480FB2B4; Wed, 6 Sep 2006 15:47:30 +0000 (UTC) Received: from mail.ca.certicom.com (nat194.certicom.com [66.48.18.194]) by machshav.com (Postfix) with ESMTP id B868EFB2AE for ; Wed, 6 Sep 2006 15:47:29 +0000 (UTC) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 9FC051006B00F; Wed, 6 Sep 2006 11:47:26 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12626-54; Wed, 6 Sep 2006 11:47:25 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 1EB491006B00E; Wed, 6 Sep 2006 11:47:25 -0400 (EDT) Received: from [10.0.8.227] ([10.0.8.227]) by certicom1.certicom.com (Lotus Domino Release 6.5.4) with ESMTP id 2006090611461569-3570 ; Wed, 6 Sep 2006 11:46:15 -0400 Message-ID: <44FEED8C.9070208@certicom.com> Date: Wed, 06 Sep 2006 11:47:24 -0400 From: Eric Fung User-Agent: Thunderbird 1.5.0.5 (X11/20060728) MIME-Version: 1.0 To: Tero Kivinen References: <44F4944A.7060806@certicom.com> <17653.15822.752778.803299@fireball.kivinen.iki.fi> In-Reply-To: <17653.15822.752778.803299@fireball.kivinen.iki.fi> X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 09/06/2006 11:46:15 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 09/06/2006 11:46:16 AM, Serialize complete at 09/06/2006 11:46:16 AM Cc: mobike@machshav.com Subject: Re: [Mobike] Changing to port 4500 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Tero Kivinen wrote: > The RFC 4555 has a bit underspecified text saying we change if both > ends supports both, but actually we do not need to know whether > remote end supports MOBIKE, knowing that it supports NAT-T is > enough. Anyways examples make it very clear that we change to port > 4500 for the IKE_AUTH. If there is no NAT between the peers and we change to port 4500, should ESP packets be UDP encapsulated or not? I don't see any pertinent guidance in RFC 4306 and at least one implementation I'm testing against differs in its interpretation. Thanks. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Sep 07 03:32:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLENU-0007R4-17 for mobike-archive@lists.ietf.org; Thu, 07 Sep 2006 03:32:48 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLENR-00038k-Hm for mobike-archive@lists.ietf.org; Thu, 07 Sep 2006 03:32:48 -0400 Received: by machshav.com (Postfix, from userid 512) id 6F05EFB2D8; Thu, 7 Sep 2006 07:32:36 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EF0D1FB2CF; Thu, 7 Sep 2006 07:32:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D003CFB2D2; Thu, 7 Sep 2006 07:32:31 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id EF0A5FB2CB for ; Thu, 7 Sep 2006 07:32:29 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id k877WKjE028548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Sep 2006 10:32:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id k877WJgn023683; Thu, 7 Sep 2006 10:32:19 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17663.51971.853768.218191@fireball.kivinen.iki.fi> Date: Thu, 7 Sep 2006 10:32:19 +0300 From: Tero Kivinen To: Eric Fung In-Reply-To: <44FEED8C.9070208@certicom.com> References: <44F4944A.7060806@certicom.com> <17653.15822.752778.803299@fireball.kivinen.iki.fi> <44FEED8C.9070208@certicom.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 24 min X-Total-Time: 30 min Cc: mobike@machshav.com Subject: Re: [Mobike] Changing to port 4500 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Eric Fung writes: > > The RFC 4555 has a bit underspecified text saying we change if both > > ends supports both, but actually we do not need to know whether > > remote end supports MOBIKE, knowing that it supports NAT-T is > > enough. Anyways examples make it very clear that we change to port > > 4500 for the IKE_AUTH. > > If there is no NAT between the peers and we change to port 4500, > should ESP packets be UDP encapsulated or not? I don't see any > pertinent guidance in RFC 4306 and at least one implementation I'm > testing against differs in its interpretation. RFC4555 specifies that UDP Encapsulation (i.e NAT Traversal) can be enabled and disabled at will, i.e. in normal case it should be enabled if NAT is detected on the selected addresses. The 4555 does not forbid enabling it even if no NAT is deteceted, as it might also be needed to go through firewalls etc, but it does not give guidance whether it should be enabled or not. Anyways the sender can use UDP encapsulation or not, and the recipient needs to be able to receive packets with UDP encapsulation and without UDP encapsulation always (at least for the mobike if NAT-T is supported). The RFC 4306 says that you MUST enable UDP encapsulation if NAT is detected, but it does not say anything whether you can enable it if no NAT is detected. It is silent about this issue, but nothing there says that it should process UDP encapsulated IPsec packets any differently than non UDP encapsulated IPsec packets, so I would guess the correct answer is that also RFC 4306 compliant implementations should accept both UDP encapsulated and normal IPsec packets for same SA. I guess most of the implementations do not do this now, and it really does not matter for the pre-mobike implementations as there is no reason to enable UDP encapsulation in the middle of the IKE SA, but for mobike it is important, i.e. there the UDP encapsulation is separate option that can be enabled and disabled at any time (decided by the sender of the packet). Note, that with mobike the UDP encapsulation might also be enabled or disabled in the middle of the SA without any notification to the other end. Here is an example of that: The initiator has two interfaces, each with one IP (I1 = 192.168.2.22, I2 = 10.0.1.11). The responder has one IP (R1 = 192.168.1.1). The initiator is using I1,R1 address pair for its traffic and there is no NAT between that, i.e. the UDP encapsulation is disabled. Then the IP address I1 is disabled (i.e. interface removed, link layer goes down, dhcp lease expires etc), and the initiator knows that I1 -> R1 does not work anymore, even without probing it. It decides to move all traffic to the I2,R1 address pair. It suspects that there might be NAT as the I2 is private use address (10.0.1.11), so while it moves all IPsec traffic to the new address pair at the same time when it starts address update. It does this because it knows that it cannot send those packets to I1,R1 pair as it does not exists anymore, so there is possibility that those will reach the other end with I2,R1 pair, and turning on UDP encapsulation at that time because it suspects there is NAT does not cost that much, but will enchance the probability that packets actually reach the responder. The address update goes forward and the responder updates the addresses accordingly, and detects from the NAT_DETECTION payloads that there is no NAT, so he keeps UDP encapsulation disabled, but still accepts the packets sent by the initiator with UDP encapsulation. When the initiator gets responders reply to the address update packet it will also detect that there was no NAT even when initiator assumed so, and it will disabled UDP encapsulation at that point (last step of the section 3.5 in the RFC 4555). So in the end initiator enabled UDP encapsulation for a few packets while doing the address updated, but disabled it immediately when it detected there was no NAT between. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike