Internet Protocol Security                        W. Dixon, B. Swander
Internet Draft                                               Microsoft
Document: draft-ietf-ipsec-udp-encaps-        A. Huttunen, J. Sierwald
justification-00.txt                              F-Secure Corporation
Category: Informational                                       V. Volpe
                                                         Cisco Systems
                                                            L. DiBurro
                                                       Nortel Networks
                                               M. Stenberg, T. Kivinen
                                      SSH Communications Security Corp

                                                             June 2001
           IPsec over NAT Justification for UDP Encapsulation
            draft-ietf-ipsec-udp-encaps-justification-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Copyright Notice
      Copyright (C) The Internet Society (2001). All Rights Reserved.


. Abstract

   This draft explains the design justification and alternatives for
   two IPsec over NAT drafts, UDP Encapsulation of IPsec Packets,
   [Hutt01] and [Kiv00].  This draft sets the requirements for a
   solution in terms of scenarios in which NAT is used, and NAT
   operations.  This draft is specifies the requirements for IPsec NAT
   traversal, scenarios these extensions enable, and design rationale
   for the proposed solution.  This draft assumes that the reader is
   familiar with the interactions of NAT with IPsec documented in
   [Aboba04].

. Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively. A packet which is processed through a network
   address translator (NAT) or a network address and port translator
   (NAPT) is said to be "NATed".



Dixon, et. al.                                                       1
          IPsec over NAT Justification for UDP Encapsulation June 2001


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC-2119]


. Introduction

   NAT is widely used for Internet "connection sharing" and ships as a
   standard feature in every router and edge device.  Cable and DSL
   deployments have been known to install NAT in embedded devices
   resident inside the home.  Additionally most hotel Internet
   connections are using NAT.  Many airport & wireless services in
   public areas use NAT to connect to the Internet.  Some Internet
   Service Providers use a centralized NAT to connect their clients to
   the Internet.

   Without a solution to the problem, the L2TP/IPsec VPN client and an
   IPsec tunnel mode VPN client can not connect from home or from
   business sites which use NAT to connect to the Internet.  Likewise,
   transport TCP and UPD traffic that is protected by IPsec transport
   mode can not be exchanged between peer to peer or server-to-server
   applications.

   Without an IETF standard solution for IPsec over NAT, vendor
   products will not interoperate, and will be forced to support
   multiple methods.

   This proposal allows ESP to pass through NAT if the NAT allows UDP
   traffic.  It does not require the NAT to be aware of IPsec and IKE
   negotiations.  The technique is used only if the initiator and the
   responder support it, and only used when necessary, since NAT
   detection is built into the protocol.

   This technique allows L2TP protected by IPsec transport mode using
   the most popular and default encryption format (IPsec ESP) to go
   through existing NATs - which do either port and address translation
   of UDP packets or pure-address translation.

   It also allows IPsec tunnel mode to go through the same type of
   NATs, a requirement for many in the industry which implement
   extensions to IPsec tunnel mode for remote access. Address
   assignment can also use the standards track DHCP over IPsec method.

   Note however that when RFC IPsec tunneling through a NAT between an
   end system (static internal & external IP) and a gateway, or between
   two gateways - the internal addresses used by packets inside the
   IPsec tunnel can not be changed by the NAT.  So the internal IP
   packet will retain a potentially invalid address on the destination
   network. There are three options to provide proper addressing for
   tunneled packets:

   -    perform a second NAT function either before the tunnel ingress
   or after the tunnel egress.

