idnits 2.17.1 draft-bellovin-useipsec-09.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 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 592. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 605. 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 (July 10, 2008) is 5769 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 July 10, 2008 5 Practice 6 Expires: January 11, 2009 8 Guidelines for Mandating the Use of IPsec Version 2 9 draft-bellovin-useipsec-09.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 January 11, 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. Mandating 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 Suppose that the designers of the Border Gateway Protocol (BGP) 380 [RFC4271] wished to use IPsec for security, rather than the mechanism 381 described in [RFC2385]. Does it meet these criteria? (Note that the 382 deeper security issues raised by BGP are not addressed by IPsec or 383 any other transmission security mechanism. See [Kent00a] and 384 [Kent00b] for more details.) 386 Selectors BGP runs between manually-configured pairs of hosts 387 on TCP port 179. The appropriate selector would be 388 the pair of BGP speakers, for that port only. Note 389 that the router's "loopback address" is almost 390 certainly the address to use. 391 Mode Transport mode would be the proper choice if IPsec 392 were used. The information being communicated is 393 generally not confidential, so encryption need not 394 be used. Either AH or ESP can be used; if ESP is 395 used, the sender's IP address would need to be 396 checked against the IP address asserted in the key 397 management exchange. (This check is mandated by 398 [RFC2401].) For the sake of interoperability, 399 either AH or ESP would need to be specified as 400 mandatory to implement. 401 Key Management To permit replay detection, an automated key 402 management system should be used, most likely IKE. 403 Again, the RFC author should pick one. 404 Security Policy Connections should be accepted only from the 405 designated peer. (Note that this restriction 406 applies only to BGP. If the router -- or any IPsec 407 host -- runs multiple services with different 408 security needs, each such service requires its own 409 security policy.) 410 Authentication Given the number of BGP-speaking routers used 411 internally by large ISPs, it is likely that shared 412 key mechanisms are inadequate. Consequently, 413 certificate-based IKE must be supported. However, 414 shared secret mode is reasonable on peering links, 415 or (perhaps) on links between ISPs and customers. 416 Whatever scheme is used, it must tie back to a 417 source IP address or AS number in some fashion, 418 since other BGP policies are expressed in these 419 terms. If certificates are used, would they use IP 420 addresses or AS numbers? Which? 422 Availability For this scenario, availability is the crucial 423 question. Do likely BGP speakers -- both backbone 424 routers and access routers -- support the profile of 425 IPsec described above? Will use of IPsec, with its 426 attendant expensive cryptographic operations, raise 427 the issue of new denial of service attacks? The 428 working group and the IESG must make these 429 determinations before deciding to use IPsec to 430 protect BGP. 432 10. Security Considerations 434 IPsec provides transmission security and simple access control only. 435 There are many other dimensions to protocol security that are beyond 436 the scope of this memo, including most notably availability. For 437 example, using IPsec does little to defend against denial of service 438 attacks; in some situations, i.e., on CPU-limited systems, it may 439 contribute to the attacks. Within its scope, the security of any 440 resulting protocol depends heavily on the accuracy of the analysis 441 that resulted in a decision to use IPsec. 443 11. Acknowledgments 445 Ran Atkinson, Lakshminath Dondeti, Barbara Fraser, Paul Hoffman, Russ 446 Housley, Stephen Kent, Eric Fleischman, assorted members of the IESG, 447 and a plethora of others have made many useful suggestions. 449 12. References 451 12.1. Normative References 453 [I-D.ietf-msec-ipsec-extensions] 454 Weis, B., "Multicast Extensions to the Security 455 Architecture for the Internet Protocol", 456 draft-ietf-msec-ipsec-extensions-06 (work in progress), 457 July 2007. 459 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 460 Internet Protocol", RFC 2401, November 1998. 462 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 463 RFC 2402, November 1998. 465 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 466 Payload (ESP)", RFC 2406, November 1998. 468 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 469 (IKE)", RFC 2409, November 1998. 471 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 472 X.509 Public Key Infrastructure Certificate and 473 Certificate Revocation List (CRL) Profile", RFC 3280, 474 April 2002. 476 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 477 Stewart, "On the Use of Stream Control Transmission 478 Protocol (SCTP) with IPsec", RFC 3554, July 2003. 480 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 481 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 482 RFC 3948, January 2005. 484 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 485 Key Management", BCP 107, RFC 4107, June 2005. 487 12.2. Informative References 489 [Bell96] Bellovin, S., "Problem Areas for the IP Security 490 Protocols", Proc. Sixth Usenix Security Symposium pp. 205- 491 214, 1996. 493 [Kent00a] Kent, S., Lynn, C., and K. Seo, "Secure Border Gateway 494 Protocol (Secure-BGP)", IEEE Journal on Selected Areas in 495 Communications 18:4 pp. 582-592, 2000. 497 [Kent00b] Kent, S., Lynn, C., Mikkelson, J., and K. Seo, "Secure 498 Border Gateway Protocol (Secure-BGP) -- Real World 499 Performance and Deployment Issues", Proc. Network and 500 Distributed System Security Symposium (NDSS), 2000. 502 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 503 Signature Option", RFC 2385, August 1998. 505 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 506 Discovery for IP Version 6 (IPv6)", RFC 2461, 507 December 1998. 509 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 510 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 511 RFC 2661, August 1999. 513 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 514 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 515 Zhang, L., and V. Paxson, "Stream Control Transmission 516 Protocol", RFC 2960, October 2000. 518 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 519 Group Domain of Interpretation", RFC 3547, July 2003. 521 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 522 Text on Security Considerations", BCP 72, RFC 3552, 523 July 2003. 525 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 526 (NAT) Compatibility Requirements", RFC 3715, March 2004. 528 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 529 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 530 August 2004. 532 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 533 Protocol 4 (BGP-4)", RFC 4271, January 2006. 535 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 536 Internet Protocol", RFC 4301, December 2005. 538 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 539 December 2005. 541 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 542 RFC 4303, December 2005. 544 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 545 RFC 4306, December 2005. 547 [RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, 548 "Kerberized Internet Negotiation of Keys (KINK)", 549 RFC 4430, March 2006. 551 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 552 "GSAKMP: Group Secure Association Key Management 553 Protocol", RFC 4535, June 2006. 555 Author's Address 557 Steven M. Bellovin 558 Columbia University 559 1214 Amsterdam Avenue 560 MC 0401 561 New York, NY 10027 562 US 564 Phone: +1 212 939 7149 565 Email: bellovin@acm.org 567 Full Copyright Statement 569 Copyright (C) The IETF Trust (2008). 571 This document is subject to the rights, licenses and restrictions 572 contained in BCP 78, and except as set forth therein, the authors 573 retain all their rights. 575 This document and the information contained herein are provided on an 576 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 577 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 578 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 579 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 580 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 581 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 583 Intellectual Property 585 The IETF takes no position regarding the validity or scope of any 586 Intellectual Property Rights or other rights that might be claimed to 587 pertain to the implementation or use of the technology described in 588 this document or the extent to which any license under such rights 589 might or might not be available; nor does it represent that it has 590 made any independent effort to identify any such rights. Information 591 on the procedures with respect to rights in RFC documents can be 592 found in BCP 78 and BCP 79. 594 Copies of IPR disclosures made to the IETF Secretariat and any 595 assurances of licenses to be made available, or the result of an 596 attempt made to obtain a general license or permission for the use of 597 such proprietary rights by implementers or users of this 598 specification can be obtained from the IETF on-line IPR repository at 599 http://www.ietf.org/ipr. 601 The IETF invites any interested party to bring to its attention any 602 copyrights, patents or patent applications, or other proprietary 603 rights that may cover technology that may be required to implement 604 this standard. Please address the information to the IETF at 605 ietf-ipr@ietf.org. 607 Acknowledgment 609 Funding for the RFC Editor function is provided by the IETF 610 Administrative Support Activity (IASA).