Negotiation of NAT-Traversal in the IKE
RFC 3947

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

Network Working Group                                         T. Kivinen
Request for Comments: 3947                                       SafeNet
Category: Standards Track                                     B. Swander
                                                               Microsoft
                                                             A. Huttunen
                                                    F-Secure Corporation
                                                                V. Volpe
                                                           Cisco Systems
                                                            January 2005

                Negotiation of NAT-Traversal in the IKE

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes how to detect one or more network address
   translation devices (NATs) between IPsec hosts, and how to negotiate
   the use of UDP encapsulation of IPsec packets through NAT boxes in
   Internet Key Exchange (IKE).

Kivinen, et al.             Standards Track                     [Page 1]
RFC 3947        Negotiation of NAT-Traversal in the IKE     January 2005

Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Specification of Requirements . . . . . . . . . . . . . . . . . 3
   3.  Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
       3.1.  Detecting Support of NAT-Traversal. . . . . . . . . . . . 4
       3.2.  Detecting the Presence of NAT . . . . . . . . . . . . . . 4
   4.  Changing to New Ports . . . . . . . . . . . . . . . . . . . . . 6
   5.  Quick Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
       5.1.  Negotiation of the NAT-Traversal Encapsulation. . . . . . 9
       5.2.  Sending the Original Source and Destination Addresses . . 9
   6.  Initial Contact Notifications. . . . . . . . . . . . . . . . . 11
   7.  Recovering from the Expiring NAT Mappings. . . . . . . . . . . 11
   8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13
   10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 14
   11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 14
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
       12.1. Normative References . . . . . . . . . . . . . . . . . . 14
       12.2. Informative References . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16

1.  Introduction

   This document is split into two parts.  The first describes what is
   needed in IKE Phase 1 for NAT-Traversal support.  This includes
   detecting whether the other end supports NAT-Traversal, and detecting
   whether there is one or more NATs between the peers.

   The second part describes how to negotiate the use of UDP
   encapsulated IPsec packets in IKE's Quick Mode.  It also describes
   how to transmit the original source and destination addresses to the
   peer, if required.  These addresses are used in transport mode to
   update the TCP/IP checksums incrementally so that they will match
   after the NAT transform.  (The NAT cannot do this, because the TCP/IP
   checksum is inside the UDP encapsulated IPsec packet.)

   The document [RFC3948] describes the details of UDP encapsulation,
   and [RFC3715] provides background information and motivation of NAT-
   Traversal in general.  In combination with [RFC3948], this document
   represents an "unconditionally compliant" solution to the
   requirements as defined by [RFC3715].

   In the basic scenario for this document, the initiator is behind
   NA(P)T, and the responder has a fixed static IP address.

Kivinen, et al.             Standards Track                     [Page 2]
RFC 3947        Negotiation of NAT-Traversal in the IKE     January 2005

   This document defines a protocol that will work even if both ends are
   behind NAT, but the process of how to locate the other end is out of
   the scope of this document.  In one scenario, the responder is behind
   a static host NAT (only one responder per IP, as there is no way to
   use any destination ports other than 500/4500).  That is, it is known
   by the configuration.

2.  Specification of Requirements

   This document shall use the keywords "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY",
   and "OPTIONAL" to describe requirements.  They are to be interpreted