Dixon, et. al.                                                       2
          IPsec over NAT Justification for UDP Encapsulation June 2001



   -    In the case where traffic inside the tunnel is clear text TCP &
   UDP traffic, this is normal NAT and not affected by the IPsec tunnel
   being NATed itself.

   -    In the case where traffic inside the IPsec tunnel is IPsec
   transport traffic, this spec provides the mechanism for the IPsec
   transport peers to detect this second NAT and pass it accordingly.

   -    Not use the RFC method of negotiating an IPsec tunnel - instead
   use proprietary extensions to RFC 2409 for address assignment for
   remote access VPN tunnels.

   -    Keep the internal address as is, and configure the destination
   network to be able to handle it.

   This method should be able to be used in all scales where NAT is
   deployed today to do simple pure address-to-address, or address and
   port translation.  However, it will not be able to be used where the
   NAT would otherwise perform packet inspection and replacement of
   address or port information inside the packet (e.g. modifying the
   FTP PORT command packet).  Thus UDP encapsulated IPsec transport and
   tunnel traffic will be successful if the communications model is
   that the client initiates TCP connections & UDP sessions from itself
   out through the NAT.

   This protocol does not involve the client communicating directly
   with the NAT for the purpose of opening ports to receive inbound
   connections.  If required, another method such as RSIP may be used
   by the application first to communicate with the NAT.

   IKE & IPsec issues with NAT are documented in [Aboba04]. This
   proposal provides a solution to all issues identified when using IKE
   Identity Protect Mode (Main Mode) or Aggressive Mode and Quick Mode.
   Other proprietary IKE extensions may be present, but are not
   considered by this draft. Address assignment for a remote access VPN
   IPsec tunnel client can use DHCPv4 Configuration of IPsec Tunnel
   Mode [Patel12].

   Most importantly, this proposal does not require change to the NAT
   device itself - which is seen as practically too difficult to
   accomplish.  The deployment of IPsec enabled systems is typically
   controlled by the user of that system, and thus can be updated
   independently of the network infrastructure at ISPs, hotels, mobile
   and temporary networks, and other places where NAT is required to
   overcome limited IPv4 Internet routeable address availability.  We
   expect the technique described here to be used in the interim to
   pass IPv4 addressed traffic only.  We expect this technique to
   become outdated as IPv6 is deployed, enabling end-to-end IPsec
   without address translation.


. <Section 4 heading as appropriate>

Dixon, et. al.                                                       3
          IPsec over NAT Justification for UDP Encapsulation June 2001



   Aboba presents requirements for an IPsec over NAT solution.  The
   [Kiv00]and [Hutt01] drafts do this as follows:

   1.   Deployability - the design ensures that IKE and IPsec ESP
   appear only asUDP protocol packets which are allowed to have their
   source and destination addresses changed by a common NAT.  An IPsec
   aware NAT is not required.  Thus the network infrastructure need not
   change.  Firewalls can filter on a single UDP port.  No change in
   DNS clients, DNS servers, DHCP clients, DHCP servers, or
   applications programs are required for this IPsec over NAT solution,
   as is typically required for IPv6 deployment.  There is no
   communication between host and NAT device.  The timeframe for
   deployment is simply the timeframe for end systems to have a
   software patch or update which enables the protocol functionality
   defined here.

   2.   Telecommuter scenario.  While this draft claims no need for
   support beyond that needed for telecommuter scenarios, the IPsec
   protocol is more generally useful than for VPN remote access.  Thus
   our design solves remote access scenarios and makes general IPsec
   transport mode or tunnel mode work through single and multiple NAT
   devices.

   3.   Scaling.  The solution specified our drafts will provide for
   scaling on the receiving end on the order which memory, CPU and
   hardware acceleration allow for RFC IPsec.  There is no inherent
   limitation in our design to scaling.  Overlapping SPD entries are
   addressed by the treatment of values contained in the main mode and
   aggressive mode ID payloads, and Proxy ID payloads.

   4.   Mode support.  Our design provides for both IKE Identity
   Protect Mode and Aggressive Mode to negotiate IPsec transport and
   tunnel mode UDP ESP encapsulation.  Our wire format and IKE design
   do specify a solution for AH encapsulation through NAT.  However,
   this capability is included only so the drafts as standards track
   documents offer a "complete solution".  Practically, we do not
   expect an implementation to support AH over NAT, preferring ESP null
   encryption with integrity, or an IPsec ESP tunnel mode for full
   packet encapsulation instead.

   5.   Interoperability.  Backward compatibility is assured through
   the continued use of UDP 500 with additional payloads to announce
   the capability of NAT discovery and traversal.  To the extent that
   existing implementations properly discard payloads they do not
   understand, an IPsec-over-NAT capable client will interoperate
   cleanly with an earlier IPsec/IKE client without the presence of
   NAT.

   6.   Security.  The security considerations section of [Kiv00]
   discusses specifically the security implications to IKE of including
   new payloads.  It was decided to leave these payloads
   unauthenticated in order to more expediently reach a solution for

