crypto/dist/ipsec-tools/src/racoon/rfc/rfc3948.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        A. Huttunen
   8 Request for Comments: 3948                          F-Secure Corporation
   9 Category: Standards Track                                     B. Swander
  10                                                                Microsoft
  11                                                                 V. Volpe
  12                                                            Cisco Systems
  13                                                               L. DiBurro
  14                                                          Nortel Networks
  15                                                              M. Stenberg
  16                                                             January 2005
  17
  18
  19                  UDP Encapsulation of IPsec ESP Packets
  20
  21 Status of this Memo
  22
  23    This document specifies an Internet standards track protocol for the
  24    Internet community, and requests discussion and suggestions for
  25    improvements.  Please refer to the current edition of the "Internet
  26    Official Protocol Standards" (STD 1) for the standardization state
  27    and status of this protocol.  Distribution of this memo is unlimited.
  28
  29 Copyright Notice
  30
  31    Copyright (C) The Internet Society (2005).
  32
  33 Abstract
  34
  35    This protocol specification defines methods to encapsulate and
  36    decapsulate IP Encapsulating Security Payload (ESP) packets inside
  37    UDP packets for traversing Network Address Translators.  ESP
  38    encapsulation, as defined in this document, can be used in both IPv4
  39    and IPv6 scenarios.  Whenever negotiated, encapsulation is used with
  40    Internet Key Exchange (IKE).
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Huttunen, et al.            Standards Track                     [Page 1]
  59 \f
  60 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
  61
  62
  63 Table of Contents
  64
  65    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  66    2.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  3
  67        2.1.  UDP-Encapsulated ESP Header Format . . . . . . . . . . .  3
  68        2.2.  IKE Header Format for Port 4500  . . . . . . . . . . . .  4
  69        2.3.  NAT-Keepalive Packet Format  . . . . . . . . . . . . . .  4
  70    3.  Encapsulation and Decapsulation Procedures . . . . . . . . . .  5
  71        3.1.  Auxiliary Procedures . . . . . . . . . . . . . . . . . .  5
  72              3.1.1.  Tunnel Mode Decapsulation NAT Procedure  . . . .  5
  73              3.1.2.  Transport Mode Decapsulation NAT Procedure . . .  5
  74        3.2.  Transport Mode ESP Encapsulation . . . . . . . . . . . .  6
  75        3.3.  Transport Mode ESP Decapsulation . . . . . . . . . . . .  6
  76        3.4.  Tunnel Mode ESP Encapsulation  . . . . . . . . . . . . .  7
  77        3.5.  Tunnel Mode ESP Decapsulation  . . . . . . . . . . . . .  7
  78    4.  NAT Keepalive Procedure  . . . . . . . . . . . . . . . . . . .  7
  79    5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
  80        5.1.  Tunnel Mode Conflict . . . . . . . . . . . . . . . . . .  8
  81        5.2.  Transport Mode Conflict  . . . . . . . . . . . . . . . .  9
  82    6.  IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 10
  83    7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
  84    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  85        8.1.  Normative References . . . . . . . . . . . . . . . . . . 11
  86        8.2.  Informative References . . . . . . . . . . . . . . . . . 11
  87    A.  Clarification of Potential NAT Multiple Client Solutions . . . 12
  88        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
  89        Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
  90
  91 1.  Introduction
  92
  93    This protocol specification defines methods to encapsulate and
  94    decapsulate ESP packets inside UDP packets for traversing Network
  95    Address Translators (NATs) (see [RFC3715], section 2.2, case i).  The
  96    UDP port numbers are the same as those used by IKE traffic, as
  97    defined in [RFC3947].
  98
  99    The sharing of the port numbers for both IKE and UDP encapsulated ESP
 100    traffic was selected because it offers better scaling (only one NAT
 101    mapping in the NAT; no need to send separate IKE keepalives), easier
 102    configuration (only one port to be configured in firewalls), and
 103    easier implementation.
 104
 105    A client's needs should determine whether transport mode or tunnel
 106    mode is to be supported (see [RFC3715], Section 3, "Telecommuter
 107    scenario").  L2TP/IPsec clients MUST support the modes as defined in
 108    [RFC3193].  IPsec tunnel mode clients MUST support tunnel mode.
 109
 110
 111
 112
 113
 114 Huttunen, et al.            Standards Track                     [Page 2]
 115 \f
 116 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 117
 118
 119    An IKE implementation supporting this protocol specification MUST NOT
 120    use the ESP SPI field zero for ESP packets.  This ensures that IKE
 121    packets and ESP packets can be distinguished from each other.
 122
 123    As defined in this document, UDP encapsulation of ESP packets is
 124    written in terms of IPv4 headers.  There is no technical reason why
 125    an IPv6 header could not be used as the outer header and/or as the
 126    inner header.
 127
 128    Because the protection of the outer IP addresses in IPsec AH is
 129    inherently incompatible with NAT, the IPsec AH was left out of the
 130    scope of this protocol specification.  This protocol also assumes
 131    that IKE (IKEv1 [RFC2401] or IKEv2 [IKEv2]) is used to negotiate the
 132    IPsec SAs.  Manual keying is not supported.
 133
 134    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 135    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 136    document are to be interpreted as described in [RFC2119].
 137
 138 2.  Packet Formats
 139
 140 2.1.  UDP-Encapsulated ESP Header Format
 141
 142     0                   1                   2                   3
 143     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 144    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 145    |        Source Port            |      Destination Port         |
 146    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 147    |           Length              |           Checksum            |
 148    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 149    |                      ESP header [RFC2406]                     |
 150    ~                                                               ~
 151    |                                                               |
 152    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 153
 154    The UDP header is a standard [RFC0768] header, where
 155
 156    o  the Source Port and Destination Port MUST be the same as that used
 157       by IKE traffic,
 158    o  the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
 159    o  receivers MUST NOT depend on the UDP checksum being a zero value.
 160
 161    The SPI field in the ESP header MUST NOT be a zero value.
 162
 163
 164
 165
 166
 167
 168
 169
 170 Huttunen, et al.            Standards Track                     [Page 3]
 171 \f
 172 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 173
 174
 175 2.2.  IKE Header Format for Port 4500
 176
 177     0                   1                   2                   3
 178     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 179    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 180    |        Source Port            |      Destination Port         |
 181    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 182    |           Length              |           Checksum            |
 183    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 184    |                       Non-ESP Marker                          |
 185    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 186    |                      IKE header [RFC2409]                     |
 187    ~                                                               ~
 188    |                                                               |
 189    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 190
 191    The UDP header is a standard [RFC0768] header and is used as defined
 192    in [RFC3947].  This document does not set any new requirements for
 193    the checksum handling of an IKE packet.
 194
 195    A Non-ESP Marker is 4 zero-valued bytes aligning with the SPI field
 196    of an ESP packet.
 197
 198 2.3.  NAT-Keepalive Packet Format
 199
 200     0                   1                   2                   3
 201     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 202    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 203    |        Source Port            |      Destination Port         |
 204    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 205    |           Length              |           Checksum            |
 206    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 207    |    0xFF       |
 208    +-+-+-+-+-+-+-+-+
 209
 210    The UDP header is a standard [RFC0768] header, where
 211
 212    o  the Source Port and Destination Port MUST be the same as used by
 213       UDP-ESP encapsulation of Section 2.1,
 214    o  the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
 215    o  receivers MUST NOT depend upon the UDP checksum being a zero
 216       value.
 217
 218    The sender MUST use a one-octet-long payload with the value 0xFF.
 219    The receiver SHOULD ignore a received NAT-keepalive packet.
 220
 221
 222
 223
 224
 225
 226 Huttunen, et al.            Standards Track                     [Page 4]
 227 \f
 228 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 229
 230
 231 3.  Encapsulation and Decapsulation Procedures
 232
 233 3.1.  Auxiliary Procedures
 234
 235 3.1.1.  Tunnel Mode Decapsulation NAT Procedure
 236
 237    When a tunnel mode has been used to transmit packets (see [RFC3715],
 238    section 3, criteria "Mode support" and "Telecommuter scenario"), the
 239    inner IP header can contain addresses that are not suitable for the
 240    current network.  This procedure defines how these addresses are to
 241    be converted to suitable addresses for the current network.
 242
 243    Depending on local policy, one of the following MUST be done:
 244
 245    1.  If a valid source IP address space has been defined in the policy
 246        for the encapsulated packets from the peer, check that the source
 247        IP address of the inner packet is valid according to the policy.
 248    2.  If an address has been assigned for the remote peer, check that
 249        the source IP address used in the inner packet is the assigned IP
 250        address.
 251    3.  NAT is performed for the packet, making it suitable for transport
 252        in the local network.
 253
 254 3.1.2.  Transport Mode Decapsulation NAT Procedure
 255
 256    When a transport mode has been used to transmit packets, contained
 257    TCP or UDP headers will have incorrect checksums due to the change of
 258    parts of the IP header during transit.  This procedure defines how to
 259    fix these checksums (see [RFC3715], section 2.1, case b).
 260
 261    Depending on local policy, one of the following MUST be done:
 262
 263    1.  If the protocol header after the ESP header is a TCP/UDP header
 264        and the peer's real source and destination IP address have been
 265        received according to [RFC3947], incrementally recompute the
 266        TCP/UDP checksum:
 267
 268        *  Subtract the IP source address in the received packet from the
 269           checksum.
 270        *  Add the real IP source address received via IKE to the
 271           checksum (obtained from the NAT-OA)
 272        *  Subtract the IP destination address in the received packet
 273           from the checksum.
 274        *  Add the real IP destination address received via IKE to the
 275           checksum (obtained from the NAT-OA).
 276        Note: If the received and real address are the same for a given
 277        address (e.g., say the source address), the operations cancel and
 278        don't need to be performed.
 279
 280
 281
 282 Huttunen, et al.            Standards Track                     [Page 5]
 283 \f
 284 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 285
 286
 287    2.  If the protocol header after the ESP header is a TCP/UDP header,
 288        recompute the checksum field in the TCP/UDP header.
 289
 290    3.  If the protocol header after the ESP header is a UDP header, set
 291        the checksum field to zero in the UDP header.  If the protocol
 292        after the ESP header is a TCP header, and if there is an option
 293        to flag to the stack that the TCP checksum does not need to be
 294        computed, then that flag MAY be used.  This SHOULD only be done
 295        for transport mode, and if the packet is integrity protected.
 296        Tunnel mode TCP checksums MUST be verified.  (This is not a
 297        violation to the spirit of section 4.2.2.7 in [RFC1122] because a
 298        checksum is being generated by the sender and verified by the
 299        receiver.  That checksum is the integrity over the packet
 300        performed by IPsec.)
 301
 302    In addition an implementation MAY fix any contained protocols that
 303    have been broken by NAT (see [RFC3715], section 2.1, case g).
 304
 305 3.2.  Transport Mode ESP Encapsulation
 306
 307                  BEFORE APPLYING ESP/UDP
 308             ----------------------------
 309       IPv4  |orig IP hdr  |     |      |
 310             |(any options)| TCP | Data |
 311             ----------------------------
 312
 313                  AFTER APPLYING ESP/UDP
 314             -------------------------------------------------------
 315       IPv4  |orig IP hdr  | UDP | ESP |     |      |   ESP   | ESP|
 316             |(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
 317             -------------------------------------------------------
 318                                       |<----- encrypted ---->|
 319                                 |<------ authenticated ----->|
 320
 321    1.  Ordinary ESP encapsulation procedure is used.
 322    2.  A properly formatted UDP header is inserted where shown.
 323    3.  The Total Length, Protocol, and Header Checksum (for IPv4) fields
 324        in the IP header are edited to match the resulting IP packet.
 325
 326 3.3.  Transport Mode ESP Decapsulation
 327
 328    1.  The UDP header is removed from the packet.
 329    2.  The Total Length, Protocol, and Header Checksum (for IPv4) fields
 330        in the new IP header are edited to match the resulting IP packet.
 331    3.  Ordinary ESP decapsulation procedure is used.
 332    4.  Transport mode decapsulation NAT procedure is used.
 333
 334
 335
 336
 337
 338 Huttunen, et al.            Standards Track                     [Page 6]
 339 \f
 340 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 341
 342
 343 3.4.  Tunnel Mode ESP Encapsulation
 344
 345                  BEFORE APPLYING ESP/UDP
 346             ----------------------------
 347       IPv4  |orig IP hdr  |     |      |
 348             |(any options)| TCP | Data |
 349             ----------------------------
 350
 351                  AFTER APPLYING ESP/UDP
 352         --------------------------------------------------------------
 353    IPv4 |new h.| UDP | ESP |orig IP hdr  |     |      |   ESP   | ESP|
 354         |(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
 355         --------------------------------------------------------------
 356                            |<------------ encrypted ----------->|
 357                      |<------------- authenticated ------------>|
 358
 359    1.  Ordinary ESP encapsulation procedure is used.
 360    2.  A properly formatted UDP header is inserted where shown.
 361    3.  The Total Length, Protocol, and Header Checksum (for IPv4) fields
 362    in the new IP header are edited to match the resulting IP packet.
 363
 364 3.5.  Tunnel Mode ESP Decapsulation
 365
 366    1.  The UDP header is removed from the packet.
 367    2.  The Total Length, Protocol, and Header Checksum (for IPv4) fields
 368        in the new IP header are edited to match the resulting IP packet.
 369    3.  Ordinary ESP decapsulation procedure is used.
 370    4.  Tunnel mode decapsulation NAT procedure is used.
 371
 372 4.  NAT Keepalive Procedure
 373
 374    The sole purpose of sending NAT-keepalive packets is to keep NAT
 375    mappings alive for the duration of a connection between the peers
 376    (see [RFC3715], Section 2.2, case j).  Reception of NAT-keepalive
 377    packets MUST NOT be used to detect whether a connection is live.
 378
 379    A peer MAY send a NAT-keepalive packet if one or more phase I or
 380    phase II SAs exist between the peers, or if such an SA has existed at
 381    most N minutes earlier.  N is a locally configurable parameter with a
 382    default value of 5 minutes.
 383
 384    A peer SHOULD send a NAT-keepalive packet if a need for it is
 385    detected according to [RFC3947] and if no other packet to the peer
 386    has been sent in M seconds.  M is a locally configurable parameter
 387    with a default value of 20 seconds.
 388
 389
 390
 391
 392
 393
 394 Huttunen, et al.            Standards Track                     [Page 7]
 395 \f
 396 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 397
 398
 399 5.  Security Considerations
 400
 401 5.1.  Tunnel Mode Conflict
 402
 403    Implementors are warned that it is possible for remote peers to
 404    negotiate entries that overlap in an SGW (security gateway), an issue
 405    affecting tunnel mode (see [RFC3715], section 2.1, case e).
 406
 407              +----+            \ /
 408              |    |-------------|----\
 409              +----+            / \    \
 410              Ari's           NAT 1     \
 411              Laptop                     \
 412             10.1.2.3                     \
 413              +----+            \ /        \       +----+          +----+
 414              |    |-------------|----------+------|    |----------|    |
 415              +----+            / \                +----+          +----+
 416              Bob's           NAT 2                  SGW           Suzy's
 417              Laptop                                               Server
 418             10.1.2.3
 419
 420    Because SGW will now see two possible SAs that lead to 10.1.2.3, it
 421    can become confused about where to send packets coming from Suzy's
 422    server.  Implementors MUST devise ways of preventing this from
 423    occurring.
 424
 425    It is RECOMMENDED that SGW either assign locally unique IP addresses
 426    to Ari's and Bob's laptop (by using a protocol such as DHCP over
 427    IPsec) or use NAT to change Ari's and Bob's laptop source IP
 428    addresses to these locally unique addresses before sending packets
 429    forward to Suzy's server.  This covers the "Scaling" criteria of
 430    section 3 in [RFC3715].
 431
 432    Please see Appendix A.
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Huttunen, et al.            Standards Track                     [Page 8]
 451 \f
 452 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 453
 454
 455 5.2.  Transport Mode Conflict
 456
 457    Another similar issue may occur in transport mode, with 2 clients,
 458    Ari and Bob, behind the same NAT talking securely to the same server
 459    (see [RFC3715], Section 2.1, case e).
 460
 461    Cliff wants to talk in the clear to the same server.
 462
 463              +----+
 464              |    |
 465              +----+ \
 466              Ari's   \
 467              Laptop   \
 468             10.1.2.3   \
 469              +----+    \ /                +----+
 470              |    |-----+-----------------|    |
 471              +----+    / \                +----+
 472              Bob's     NAT                Server
 473              Laptop   /
 474             10.1.2.4 /
 475                     /
 476             +----+ /
 477             |    |/
 478             +----+
 479             Cliff's
 480             Laptop
 481            10.1.2.5
 482
 483    Now, transport SAs on the server will look like this:
 484
 485    To Ari: Server to NAT, <traffic desc1>, UDP encap <4500, Y>
 486
 487    To Bob: Server to NAT, <traffic desc2>, UDP encap <4500, Z>
 488
 489    Cliff's traffic is in the clear, so there is no SA.
 490
 491    <traffic desc> is the protocol and port information.  The UDP encap
 492    ports are the ports used in UDP-encapsulated ESP format of section
 493    2.1.  Y,Z are the dynamic ports assigned by the NAT during the IKE
 494    negotiation.  So IKE traffic from Ari's laptop goes out on UDP
 495    <4500,4500>.  It reaches the server as UDP <Y,4500>, where Y is the
 496    dynamically assigned port.
 497
 498    If the <traffic desc1> overlaps <traffic desc2>, then simple filter
 499    lookups may not be sufficient to determine which SA has to be used to
 500    send traffic.  Implementations MUST handle this situation, either by
 501    disallowing conflicting connections, or by other means.
 502
 503
 504
 505
 506 Huttunen, et al.            Standards Track                     [Page 9]
 507 \f
 508 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 509
 510
 511    Assume now that Cliff wants to connect to the server in the clear.
 512    This is going to be difficult to configure, as the server already has
 513    a policy (from Server to the NAT's external address) for securing
 514    <traffic desc>.  For totally non-overlapping traffic descriptions,
 515    this is possible.
 516
 517    Sample server policy could be as follows:
 518
 519    To Ari: Server to NAT, All UDP, secure
 520
 521    To Bob: Server to NAT, All TCP, secure
 522
 523    To Cliff: Server to NAT, ALL ICMP, clear text
 524
 525    Note that this policy also lets Ari and Bob send cleartext ICMP to
 526    the server.
 527
 528    The server sees all clients behind the NAT as the same IP address, so
 529    setting up different policies for the same traffic descriptor is in
 530    principle impossible.
 531
 532    A problematic example of configuration on the server is as follows:
 533
 534    Server to NAT, TCP, secure (for Ari and Bob)
 535
 536    Server to NAT, TCP, clear (for Cliff)
 537
 538    The server cannot enforce his policy, as it is possible that
 539    misbehaving Bob sends traffic in the clear.  This is
 540    indistinguishable from when Cliff sends traffic in the clear.  So it
 541    is impossible to guarantee security from some clients behind a NAT,
 542    while allowing clear text from different clients behind the SAME NAT.
 543    If the server's security policy allows this, however, it can do
 544    best-effort security: If the client from behind the NAT initiates
 545    security, his connection will be secured.  If he sends in the clear,
 546    the server will still accept that clear text.
 547
 548    For security guarantees, the above problematic scenario MUST NOT be
 549    allowed on servers.  For best effort security, this scenario MAY be
 550    used.
 551
 552    Please see Appendix A.
 553
 554 6.  IAB Considerations
 555
 556    The UNSAF [RFC3424] questions are addressed by the IPsec-NAT
 557    compatibility requirements document [RFC3715].
 558
 559
 560
 561
 562 Huttunen, et al.            Standards Track                    [Page 10]
 563 \f
 564 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 565
 566
 567 7.  Acknowledgments
 568
 569    Thanks to Tero Kivinen and William Dixon, who contributed actively to
 570    this document.
 571
 572    Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen, and Santeri
 573    Paavolainen, who contributed to the early documents about NAT
 574    traversal.
 575
 576 8.  References
 577
 578 8.1.  Normative References
 579
 580    [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
 581               August 1980.
 582
 583    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 584               Requirement Levels", BCP 14, RFC 2119, March 1997.
 585
 586    [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
 587               Internet Protocol", RFC 2401, November 1998.
 588
 589    [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
 590               Payload (ESP)", RFC 2406, November 1998.
 591
 592    [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
 593               (IKE)", RFC 2409, November 1998.
 594
 595    [RFC3947]  Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
 596               RFC 3947, January 2005.
 597
 598 8.2.  Informative References
 599
 600    [RFC1122]  Braden, R., "Requirements for Internet Hosts -
 601               Communication Layers", STD 3, RFC 1122, October 1989.
 602
 603    [RFC3193]  Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
 604               "Securing L2TP using IPsec", RFC 3193, November 2001.
 605
 606    [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
 607               Self-Address Fixing (UNSAF) Across Network Address
 608               Translation", RFC 3424, November 2002.
 609
 610    [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
 611               (NAT) Compatibility Requirements", RFC 3715, March 2004.
 612
 613    [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
 614               Work in Progress, October 2004.
 615
 616
 617
 618 Huttunen, et al.            Standards Track                    [Page 11]
 619 \f
 620 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 621
 622
 623 Appendix A.  Clarification of Potential NAT Multiple Client Solutions
 624
 625    This appendix provides clarification about potential solutions to the
 626    problem of multiple clients behind the same NAT simultaneously
 627    connecting to the same destination IP address.
 628
 629    Sections 5.1 and 5.2 say that you MUST avoid this problem.  As this
 630    is not a matter of wire protocol, but a matter local implementation,
 631    the mechanisms do not belong in the protocol specification itself.
 632    They are instead listed in this appendix.
 633
 634    Choosing an option will likely depend on the scenarios for which one
 635    uses/supports IPsec NAT-T.  This list is not meant to be exhaustive,
 636    so other solutions may exist.  We first describe the generic choices
 637    that solve the problem for all upper-layer protocols.
 638
 639    Generic choices for ESP transport mode:
 640
 641    Tr1) Implement a built-in NAT (network address translation) above
 642    IPsec decapsulation.
 643
 644    Tr2) Implement a built-in NAPT (network address port translation)
 645    above IPsec decapsulation.
 646
 647    Tr3) An initiator may decide not to request transport mode once NAT
 648    is detected and may instead request a tunnel-mode SA.  This may be a
 649    retry after transport mode is denied by the responder, or the
 650    initiator may choose to propose a tunnel SA initially.  This is no
 651    more difficult than knowing whether to propose transport mode or
 652    tunnel mode without NAT.  If for some reason the responder prefers or
 653    requires tunnel mode for NAT traversal, it must reject the quick mode
 654    SA proposal for transport mode.
 655
 656    Generic choices for ESP tunnel mode:
 657
 658    Tn1) Same as Tr1.
 659
 660    Tn2) Same as Tr2.
 661
 662    Tn3) This option is possible if an initiator can be assigned an
 663    address through its tunnel SA, with the responder using DHCP.  The
 664    initiator may initially request an internal address via the
 665    DHCP-IPsec method, regardless of whether it knows it is behind a NAT.
 666    It may re-initiate an IKE quick mode negotiation for DHCP tunnel SA
 667    after the responder fails the quick mode SA transport mode proposal.
 668    This happens either when a NAT-OA payload is sent or because it
 669
 670
 671
 672
 673
 674 Huttunen, et al.            Standards Track                    [Page 12]
 675 \f
 676 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 677
 678
 679    discovers from NAT-D that the initiator is behind a NAT and its local
 680    configuration/policy will only accept a NAT connection when being
 681    assigned an address through DHCP-IPsec.
 682
 683    There are also implementation choices that offer limited
 684    interoperability.  Implementors should specify which applications or
 685    protocols should work if these options are selected.  Note that
 686    neither Tr4 nor Tn4, as described below, are expected to work with
 687    TCP traffic.
 688
 689    Limited interoperability choices for ESP transport mode:
 690
 691    Tr4) Implement upper-layer protocol awareness of the inbound and
 692    outbound IPsec SA so that it doesn't use the source IP and the source
 693    port as the session identifier (e.g., an L2TP session ID mapped to
 694    the IPsec SA pair that doesn't use the UDP source port or the source
 695    IP address for peer uniqueness).
 696
 697    Tr5) Implement application integration with IKE initiation so that it
 698    can rebind to a different source port if the IKE quick mode SA
 699    proposal is rejected by the responder; then it can repropose the new
 700    QM selector.
 701
 702    Limited interoperability choices for ESP tunnel mode:
 703
 704    Tn4) Same as Tr4.
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Huttunen, et al.            Standards Track                    [Page 13]
 731 \f
 732 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 733
 734
 735 Authors' Addresses
 736
 737    Ari Huttunen
 738    F-Secure Corporation
 739    Tammasaarenkatu 7
 740    HELSINKI  FIN-00181
 741    FI
 742
 743    EMail: Ari.Huttunen@F-Secure.com
 744
 745
 746    Brian Swander
 747    Microsoft
 748    One Microsoft Way
 749    Redmond, WA  98052
 750    US
 751
 752    EMail: briansw@microsoft.com
 753
 754
 755    Victor Volpe
 756    Cisco Systems
 757    124 Grove Street
 758    Suite 205
 759    Franklin, MA  02038
 760    US
 761
 762    EMail: vvolpe@cisco.com
 763
 764
 765    Larry DiBurro
 766    Nortel Networks
 767    80 Central Street
 768    Boxborough, MA  01719
 769    US
 770
 771    EMail: ldiburro@nortelnetworks.com
 772
 773
 774    Markus Stenberg
 775    FI
 776
 777    EMail: markus.stenberg@iki.fi
 778
 779
 780
 781
 782
 783
 784
 785
 786 Huttunen, et al.            Standards Track                    [Page 14]
 787 \f
 788 RFC 3948         UDP Encapsulation of IPsec ESP Packets     January 2005
 789
 790
 791 Full Copyright Statement
 792
 793    Copyright (C) The Internet Society (2005).
 794
 795    This document is subject to the rights, licenses and restrictions
 796    contained in BCP 78, and except as set forth therein, the authors
 797    retain all their rights.
 798
 799    This document and the information contained herein are provided on an
 800    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 801    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 802    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 803    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 804    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 805    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 806
 807 Intellectual Property
 808
 809    The IETF takes no position regarding the validity or scope of any
 810    Intellectual Property Rights or other rights that might be claimed to
 811    pertain to the implementation or use of the technology described in
 812    this document or the extent to which any license under such rights
 813    might or might not be available; nor does it represent that it has
 814    made any independent effort to identify any such rights.  Information
 815    on the IETF's procedures with respect to rights in IETF Documents can
 816    be found in BCP 78 and BCP 79.
 817
 818    Copies of IPR disclosures made to the IETF Secretariat and any
 819    assurances of licenses to be made available, or the result of an
 820    attempt made to obtain a general license or permission for the use of
 821    such proprietary rights by implementers or users of this
 822    specification can be obtained from the IETF on-line IPR repository at
 823    http://www.ietf.org/ipr.
 824
 825    The IETF invites any interested party to bring to its attention any
 826    copyrights, patents or patent applications, or other proprietary
 827    rights that may cover technology that may be required to implement
 828    this standard.  Please address the information to the IETF at ietf-
 829    ipr@ietf.org.
 830
 831 Acknowledgement
 832
 833    Funding for the RFC Editor function is currently provided by the
 834    Internet Society.
 835
 836
 837
 838
 839
 840
 841
 842 Huttunen, et al.            Standards Track                    [Page 15]
 843 \f