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