Dixon, et. al.                                                       4
          IPsec over NAT Justification for UDP Encapsulation June 2001


   IPsec over NAT, rather than adopt new proposals for the
   authentication of all payloads in IKE phase 1 and phase 2 discussed
   by the now expired [Kiv-HASH-02].  Further, we specifically did not
   change anything about verifying the contents of a tunnel match the
   address selectors negotiated in the Proxy ID.  And we provide a NAT-
   OA original address payload so that the authenticated IPsec
   receiving peer may either reconstruct the original packet headers or
   take some other action based on knowledge of the original address
   for the purpose of anti-spoofing checks during packet processing.

   Additionally the following goals were set by the authors for an
   IPsec over NAT solution:
   1.   One IETF standardized way for IKE/IPsec NAT traversal.

   2.   Minimize the use of UDP encapsulation overhead
        a. Discover if NAT is present in the path between the two IKE
   peers, and discover which is behind the NAT.
        b. Allow for products to be configured to not perform UDP
   encapsulation when the user knows the presence of the NAT, itÆs
   IPsec-friendly capability. product works through IPsec-friendly
   NATs.

   3.   Transport IKE and IPsec traffic through the NAT without forcing
   the NATs to be modified.

   4.   Keep the NAT mappings (or state firewall mappings) alive for
   the duration of the IKE and IPsec sessions.

   5.   Keep IKE as simple as possible for ease of interop, better
   security.

   6.   Minimize keep-alive traffic to reduce the number of timers
   required.



. NAT Scenarios

   This section identifies common network topologies where NAT is used
   to pass traffic between address boundaries.  A NAT device may also
   be viewed as a stateful filtering device that performs no
   translation of the address or ports in the packet, but creates
   mapping states specific to the address and port information in a
   packet.

   All below scenarios may support an IPsec transport/tunnel SA for all
   possible traffic, where 1 or more TCP or UDP or other protocol
   sessions may be protected by the single IPsec transport/tunnel
   security association.  Security associations are assumed to exist in
   pairs.  There may be multiple transport/tunnel SAs of finer
   granularity as well.



Dixon, et. al.                                                       5
          IPsec over NAT Justification for UDP Encapsulation June 2001


   The term "private IP address" used here is not restricted to be the
   IANA defined private IP address space, but rather is exemplary of an
   address used within an address boundary defined by the NAT device.

   A.   One or more clients behind a NAT connecting simultaneously to a
   server's Internet IP address.

   C1 private IP <-> NAT Internet IP <---> Internet IP S1

   NAT is doing pure address translation 1:1, or doing many:1 address
   translation with port translation.


   B. One or more clients behind NAT1 connecting simultaneously to the
   same dest IP address which is behind NAT2

   C1 private IP <-> NAT1 Internet IP <-> Internet IP NAT2 <-> private
   IP S1


   NAT1 is performing many:1 port address translation (onto Internet
   for example), NAT2 is performing 1:1 address translation (into DMZ
   for example)

   C. One or more clients through 2 or more outbound NATs to
   destination Internet IP address

   C1 private IP <-> NAT1 private IP <-> NAT2 Internet IP <-> Internet
   IP S1

   NAT1, NAT2 are performing many:1 port address translation.

   D. Internet client connecting to server behind NAT.

   C1 Internet IP <-> Internet IP NAT1 <-> private IP S1

   NAT would most likely be doing 1:1 address translation, but may be
   publishing an address and port combination that is fully translated
   to an private address and different port.

   E. Multiple clients identically configured (i.e. C1 and C2 have the
   same private network IP address assigned to them, e.g. 192.168.0.2),
   each behind their own NAT, connected to same Internet IP of Server1.

   C1 private IP <-> NAT1 Internet IP <-> Internet IP S1
   C2 private IP <-> NAT2 Internet IP <-> Internet IP S1

   F. Gateway to gateway tunnel over NAT.

   C1 private IP <-> GW1 <=> NAT1 Internet IP <=> GW2 <-> private IP S1

   An IPsec tunnel SA is established between GW1 and GW2.  NAT1
   performs address translation on the tunnel packets.

Dixon, et. al.                                                       6
          IPsec over NAT Justification for UDP Encapsulation June 2001




. Design Overview and Rationale>

   The IETF standard for NAT traversal by IPsec should be unencumbered
   from intellectual property claims to ensure rapid adoption by the
   IPsec vendor community.

   We propose to UDP encapsulate the ESP traffic, thereby allowing it
   through the NAT.

   During design several different criteria needed to be balanced
   -    Encapsulation using UDP port 500 was chosen so as to enable
   easy deployment without the need to change firewall rules used by
   corporations.
   -    The chosen method UDP encapsulates ESP traffic as efficiently
   as possible.  AH and future protocols may be UDP encapsulated, but
   at greater expense. This ensures that the most widely needed traffic
   protection method is most efficient.
   -    Encapsulation using UDP port 500 makes each packet 8 bytes
   larger than encapsulation using a different port, this is however
   balanced by the reduced need to have keepalive packets, and reduced
   complexity in IKE.


