1IP Security Protocol Working Group (IPSEC) T. Kivinen 2INTERNET-DRAFT SSH Communications Security 3draft-ietf-ipsec-nat-t-ike-03.txt A. Huttunen 4Expires: 24 December 2002 F- Secure Corporation 5 B. Swander 6 Microsoft 7 V. Volpe 8 Cisco Systems 9 24 June 2002 10 11 12 13 Negotiation of NAT-Traversal in the IKE 14 15Status of This Memo 16 17This document is a submission to the IETF IP Security Protocol 18(IPSEC) Working Group. Comments are solicited and should be 19addressed to the working group mailing list (ipsec@lists.tislabs.com) 20or to the editor. 21 22This document is an Internet-Draft and is in full conformance 23with all provisions of Section 10 of RFC2026. 24 25Internet-Drafts are working documents of the Internet Engineering 26Task Force (IETF), its areas, and its working groups. Note that 27other groups may also distribute working documents as 28Internet-Drafts. 29 30Internet-Drafts are draft documents valid for a maximum of six 31months and may be updated, replaced, or obsoleted by other 32documents at any time. It is inappropriate to use Internet- 33Drafts as reference material or to cite them other than as 34"work in progress." 35 36The list of current Internet-Drafts can be accessed at 37http://www.ietf.org/ietf/1id-abstracts.txt 38 39The list of Internet-Draft Shadow Directories can be accessed at 40http://www.ietf.org/shadow.html. 41 42Abstract 43 44This document describes how to detect one or more NATs between IPsec 45hosts, and how to negotiate the use of UDP encapsulation of the IPsec 46packets through the NAT boxes in IKE. 47 48 49 50 51 52 53 54 55 56 57 58T. Kivinen, et. al. [page 1] 59 60INTERNET-DRAFT 24 June 2002 61 62Table of Contents 63 641. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 652. Specification of Requirements . . . . . . . . . . . . . . . . . 2 663. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 3.1. Detecting support of Nat-Traversal . . . . . . . . . . . . . 3 68 3.2. Detecting presence of NAT . . . . . . . . . . . . . . . . . 3 694. Floating to the new ports . . . . . . . . . . . . . . . . . . . 5 705. Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Negotiation of the NAT-Traversal encapsulation . . . . . . . 7 72 5.2. Sending the original source address . . . . . . . . . . . . 8 736. Initial contact notifications . . . . . . . . . . . . . . . . . 8 747. Recovering from the expiring NAT mappings . . . . . . . . . . . 9 758. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 769. Intellectual property rights . . . . . . . . . . . . . . . . . . 10 7710. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10 7811. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7912. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 80 81 82 831. Introduction 84 85This document is split in two parts. The first part describes what is 86needed in the IKE phase 1 for the NAT-Traversal support. This includes 87detecting if the other end supports NAT-Traversal, and detecting if 88there is one or more NAT along the path from host to host. 89 90The second part describes how to negotiate the use of UDP encapsulated 91IPsec packets in the IKE Quick Mode. It also describes how to transmit 92the original source address to the other end if needed. The original 93source address can be used to incrementally update the TCP/IP checksums 94so that they will match after the NAT transform (The NAT cannot do this, 95because the TCP/IP checksum is inside the UDP encapsulated IPsec 96packet). 97 98The document [Hutt02] describes the details of the UDP encapsulation and 99the document [Dixon01] provides background information and motivation of 100the NAT-Traversal in general. 101 1022. Specification of Requirements 103 104This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 105"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 106"OPTIONAL" to describe requirements. They are to be interpreted as 107described in [RFC-2119] document. 108 1093. Phase 1 110 111The detection of the support for the NAT-Traversal and detection of the 112NAT along the path happens in the IKE [RFC-2409] phase 1. 113 114The NAT is supposed to float the IKE UDP port, and recipients MUST be 115 116 117T. Kivinen, et. al. [page 2] 118 119INTERNET-DRAFT 24 June 2002 120 121able to process IKE packets whose source port is different than 500. 122There are cases where the NAT does not have to float the source port 123(only one (IPsec) host behind the NAT or for the first IPsec host it can 124keep the port 500, and float only the following IPsec hosts). 125 126Recipients MUST reply back to the source address from the packet. This 127also means that when the original responder is doing rekeying, or 128sending notifications etc. to the original initiator it MUST send the 129packets from the same set of port and IP numbers that was used when the 130IKE SA was last time used (i.e the source and destination port and IP 131numbers must be same). 132 133For example the initiator sends packet having source and destination 134port 500, the NAT changes that to such packet which have source port 13512312 and destination port 500, the responder must be able to process 136the packet whose source address is that 12312 and it must reply back 137with packet whose source address is 500 and destination address 12312, 138the NAT will then translate this packet to have source address 500 and 139destination address 500. 140 1413.1. Detecting support of Nat-Traversal 142 143The NAT-Traversal capability of the remote host is determined by an 144exchange of vendor strings; in Phase 1 two first messages, the vendor id 145payload for this specification of NAT-Traversal (MD5 hash of "draft- 146ietf-ipsec-nat-t-ike-03" - ["7d9419a6 5310ca6f 2c179d92 15529d56"]) MUST 147be sent if supported (and it MUST be received by both sides) for the 148NAT-Traversal probe to continue. 149 1503.2. Detecting presence of NAT 151 152The purpose of the NAT-D payload is twofold, It not only detects the 153presence of NAT between two IKE peers, it also detects where the NAT is. 154The location of the NAT device is important in that the keepalives need 155to initiate from the peer "behind" the NAT. 156 157To detect the NAT between the two hosts, we need to detect if the IP 158address or the port changes along the path. This is done by sending the 159hashes of IP address and port of both source and destination addresses 160from each end to another. When both ends calculate those hashes and get 161same result they know there is no NAT between. If the hashes do not 162match, somebody translated the address or port between, meaning we need 163to do NAT-Traversal to get IPsec packet through. 164 165If the sender of the packet does not know his own IP address (in case of 166multiple interfaces, and implementation don't know which is used to 167route the packet out), he can include multiple local hashes to the 168packet (as separate NAT-D payloads). In this case the NAT is detected if 169and only if none of the hashes match. 170 171The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each 172payload contains one hash, so in case of multiple hashes, multiple NAT-D 173payloads are sent. In normal case there is only two NAT-D payloads. 174 175 176T. Kivinen, et. al. [page 3] 177 178INTERNET-DRAFT 24 June 2002 179 180The NAT-D payloads are included in the third and fourth packet in the 181main mode and second and third packet in the aggressive mode. 182 183The format of the NAT-D packet is 184 185 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 186 +---------------+---------------+---------------+---------------+ 187 | Next Payload | RESERVED | Payload length | 188 +---------------+---------------+---------------+---------------+ 189 ~ HASH of the address and port ~ 190 +---------------+---------------+---------------+---------------+ 191 192The payload type for the NAT discovery payload is 130 (XXX CHANGE). 193 194The HASH is calculated as follows: 195 196 HASH = HASH(CKY-I | CKY-R | IP | Port) 197 198using the negotiated HASH algorithm. All data inside the HASH is in the 199network byte-order. The IP is 4 octets for the IPv4 address and 16 200octets for the IPv6 address. The port number is encoded as 2 octet 201number in network byte-order. The first NAT-D payload contains the 202remote ends IP address and port (i.e the destination address of the UDP 203packet). The rest of the NAT-D payloads contain possible local end IP 204addresses and ports (i.e all possible source addresses of the UDP 205packet). 206 207If there is no NAT between then the first NAT-D payload should match one 208of the local NAT-D packet (i.e the local NAT-D payloads this host is 209sending out), and the one of the other NAT-D payloads must match the 210remote ends IP address and port. If the first check fails (i.e first 211NAT-D payload does not match any of the local IP addresses and ports), 212then it means that there is dynamic NAT between, and this end should 213start sending keepalives as defined in the [Hutt02]. 214 215The CKY-I and CKY-R are the initiator and responder cookies, and they 216are added to the hash to make precomputation attacks for the IP address 217and port impossible. 218 219An example of phase 1 exchange using NAT-Traversal in main mode 220(authentication with signatures) is: 221 222 Initiator Responder 223 ------------ ------------ 224 HDR, SA, VID --> 225 <-- HDR, SA, VID 226 HDR, KE, Ni, NAT-D, NAT-D --> 227 <-- HDR, KE, Nr, NAT-D, NAT-D 228 HDR*#, IDii, [CERT, ] SIG_I --> 229 <-- HDR*#, IDir, [ CERT, ], SIG_R 230 231An example of phase 1 exchange using NAT-Traversal in aggressive mode 232(authentication with signatures) is: 233 234 235T. Kivinen, et. al. [page 4] 236 237INTERNET-DRAFT 24 June 2002 238 239 Initiator Responder 240 ------------ ------------ 241 HDR, SA, KE, Ni, IDii, VID --> 242 <-- HDR, SA, KE, Nr, IDir, 243 [CERT, ], VID, NAT-D, 244 NAT-D, SIG_R 245 HDR*#, [CERT, ], NAT-D, NAT-D, 246 SIG_I --> 247 248The '#' sign identifies that those packets are sent to the floated port 249if NAT is detected. 250 2514. Floating to the new ports 252 253IPsec-aware NATs can cause problems. Some NATs will not float IKE source 254port 500 even if there are multiple clients behind the NAT. They can 255also map IKE cookies to demultiplex traffic instead of using the source 256port. Both of these are problematic for generic NAT transparency since 257it is difficult for IKE to discover the capabilities of the NAT. The 258best approach is to simply move the IKE traffic off port 500 as soon as 259possible to avoid any IPsec-aware NAT special casing. Moving IKE from 260port 500 to port 4500 is known as port floating. 261 262Take the common case of the initiator behind the NAT. The initiator must 263quickly float to 4500 once the NAT has been detected to minimize the 264window of IPsec-aware NAT problems. 265 266In main mode, the initiator MUST float on the ID payload if there is NAT 267between the hosts. The initiator MUST set both UDP source and 268destination ports to 4500. All subsequent packets sent to this peer 269(including informationals) MUST be sent on 4500. In addition, the IKE 270data MUST be prepended with a non-ESP marker allowing for demultiplexing 271of traffic as defined in [Hutt02]. 272 273Thus, the IKE packet now looks like: 274 275 IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I 276 277assuming authentication using signatures. The 4 bytes of non-ESP marker 278is defined in the [Hutt02]. 279 280When the responder gets this packet he performs the usual decryption and 281processing of the various payloads. If this is successful, he MUST 282update local state so that all subsequent packets (including 283informationals) to the peer use the new port, and possibly new IP 284address obtained from the incoming valid packet. The port will generally 285be different since the NAT will map UDP(500,500) to UDP(X,500), and 286UDP(4500,4500) to UDP(Y,4500). The IP address will seldom be different 287from the pre-float IP address. The responder MUST respond with all 288subsequent IKE packets to this peer using UDP(4500,Y). 289 290Similarly, if the responder needs to rekey the phase 1 SA, then he MUST 291start the negotiation using UDP(4500,Y). Any implementation that 292 293 294T. Kivinen, et. al. [page 5] 295 296INTERNET-DRAFT 24 June 2002 297 298supports NAT traversal, MUST support negotiations that begin on port 2994500. If a negotiation starts on 4500, then it doesn't need to float 300anywhere else in the exchange. 301 302Once floating has occurred, if a packet is received on 500, that packet 303is old. If the packet is an informational, it MAY be processed if local 304policy allows. If the packet is a main mode or aggressive mode packet, 305it SHOULD be discarded. 306 307Here is an example of phase 1 exchange using NAT-Traversal in main mode 308(authentication with signatures) with port floating: 309 310 Initiator Responder 311 ------------ ------------ 312 UDP(500,500) HDR, SA, VID --> 313 <-- UDP(500,X) HDR, SA, VID 314 UDP(500,500) HDR, KE, Ni, 315 NAT-D, NAT-D --> 316 <-- UDP(500,X) HDR, KE, Nr, 317 NAT-D, NAT-D 318 UDP(4500,4500) HDR*#, IDii, 319 [CERT, ]SIG_I --> 320 <-- UDP(4500,Y) HDR*#, IDir, 321 [ CERT, ], SIG_R 322 323The floating algorithm for aggressive mode is very similar. After the 324NAT has been detected, the initiator sends: IP UDP(4500,4500) <4 bytes 325of non-ESP marker> HDR*, [CERT, ], NAT-D, NAT-D, SIG_I The responder 326does similar processing to the above, and if successful, MUST update his 327internal IKE ports. The responder MUST respond with all subsequent IKE 328packets to this peer using UDP(4500,Y). 329 330 Initiator Responder 331 ------------ ------------ 332 333 UDP(500,500) HDR, SA, KE, 334 Ni, IDii, VID --> 335 <-- UDP(500,X) HDR, SA, KE, 336 Nr, IDir, [CERT, ], 337 VID, NAT-D, NAT-D, 338 SIG_R 339 UDP(4500,4500) HDR*#, [CERT, ], 340 NAT-D, NAT-D, 341 SIG_I --> 342 343 <-- UDP(4500, Y) HDR*#, ... 344 345While floating, the port in the ID payload in Main Mode/Aggressive Mode 346MUST be 0. 347 348The most common case for the responder behind the NAT is if the NAT is 349simply doing 1-1 address translation. In this case, the initiator still 350floats both ports to 4500. The responder uses the identical algorithm 351 352 353T. Kivinen, et. al. [page 6] 354 355INTERNET-DRAFT 24 June 2002 356 357as above, although in this case, Y will equal 4500, since no port 358translation is happening. 359 360A different floating case involves out-of-band discovery of the ports to 361use. For instance, if the responder is behind a port translating NAT, 362and the initiator needs to contact it first, then the initiator will 363need to determine which ports to use, usually by contacting some other 364server. Once the initiator knows which ports to use to traverse the NAT, 365generally something like UDP(Z,4500), he initiates using these ports. 366This is similar to the responder rekey case above in that the ports to 367use are already known upfront, and no additional floating need take 368place. 369 370Also the first keepalive timer starts after floating to new port, no 371keepalives are sent to the port 500 mapping. 372 3735. Quick Mode 374 375After the Phase 1 both ends know if there is a NAT present between. The 376final decision of using the NAT-Traversal is left to the quick mode. The 377use of NAT-Traversal is negotiated inside the SA payloads of the quick 378mode. In the quick mode both ends can also send the original source 379addresses of the IPsec packets (in case of the transport mode) to the 380other, end so the other end has possibility to fix the TCP/IP checksum 381field after the NAT transform. 382 383This sending of the original source address is optional, and it is not 384useful in the UDP-Encapsulated-Tunnel mode, as there is going to be 385proper IP header inside the UDP-Encapsulated packet. In case of only 386UDP-Encapsulated-Tunnel mode is negotiation then both ends SHOULD NOT 387send original source address. 388It also might be unnecessary in the transport mode if the other end can 389turn off TCP/IP checksum verification. If the sending end knows (for 390example from the vendor id payload) that the other end can turn off 391TCP/IP checksum verification, he MAY leave the original source address 392payload away. Otherwise he SHOULD send the original source address. 393 3945.1. Negotiation of the NAT-Traversal encapsulation 395 396The negotiation of the NAT-Traversal happens by adding two new 397encapsulation modes. These encapsulation modes are: 398 399UDP-Encapsulated-Tunnel 61443 (XXX CHANGE) 400UDP-Encapsulated-Transport 61444 (XXX CHANGE) 401 402It is not normally useful to propose both normal tunnel or transport 403mode and UDP-Encapsulated modes. If there is a NAT box between normal 404tunnel or transport encapsulations may not work, and if there is no NAT 405box between, there is no point of wasting bandwidth by adding UDP 406encapsulation of packets. Because of this initiator SHOULD NOT include 407both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP- 408Encapsulated-Transport in its proposals. 409 410 411 412T. Kivinen, et. al. [page 7] 413 414INTERNET-DRAFT 24 June 2002 415 4165.2. Sending the original source address 417 418In case of transport mode both ends SHOULD send the original source 419address to the other end. For the tunnel mode both ends SHOULD NOT send 420original source address to the other end. 421 422The original source address of packets put to this transport mode IPsec 423SA is sent to other end using NAT-OA (NAT Original Address) payload. 424 425The NAT-OA payloads are sent inside the first and second packets of the 426quick mode. The initiator SHOULD send the payload if it proposes any 427UDP-Encapsulated-Transport mode and the responder SHOULD send the 428payload only if it selected UDP-Encapsulated-Transport mode. I.e it is 429possible that initiator send the NAT-OA payload, but proposes both UDP- 430Encapsulated transport and tunnel mode, and then the responder selects 431the UDP-Encapsulated tunnel mode and do not send NAT-OA payload back. 432 433A peer MUST NOT fail a negotiation if it does not receive a NAT-OA 434payload if the NAT-OA payload only would contain redundant information. 435I.e. only the machine(s) that are actually behind the NAT need to send 436the NAT-OA payload. A machine with a public, non-changing IP address 437doesn't need to send the NAT-OA payload. 438 439The format of the NAT-OA packet is 440 441 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 442 +---------------+---------------+---------------+---------------+ 443 | Next Payload | RESERVED | Payload length | 444 +---------------+---------------+---------------+---------------+ 445 | ID Type | RESERVED | RESERVED | 446 +---------------+---------------+---------------+---------------+ 447 | IPv4 (4 octets) or IPv6 address (16 octets) | 448 +---------------+---------------+---------------+---------------+ 449 450The payload type for the NAT original address payload is 131 (XXX 451CHANGE). 452 453The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and 454ID_IPV6_ADDR types are allowed. The two reserved fields after the ID 455Type must be zero. 456 457An example of quick mode using NAT-OA payloads is: 458 459 Initiator Responder 460 ------------ ------------ 461 HDR*, HASH(1), SA, Ni, [, KE] 462 [, IDci, IDcr ] [, NAT-OA] --> 463 <-- HDR*, HASH(2), SA, Nr, [, KE] 464 [, IDci, IDcr ] [, NAT-OA] 465 HDR*, HASH(3) 466 4676. Initial contact notifications 468 469 470 471T. Kivinen, et. al. [page 8] 472 473INTERNET-DRAFT 24 June 2002 474 475The source IP and port address of the INITIAL-CONTACT notification for 476the host behind NAT are not meaningful, so the IP and port numbers MUST 477NOT be used for the determine which IKE/IPsec SAs to remove. The ID 478payload sent from the other SHOULD be used instead. I.e when INITIAL- 479CONTACT notification is received from the other end, the receiving end 480SHOULD remove all the SAs associated with the same ID payload. 481 4827. Recovering from the expiring NAT mappings 483 484There are cases where NAT box decides to remove mappings that are still 485alive (for example, the keepalive interval is too long, or the NAT box 486is rebooted). To recover from those ends which are NOT behind NAT SHOULD 487use the last valid authenticated packet from the other end to determine 488which IP and port addresses the should be used. The host behind dynamic 489NAT MUST NOT do this as otherwise it opens DoS attack possibility, and 490there is no need for that, because the IP address or port of other host 491will not change (it is not behind NAT). 492Keepalives cannot be used for this purposes as they are not 493authenticated, but any IKE authenticated IKE packet or ESP packet can be 494used to notice that the IP address or the port has changed. 495 4968. Security Considerations 497 498Whenever changes to some fundamental parts of a security protocol are 499proposed, the examination of security implications cannot be skipped. 500Therefore, here are some observations on the effects, and whether or not 501these effects matter. 502 503o IKE probe reveals NAT-Traversal support to everyone. This should not 504 be an issue. 505 506o The value of authentication mechanisms based on IP addresses 507 disappears once NATs are in the picture. That is not necessarily a 508 bad thing (for any real security, other authentication measures than 509 IP addresses should be used). This means that pre-shared-keys 510 authentication cannot be used with the main mode without group shared 511 keys for everybody behind the NAT box, which is huge security risk. 512 Use of group shared keys is NOT RECOMMENDED. 513 514o As the internal address space is only 32 bits, and it is usually very 515 sparse, it might be possible for the attacker to find out the 516 internal address used behind the NAT box by trying all possible IP- 517 addresses and trying to find the matching hash. The port numbers are 518 normally fixed to 500, and the cookies can be extracted from the 519 packet. This limits the hash calculations down to 2^32. If educated 520 guess of use of private address space is done, then the number of 521 hash calculations needed to find out the internal IP address goes 522 down to the 2^24 + 2 * (2^16). 523 524o Neither NAT-D payloads or Vendor ID payloads are authenticated at all 525 in the main mode nor in the aggressive mode. This means that attacker 526 can remove those payloads, modify them or add them. By removing or 527 adding them the attacker can cause Denial Of Service attacks. By 528 529 530T. Kivinen, et. al. [page 9] 531 532INTERNET-DRAFT 24 June 2002 533 534 modifying the NAT-D packets the attacker can cause both ends to use 535 UDP-Encapsulated modes instead of directly using tunnel or transport 536 mode, thus wasting some bandwidth. 537 538o The sending of the original source address in the Quick Mode reveals 539 the internal IP address behind the NAT to the other end. In this case 540 we have already authenticated the other end, and sending of the 541 original source address is only needed in transport mode. 542 543o Updating the IKE SA / ESP UDP encapsulation IP addresses and ports 544 for each valid authenticated packet can cause DoS in case we have 545 attacker who can listen all traffic in the network, and can change 546 the order of the packet and inject new packets before the packet he 547 has already seen. I.e attacker can take the authenticated packet from 548 the host behind NAT, change the packet UDP source or destination 549 ports or IP addresses and sent it out to the other end before the 550 real packet reaches there. The host not behind the NAT will update 551 its IP address and port mapping and sends further traffic to wrong 552 host or port. This situation is fixed immediately when the attacker 553 stops modifying the packets as the first real packet will fix the 554 situation back to normal. Implementations MAY print out warning every 555 time the mapping is changed, as in normal case it should not happen 556 that often. 557 5589. Intellectual property rights 559 560The IETF has been notified of intellectual property rights claimed in 561regard to some or all of the specification contained in this document. 562For more information consult the online list of claimed rights. 563 564SSH Communications Security Corp has notified the working group of one 565or more patents or patent applications that may be relevant to this 566internet-draft. SSH Communications Security Corp has already given a 567license for those patents to the IETF. For more information consult the 568online list of claimed rights. 569 57010. Acknowledgments 571 572Thanks to Markus Stenberg, Larry DiBurro and William Dixon who 573contributed actively to this document. 574 575Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who 576contributed to the drafts used as base for this document. 577 57811. References 579 580[RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 581November 1998 582 583[RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation 584for ISAKMP", November 1998 585 586[RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 587 588 589T. Kivinen, et. al. [page 10] 590 591INTERNET-DRAFT 24 June 2002 592 593Requirement Levels", March 1997 594 595[Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", 596draft-ietf-ipsec-udp-encaps-03.txt, June 2002 597 598[Dixon01] Dixon, W. et. al., "IPSec over NAT Justification for UDP 599Encapsulation", draft-ietf-ipsec-udp-encaps-justification-00.txt, June 6002001 601 60212. Authors' Addresses 603 604 Tero Kivinen 605 SSH Communications Security Corp 606 Fredrikinkatu 42 607 FIN-00100 HELSINKI 608 Finland 609 E-mail: kivinen@ssh.fi 610 611 Ari Huttunen 612 F-Secure Corporation 613 Tammasaarenkatu 7, 614 FIN-00181 HELSINKI 615 Finland 616 E-mail: Ari.Huttunen@F-Secure.com 617 618 Brian Swander 619 Microsoft 620 One Microsoft Way 621 Redmond WA 98052 622 E-mail: briansw@microsoft.com 623 624 Victor Volpe 625 Cisco Systems 626 124 Grove Street 627 Suite 205 628 Franklin, MA 02038 629 E-mail: vvolpe@cisco.com 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647T. Kivinen, et. al. [page 11] 648-- 649kivinen@ssh.fi 650SSH Communications Security http://www.ssh.fi/ 651SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ 652