[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                        M. Stenberg
Internet-Draft                                            S. Paavolainen
Expires: January 12, 2001                                      T. Ylonen
                                                              T. Kivinen
                                        SSH Communications Security Corp
                                                           July 14, 2000

                          IPsec NAT-Traversal

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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 12, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.


   IPsec architecture is based on the concept of keeping data secure
   while it is being transported across a network. Therefore there are
   problems when packet headers change while in transmit across the
   network, by virtue of NAT devices.

   This draft details the changes needed in order to make both initial
   IKE negotiation and subsequent authenticated/encrypted
   communications across IPsec AH/ESP SAs work despite the changes in
   the headers, and possible protocol transformations.

Stenberg, et. al.       Expires January 12, 2001                [Page 1]

Internet-Draft            IPsec NAT-Traversal                  July 2000

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Definitions  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Analysis . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.1   Assumptions  . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2   IPsec cases  . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2.1 Host-to-host . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.2.2 Host-to-network  . . . . . . . . . . . . . . . . . . . . . .  5
   2.2.3 Network-to-network . . . . . . . . . . . . . . . . . . . . .  5
   2.3   Issues stemming from NAT technology  . . . . . . . . . . . .  5
   2.4   Summary of issues  . . . . . . . . . . . . . . . . . . . . .  5
   3.    Solution . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1   IKE probe  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.1.1 Determining of support . . . . . . . . . . . . . . . . . . .  7
   3.1.2 NAT-Traversal need-probe . . . . . . . . . . . . . . . . . .  8
   3.2   IPsec SA traffic encapsulation . . . . . . . . . . . . . . .  8
   3.3   Heartbeat  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.3.1 Heartbeat format . . . . . . . . . . . . . . . . . . . . . . 11
   3.4   Built-in NAT . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.    Known issues with the solution . . . . . . . . . . . . . . . 13
   4.1   Conceptual issues  . . . . . . . . . . . . . . . . . . . . . 13
   4.2   Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.3   Security considerations  . . . . . . . . . . . . . . . . . . 14
   4.4   Intellectual property rights . . . . . . . . . . . . . . . . 14
         References . . . . . . . . . . . . . . . . . . . . . . . . . 15
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 16

Stenberg, et. al.       Expires January 12, 2001                [Page 2]

Internet-Draft            IPsec NAT-Traversal                  July 2000

1. Introduction

   NAT devices have proliferated recently. The eventual wider adoption
   of IPv6 will also cause great deal of NAT activity, as IPv4 is here
   to stay for the foreseeable future. Thus, there will be need for
   bridging between IPv4 and IPv6 networks, and as long as there are
   NATs around, basic IPsec as defined by RFC[1] will not work. It is
   quite important that there is a defined standard for handling IPsec
   traffic in networks with NAT devices. Preferably, a standard will
   evolve to fit all possible cases that may arise.

   In Section 2, most of the different IPsec+NAT permutations are
   analyzed and finally, a list of issues is presented. Section 3
   details the proposed solution to these issues. Finally, potential
   problems in the solution are noted in Section 4.

1.1 Definitions

   Following definitions will be used when discussing different types
   of NATs.

   o  Static NAT: A NAT device that (for the traffic under discussion)
      uses only a single static NAT translation.

   o  Dynamic NAT: A NAT device that (for the traffic under discussion)
      creates address mappings dynamically based on some configured
      static rules.

   o  Host NAT: A NAT that changes only the src/dst in packets.

   o  Host/port NAT: A NAT that changes src/dst and srcport/dstport in

   o  Protocol NAT: A NAT that changes the protocol of the packet; this
      usually involves a whole new header for the packet.

Stenberg, et. al.       Expires January 12, 2001                [Page 3]

Internet-Draft            IPsec NAT-Traversal                  July 2000

2. Analysis

2.1 Assumptions

   It can be safely assumed that IKE[2] works. IKE negotiations are
   handled with normal UDP traffic, and therefore it should work
   despite network address changes across the route. IP packet payloads
   are assumed to be left unmodified; changes to the UDP headers can
   occur, as long as nothing drops the packets before they reach the

   As normal IPsec traffic does not pass across host/port NATs (and may
   not pass across protocol NATs), a complete NAT-Traversal design
   should encapsulate IPsec SAs in UDP packets, which are (in most of
   the important respects) like IP packets, except that they can pass
   through all types of NATs.

2.2 IPsec cases

   Initially, most of the different IPsec+NAT combinations are listed
   here to make sure that all implications of NAT use are addressed.
   IPsec cases can be divided to three different categories (with
   possible NATs in various places along the route between hosts
   employing IPsec).

   o  Host-to-host (tunnel or transport mode)

   o  Host-to-network (tunnel mode)

   o  Network-to-network (tunnel mode)

   In all cases, the IKE responder must be, at best, only behind a
   series of static host NATs; dynamic NATs do not work, for obvious
   reasons (the IKE initiator cannot contact such an address), and
   host/port NATs do not work because IKE is defined to be

   The IKE initiator can be behind any kind of NAT, although in cases
   where initiation of traffic from both directions should be allowed
   (primarily VPN-like cases), the same restrictions that apply to the
   responder apply also to the initiator.

   ISSUE0: Both hosts need to know that there is a NAT in the middle,
   but currently IKE/IPsec do not provide such methodology (beyond the
   fact that all IPsec SA packets, if they even arrive, will be dropped
   as invalid).

   ISSUE1: It is obvious that programs residing on an IKE responder
   that is behind a host NAT cannot know about the existence of the

Stenberg, et. al.       Expires January 12, 2001                [Page 4]

Internet-Draft            IPsec NAT-Traversal                  July 2000

   host NAT, nor about the specific address mappings configured there.
   Thus, the IKE responder implementation should have advance knowledge
   about the address mappings.

2.2.1 Host-to-host

   Host-to-host traffic using tunnel or transport mode is the most
   basic case; it only becomes interesting if there is no shared
   address space between the parties (i.e., a VPN of sorts) and there
   are NATs in between.

   ISSUE2: If NATs are employed across the route, there may be
   addressing conflicts in tunnel mode (and there WILL be conflicts in
   transport mode). From the IKE responder point of view, the IKE
   initiators' addresses may conflict if they are in private networks
   (such as the IANA-assigned subnet).

2.2.2 Host-to-network

   Only tunnel mode is applicable for host-to-network communication,
   and the only apparent problem is the potential lack of shared
   address space (i.e., a host without an address in the remote network
   that it is accessing). Therefore, there is potential for ISSUE2-type
   of problems.

2.2.3 Network-to-network

   Only tunnel mode is applicable in network-to-network communication,
   and ISSUE2 is potentially a problem as well, although accounting for
   network-to-network non-unique address mappings may be obscure.

2.3 Issues stemming from NAT technology

   ISSUE3: The dynamic NATs may change their address mapping suddenly
   (or they may be rebooted), making the remote host concept unworkable
   even as a unique (host, port) pair.

2.4 Summary of issues

   There are basically four problems that need addressing:

   1.  detection of network address translation during IKE negotiation

   2.  a way of sending packets across the network so that NAT effects
       can be countered, yet the security of the system will not be
       affected (UDP encapsulation; assumption),

   3.  keeping NAT mapping static - NAT devices with dynamic host/port

Stenberg, et. al.       Expires January 12, 2001                [Page 5]

Internet-Draft            IPsec NAT-Traversal                  July 2000

       allocation configurations typically contain timeouts that will
       cause changes in addressing, if not circumvented by using a
       heartbeat to keep the specific mappings up (ISSUE3), and

   4.  the lack of unique IP addresses in the NAT world; it is possible
       for a server to have several clients with the same configured IP
       address, although they appear to the server to be from different
       hosts/ports (ISSUE2).

   ISSUE1 (host NAT case, where the IKE responder does not know what
   address to use) is trivial to solve, as seen in the end of Section

Stenberg, et. al.       Expires January 12, 2001                [Page 6]

Internet-Draft            IPsec NAT-Traversal                  July 2000

3. Solution

   The solution that resolves all the issues mentioned in Section 2.4
   can be divided into four different parts, which are detailed in this

   o  IKE probe to detect NAT presence,

   o  IPsec SA traffic encapsulation to counter NAT effects,

   o  NAT translation keepalive heartbeat which maintains NAT mappings,

   o  built-in NAT (if needed) to make addresses unique.

                    Incoming packet       Outgoing packet
                    /     |                     |     \
                   /      |                     |      \
          NAT-T decap.    |                     |   Un-NAT dst
               |          |                     |      |
             IPsec      IPsec                 IPsec  IPsec
               |                                       |
            NAT src                                NAT-T encap.

   Figure 1: IPsec processing with and without a NAT-Traversal process.

3.1 IKE probe

   There is a need for two different exchanges in the IKE Phase 1
   negotiation; initially, determining whether or not both sides
   support NAT-Traversal. Then, if both sides do support it, there
   should be a probe sequence that results in knowledge about whether
   or not the network between hosts contains a NAT device.

   As there is a need for two exchanges, of two messages each, it is
   obvious that NAT-Traversal cannot be supported in P1 modes with less
   than four messages sent across. Therefore, Aggressive Mode cannot be
   used with this NAT-Traversal approach.

   IKE Main Mode exchange contains 6 messages and therefore the probing
   sequence can be done within it.

3.1.1 Determining of support

   The NAT-Traversal capability of the remote host is determined by an
   exchange of vendor strings; in Main Mode's four first messages, the
   vendor id for this specification of NAT-Traversal
   ("draft-stenberg-ipsec-nat-traversal-00") MUST be sent if supported

Stenberg, et. al.       Expires January 12, 2001                [Page 7]

Internet-Draft            IPsec NAT-Traversal                  July 2000

   (and it MUST be received by remote side) for the NAT-Traversal probe
   to continue.

3.1.2 NAT-Traversal need-probe

   Once the NAT-Traversal support of both parties has been determined,
   in the last two encrypted messages of Main Mode, there are
   additional private payloads sent in both directions.

   Initially, in the 5th message of Main Mode, the initiator will add
   one private payload to the message. PAYLOAD_TYPE (from private
   range) is 211.

    The payload should contain the following:

     {perceived remote identity - IP address and port}
     {one or more local identities - local interface address+port numbers}

   Figure 2: Probe payload in Main Mode message #5

   The probe payload is encoded as a series of Identification Payloads
   of [3], with the perceived remote identity as the first payload, and
   the local identities as the following payloads.

   Once the IKE responder receives the payload represented in Figure 2,
   the remote should check whether or not the remote identity, as
   perceived by the IKE initiator, matches one of the locally
   configured interface addresses (with proper port number). Also, the
   remote identity as perceived by the IKE responder should match one
   of the address+port pairs sent in the packet.

   If one (or two) of those tests fails, the responder knows that
   NAT-Traversal is needed. The decision about whether to use
   NAT-Traversal or not is left up to the responder, and the responder
   transmits the decision as a private payload of type 211 in the last
   message of Main Mode.

   The payload is just one byte long, and contains 0 when NAT-Traversal
   is not elected to be used, and 1 when NAT-Traversal is chosen.

3.2 IPsec SA traffic encapsulation

   Automatic use of NAT-Traversal encapsulation for IKE-negotiated
   IPsec SAs MUST NOT be done. Instead, NAT-Traversal MUST be used only
   when IKE negotiation has resulted in a decision to use
   NAT-Traversal, or when manually keyed IPsec SAs are configured to
   use it.

   Traffic that is not in AH or ESP format MUST NOT be encapsulated

Stenberg, et. al.       Expires January 12, 2001                [Page 8]

Internet-Draft            IPsec NAT-Traversal                  July 2000

   using this scheme, as that provides a way to create DDoS attacks,
   and possibly some other security problems as well.

   Normal AH/ESP traffic does not pass through NATs unmodified;
   typically, the addresses may change (src/dst), and that makes the
   resulting AH/ESP packet unusable. Thus, there has to be enough
   redundant data to always be able to recreate a packet to its
   original form. Additionally, it should preferably follow the same
   NAT route as IKE packets, to make the implementation simpler.

   Therefore (as noted before), the traffic has to be encapsulated as
   UDP packets between two hosts (which implies that they follow same
   route even in host/port NATs) using the IKE port.  The basic idea
   behind this NAT-Traversal data encapsulation format is that it
   should be a format that can be adapted to future needs; therefore,
   the only requirement for this initial version is that it contains a
   version number, and it is invalid for IKE purposes.

    An IPsec NAT-Traversal envelope for IPv4 packet encapsulation looks
   like this:

     <IP HEADER:
       dst=perceived remote host>

     <UDP header:
       srcport=500 (IKE port),
       dstport=perceived remote port>

      1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
     | NAT-T version | IP4 hlen      | IP4 ToS       | IP4 protocol  |
     |            IP4 ID             |           IP4 frag_offset     |
     |                           IP4 src                             |
     |                           <unused>                            |
     | <unused>      | 0 (IKE ver.)  |

     <IP4 HEADER leftovers, if any>

   Figure 3: A NAT-Traversal envelope for an IPv4 IPsec packet.

   The variables with the IP4 prefix are the original values that are
   normally sent to the network as the header for the IPsec ESP data.

Stenberg, et. al.       Expires January 12, 2001                [Page 9]

Internet-Draft            IPsec NAT-Traversal                  July 2000

   The header leftovers, if any, are the difference between the new
   packet's IP4 header length and the original packet's IP4 header
   length. The IP4 dst is not stored, as the remote host should be able
   to know which address it is using to communicate with each host (in
   the host-to-host case, with the responder behind a host NAT, the
   only recourse is manual configuration data).

   The NAT-T version field specifies the encapsulation specified;
   defined types are as follows (and undefined types will be dropped

    Name                    | Value
    TYPE_HEARTBEAT          | 0x02

   The IPv4 encapsulation is defined in this section, and the heartbeat
   is specified in Section 3.3.

   Encapsulation occurs after IPsec processing, and it copies all
   variables as-is from the original packet. Decapsulation occurs
   before IPsec processing, and it copies values from the envelope to
   the real packet and discards the envelope. In some cases, it may
   involve changing of dst to be the host NAT address (if the remote
   side negotiated with the host NAT address, not the real configured
   address, and thus the host:spi pair is that of the host NAT

3.3 Heartbeat

   Disclaimer: the IKE SA heartbeat should probably be used whenever
   one becomes a standard. Until then, the NAT-Traversal will have its
   own heartbeat that is entirely separate from the IKE SA and is used
   between two hosts.

   The sole purpose of the heartbeat is to keep the NATs in the network
   route between hosts from removing the mapping from their dynamic
   configuration (if any). Therefore, the actual contents of the
   heartbeat can be more or less ignored (unless they stop arriving),
   and thus encrypting them would serve no useful purpose.

   Heartbeats MUST be sent as long as there is at least one IKE-probed
   IPsec SA in existence between two hosts that employ NAT-Traversal to
   communicate with each other.

   The IKE initiator MUST send a heartbeat packet every
   HEARTBEAT_INTERVAL (=10) seconds. The IKE responder SHOULD reply to
   it. There MUST NOT be replies to address+port pairs with no IPsec
   SAs up, or when there are too many heartbeat packets going on (i.e.,

Stenberg, et. al.       Expires January 12, 2001               [Page 10]

Internet-Draft            IPsec NAT-Traversal                  July 2000

   there should be one reply [at most] in HEARTBEAT_INTERVAL/2
   seconds). HEARTBEAT_INTERVAL MAY be higher, but as it is not
   negotiated, both sides must be configured for a higher
   HEARTBEAT_INTERVAL independently.

    The heartbeat sequence in practice works as follows, using the
   heartbeat format defined in Section 3.3.1:

   Initiator                     Responder
   -> Heartbeat (flag = FLAG_HEARTBEAT_PING)
   <- Heartbeat (flag = FLAG_HEARTBEAT_REPLY)

3.3.1 Heartbeat format

   The heartbeat packet format is very simple; it uses the same kind of
   pseudo-IKE encapsulation as the previously defined IP4 envelope, but
   with less fields in use.

      1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
     | NAT-T version | HB flag       |           <unused>            |
     |                           <unused>                            |
     |                           <unused>                            |
     |                           <unused>                            |
     | <unused>      | 0 (IKE ver.)  |

   Figure 5: Heartbeat format.

    Name                 | Value

   Other values SHOULD be silently ignored.

3.4 Built-in NAT

   Built-in host NAT implementation within the IPsec stack is necessary
   in some tunnel cases and all transport cases. To stay consistent
   with [2], which specifies that both tunnel and transport mode MUST
   be supported, we define that there MUST be a built-in host NAT
   implementation for NAT-Traversal use.

   The built-in NAT is needed in some cases where ISSUE2 surfaces (see

Stenberg, et. al.       Expires January 12, 2001               [Page 11]

Internet-Draft            IPsec NAT-Traversal                  July 2000

   Section 2.2 for details) to make the remote host(s) unique.
   Typically, the host mapping should be from (perceived_remote_host,
   perceived_remote_port) to some internal A- or B-class network.
   Whenever the remote side successfully initiates IPsec SA employing
   NAT-Traversal, there should be an internal NAT definition for the
   (remote_host, remote_port) if one is required according to the local
   configuration (or if transport mode is used, in which case internal
   host NAT SHOULD always be employed). Whenever IPsec processing for
   an incoming packet is done, the internal host NAT should be done to
   the src. Whenever an outgoing packet headed towards an internal NAT
   address enters the IPsec, the internal NAT address should be changed
   to the address that was used for negotiating the IPsec SA.

   In tunnel mode, it is possible that whole networks may need masking.
   In the NAT-Traversal+IPsec case, a separate NAT box would not be
   able to know about the (perceived_remote_host,
   perceived_remote_port) pair which provides uniqueness to the
   tunneled IP addresses. Therefore, there is a need for NAT within the
   IPsec implementation. This MAY be supported, but no details about
   implementation details  will be provided here.

Stenberg, et. al.       Expires January 12, 2001               [Page 12]

Internet-Draft            IPsec NAT-Traversal                  July 2000

4. Known issues with the solution

4.1 Conceptual issues

   Most of the solution is solid. An IPv6 and IPv4-IPv6
   interoperability specification will be added to the next draft

   However, the non-unique hosts may cause problems, as there is a
   potential problem of (host-port-proto-spi) not being unique any
   more. The problem does not surface in the incoming traffic, but it
   may occur in the outgoing case. There are (at least) a couple of
   different solutions to the problem:

   o  Tying the remote-host,remote-port of NAT-T IPsec SA decapsulation
      and the (host-port-proto-spi).

   o  Refusal of duplicate IPsec SA SPIs during IKE P2QM negotiation.

4.2 Overhead

   Overall, this solution is almost the most minimal one possible that
   covers most of the eventual possibilities and does not become overly
   complex. Different types of overhead caused by this draft are noted
   here, as well as possible ways of decreasing/removing the overheads
   involved. Processing time and memory overhead are ignored as
   negligible (some more processing for each packet, potentially
   logarithmic searches for free addresses, minimal extra data for each
   IPsec SA).

   o  IKE P1 negotiation extra payloads: Moderately small, typically
      less than 200 bytes. Does not appear to be reducible.

   o  Each IPv4-based IPsec SA packet will contain extra overhead of 8
      (UDP header) + 17 (NAT-T header) = 25 bytes. This might be
      lowered slightly by dropping the IKE version field. Additionally,
      more intelligent probing about what fields are changed across the
      route would decrease the overhead as well, although at the cost
      of increasing complexity. Some overhead is inevitable.

   o  Heartbeat overhead of 20 (IP header) + 8 (UDP header) + 17 (NAT-T
      header) = 45 bytes * 2 every HEARTBEAT_INTERVAL. 9 bytes/second
      may seem excessive, but as long as a general-purpose solution is
      desired, it cannot be bypassed unless the encapsulation changes
      from IKE-compliance (see previous entry). Heartbeat delay
      negotiation for slower-reaction dynamic NAT routes (and disabling
      when there are only static NATs) might be in order. This will be
      investigated further in future versions of this draft.

Stenberg, et. al.       Expires January 12, 2001               [Page 13]

Internet-Draft            IPsec NAT-Traversal                  July 2000

4.3 Security considerations

   Whenever changes to some fundamental parts of a security protocol
   are proposed, the examination of security implications cannot be
   skipped. Therefore, here are some observations regarding what is
   affected, and whether or not the effect matters. This section will
   be expanded further in future versions of this draft.

   o  IKE probe reveals NAT-Traversal support to everyone. This should
      be a non-issue.

   o  IPsec encapsulation which contains source address before NAT is a
      security leak of sorts, if internal network characteristics are
      desired to be kept hidden.

   o  Obviously, the value of authentication mechanisms based on IP
      addresses gets near zero once NATs are in the picture. That is
      not necessarily a bad thing; for any real security, other
      authentication measures than IP addresses should be used in any

   o  Some DoS implications exist; a single malicious user can possibly
      allocate up to (number-of-hosts-available) * 65535
      (=number-of-ports-on-host) internal host IP addresses at the same
      time - and cause that many negotiations as well (this is 65535
      times as much DoS potential as traditional IKE). As the IP
      addresses are allocated only after authentication is successful,
      the culprit is known, however, and therefore this can be
      considered a slight risk at best.

   o  The encapsulation scheme prevents some control of IP-level
      headers. Therefore, there is some potential for forging of some
      fields of the ESP transport mode IP header. Because the
      decapsulated destination+spi MUST remain unchanged, there are no
      apparent security risks, unless the remote end's IP-level
      handling has some exploitable bugs (and even then only in
      implementation approach B of Appendix A of [1]). AH+ESP should be
      employed if IP-level header integrity is desired, as usual.
      Therefore, this is a non-issue; although firewall administration
      loses some control over IP headers that are passed through, use
      of flawed IP protocol implementations is in itself a bad idea.

4.4 Intellectual property rights

   SSH Communications Security Corp has patent applications which may
   cover parts of this technology.  If this technology starts to
   progress on the IETF standards track, SSH is willing to seek a
   licensing solution that allows widespread use of this technology.

Stenberg, et. al.       Expires January 12, 2001               [Page 14]

Internet-Draft            IPsec NAT-Traversal                  July 2000


   [1]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

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

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

Authors' Addresses

   Markus Stenberg
   SSH Communications Security Corp
   Fredrikinkatu 42
   FIN-00100 Helsinki

   EMail: mstenber@ssh.com

   Santeri Paavolainen
   SSH Communications Security Corp
   Fredrikinkatu 42
   FIN-00100 Helsinki

   EMail: santtu@ssh.com

   Tatu Ylonen
   SSH Communications Security Corp
   Fredrikinkatu 42
   FIN-00100 Helsinki

   EMail: ylo@ssh.com

   Tero Kivinen
   SSH Communications Security Corp
   Fredrikinkatu 42
   FIN-00100 Helsinki

   EMail: kivinen@ssh.com

Stenberg, et. al.       Expires January 12, 2001               [Page 15]

Internet-Draft            IPsec NAT-Traversal                  July 2000

Full Copyright Statement

   Copyright (C) The Internet Society (2000). 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

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

   This document and the information contained herein is provided on an


   Funding for the RFC editor function is currently provided by the
   Internet Society.

Stenberg, et. al.       Expires January 12, 2001               [Page 16]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/