7.0 UDP-encapsulated ESP Header Format

7.1 Not using TCP

   UDP header provided minimal standard encapsulation, 8 bytes, that
   would traverse exiting NATs.  TCP would incur a minimal 20byte
   header.

   NAT and firewall devices are aware of TCP connection setup traffic
   pattern.  Thus these devices expect to see a real TCP connection
   establish and operation, but to varying degrees.  It was a non-goal
   of this work to enable IPsec work through a TCP proxy.  Thus a TCP
   encapsulation would only be for the purpose of exposing a useless
   header for NAT traversal.

   We could run IKE over TCP or we could use IKE as it is and just use
   TCP for IPsec SA packet encapsulation.  A real TCP connection would
   degrade the reliability of communication which the security features
   of IPsec SAs and packet format provide.  For both IKE and IPsec, the
   traffic flow channel is not subject to disruption, except by packet
   loss or packet modification.  Using a real TCP connection to
   transport either IKE or IPsec would introduce vulnerability to
   trivial TCP connection reset attacks by spoofed TCP packets.  Thus
   logic would have to be implemented to constantly re-establish the
   TCP connection whenever it went down.  Which side would do this ?
   It would have to be the side that originally established the
   communication if stateful filtering were in place.  Therefore a real
   TCP connection would not be desired.  Rather a fake TCP handshake

Dixon, et. al.                                                       7
          IPsec over NAT Justification for UDP Encapsulation June 2001


   and then using a TCP header without sequence number tracking,
   ACKing, etc.  An additional weakening of the security properties of
   IKE would be introduced if TCP FIN or RST flags where used in
   combination with IKE SA delete messages.  Thus a keep-alive
   mechanism would need to be invented for this partial TCP
   functionality.

   There is some evidence to suggest that when IPsec transported a
   normal TCP connection over yet another full TCP connection, the two
   TCPs will interact with each other to slow down data transfer
   [Titz].

   Routers handle TCP so to ensure in order delivery of TCP segments.
   Most TCP implementations require nor more than 3-5 packets received
   out of order.  There is no such requirement for UDP, only the IPsec
   SA anti-replay window.

   It was the consensus of the authors that the complexity of faking
   TCP and the additional overhead of the TCP header made UDP the
   preferred choice for encapsulation.

7.2 Unifying Control and Data traffic on UDP 500

   A single UDP src, dst port mapping is used for both IKE and IPsec
   packets.  Since the IKE initiation is sent to the well known ISAKMP
   destination port 500, the receiver must use the UDP source port as
   the packet is received (inbound SA) to be the destination port of
   the return traffic (outbound SA).  The source port of the return
   traffic must be the destination port observed when the inbound SA
   packet was received.  This is to ensure that NAT port mappings are
   properly preserved.

   This draft uses the well-known IKE UDP port 500 to encapsulate both
   IKE control traffic and ESP data traffic.  This approach allows for:

   -    a single well known port over which ESP UDP encapsulation would
   be done.  The IKE port is already assigned, and well-known for IPsec
   so existing documentation and training wonÆt have to be changed.
   -    It is easiest to explain how to allow IPsec traffic, simply
   open UDP port 500
   -    A single approach allows firewall configurations to ship with
   defaults
   -    minimization of keep-alive/heartbeats for both IKE & ESP - as
   long as there was traffic flowing middle devices like stateful FWs &
   NATs would keep the mapping alive

. Alternatives To Unified Data & Control Considered

   In the following, "501" refers to a newly defined (eventually by
   IANA) well-known port for IKE.  Using "501" either for IKE and/or
   for the UDP encapsulation of the IPsec packets would allow us to
   change the header formats of IKE and potentially squeeze out more


Dixon, et. al.                                                       8
          IPsec over NAT Justification for UDP Encapsulation June 2001


   efficiency for the more common IPsec traffic.  For example, the
   format could be:

    [IP][UDP 1025, 501][IPsec ESP traffic]

    And

    [IP] [UDP 1025, 501][<4 bytes 0>][<4 byte TYPE>][IKE or ESP
   traffic.]

   In the second case, the <4 bytes 0> would line up with the ESP
   header's SPI, which would never be 0, therefore distinguishing the
   difference if both were encapsulated on 501.   This clearly has the
   benefit of being tighter on the wire for the more common ESP
   traffic.  The alternatives below will show why we discarded these
   (and similar) encapsulation schemes.


