idnits 2.17.1 draft-bellovin-useipsec-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 608. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (August 3, 2008) is 5744 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-msec-ipsec-extensions-06 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bellovin 3 Internet-Draft Columbia University 4 Intended status: Best Current August 3, 2008 5 Practice 6 Expires: February 4, 2009 8 Guidelines for Specifying the Use of IPsec Version 2 9 draft-bellovin-useipsec-10.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 4, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The Security Considerations sections of many Internet Drafts say, in 43 effect, "just use IPsec". While this is sometimes correct, more 44 often it will leave users without real, interoperable security 45 mechanisms. This memo offers some guidance on when IPsec Version 2 46 should and should not be specified. 48 1. Introduction 50 The Security Considerations sections of many Internet Drafts say, in 51 effect, "just use IPsec". While the use of IPsec is sometimes the 52 correct security solution, more information is needed to provide 53 interoperable security solutions. In some cases, IPsec is 54 unavailable in the likely endpoints. If IPsec is unavailable to -- 55 and hence unusable by -- a majority of the user in a particular 56 protocol environment, then the specification of IPsec is tantamount 57 to saying "turn off security" within this community. Further, when 58 IPsec is available, the implementation may not provide the proper 59 granularity of protection. Finally, if IPsec is available and 60 appropriate, the document mandating the use of IPsec needs to specify 61 just how it is to be used. 63 The goal of this document is to provide guidance to protocol 64 designers on the specification of IPsec when it is the appropriate 65 security mechanism. The protocol specification is expected to 66 provide realistic, interoperable security. Therefore guidance on the 67 configuration of the various IPsec databases, such as the Security 68 Policy Database (SPD), is often required. 70 This document describes how to specify the use of IPsec Version 2 71 [RFC2401], including ESPv2 [RFC2406], AHv2 [RFC2402], and IKEv1 72 [RFC2409]. A separate document will describe the IPsec Version3 73 suite [RFC4301] [RFC4302] [RFC4303] [RFC4306]. 75 For further guidance on security considerations (including discussion 76 of IPsec), see [RFC3552]. 78 NOTE: Many of the arguments below relate to the capabilities of 79 current implementations of IPsec. These may change over time; this 80 advice based on the knowledge available to the IETF at publication 81 time. 83 2. WARNING 85 The design of security protocols is a subtle and difficult art. The 86 cautions here about specifying the use of IPsec should NOT be taken 87 to mean that that you should invent your own new security protocol 88 for each new application. If IPsec is a bad choice, using another 89 standardized, well-understood security protocol will almost always 90 give the best results for both implementation and deployment. 91 Security protocols are very hard to design; rolling out a new one 92 will require extensive theoretical and practical work to confirm its 93 security properties and will incur both delay and uncertainty. 95 3. The Pieces of IPsec 97 IPsec is composed of a number of different pieces. These can be used 98 to provide confidentiality, integrity, and replay protection; though 99 some of these can be configured manually, in general a key management 100 component is used. Additionally, the decision about whether and how 101 to use IPsec is controlled by a policy database of some sort. 103 3.1. AH and ESP 105 The Authentication Header (AH) [RFC2402] and the Encapsulating 106 Security Protocol (ESP) [RFC2406] are the over-the-wire security 107 protocols. Both provide (optional) replay protection. ESP typically 108 is used to provide confidentiality (encryption), integrity and 109 authentication for traffic. ESP also can provide integrity and 110 authentication without confidentiality, which makes it a good 111 alternative to AH in most cases where confidentiality is not a 112 required or desired service. Finally, ESP can be used to provide 113 confidentiality alone, although this is not recommended [Bell96]. 115 The difference in integrity protection offered by AH is that AH 116 protects portions of the preceding IP header, including the source 117 and destination address. However, if ESP is used in tunnel mode (see 118 Section 3.2) and integrity/authentication is enabled, the IP header 119 seen by the source and destination hosts is completely protected 120 anyway. 122 AH can also protect those IP options that need to be seen by 123 intermediate routers, but must be intact and authentic when delivered 124 to the receiving system. At this time, use (and existence) of such 125 IP options is extremely rare. 127 If an application requires such protection, and if the information to 128 be protected cannot be inferred from the key management process, AH 129 must be used. (ESP is generally regarded as easier to implement; 130 however, virtually all IPsec packages support both.) If 131 confidentiality is required, ESP must be used. It is possible to use 132 AH in conjunction with ESP, but this combination is rarely required. 134 All variants of IPsec have problems with NAT boxes -- see [RFC3715] 135 for details -- but AH is considerably more troublesome. In 136 environments where there is substantial likelihood that the two end- 137 points will be separated by a NAT box -- this includes almost all 138 services involving user-to-server traffic, as opposed to server-to- 139 server traffic -- NAT traversal [RFC3948] should be mandated and AH 140 should be avoided. (Note that [RFC3948] is for ESP only, and cannot 141 be used for AH.) 143 3.2. Transport and Tunnel Mode 145 AH and ESP can both be used in either transport mode or tunnel mode. 146 In tunnel mode, the IPsec header is followed by an inner IP header; 147 this is the normal usage for Virtual Private Networks (VPN), and it 148 is generally required whenever either end of the IPsec-protected path 149 is not the ultimate IP destination, e.g., when IPsec is implemented 150 in a firewall, router, etc. 152 Transport mode is preferred for point-to-point communication, though 153 tunnel mode can be used for this purpose. 155 3.3. Key Management 157 Any cryptographic system requires key management. IPsec provides for 158 both manual and automatic key management schemes. Manual key 159 management is easy; however, it doesn't scale very well. Also, 160 IPsec's replay protection mechanisms are not available if manual key 161 management is used. The need for automatic key exchange is discussed 162 in more detail in [RFC4107]. 164 The primary automated key exchange mechanism for IPsec is the 165 Internet Key Exchange (IKE) [RFC2409]. A new, simpler version of IKE 166 has been approved, but there many existing systems still use IKEv1 167 [RFC4306]. This document does not discuss IKEv2 and IPsecv3. A 168 second mechanism, Kerberized Internet Negotiation of Keys (KINK) 169 [RFC4430], has been defined. It, of course, uses Kerberos, and is 170 suitable if and only if a Kerberos infrastructure is available. 172 If a decision to use IKE is made, the precise mode of operation must 173 be specified as well. IKE can be used in main mode or aggressive 174 mode; both support digital signatures, two different ways of using 175 public key encryption, and shared secrets for authentication. 177 Shared secret authentication is simpler; however, it doesn't scale as 178 well in many-to-many communication scenarios, since each endpoint 179 must share a unique secret with every peer with which it can 180 communicate. Note, though, that using shared secrets in IKE is far 181 preferable to manual keying. 183 In most real-world situations where public key modes of IKE are used, 184 locally-issued certificates are employed. That is, the administrator 185 of the system or network concerned will issue certificates to all 186 authorized users. These certificates are useful only for IPsec. 188 It is sometimes possible to use certificates [RFC3280] from an 189 existing public key infrastructure (PKI) with IKE. In practice, this 190 is rare. Furthermore, there not only is no global PKI covering most 191 Internet endpoints, there probably never will be one. Designing a 192 structure which assumes such a PKI is a mistake. In particular, 193 assuming that an arbitrary node will have an "authentic" certificate, 194 issued by a mutually trusted third party and vouching for that node's 195 identity, is wrong. Again, such a PKI does not and probably will not 196 exist. Public key IKE is generally a good idea, but almost always 197 with locally-issued certificates. 199 Note that public key schemes require a substantial amount of 200 computation. Protocol designers should consider whether or not such 201 computations are feasible on devices of interest to their clientele. 202 Using certificates roughly doubles the number of large 203 exponentiations that must be performed, compared with shared secret 204 versions of IKE. 206 Today, even low-powered devices can generally perform enough 207 computation to set up a limited number of security associations; 208 concentration points, such as firewalls or VoIP servers, may require 209 hardware assists, especially if many peers are expected to create 210 security associations at about the same time. 212 Using any automated key management mechanism can be difficult when 213 trying to protect low-level protocols. For example, even though 214 [RFC2461] specified the use of IPsec to protect IPv6 Neighbor 215 Discovery, it was impossible to do key management: nodes couldn't use 216 IKE because it required IP-level communication, and that isn't 217 possible before Neighbor Discovery associations are set up. 219 3.4. Applications Program Interface (API) 221 It is, in some sense, a misnomer to speak of the API as a part of 222 IPsec, since that piece is missing on many systems. To the extent 223 that it does exist, it isn't standardized. The problem is simple: it 224 is difficult or impossible to request IPsec protection, or to tell if 225 was used for given inbound packets or connections. 227 There are additional problems: 228 o Applications have rarely access to such APIs. Rather, IPsec is 229 usually configured by a system or network administrator. 230 o Applications are unable to verify that IPsec services are being 231 used underneath. 232 o Applications are unaware of the specific identities and properties 233 of the protected channel provided by IPsec. For instance, the 234 IPsec key management mechanisms may be aware of the identity and 235 authorization of the peer, but this information cannot be used by 236 the application, nor linked to application-level decisions, such 237 as access to resources reserved to the entity identified by this 238 identity. 240 Router- or firewall-based IPsec implementations pose even greater 241 problems, since there is no standardized over-the-wire protocol for 242 communicating this information from outboard encryptors to hosts. 244 By contrast, higher-layer security services such as TLS are able to 245 provide the necessary control and assurance. 247 4. Availability of IPsec in Target Devices 249 Although IPsec is now widely implemented, and is available for 250 current releases of most host operating systems, it is less available 251 for embedded systems. Few hubs, network address translators, etc., 252 implement it, especially at the low end. It is generally 253 inappropriate to rely on IPsec when many of the endpoints are in this 254 category. 256 Even for host-to-host use, IPsec availability (and experience, and 257 ease of use) has generally been for VPNs. Hosts that support IPsec 258 for VPN use frequently do not support it on a point-to-point basis, 259 especially via a stable, well-defined API or user interface. 261 Finally, few implementations support multiple layers of IPsec. If a 262 telecommuter is using IPsec in VPN mode to access an organizational 263 network, he or she may not be able to employ a second level of IPsec 264 to protect an application connection to a host within the 265 organization. (We note that such support is, in fact, mandated by 266 Case 4 of Section 4.5 of [RFC2401]. Nevertheless, it is not widely 267 available.) The likelihood of such deployment scenarios should be 268 taken into account when deciding whether or not to mandate IPsec. 270 5. Endpoints 272 [RFC2401] describes many different forms of endpoint identifier. 273 These include source addresses (both IPv4 and IPv6), host names 274 (possibly as embedded in X.500 certificates), and user IDs (again, 275 possibly as embedded in a certificate). Not all forms of identifier 276 are available on all implementations; in particular, user-granularity 277 identification is not common. This is especially a concern for 278 multi-users systems, where it may not be possible to use different 279 certificates to distinguish between traffic from two different users. 281 Again, we note that the ability to provide fine-grained protection, 282 such as keying each connection separately, and with per-user 283 credentials, was one of the original design goals of IPsec. 284 Nevertheless, only a few platforms support it. Indeed, some 285 implementations do not even support using port numbers when deciding 286 whether or not to apply IPsec protection. 288 6. Selectors and the SPD 290 Section 4.4 of [RFC2401] describes the Security Policy Database (SPD) 291 and "selectors" used to decide what traffic should be protected by 292 IPsec. Choices include source and destination addresses (or address 293 ranges), protocol numbers (i.e., 6 for TCP and 17 for UDP), and port 294 numbers for TCP and UDP. Protocols whose protection requirements 295 cannot be described in such terms are poorer candidates for IPsec; in 296 particular, it becomes impossible to apply protection at any finer 297 grain than "destination host". Thus, traffic embedded in an L2TP 298 [RFC2661] session cannot be protected selectively by IPsec above the 299 L2TP layer, because IPsec has no selectors defined that let it peer 300 into the L2TP packet to find the TCP port numbers. Similarly, SCTP 301 [RFC2960] did not exist when [RFC2401] was written; thus, protecting 302 individual SCTP applications on the basis of port number could not be 303 done until a new document was written [RFC3554] that defined new 304 selectors for IPsec, and implementations appeared. 306 Furthermore, in a world that runs to a large extent on dynamically 307 assigned addresses and often uses dynamically assigned port numbers 308 as well, an all-or-nothing policy for VPNs can work well; other 309 policies, however, can be difficult to create in any usable form. 311 The granularity of protection available may have side-effects. If 312 certain traffic between a pair of machines is protected by IPsec, 313 does the implementation permit other traffic to be unprotected, or 314 protected by different policies? Alternatively, if the 315 implementation is such that it is only capable of protecting all 316 traffic or none, does the device have sufficient CPU capacity to 317 encrypt everything? Note that some low-end devices may have limited 318 secure storage capacity for keys, etc. 320 Implementation issues are also a concern here. As before, too many 321 vendors have not implemented the full specification; too many IPsec 322 implementations are not capable of using port numbers in their 323 selectors. Protection of traffic between two hosts is thus on an all 324 or nothing basis when these non-compliant implementations are 325 employed. 327 7. Broadcast and Multicast 329 Although the designers of IPsec tried to leave room for protection of 330 multicast traffic, a complete design wasn't finished until much 331 later. As such, many IPsec implementations do not support multicast. 333 [I-D.ietf-msec-ipsec-extensions] describes extensions to IPsec to 334 support it. Other relevant documents include [RFC3830], [RFC3547], 335 and [RFC4535], 337 Because of the delay, protocol designers who use multicast should 338 consider the availability of these extensions in target platforms of 339 interest. 341 8. Specifying IPsec 343 Despite all of the caveats given above, it may still be appropriate 344 to use IPsec in particular situations. The range of choices make it 345 mandatory to define precisely how IPsec is to be used. Authors of 346 standards documents that rely on IPsec must specify the following: 348 a. What selectors the initiator of the conversation (the client, in 349 client-server architectures) should use? What addresses, port 350 numbers, etc., are to be used? 351 b. What IPsec protocol is to be used: AH or ESP? What mode is to be 352 employed: transport mode or tunnel mode? 353 c. What form of key management is appropriate? 354 d. What form of identification should be used? Choices include IP 355 address, DNS name with or without a user name, and X.500 356 distinguished name. 357 e. If the application server will switch userids (i.e., is a login 358 service of some sort) and user name identification is used, is a 359 new security association negotiated that utilizes a user- 360 granularity certificate? If so, when? 361 f. What form of authentication should be used? Choices include pre- 362 shared secrets and certificates. 363 g. How are the participants authorized to perform the operations 364 that they request? For instance, are all devices with a 365 certificate from a particular source allowed to use any 366 application with with IPsec or access any resource? (This 367 problem can appear with any security service, of course.) 368 h. Which of the many variants of IKE must be supported? Main mode? 369 Aggressive mode? 371 Note that the are two different versions of IKE, IKE and IKEv2. 372 IKEv2 is simpler and cleaner, but is not yet widely available. 373 You must specify which version of IKE you require. 374 i. Is suitable IPsec support available in likely configurations of 375 the products that would have to employ IPsec? 377 9. Example 379 Let us now work through an example based on these guidelines. We 380 will use Border Gateway Protocol (BGP) [RFC4271] to show how to 381 evaluate and specify the use of IPsec for transmission security, 382 rather than the mechanism described in [RFC2385]. Note carefully 383 that we are not saying that IPsec is an appropriate choice here. 384 Rather, we are demonstrating the necessary examination and 385 specification process. Also note that the deeper security issues 386 raised by BGP are not addressed by IPsec or any other transmission 387 security mechanism; see [Kent00a] and [Kent00b] for more details. 389 Selectors BGP runs between manually-configured pairs of hosts 390 on TCP port 179. The appropriate selector would be 391 the pair of BGP speakers, for that port only. Note 392 that the router's "loopback address" is almost 393 certainly the address to use. 394 Mode Transport mode would be the proper choice if IPsec 395 were used. The information being communicated is 396 generally not confidential, so encryption need not 397 be used. Either AH or ESP can be used; if ESP is 398 used, the sender's IP address would need to be 399 checked against the IP address asserted in the key 400 management exchange. (This check is mandated by 401 [RFC2401].) For the sake of interoperability, 402 either AH or ESP would need to be specified as 403 mandatory to implement. 404 Key Management To permit replay detection, an automated key 405 management system should be used, most likely IKE. 406 Again, the RFC author should pick one. 407 Security Policy Connections should be accepted only from the 408 designated peer. (Note that this restriction 409 applies only to BGP. If the router -- or any IPsec 410 host -- runs multiple services with different 411 security needs, each such service requires its own 412 security policy.) 413 Authentication Given the number of BGP-speaking routers used 414 internally by large ISPs, it is likely that shared 415 key mechanisms are inadequate. Consequently, 416 certificate-based IKE must be supported. However, 417 shared secret mode is reasonable on peering links, 418 or (perhaps) on links between ISPs and customers. 419 Whatever scheme is used, it must tie back to a 420 source IP address or AS number in some fashion, 421 since other BGP policies are expressed in these 422 terms. If certificates are used, would they use IP 423 addresses or AS numbers? Which? 425 Availability For this scenario, availability is the crucial 426 question. Do likely BGP speakers -- both backbone 427 routers and access routers -- support the profile of 428 IPsec described above? Will use of IPsec, with its 429 attendant expensive cryptographic operations, raise 430 the issue of new denial of service attacks? The 431 working group and the IESG must make these 432 determinations before deciding to use IPsec to 433 protect BGP. 435 10. Security Considerations 437 IPsec provides transmission security and simple access control only. 438 There are many other dimensions to protocol security that are beyond 439 the scope of this memo, including most notably availability. For 440 example, using IPsec does little to defend against denial of service 441 attacks; in some situations, i.e., on CPU-limited systems, it may 442 contribute to the attacks. Within its scope, the security of any 443 resulting protocol depends heavily on the accuracy of the analysis 444 that resulted in a decision to use IPsec. 446 11. Acknowledgments 448 Ran Atkinson, Lakshminath Dondeti, Barbara Fraser, Paul Hoffman, Russ 449 Housley, Stephen Kent, Eric Fleischman, assorted members of the IESG, 450 and a plethora of others have made many useful suggestions. 452 12. References 454 12.1. Normative References 456 [I-D.ietf-msec-ipsec-extensions] 457 Weis, B., "Multicast Extensions to the Security 458 Architecture for the Internet Protocol", 459 draft-ietf-msec-ipsec-extensions-06 (work in progress), 460 July 2007. 462 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 463 Internet Protocol", RFC 2401, November 1998. 465 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 466 RFC 2402, November 1998. 468 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 469 Payload (ESP)", RFC 2406, November 1998. 471 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 472 (IKE)", RFC 2409, November 1998. 474 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 475 X.509 Public Key Infrastructure Certificate and 476 Certificate Revocation List (CRL) Profile", RFC 3280, 477 April 2002. 479 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 480 Stewart, "On the Use of Stream Control Transmission 481 Protocol (SCTP) with IPsec", RFC 3554, July 2003. 483 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 484 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 485 RFC 3948, January 2005. 487 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 488 Key Management", BCP 107, RFC 4107, June 2005. 490 12.2. Informative References 492 [Bell96] Bellovin, S., "Problem Areas for the IP Security 493 Protocols", Proc. Sixth Usenix Security Symposium pp. 205- 494 214, 1996. 496 [Kent00a] Kent, S., Lynn, C., and K. Seo, "Secure Border Gateway 497 Protocol (Secure-BGP)", IEEE Journal on Selected Areas in 498 Communications 18:4 pp. 582-592, 2000. 500 [Kent00b] Kent, S., Lynn, C., Mikkelson, J., and K. Seo, "Secure 501 Border Gateway Protocol (Secure-BGP) -- Real World 502 Performance and Deployment Issues", Proc. Network and 503 Distributed System Security Symposium (NDSS), 2000. 505 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 506 Signature Option", RFC 2385, August 1998. 508 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 509 Discovery for IP Version 6 (IPv6)", RFC 2461, 510 December 1998. 512 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 513 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 514 RFC 2661, August 1999. 516 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 517 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 518 Zhang, L., and V. Paxson, "Stream Control Transmission 519 Protocol", RFC 2960, October 2000. 521 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 522 Group Domain of Interpretation", RFC 3547, July 2003. 524 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 525 Text on Security Considerations", BCP 72, RFC 3552, 526 July 2003. 528 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 529 (NAT) Compatibility Requirements", RFC 3715, March 2004. 531 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 532 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 533 August 2004. 535 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 536 Protocol 4 (BGP-4)", RFC 4271, January 2006. 538 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 539 Internet Protocol", RFC 4301, December 2005. 541 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 542 December 2005. 544 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 545 RFC 4303, December 2005. 547 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 548 RFC 4306, December 2005. 550 [RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, 551 "Kerberized Internet Negotiation of Keys (KINK)", 552 RFC 4430, March 2006. 554 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 555 "GSAKMP: Group Secure Association Key Management 556 Protocol", RFC 4535, June 2006. 558 Author's Address 560 Steven M. Bellovin 561 Columbia University 562 1214 Amsterdam Avenue 563 MC 0401 564 New York, NY 10027 565 US 567 Phone: +1 212 939 7149 568 Email: bellovin@acm.org 570 Full Copyright Statement 572 Copyright (C) The IETF Trust (2008). 574 This document is subject to the rights, licenses and restrictions 575 contained in BCP 78, and except as set forth therein, the authors 576 retain all their rights. 578 This document and the information contained herein are provided on an 579 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 580 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 581 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 582 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 583 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 584 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 586 Intellectual Property 588 The IETF takes no position regarding the validity or scope of any 589 Intellectual Property Rights or other rights that might be claimed to 590 pertain to the implementation or use of the technology described in 591 this document or the extent to which any license under such rights 592 might or might not be available; nor does it represent that it has 593 made any independent effort to identify any such rights. Information 594 on the procedures with respect to rights in RFC documents can be 595 found in BCP 78 and BCP 79. 597 Copies of IPR disclosures made to the IETF Secretariat and any 598 assurances of licenses to be made available, or the result of an 599 attempt made to obtain a general license or permission for the use of 600 such proprietary rights by implementers or users of this 601 specification can be obtained from the IETF on-line IPR repository at 602 http://www.ietf.org/ipr. 604 The IETF invites any interested party to bring to its attention any 605 copyrights, patents or patent applications, or other proprietary 606 rights that may cover technology that may be required to implement 607 this standard. Please address the information to the IETF at 608 ietf-ipr@ietf.org. 610 Acknowledgment 612 Funding for the RFC Editor function is provided by the IETF 613 Administrative Support Activity (IASA).