idnits 2.17.1 draft-ietf-ipsec-nat-t-ike-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 June 2002) is 7949 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'Hutt02' -- Possible downref: Normative reference to a draft: ref. 'Dixon01' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) T. Kivinen 2 INTERNET-DRAFT SSH Communications Security 3 draft-ietf-ipsec-nat-t-ike-03.txt A. Huttunen 4 Expires: 24 December 2002 F- Secure Corporation 5 B. Swander 6 Microsoft 7 V. Volpe 8 Cisco Systems 9 24 June 2002 11 Negotiation of NAT-Traversal in the IKE 13 Status of This Memo 15 This document is a submission to the IETF IP Security Protocol 16 (IPSEC) Working Group. Comments are solicited and should be 17 addressed to the working group mailing list (ipsec@lists.tislabs.com) 18 or to the editor. 20 This document is an Internet-Draft and is in full conformance 21 with all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as 32 "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes how to detect one or more NATs between IPsec 43 hosts, and how to negotiate the use of UDP encapsulation of the IPsec 44 packets through the NAT boxes in IKE. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 50 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3.1. Detecting support of Nat-Traversal . . . . . . . . . . . . . 3 52 3.2. Detecting presence of NAT . . . . . . . . . . . . . . . . . 3 53 4. Floating to the new ports . . . . . . . . . . . . . . . . . . . 5 54 5. Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5.1. Negotiation of the NAT-Traversal encapsulation . . . . . . . 7 56 5.2. Sending the original source address . . . . . . . . . . . . 8 57 6. Initial contact notifications . . . . . . . . . . . . . . . . . 8 58 7. Recovering from the expiring NAT mappings . . . . . . . . . . . 9 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 60 9. Intellectual property rights . . . . . . . . . . . . . . . . . . 10 61 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 65 1. Introduction 67 This document is split in two parts. The first part describes what is 68 needed in the IKE phase 1 for the NAT-Traversal support. This includes 69 detecting if the other end supports NAT-Traversal, and detecting if 70 there is one or more NAT along the path from host to host. 72 The second part describes how to negotiate the use of UDP encapsulated 73 IPsec packets in the IKE Quick Mode. It also describes how to transmit 74 the original source address to the other end if needed. The original 75 source address can be used to incrementally update the TCP/IP checksums 76 so that they will match after the NAT transform (The NAT cannot do this, 77 because the TCP/IP checksum is inside the UDP encapsulated IPsec 78 packet). 80 The document [Hutt02] describes the details of the UDP encapsulation and 81 the document [Dixon01] provides background information and motivation of 82 the NAT-Traversal in general. 84 2. Specification of Requirements 86 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 87 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 88 "OPTIONAL" to describe requirements. They are to be interpreted as 89 described in [RFC-2119] document. 91 3. Phase 1 93 The detection of the support for the NAT-Traversal and detection of the 94 NAT along the path happens in the IKE [RFC-2409] phase 1. 96 The NAT is supposed to float the IKE UDP port, and recipients MUST be 97 able to process IKE packets whose source port is different than 500. 98 There are cases where the NAT does not have to float the source port 99 (only one (IPsec) host behind the NAT or for the first IPsec host it can 100 keep the port 500, and float only the following IPsec hosts). 102 Recipients MUST reply back to the source address from the packet. This 103 also means that when the original responder is doing rekeying, or 104 sending notifications etc. to the original initiator it MUST send the 105 packets from the same set of port and IP numbers that was used when the 106 IKE SA was last time used (i.e the source and destination port and IP 107 numbers must be same). 109 For example the initiator sends packet having source and destination 110 port 500, the NAT changes that to such packet which have source port 111 12312 and destination port 500, the responder must be able to process 112 the packet whose source address is that 12312 and it must reply back 113 with packet whose source address is 500 and destination address 12312, 114 the NAT will then translate this packet to have source address 500 and 115 destination address 500. 117 3.1. Detecting support of Nat-Traversal 119 The NAT-Traversal capability of the remote host is determined by an 120 exchange of vendor strings; in Phase 1 two first messages, the vendor id 121 payload for this specification of NAT-Traversal (MD5 hash of "draft- 122 ietf-ipsec-nat-t-ike-03" - ["7d9419a6 5310ca6f 2c179d92 15529d56"]) MUST 123 be sent if supported (and it MUST be received by both sides) for the 124 NAT-Traversal probe to continue. 126 3.2. Detecting presence of NAT 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. 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. 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. 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. 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. 154 The format of the NAT-D packet is 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 +---------------+---------------+---------------+---------------+ 163 The payload type for the NAT discovery payload is 130 (XXX CHANGE). 165 The HASH is calculated as follows: 167 HASH = HASH(CKY-I | CKY-R | IP | Port) 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 packet). The rest of the NAT-D payloads contain possible local end IP 175 addresses and ports (i.e all possible source addresses of the UDP 176 packet). 178 If there is no NAT between then the first NAT-D payload should match one 179 of the local NAT-D packet (i.e the local NAT-D payloads this host is 180 sending out), and the one of the other NAT-D payloads must match the 181 remote ends IP address and port. If the first check fails (i.e first 182 NAT-D payload does not match any of the local IP addresses and ports), 183 then it means that there is dynamic NAT between, and this end should 184 start sending keepalives as defined in the [Hutt02]. 186 The CKY-I and CKY-R are the initiator and responder cookies, and they 187 are added to the hash to make precomputation attacks for the IP address 188 and port impossible. 190 An example of phase 1 exchange using NAT-Traversal in main mode 191 (authentication with signatures) is: 193 Initiator Responder 194 ------------ ------------ 195 HDR, SA, VID --> 196 <-- HDR, SA, VID 197 HDR, KE, Ni, NAT-D, NAT-D --> 198 <-- HDR, KE, Nr, NAT-D, NAT-D 199 HDR*#, IDii, [CERT, ] SIG_I --> 200 <-- HDR*#, IDir, [ CERT, ], SIG_R 202 An example of phase 1 exchange using NAT-Traversal in aggressive mode 203 (authentication with signatures) is: 205 Initiator Responder 206 ------------ ------------ 207 HDR, SA, KE, Ni, IDii, VID --> 208 <-- HDR, SA, KE, Nr, IDir, 209 [CERT, ], VID, NAT-D, 210 NAT-D, SIG_R 211 HDR*#, [CERT, ], NAT-D, NAT-D, 212 SIG_I --> 214 The '#' sign identifies that those packets are sent to the floated port 215 if NAT is detected. 217 4. Floating to the new ports 219 IPsec-aware NATs can cause problems. Some NATs will not float IKE source 220 port 500 even if there are multiple clients behind the NAT. They can 221 also map IKE cookies to demultiplex traffic instead of using the source 222 port. Both of these are problematic for generic NAT transparency since 223 it is difficult for IKE to discover the capabilities of the NAT. The 224 best approach is to simply move the IKE traffic off port 500 as soon as 225 possible to avoid any IPsec-aware NAT special casing. Moving IKE from 226 port 500 to port 4500 is known as port floating. 228 Take the common case of the initiator behind the NAT. The initiator must 229 quickly float to 4500 once the NAT has been detected to minimize the 230 window of IPsec-aware NAT problems. 232 In main mode, the initiator MUST float on the ID payload if there is NAT 233 between the hosts. The initiator MUST set both UDP source and 234 destination ports to 4500. All subsequent packets sent to this peer 235 (including informationals) MUST be sent on 4500. In addition, the IKE 236 data MUST be prepended with a non-ESP marker allowing for demultiplexing 237 of traffic as defined in [Hutt02]. 239 Thus, the IKE packet now looks like: 241 IP UDP(4500,4500) HDR*, IDii, [CERT, ] SIG_I 243 assuming authentication using signatures. The 4 bytes of non-ESP marker 244 is defined in the [Hutt02]. 246 When the responder gets this packet he performs the usual decryption and 247 processing of the various payloads. If this is successful, he MUST 248 update local state so that all subsequent packets (including 249 informationals) to the peer use the new port, and possibly new IP 250 address obtained from the incoming valid packet. The port will generally 251 be different since the NAT will map UDP(500,500) to UDP(X,500), and 252 UDP(4500,4500) to UDP(Y,4500). The IP address will seldom be different 253 from the pre-float IP address. The responder MUST respond with all 254 subsequent IKE packets to this peer using UDP(4500,Y). 256 Similarly, if the responder needs to rekey the phase 1 SA, then he MUST 257 start the negotiation using UDP(4500,Y). Any implementation that 258 supports NAT traversal, MUST support negotiations that begin on port 259 4500. If a negotiation starts on 4500, then it doesn't need to float 260 anywhere else in the exchange. 262 Once floating has occurred, if a packet is received on 500, that packet 263 is old. If the packet is an informational, it MAY be processed if local 264 policy allows. If the packet is a main mode or aggressive mode packet, 265 it SHOULD be discarded. 267 Here is an example of phase 1 exchange using NAT-Traversal in main mode 268 (authentication with signatures) with port floating: 270 Initiator Responder 271 ------------ ------------ 272 UDP(500,500) HDR, SA, VID --> 273 <-- UDP(500,X) HDR, SA, VID 274 UDP(500,500) HDR, KE, Ni, 275 NAT-D, NAT-D --> 276 <-- UDP(500,X) HDR, KE, Nr, 277 NAT-D, NAT-D 278 UDP(4500,4500) HDR*#, IDii, 279 [CERT, ]SIG_I --> 280 <-- UDP(4500,Y) HDR*#, IDir, 281 [ CERT, ], SIG_R 283 The floating algorithm for aggressive mode is very similar. After the 284 NAT has been detected, the initiator sends: IP UDP(4500,4500) <4 bytes 285 of non-ESP marker> HDR*, [CERT, ], NAT-D, NAT-D, SIG_I The responder 286 does similar processing to the above, and if successful, MUST update his 287 internal IKE ports. The responder MUST respond with all subsequent IKE 288 packets to this peer using UDP(4500,Y). 290 Initiator Responder 291 ------------ ------------ 293 UDP(500,500) HDR, SA, KE, 294 Ni, IDii, VID --> 295 <-- UDP(500,X) HDR, SA, KE, 296 Nr, IDir, [CERT, ], 297 VID, NAT-D, NAT-D, 298 SIG_R 299 UDP(4500,4500) HDR*#, [CERT, ], 300 NAT-D, NAT-D, 301 SIG_I --> 303 <-- UDP(4500, Y) HDR*#, ... 305 While floating, the port in the ID payload in Main Mode/Aggressive Mode 306 MUST be 0. 308 The most common case for the responder behind the NAT is if the NAT is 309 simply doing 1-1 address translation. In this case, the initiator still 310 floats both ports to 4500. The responder uses the identical algorithm 311 as above, although in this case, Y will equal 4500, since no port 312 translation is happening. 314 A different floating case involves out-of-band discovery of the ports to 315 use. For instance, if the responder is behind a port translating NAT, 316 and the initiator needs to contact it first, then the initiator will 317 need to determine which ports to use, usually by contacting some other 318 server. Once the initiator knows which ports to use to traverse the NAT, 319 generally something like UDP(Z,4500), he initiates using these ports. 320 This is similar to the responder rekey case above in that the ports to 321 use are already known upfront, and no additional floating need take 322 place. 324 Also the first keepalive timer starts after floating to new port, no 325 keepalives are sent to the port 500 mapping. 327 5. Quick Mode 329 After the Phase 1 both ends know if there is a NAT present between. The 330 final decision of using the NAT-Traversal is left to the quick mode. The 331 use of NAT-Traversal is negotiated inside the SA payloads of the quick 332 mode. In the quick mode both ends can also send the original source 333 addresses of the IPsec packets (in case of the transport mode) to the 334 other, end so the other end has possibility to fix the TCP/IP checksum 335 field after the NAT transform. 337 This sending of the original source address is optional, and it is not 338 useful in the UDP-Encapsulated-Tunnel mode, as there is going to be 339 proper IP header inside the UDP-Encapsulated packet. In case of only 340 UDP-Encapsulated-Tunnel mode is negotiation then both ends SHOULD NOT 341 send original source address. 342 It also might be unnecessary in the transport mode if the other end can 343 turn off TCP/IP checksum verification. If the sending end knows (for 344 example from the vendor id payload) that the other end can turn off 345 TCP/IP checksum verification, he MAY leave the original source address 346 payload away. Otherwise he SHOULD send the original source address. 348 5.1. Negotiation of the NAT-Traversal encapsulation 350 The negotiation of the NAT-Traversal happens by adding two new 351 encapsulation modes. These encapsulation modes are: 353 UDP-Encapsulated-Tunnel 61443 (XXX CHANGE) 354 UDP-Encapsulated-Transport 61444 (XXX CHANGE) 356 It is not normally useful to propose both normal tunnel or transport 357 mode and UDP-Encapsulated modes. If there is a NAT box between normal 358 tunnel or transport encapsulations may not work, and if there is no NAT 359 box between, there is no point of wasting bandwidth by adding UDP 360 encapsulation of packets. Because of this initiator SHOULD NOT include 361 both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP- 362 Encapsulated-Transport in its proposals. 364 5.2. Sending the original source address 366 In case of transport mode both ends SHOULD send the original source 367 address to the other end. For the tunnel mode both ends SHOULD NOT send 368 original source address to the other end. 370 The original source address of packets put to this transport mode IPsec 371 SA is sent to other end using NAT-OA (NAT Original Address) payload. 373 The NAT-OA payloads are sent inside the first and second packets of the 374 quick mode. The initiator SHOULD send the payload if it proposes any 375 UDP-Encapsulated-Transport mode and the responder SHOULD send the 376 payload only if it selected UDP-Encapsulated-Transport mode. I.e it is 377 possible that initiator send the NAT-OA payload, but proposes both UDP- 378 Encapsulated transport and tunnel mode, and then the responder selects 379 the UDP-Encapsulated tunnel mode and do not send NAT-OA payload back. 381 A peer MUST NOT fail a negotiation if it does not receive a NAT-OA 382 payload if the NAT-OA payload only would contain redundant information. 383 I.e. only the machine(s) that are actually behind the NAT need to send 384 the NAT-OA payload. A machine with a public, non-changing IP address 385 doesn't need to send the NAT-OA payload. 387 The format of the NAT-OA packet is 389 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 390 +---------------+---------------+---------------+---------------+ 391 | Next Payload | RESERVED | Payload length | 392 +---------------+---------------+---------------+---------------+ 393 | ID Type | RESERVED | RESERVED | 394 +---------------+---------------+---------------+---------------+ 395 | IPv4 (4 octets) or IPv6 address (16 octets) | 396 +---------------+---------------+---------------+---------------+ 398 The payload type for the NAT original address payload is 131 (XXX 399 CHANGE). 401 The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and 402 ID_IPV6_ADDR types are allowed. The two reserved fields after the ID 403 Type must be zero. 405 An example of quick mode using NAT-OA payloads is: 407 Initiator Responder 408 ------------ ------------ 409 HDR*, HASH(1), SA, Ni, [, KE] 410 [, IDci, IDcr ] [, NAT-OA] --> 411 <-- HDR*, HASH(2), SA, Nr, [, KE] 412 [, IDci, IDcr ] [, NAT-OA] 413 HDR*, HASH(3) 415 6. Initial contact notifications 416 The source IP and port address of the INITIAL-CONTACT notification for 417 the host behind NAT are not meaningful, so the IP and port numbers MUST 418 NOT be used for the determine which IKE/IPsec SAs to remove. The ID 419 payload sent from the other SHOULD be used instead. I.e when INITIAL- 420 CONTACT notification is received from the other end, the receiving end 421 SHOULD remove all the SAs associated with the same ID payload. 423 7. Recovering from the expiring NAT mappings 425 There are cases where NAT box decides to remove mappings that are still 426 alive (for example, the keepalive interval is too long, or the NAT box 427 is rebooted). To recover from those ends which are NOT behind NAT SHOULD 428 use the last valid authenticated packet from the other end to determine 429 which IP and port addresses the should be used. The host behind dynamic 430 NAT MUST NOT do this as otherwise it opens DoS attack possibility, and 431 there is no need for that, because the IP address or port of other host 432 will not change (it is not behind NAT). 433 Keepalives cannot be used for this purposes as they are not 434 authenticated, but any IKE authenticated IKE packet or ESP packet can be 435 used to notice that the IP address or the port has changed. 437 8. Security Considerations 439 Whenever changes to some fundamental parts of a security protocol are 440 proposed, the examination of security implications cannot be skipped. 441 Therefore, here are some observations on the effects, and whether or not 442 these effects matter. 444 o IKE probe reveals NAT-Traversal support to everyone. This should not 445 be an issue. 447 o The value of authentication mechanisms based on IP addresses 448 disappears once NATs are in the picture. That is not necessarily a 449 bad thing (for any real security, other authentication measures than 450 IP addresses should be used). This means that pre-shared-keys 451 authentication cannot be used with the main mode without group shared 452 keys for everybody behind the NAT box, which is huge security risk. 453 Use of group shared keys is NOT RECOMMENDED. 455 o As the internal address space is only 32 bits, and it is usually very 456 sparse, it might be possible for the attacker to find out the 457 internal address used behind the NAT box by trying all possible IP- 458 addresses and trying to find the matching hash. The port numbers are 459 normally fixed to 500, and the cookies can be extracted from the 460 packet. This limits the hash calculations down to 2^32. If educated 461 guess of use of private address space is done, then the number of 462 hash calculations needed to find out the internal IP address goes 463 down to the 2^24 + 2 * (2^16). 465 o Neither NAT-D payloads or Vendor ID payloads are authenticated at all 466 in the main mode nor in the aggressive mode. This means that attacker 467 can remove those payloads, modify them or add them. By removing or 468 adding them the attacker can cause Denial Of Service attacks. By 469 modifying the NAT-D packets the attacker can cause both ends to use 470 UDP-Encapsulated modes instead of directly using tunnel or transport 471 mode, thus wasting some bandwidth. 473 o The sending of the original source address in the Quick Mode reveals 474 the internal IP address behind the NAT to the other end. In this case 475 we have already authenticated the other end, and sending of the 476 original source address is only needed in transport mode. 478 o Updating the IKE SA / ESP UDP encapsulation IP addresses and ports 479 for each valid authenticated packet can cause DoS in case we have 480 attacker who can listen all traffic in the network, and can change 481 the order of the packet and inject new packets before the packet he 482 has already seen. I.e attacker can take the authenticated packet from 483 the host behind NAT, change the packet UDP source or destination 484 ports or IP addresses and sent it out to the other end before the 485 real packet reaches there. The host not behind the NAT will update 486 its IP address and port mapping and sends further traffic to wrong 487 host or port. This situation is fixed immediately when the attacker 488 stops modifying the packets as the first real packet will fix the 489 situation back to normal. Implementations MAY print out warning every 490 time the mapping is changed, as in normal case it should not happen 491 that often. 493 9. Intellectual property rights 495 The IETF has been notified of intellectual property rights claimed in 496 regard to some or all of the specification contained in this document. 497 For more information consult the online list of claimed rights. 499 SSH Communications Security Corp has notified the working group of one 500 or more patents or patent applications that may be relevant to this 501 internet-draft. SSH Communications Security Corp has already given a 502 license for those patents to the IETF. For more information consult the 503 online list of claimed rights. 505 10. Acknowledgments 507 Thanks to Markus Stenberg, Larry DiBurro and William Dixon who 508 contributed actively to this document. 510 Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who 511 contributed to the drafts used as base for this document. 513 11. References 515 [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 516 November 1998 518 [RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation 519 for ISAKMP", November 1998 521 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 522 Requirement Levels", March 1997 524 [Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 525 [Dixon01] Dixon, W. et. al., "IPSec over NAT Justification for UDP 526 Encapsulation", draft-ietf-ipsec-udp-encaps-justification-00.txt, June 527 2001 529 12. Authors' Addresses 531 Tero Kivinen 532 SSH Communications Security Corp 533 Fredrikinkatu 42 534 FIN-00100 HELSINKI 535 Finland 536 E-mail: kivinen@ssh.fi 538 Ari Huttunen 539 F-Secure Corporation 540 Tammasaarenkatu 7, 541 FIN-00181 HELSINKI 542 Finland 543 E-mail: Ari.Huttunen@F-Secure.com 545 Brian Swander 546 Microsoft 547 One Microsoft Way 548 Redmond WA 98052 549 E-mail: briansw@microsoft.com 551 Victor Volpe 552 Cisco Systems 553 124 Grove Street 554 Suite 205 555 Franklin, MA 02038 556 E-mail: vvolpe@cisco.com 558 -- 559 kivinen@ssh.fi 560 SSH Communications Security http://www.ssh.fi/ 561 SSH IPSEC Toolkit http://www.ssh.fi/ipsec/