8.1 Using a non-500 dest port for "IPsec over NAT" negotiation traffic

   One desired benefit of using 501 was to completely isolate the
   IKE/IPsec over NAT from the standard IKE/IPsec implementation.  We
   would still keep IKE and ESP on the same port pair, and thus
   essentially defined a new well known port and protocol for it,
   preserving UDP 500 as "unpolluted" for RFC 2409 use only.  However,
   this does not meet [Aboba04] requirement of backward compatibility.
   Also, UDP 500 is already extended in many ways with special behavior
   indicated through the use of vendor-id payloads.

   The operational issue is how the initiator knows to use this UDP
   dest port 501 for the first packet when IKE initiates.  It could be
   configured if the initiator knows it is behind a NAT.  However this
   seems very impractical as NATs are generally invisible to the end
   system behind it and there would be no way to establish trust with
   the hotel NAT, the home NAT, the ISP NAT, etc.

   The deciding factor is that we only want to use the UDP
   encapsulation when necessary, that is when a NAT is discovered. So
   we conclude that NAT discovery must be part of the initial IKE
   negotiation for this technique to be widely deployable.

   The initiator could attempt 500 and then retry on 501 at the heavy
   expense of a timeout.  Or the initiator could send simultaneously to
   501 and to 500.  The 501 packet could include NAT discovery, while
   the 500 packet would not.  Either we receive no reply to the 500
   packet, or we do but also receive a reply from 501 indicating NAT.
   Clearly timing may introduce a mistake in the decision of which mode
   to use.  Better to avoid this complexity altogether and work within
   the standard IKE message exchange state machine.

   To know that 500 did not succeed because of a NAT, we'd need
   discovery packets in the port 500 usage negotiation.  To reply back
   to the initiator that NAT was discovered, the port 500 receiver

Dixon, et. al.                                                       9
          IPsec over NAT Justification for UDP Encapsulation June 2001


   would have to reply back to the as-received source port.  For some
   implementations of IKE, this is also a change.  So we saw several
   changes required in IKE using port 500 to enable usage of 501.  It
   was then clear that NAT discovery using port 500 was the way to go.
   A new NAT-traversal behavior would be engaged by first the
   capability message, and secondly by the actual discovery payloads.


8.2 Initial contact on 500, discovery, move IKE to well known port 501

   We could still move the negotiation off of 500 when NAT was
   discovered.  In the middle of the negotiation, it is possible for
   both peers to float to using 501 at the same time.  This would be
   for the eventual purpose of using the same src, dst 501 port pair
   (NAT mapping) for the IPsec SAs bound to the IKE exchange to
   aggregate keep-alives.  The initial outbound mapping for 500 would
   expire on the NAT, followed by a new mapping would be established by
   the completion of IKE and maintained by the IPsec SA packet flow.

   The main problem here is when and how to float.  This would have to
   be clearly defined with MUST statements to assure interoperability.
   Clearly, the easiest time to float would be at the end of Main Mode,
   but before Quick Mode started.  However, there is the design
   requirement that we allow for negotiation of encapsulation type in
   Quick Mode to support the case of allowing IPsec-friendly NATs to
   pass non-UDP encapsulated ESP traffic.  So, if we floated to 501
   before Quick Mode, we will do that unnecessarily in the IPsec-
   friendly NAT case.  If we delay floating to 501 until after both
   sides have agreed to do UDP encapsulation in the quick mode SA
   payload exchange, then we have timing conditions since there may be
   multiple quick modes going, and floating any one quick mode, floats
   the main mode under it, to the potential detriment of the other
   quick modes.

   Rekey introduces additional interop complexity.  Assume the float to
   501 by the above means happens at the end of main mode.  Assume the
   peer outside the NAT is rekeying the Main Mode.  Since IKE floated
   to 501, there are no keep alives keeping a UDP 500 hole open, so the
   peer will need to initiate the MM to 501 instead of 500.  Now we
   have to handle the case where the main mode starts on 501 as well.

   Finally, we consider the firewall configuration.  The case where
   neither side has initiated, but either side could, means the
   firewall configuration would have to allow inbound requests on both
   sides destined to 500 and to 501.  The authors didn't think this was
   a major reason, but one to mention as we have all experienced
   resistance to opening ports from customer firewall administrators.


8.3 Initial contact on 500, discovery, move IKE to dynamically
    chosen port



