Comments regarding IPsec NAT traversal / new proposal
Ari Huttunen <Ari.Huttunen@F-Secure.com> Wed, 26 July 2000 14:25 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06199; Wed, 26 Jul 2000 07:25:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22479 Wed, 26 Jul 2000 08:53:56 -0400 (EDT)
Message-ID: <397EE19F.5AE38323@F-Secure.com>
Date: Wed, 26 Jul 2000 16:03:27 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec-list <ipsec@lists.tislabs.com>
Subject: Comments regarding IPsec NAT traversal / new proposal
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This mail applies partly to both of these drafts: draft-aboba-nat-ipsec-02.txt draft-stenberg-ipsec-nat-traversal-00.txt We believe that using UDP encapsulation is the correct way to traverse NATs, at least in the short term. We also intend to produce an internet draft about this, however it didn't materialize before the Pittsburgh meeting. The current proposals are unnecessarily complex, and I'd like some discussion about these issues, to judge if this is indeed the case. ASSUMPTION: There is no *need* to enable AH traffic to traverse through a NAT. ESP is sufficient to provide encryption and/or authentication. By accepting this assumption, the solution can be made less complex. It has been argued that in some rare cases AH is necessary to protect the IP header. If this is so, I argue that there is no need to make this pass through a NAT as well. Thus, we can use the following encapsulation that is less complex and has less overhead than either of the referred drafts has, i.e. 8 octets. Transport mode: --------------------------------------------------------- IPv4 |orig IP hdr | UDP | ESP | | ESP | ESP| |(any options)| Hdr | Hdr | Payload Data | Trailer |Auth| --------------------------------------------------------- ASSUMPTION: We do *not* wish to use the same UDP port for both IKE and IPsec traffic encapsulated in UDP. This is because we'd loose the possibility to filter these traffic types separately in a firewall. For this purpose we've reserved the port 2797 from IANA. As draft-stenberg-ipsec-nat-traversal-00.txt mentions, there is a potential need for a keepalive to ensure NAT tables remain up-to-date. Because our proposal uses a different port than IKE, there is a need for a keepalive that sends packets along the ESPoverUDP path. This can be achieved for instance by sending empty UDP packets (i.e. without ESP contents). (Assuming the general IPsec keepalive is along the IKE SA and can't be used.) In particular, the method of negotiating and setting up UDP encapsulation as defined in draft-stenberg-ipsec-nat-traversal-00.txt is too complex. We propose the following mechanism for discussion: 1) IKE phase 1 is not modified. 2) IKE phase 2 adds a new protocol ID, Protocol ID Value ----------- ----- RESERVED 0 PROTO_ISAKMP 1 PROTO_IPSEC_AH 2 PROTO_IPSEC_ESP 3 PROTO_IPCOMP 4 PROTO_IPSEC_ESP_OVER_UDP X This is used to send proposals for plain IPsec as well as ESPoverUDP during the QM. As usual, the responder may use any proposal it wishes. The proposal shall contain parameters that say which src/dst port/addresses were used by the initiator when sending the IKE packet. If these differ from those observed by the responder, there is a NAT acting between them, and the responder SHOULD choose the ESP over UDP proposal. Unlike draft-stenberg-ipsec-nat-traversal-00.txt, this method does not leak information regarding the internal structure of the network, because QM messages are encrypted. We don't have patent applications regarding this, but I have no way of knowing whether SSH has tried to patent some it. -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security
- Comments regarding IPsec NAT traversal / new prop… Ari Huttunen
- IPSec Performance Tests ANDREW ARRON LITTLE
- Re: Comments regarding IPsec NAT traversal / new … Jim Tiller