Negotiation of NAT-Traversal in the IKE
RFC 3947
|
| Document |
Type |
|
RFC - Proposed Standard
(January 2005; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3947 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Russ Housley
|
|
Send notices to |
|
(None)
|
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
Show full document text