Dixon, et. al.                                                      10
          IPsec over NAT Justification for UDP Encapsulation June 2001


   In addition to all the complexities above, this approach makes
   static port filtering in effective.  Handling the idle (no active
   IPsec quick mode) and rekey cases make this the most difficult
   choice with which to achieve interoperability.  The typical scenario
   of double firewalls would pose the greatest difficulty, as IKE can
   initiate from either side.


8.4 Initial contact and maintain IKE on 500, use 501 for IPsec only

   The motivation for this approach is to avoid an 8 byte cookie=0x00
   as the demultiplexing value to separate ESP traffic from IKE traffic
   which is used when all traffic uses only port 500.

   This approach means that we must keep both the 500 and 501 NAT
   mappings alive. The only real problem with this approach is that is
   depends on the initiator of the negotiation to also be the initiator
   of the UDP src xxx, dst 501 packet in order to establish the NAT
   mapping.  This is not always the case.

   In scenario A, where the client initiated from behind the NAT to
   establish the NAT1 translation to UDP source 1025, dest 500, then
   sent another outbound UDP packet to 501, which the NAT would
   translate to UDP src 1026, dest 501 - this would work initially.
   Assume then that the client performs a long running download of
   data, causing the gateway to rekey quick mode first.  When the
   gateway, still using the UDP 1025, 500 mapping for IKE, completed
   the quick mode, it could not send to UDP destination 501 because the
   client's NAT does not have a mapping for this.  Instead, the gateway
   must continue to use UDP 1026, 501 for the UDP encapsulation of the
   new ESP SA.

   Now consider that the session goes idle - idle from the point of
   view of the IPsec SA being used to send protected packets.  The
   client is still sending keep alive packets to maintain the client
   mapping on the NAT.  But the gateway doesn't necessarily get these.
   So the gateway can delete the IPsec SA, as can the client.  Both may
   or may not make the decision to delete their inbound or outbound SA
   at any time.  The notify messages may or may not be sent and may or
   may not be honored by the receiver.  Perhaps an outbound packet
   arrives to the IPsec system which would use the already deleted
   IPsec SA.  The gateway rekeys to the client using quick mode on UDP
   1025, 500.  The gateway now must choose a UDP source port with dest
   501 for the UDP encapsulation of the new IPsec SA.  The client's NAT
   won't have a mapping for anything other than what the client used
   previously.  So the gateway MUST use the previous mapping, and the
   client MUST keep the mapping alive for deleted IPsec SAs.  The
   client is not the sender of the first ESP packet on the new quick
   mode.  This could be fixed by the client "punching out" with a keep-
   alive message, in anticipation of the incoming UDP ESP packet from
   the gateway destined for UDP 501 on the client.  But the complexity
   and timing conditions can be avoiding by always using the


Dixon, et. al.                                                      11
          IPsec over NAT Justification for UDP Encapsulation June 2001


   established IKE UDP mapping.  Interoperability is also better served
   by keeping the same mapping.

   Using both 501 and 500 doubles the keep-alives since both must be
   kept current on the NAT, which increases the state required for each
   IPsec SA. And again, using both 500 and 501 requires firewall
   administrators to open both for bidirectional communication.

. Addresses in IKE ID Payloads

