UDP Encapsulation of IPsec ESP Packets
RFC 3948

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

• Versions
• 09

Network Working Group                                        A. Huttunen
Request for Comments: 3948                          F-Secure Corporation
Category: Standards Track                                     B. Swander
                                                               Microsoft
                                                                V. Volpe
                                                           Cisco Systems
                                                              L. DiBurro
                                                         Nortel Networks
                                                             M. Stenberg
                                                            January 2005

                 UDP Encapsulation of IPsec ESP Packets

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 protocol specification defines methods to encapsulate and
   decapsulate IP Encapsulating Security Payload (ESP) packets inside
   UDP packets for traversing Network Address Translators.  ESP
   encapsulation, as defined in this document, can be used in both IPv4
   and IPv6 scenarios.  Whenever negotiated, encapsulation is used with
   Internet Key Exchange (IKE).

Huttunen, et al.            Standards Track                     [Page 1]
RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  3
       2.1.  UDP-Encapsulated ESP Header Format . . . . . . . . . . .  3
       2.2.  IKE Header Format for Port 4500  . . . . . . . . . . . .  4
       2.3.  NAT-Keepalive Packet Format  . . . . . . . . . . . . . .  4
   3.  Encapsulation and Decapsulation Procedures . . . . . . . . . .  5
       3.1.  Auxiliary Procedures . . . . . . . . . . . . . . . . . .  5
             3.1.1.  Tunnel Mode Decapsulation NAT Procedure  . . . .  5
             3.1.2.  Transport Mode Decapsulation NAT Procedure . . .  5
       3.2.  Transport Mode ESP Encapsulation . . . . . . . . . . . .  6
       3.3.  Transport Mode ESP Decapsulation . . . . . . . . . . . .  6
       3.4.  Tunnel Mode ESP Encapsulation  . . . . . . . . . . . . .  7
       3.5.  Tunnel Mode ESP Decapsulation  . . . . . . . . . . . . .  7
   4.  NAT Keepalive Procedure  . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
       5.1.  Tunnel Mode Conflict . . . . . . . . . . . . . . . . . .  8
       5.2.  Transport Mode Conflict  . . . . . . . . . . . . . . . .  9
   6.  IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       8.1.  Normative References . . . . . . . . . . . . . . . . . . 11
       8.2.  Informative References . . . . . . . . . . . . . . . . . 11
   A.  Clarification of Potential NAT Multiple Client Solutions . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15

1.  Introduction

   This protocol specification defines methods to encapsulate and
   decapsulate ESP packets inside UDP packets for traversing Network
   Address Translators (NATs) (see [RFC3715], section 2.2, case i).  The
   UDP port numbers are the same as those used by IKE traffic, as
   defined in [RFC3947].

   The sharing of the port numbers for both IKE and UDP encapsulated ESP
   traffic was selected because it offers better scaling (only one NAT
   mapping in the NAT; no need to send separate IKE keepalives), easier
   configuration (only one port to be configured in firewalls), and
   easier implementation.

   A client's needs should determine whether transport mode or tunnel
   mode is to be supported (see [RFC3715], Section 3, "Telecommuter
   scenario").  L2TP/IPsec clients MUST support the modes as defined in
   [RFC3193].  IPsec tunnel mode clients MUST support tunnel mode.

Huttunen, et al.            Standards Track                     [Page 2]
RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005

   An IKE implementation supporting this protocol specification MUST NOT
   use the ESP SPI field zero for ESP packets.  This ensures that IKE
   packets and ESP packets can be distinguished from each other.

   As defined in this document, UDP encapsulation of ESP packets is
   written in terms of IPv4 headers.  There is no technical reason why