crypto/dist/ipsec-tools/src/racoon/rfc/draft-ietf-ipsec-nat-t-ike-00.txt

   1 IP Security Protocol Working Group (IPSEC)       T. Kivinen, M. Stenberg
   2 INTERNET-DRAFT                               SSH Communications Security
   3 draft-ietf-ipsec-nat-t-ike-00.txt                            A. Huttunen
   4 Expires: 10 December 2001                           F-Secure Corporation
   5                                                     W. Dixon, B. Swander
   6                                                                Microsoft
   7                                                                 V. Volpe
   8                                                            Cisco Systems
   9                                                               L. DiBurro
  10                                                          Nortel Networks
  11                                                             10 June 2001
  12
  13
  14
  15                 Negotiation of NAT-Traversal in the IKE
  16
  17 Status of This Memo
  18
  19 This document is a submission to the IETF IP Security Protocol
  20 (IPSEC) Working Group.  Comments are solicited and should be
  21 addressed to the working group mailing list (ipsec@lists.tislabs.com)
  22 or to the editor.
  23
  24 This document is an Internet-Draft and is in full conformance
  25 with all provisions of Section 10 of RFC2026.
  26
  27 Internet-Drafts are working documents of the Internet Engineering
  28 Task Force (IETF), its areas, and its working groups.  Note that
  29 other groups may also distribute working documents as
  30 Internet-Drafts.
  31
  32 Internet-Drafts are draft documents valid for a maximum of six
  33 months and may be updated, replaced, or obsoleted by other
  34 documents at any time.  It is inappropriate to use Internet-
  35 Drafts as reference material or to cite them other than as
  36 "work in progress."
  37
  38 The list of current Internet-Drafts can be accessed at
  39 http://www.ietf.org/ietf/1id-abstracts.txt
  40
  41 The list of Internet-Draft Shadow Directories can be accessed at
  42 http://www.ietf.org/shadow.html.
  43
  44 Abstract
  45
  46 This document describes how to detect one or more NATs between IPsec
  47 hosts, and how to negotiate the use of UDP encapsulation of the IPsec
  48 packets through the NAT boxes in IKE.
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 T. Kivinen, et. al.                                             [page 1]
  59 \f
  60 INTERNET-DRAFT                                              10 June 2001
  61
  62 Table of Contents
  63
  64 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
  65 2.  Specification of Requirements   . . . . . . . . . . . . . . . . .  2
  66 3.  Phase 1   . . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
  67   3.1.  Detecting support of Nat-Traversal  . . . . . . . . . . . . .  2
  68   3.2.  Detecting presense of NAT   . . . . . . . . . . . . . . . . .  3
  69 4.  Quick Mode  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  70   4.1.  Negotiation of the NAT-Traversal encapsulation  . . . . . . .  5
  71   4.2.  Sending the original source address   . . . . . . . . . . . .  5
  72 5.  Security Considerations   . . . . . . . . . . . . . . . . . . . .  6
  73 6.  Intellectual property rights  . . . . . . . . . . . . . . . . . .  7
  74 7.  Acknowledgments   . . . . . . . . . . . . . . . . . . . . . . . .  7
  75 8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
  76 9.  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  7
  77
  78
  79
  80 1.  Introduction
  81
  82 This document is split in two parts. The first part describes what is
  83 needed in the IKE phase 1 for the NAT-Traversal support. This includes
  84 detecting if the other end supports NAT-Traversal, and detecting if
  85 there is one or more NAT along the path from host to host.
  86
  87 The second part describes how to negotiate the use of UDP encapsulated
  88 IPsec packets in the IKE Quick Mode. It also describes how to transmit
  89 the original source address to the other end if needed. The original
  90 source address can be used to incrementally update the TCP/IP checksums
  91 so that they will match after the NAT transform (The NAT cannot do this,
  92 because the TCP/IP checksum is inside the UDP encapsulated IPsec
  93 packet).
  94
  95 The document [Hutt01] describes the details of the UDP encapsulation and
  96 the document [Dixon01] provides background information and motivation of
  97 the NAT-Traversal in general.
  98
  99 2.  Specification of Requirements
 100
 101 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED",
 102 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and
 103 "OPTIONAL" to describe requirements. They are to be interpreted as
 104 described in [RFC-2119] document.
 105
 106 3.  Phase 1
 107
 108 The detection of the support for the NAT-Traversal and detection of the
 109 NAT along the path happens in the IKE [RFC-2409] phase 1.
 110
 111 3.1.  Detecting support of Nat-Traversal
 112
 113 The NAT-Traversal capability of the remote host is determined by an
 114 exchange of vendor strings; in Phase 1 two first messages, the vendor id
 115
 116
 117 T. Kivinen, et. al.                                             [page 2]
 118 \f
 119 INTERNET-DRAFT                                              10 June 2001
 120
 121 payload for this specification of NAT-Traversal (MD5 hash of "draft-
 122 ietf-ipsec-nat-t-ike-00" - ["4485152d 18b6bbcd 0be8a846 9579ddcc"]) MUST
 123 be sent if supported (and it MUST be received by both sides) for the
 124 NAT-Traversal probe to continue.
 125
 126 3.2.  Detecting presense of NAT
 127
 128 The purpose of the NAT-D payload is twofold, It not only detects the
 129 presence of NAT between two IKE peers, it also detects where the NAT is.
 130 The location of the NAT device is important in that the keepalives need
 131 to initiate from the peer "behind" the NAT.
 132
 133 To detect the NAT between the two hosts, we need to detect if the IP
 134 address or the port changes along the path. This is done by sending the
 135 hashes of IP address and port of both source and destination addresses
 136 from each end to another. When both ends calculate those hashes and get
 137 same result they know there is no NAT between. If the hashes do not
 138 match, somebody translated the address or port between, meaning we need
 139 to do NAT-Traversal to get IPsec packet through.
 140
 141 If the sender of the packet does not know his own IP address (in case of
 142 multiple interfaces, and implementation don't know which is used to
 143 route the packet out), he can include multiple local hashes to the
 144 packet (as separate NAT-D payloads). In this case the NAT is detected if
 145 and only if none of the hashes match.
 146
 147 The hashes are sent as a series of NAT-D (NAT discovery) payloads.  Each
 148 payload contains one hash, so in case of multiple hashes, multiple NAT-D
 149 payloads are sent. In normal case there is only two NAT-D payloads.
 150
 151 The NAT-D payloads are included in the third and fourth packet in the
 152 main mode and second and third packet in the aggressive mode.
 153
 154 The format of the NAT-D packet is
 155
 156       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
 157      +---------------+---------------+---------------+---------------+
 158      | Next Payload  |    RESERVED   |        Payload length         |
 159      +---------------+---------------+---------------+---------------+
 160      ~               HASH of the address and port                    ~
 161      +---------------+---------------+---------------+---------------+
 162
 163 The payload type for the NAT discovery payload is 130 (XXX CHANGE).
 164
 165 The HASH is calculated as follows:
 166
 167         HASH = HASH(CKY-I | CKY-R | IP | Port)
 168
 169 using the negotiated HASH algorithm. All data inside the HASH is in the
 170 network byte-order. The IP is 4 octets for the IPv4 address and 16
 171 octets for the IPv6 address. The port number is encoded as 2 octet
 172 number in network byte-order. The first NAT-D payload contains the
 173 remote ends IP address and port (i.e the destination address of the UDP
 174
 175
 176 T. Kivinen, et. al.                                             [page 3]
 177 \f
 178 INTERNET-DRAFT                                              10 June 2001
 179
 180 packet). The rest of the NAT-D payloads contain possible local end IP
 181 addresses and ports (i.e all possible source addresses of the UDP
 182 packet).
 183
 184 If there is no NAT between then the first NAT-D payload should match one
 185 of the local NAT-D packet (i.e the local NAT-D payloads this host is
 186 sending out), and the one of the other NAT-D payloads must match the
 187 remote ends IP address and port. If the first check fails (i.e first
 188 NAT-D payload does not match any of the local IP addresses and ports),
 189 then it means that there is dynamic NAT between, and this end should
 190 start sending keepalives as defined in the [Hutt01].
 191
 192 The CKY-I and CKY-R are the initiator and responder cookies, and they
 193 are added to the hash to make precomputation attacks for the IP address
 194 and port impossible.
 195
 196 An example of phase 1 exchange using NAT-Traversal in main mode
 197 (authentication with signatures) is:
 198
 199          Initiator                       Responder
 200         ------------                    ------------
 201         HDR, SA, VID                 -->
 202                                      <-- HDR, SA, VID
 203         HDR, KE, Ni, NAT-D, NAT-D    -->
 204                                      <-- HDR, KE, Nr, NAT-D, NAT-D
 205         HDR*, IDii, [CERT, ] SIG_I   -->
 206                                      <-- HDR*, IDir, [ CERT, ], SIG_R
 207
 208 An example of phase 1 exchange using NAT-Traversal in aggressive mode
 209 (authentication with signatures) is:
 210
 211          Initiator                       Responder
 212         ------------                    ------------
 213         HDR, SA, KE, Ni, IDii, VID   -->
 214                                      <-- HDR, SA, KE, Nr, IDir, [CERT, ],
 215                                            VID, NAT-D, NAT-D, SIG_R
 216         HDR*, [CERT, ], NAT-D, NAT-D,
 217           SIG_I                      -->
 218
 219 4.  Quick Mode
 220
 221 After the Phase 1 both ends know if there is a NAT present between.  The
 222 final decision of using the NAT-Traversal is left to the quick mode. The
 223 use of NAT-Traversal is negotiated inside the SA payloads of the quick
 224 mode. In the quick mode both ends can also send the original source
 225 addresses of the IPsec packets (in case of the transport mode) to the
 226 other, end so the other end has possibility to fix the TCP/IP checksum
 227 field after the NAT transform.
 228
 229 This sending of the original source address is optional, and it is not
 230 useful in the UDP-Encapsulated-Tunnel mode, as there is going to be
 231 proper IP header inside the UDP-Encapsulated packet. In case of only
 232 UDP-Encapsulated-Tunnel mode is negotiation then both ends SHOULD NOT
 233
 234
 235 T. Kivinen, et. al.                                             [page 4]
 236 \f
 237 INTERNET-DRAFT                                              10 June 2001
 238
 239 send original source address.
 240
 241 It also might be unnecessary in the transport mode if the other end can
 242 turn off TCP/IP checksum verification. If the sending end knows (for
 243 example from the vendor id payload) that the other end can turn off
 244 TCP/IP checksum verification, he MAY leave the original source address
 245 payload away. Otherwise he SHOULD send the original source address.
 246
 247 4.1.  Negotiation of the NAT-Traversal encapsulation
 248
 249 The negoation of the NAT-Traversal happens by adding two new
 250 encapsulation modes. These encapsulation modes are:
 251
 252 UDP-Encapsulated-Tunnel         61443 (XXX CHANGE)
 253 UDP-Encapsulated-Transport      61444 (XXX CHANGE)
 254
 255 It is not normally useful to propose both normal tunnel or transport
 256 mode and UDP-Encapsulated modes. If there is a NAT box between normal
 257 tunnel or transport encapsulations may not work, and if there is no NAT
 258 box between, there is no point of wasting bandwidth by adding UDP
 259 encapsulation of packets. Because of this initiator SHOULD NOT include
 260 both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP-
 261 Encapsulated-Transport in its proposals.
 262
 263 4.2.  Sending the original source address
 264
 265 In case of transport mode both ends SHOULD send the original source
 266 address to the other end. For the tunnel mode both ends SHOULD NOT send
 267 original source address to the other end. In case of AH is negotiated
 268 each end MUST send original source address.
 269
 270 The original source address of packets put to this transport mode IPsec
 271 SA is sent to other end using NAT-OA (NAT Original Address) payload.
 272
 273 The NAT-OA payloads are sent inside the first and second packets of the
 274 quick mode. The initiator SHOULD send the payload if it proposes any
 275 UDP-Encapsulated-Transport mode and the responder SHOULD send the
 276 payload only if it selected UDP-Encapsulated-Transport mode. I.e it is
 277 possible that initiator send the NAT-OA payload, but proposes both UDP-
 278 Encapsulated transport and tunnel mode, and then the responder selectes
 279 the UDP-Encapsulated tunnel mode and do not send NAT-OA payload back.
 280
 281 A peer MUST NOT fail a negotiation if it does not receive a NAT-OA
 282 payload if the NAT-OA payload only would contain redundant information.
 283 I.e. only the machine(s) that are actually behind the NAT need to send
 284 the NAT-OA payload. A machine with a public, non-changing IP address
 285 doesn't need to send the NAT-OA payload.
 286
 287 In case of AH negotiation initiator MUST send NAT-OA payload, and the
 288 responder MUST reply to it if it selected proposal including AH.
 289
 290 The format of the NAT-OA packet is
 291
 292
 293
 294 T. Kivinen, et. al.                                             [page 5]
 295 \f
 296 INTERNET-DRAFT                                              10 June 2001
 297
 298       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
 299      +---------------+---------------+---------------+---------------+
 300      | Next Payload  |    RESERVED   |        Payload length         |
 301      +---------------+---------------+---------------+---------------+
 302      |    ID Type    |    RESERVED   |           RESERVED            |
 303      +---------------+---------------+---------------+---------------+
 304      |         IPv4 (4 octets) or IPv6 address (16 octets)           |
 305      +---------------+---------------+---------------+---------------+
 306
 307 The payload type for the NAT discovery payload is 131 (XXX CHANGE).
 308
 309 The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and
 310 ID_IPV6_ADDR types are allowed. The two reserved fields after the ID
 311 Type must be zero.
 312
 313 An example of quick mode using NAT-OA payloads is:
 314
 315          Initiator                       Responder
 316         ------------                    ------------
 317         HDR*, HASH(1), SA, Ni, [, KE]
 318           [, IDci, IDcr ] [, NAT-OA] -->
 319                                      <-- HDR*, HASH(2), SA, Nr, [, KE]
 320                                           [, IDci, IDcr ] [, NAT-OA]
 321         HDR*, HASH(3)
 322
 323 5.  Security Considerations
 324
 325 Whenever changes to some fundamental parts of a security protocol are
 326 proposed, the examination of security implications cannot be skipped.
 327 Therefore, here are some observations on the effects, and whether or not
 328 these effects matter. This section will be expanded further in future
 329 versions of this draft.
 330
 331 o  IKE probe reveals NAT-Traversal support to everyone. This should not
 332    be an issue.
 333
 334 o  The value of authentication mechanisms based on IP addresses
 335    disappears once NATs are in the picture. That is not necessarily a
 336    bad thing (for any real security, other authentication measures than
 337    IP addresses should be used). This means that pre-shared-keys
 338    authentication cannot be used with the main mode without group shared
 339    keys for everybody behind the NAT box, which is huge security risk.
 340
 341 o  As the internal address space is only 32 bits, and it is usually very
 342    sparce, it might be possible for the attacker to find out the
 343    internal address used behind the NAT box by trying all possible IP-
 344    addresses and trying to find the matching hash. The port numbers are
 345    normally fixed to 500, and the other ends IP address is usually also
 346    known. This limits the hash calculations down to 2^32. If educated
 347    guess of use of private address space is done, then the number of
 348    hash calculations needed to find out the internal IP address goes
 349    down to the 2^24 + 2 * (2^16).
 350
 351
 352
 353 T. Kivinen, et. al.                                             [page 6]
 354 \f
 355 INTERNET-DRAFT                                              10 June 2001
 356
 357 o  The NAT-D payloads nor the Vendor ID payloads are not authenticated
 358    at all in the main mode nor in the aggressive mode. This means that
 359    attacker can remove those payloads, modify them or add them. By
 360    removing or adding them the attacker can cause Denial Of Service
 361    attacks. By modifying the NAT-D packets the attacker can cause both
 362    ends to use UDP-Encapsulated modes instead of directly using tunnel
 363    or transport mode, thus wasting some bandwidth.
 364
 365 o  The sending of the original source address in the Quick Mode releveas
 366    the internal ip address behind the NAT to the other end. In this case
 367    we have already authenticated the other end, and sending of the
 368    original source address is only needed in transport mode.
 369
 370 6.  Intellectual property rights
 371
 372 The IETF has been notified of intellectual property rights claimed in
 373 regard to some or all of the specification contained in this document.
 374 For more information consult the online list of claimed rights.
 375
 376 SSH Communications Security Corp has notified the working group of one
 377 or more patents or patent applications that may be relevant to this
 378 internet-draft. SSH Communications Security Corp has already given a
 379 licence for those patents to the IETF. For more information consult the
 380 online list of claimed rights.
 381
 382 7.  Acknowledgments
 383
 384 Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who
 385 contributed to the drafts used as base for this document.
 386
 387 8.  References
 388
 389 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)",
 390 November 1998
 391
 392 [RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation
 393 for ISAKMP", November 1998
 394
 395 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate
 396 Requirement Levels", March 1997
 397
 398 [Hutt01] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets",
 399 draft-ietf-ipsec-udp-encaps-00.txt, June 2001
 400
 401 [Dixon01] Dixon, W. et. al., "IPSec over NAT Justification for UDP
 402 Encapsulation", draft-ietf-ipsec-udp-encaps-justification-00.txt, June
 403 2001
 404
 405 9.  Authors' Addresses
 406
 407     Tero Kivinen
 408     SSH Communications Security Corp
 409     Fredrikinkatu 42
 410
 411
 412 T. Kivinen, et. al.                                             [page 7]
 413 \f
 414 INTERNET-DRAFT                                              10 June 2001
 415
 416     FIN-00100 HELSINKI
 417     Finland
 418     E-mail: kivinen@ssh.fi
 419
 420     Markus Stenberg
 421     SSH Communications Security Corp
 422     Fredrikinkatu 42
 423     FIN-00100 HELSINKI
 424     Finland
 425     E-mail: mstenber@ssh.com
 426
 427     Ari Huttunen
 428     F-Secure Corporation
 429     Tammasaarenkatu 7,
 430     FIN-00181 HELSINKI
 431     Finland
 432     E-mail: Ari.Huttunen@F-Secure.com
 433
 434     William Dixon
 435     Microsoft
 436     One Microsoft Way
 437     Redmond WA 98052
 438     E-mail: wdixon@microsoft.com
 439
 440     Brian Swander
 441     Microsoft
 442     One Microsoft Way
 443     Redmond WA 98052
 444     E-mail: briansw@microsoft.com
 445
 446     Victor Volpe
 447     Cisco Systems
 448     124 Grove Street
 449     Suite 205
 450     Franklin, MA 02038
 451     E-mail: vvolpe@cisco.com
 452
 453     Larry DiBurro
 454     Nortel Networks
 455     80 Central Street
 456     Boxborough, MA 01719
 457     ldiburro@nortelnetworks.com
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470 T. Kivinen, et. al.                                             [page 8]