9.1 IKE Main Mode ID Payload

   If a NAT is present, certain limitations are placed upon the valid
   IDs exchanges in IKE.  RFC 2408 and 2407 specify the ID payload to
   represent an identity of the initiator for the purpose of the
   responder using it for a policy lookup.  Section 4.6.2.1
   Identification Type Values allows many types.  However in practice,
   implementations choose one or a few type values to support in their
   policy system.  Backward compatibility is not a concern, as both
   initiator and responder must change to support this draft.  However,
   backward compatibility with policy configuration systems is desired.
   The authors think that the IKE Main Mode ID payload value is largely
   being ignored or is not relevant to security policy lookup in the
   majority of IKE implementations, based on interop test results.  We
   think this is because the receiver can not depend on an initiator
   (other than it's own implementation) using a particular type value.

   So [Kiv00] simply omits mention of the Main Mode ID payload, leaving
   it as a local matter.  If the ID payload is meaningful in the
   implementation as an IP address, then that implementation must
   decide how to handle the case where the initiator's IP address put
   into the ID payload is invalid to the receiver.  The receiver will
   know that NAT is present based on NAT discovery.


9.2 Addresses in IKE Quick Mode Proxy ID Payload

   There was no consensus among the draft authors about particular
   language, so [Kiv00] does not address this at all.  We note here
   that the IPsec packet processing comparison against the proxy id
   selector is a MUST via RFC 2401, 5.2.1 page 32, "In general, a
   packet's source address MUST match the SA selector value."

   This is most security critical in tunnel mode. But actually the
   tunnel mode proxy ID selectors would be the same as without NAT.  So
   it's not an issue in tunnel mode.  The tunnel mode Proxy ID using
   address selectors MUST remain a descriptor for the contents of the
   tunnel.

   In transport mode ESP through NAT - to be consistent on this RFC
   2401 MUST point, there are two ways to go:
   1. the IKE-NAT-T initiator MUST propose 0.0.0.0 as source IP in the
   Proxy ID quick mode selector

Dixon, et. al.                                                      12
          IPsec over NAT Justification for UDP Encapsulation June 2001


   2. the [Kiv00] responder MUST use the actual source IP of the packet
   to replace the source IP of the initiator's selector before doing
   responder policy lookup with that selector.

   #2 seems the best way to go to allow policy to be set for Internet
   source IPs (e.g. all traffic from DMZ Corp A would have source
   IP=xxx.xx.xx.xx when going outbound through their NAT - the selector
   at Corp B could be specific about traffic from Corp A.).


   We are open to comments on an [Kiv00] section 4.3, something like:

   "For transport quick mode, the proxy ID source IP address is sent by
   the initiator per RFC 2409.  However the [Kiv00] compliant responder
   MUST use the actual source IP of the packet to replace the source IP
   of the initiator's selector before doing responder policy lookup
   with that selector.  This is a MUST, not SHOULD, to be consistent
   with RFC 2401 section 5.2.1 which requires selector comparison after
   decryption."

   However, for transport mode, since the packet is authenticated by
   the successful processing of the hash, when the selector used in the
   Proxy ID was NOT an IP address, perhaps an FQDN, there is no meaning
   to the RFC 2401 MUST check of the packet against the selector.

   So we have omitted specifying the Proxy ID payload contents and
   handling, leaving the processing as a local matter.


. Keep-alive Mechanism

   The keep-alive packet is used to maintain a viable UDP path between
   IPsec peers.  It provides traffic flow in the absence of normal IKE
   or IPsec traffic so that NAT and stateful filtering mappings remain
   active.  The mechanism must work to maintain the mapping for the
   majority of existing NATs, without changing the NAT. The keep-alive
   packet is used strictly for path maintenance.  It has no security
   function and thus does not use the cryptographic context of either
   IKE or IPsec.  Thus a minimal UDP packet is sufficient for this
   purpose.  Since it is not known how far on the path between peers
   the NAT occurs, the packet is sent with normal TTL values, not 1 or
   2.  The keep-alive SHOULD only be sent by the peer(s) behind the NAT
   to minimize keep alive traffic.   The keep-alive SHOULD be silently
   discarded by the IPsec packet processor.

   An informal survey of NAT mapping timeouts showed a minimum of 30
   seconds as the time at which the mapping expired for UDP.
   There are IETF IPsec Working Group proposals on a keep-alive
   mechanism for IPsec or IKE peers, which uses the security context
   established between them.  However, that keep-alive mechanism may
   not reach consensus in the working group before the NAT traversal
   work.  That mechanism may be necessarily indistinguishable from
   normal IKE and IPsec traffic, and thus not filterable by the network

Dixon, et. al.                                                      13
          IPsec over NAT Justification for UDP Encapsulation June 2001


   to conserve bandwidth.  Also, that mechanism need not be frequent
   enough to maintain a UDP path, since its purpose is to reliably
   verify that a peer cryptographic context exists (e.g. An IPsec
   tunnel still exists).

. Security Considerations

   The authors do not think this method exposes any security
   vulnerabilities into otherwise sound IPsec implementation. However,
   the following issues need to be addressed by implementers.

   When using IPsec tunnel mode, clients connecting to the gateway may
   be using the same IP address in the inner IP header. One scenario
   where this is likely to happen is when the clients are using in the
   inner IP header their local private network address, and they are in
   different private networks. The GW MUST ensure that traffic destined
   towards the clients is sent only to the correct recipient.

   When using IPsec tunnel mode, a client connecting to a gateway may
   be trying to steal an IP address from the network protected by the
   gateway. The QM initiated by the client MUST only be allowed by the
   gateway if:
   -    The QM IP address identities match the static policy defined at
   the gateway.
   -    The QM IP source address matches the address assigned to the
   client by the gateway.
   -    The gateway is configured to do further NAT to the packets,
   ensuring that whatever IP address the client is using, this cannot
   be used to steal local network IP addresses.
   Any of these ensures that attacker is not possible to steal local
   network IP addresses.

   An active attacker can change the UDP header such that the UDP
   destination port will be different that 500 or 501.  This will cause
   a stream of IKE or ESP packets to be delivered to another port.  An
   application listening on that UDP port may get flooded with packets
   it can not understand.  Denial of service for that other UDP
   application may be accomplished.  Denial of service on the system
   may be accomplished if the processing of the bogus packets consumes
   CPU or crashes that service.

. Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed
   in regard to some or all of the specification contained in this
   document. For more information consult the online list of claimed
   rights.

   SSH Communications Security Corp has notified the working group of
   one or more patents or patent applications that may be relevant to
   this internet-draft. SSH Communications Security Corp has already
   given a license for those patents to the IETF. For more information
   consult the online list of claimed rights.

Dixon, et. al.                                                      14
          IPsec over NAT Justification for UDP Encapsulation June 2001



. References

     [Aboba04] Aboba, B. "IPsec-NAT Compatibility Requirements", draft-
   aboba-nat-ipsec-04.txt, 30 May 2001.

     [Hutt01] Huttunen, A. et. al., "UDP Encapsulation of IPsec
   Packets", draft-ietf-ipsec-udp-encaps-00.txt, April 2001.

     [Kiv00] Kivinen, T. et. al., "Negotiation of NAT-Traversal in the
   IKE", draft-ietf-ipsec-nat-t-ike-00.txt, May 2001.

     [Kiv-HASH-02] Kivinen, T., "Fixing IKE Phase 1 & 2 Authentication
   HASHs", draft-ietf-ipsec-ike-hash-revised-02.txt, 22 November 2000.

     [Patel12] Patel, B. "DHCPv4 Configuration of IPsec Tunnel Mode",
   draft-ietf-ipsec-dhcp-12.txt, 13 May 2001.

     [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange
   (IKE)", RFC 2409, November 1998.

     [RFC-2407] Piper D., "The Internet IP Security Domain Of
   Interpretation for ISAKMP", RFC 2407, November 1998.

     [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate
     Requirement Levels", RFC 2119, March 1997.

     [Titz] Titz, Olaf.  "Why TCP Over TCP Is A Bad Idea"
   http://sites.inka.de/sites/bigred/devel/tcp-tcp.html



. Acknowledgements

   The authors wish to acknowledge and thank Bernard Aboba, Cheryl
   Madson and Jonathan Trostle.


. Author's Addresses

         Tero Kivinen
         SSH Communications Security Corp
         Fredrikinkatu 42
         FIN-00100 HELSINKI
         Finland
         E-mail: kivinen@ssh.fi

         Markus Stenberg
         SSH Communications Security Corp
         Fredrikinkatu 42
         FIN-00100 HELSINKI
         Finland
         E-mail: mstenber@ssh.com

Dixon, et. al.                                                      15
          IPsec over NAT Justification for UDP Encapsulation June 2001



         Ari Huttunen
         F-Secure Corporation
         Tammasaarenkatu 7,
         FIN-00181 HELSINKI
         Finland
         E-mail: Ari.Huttunen@F-Secure.com

         William Dixon
         Microsoft
         One Microsoft Way
         Redmond WA 98052
         E-mail: wdixon@microsoft.com

         Brian Swander
         Microsoft
         One Microsoft Way
         Redmond WA 98052
         E-mail: briansw@microsoft.com

         Victor Volpe
         Cisco Systems
         124 Grove Street
         Suite 205
         Franklin, MA 02038
         E-mail: vvolpe@cisco.com

         Larry DiBurro
         Nortel Networks
         XXX address missing
         ldiburro@nortelnetworks.com























Dixon, et. al.                                                      16
          IPsec over NAT Justification for UDP Encapsulation June 2001



Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.

   This document and translations of it may be copied and
   furnished to others, and derivative works that comment on or
   otherwise explain it or assist in its implementation may be
   prepared, copied, published and distributed, in whole or in
   part, without restriction of any kind, provided that the above
   copyright notice and this paragraph are included on all such
   copies and derivative works.  However, this document itself may
   not be modified in any way, such as by removing the copyright
   notice or references to the Internet Society or other Internet
   organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or
   as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will
   not be revoked by the Internet Society or its successors or
   assigns.
































Dixon, et. al.                                                      17