idnits 2.17.1 draft-touch-anonsec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (May 5, 2004) is 7288 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2385 (ref. '2') (Obsoleted by RFC 5925) ** Downref: Normative reference to an Informational RFC: RFC 1337 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 793 (ref. '6') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (ref. '7') (Obsoleted by RFC 7323) ** Downref: Normative reference to an Informational RFC: RFC 1810 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 1263 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 2960 (ref. '12') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 2401 (ref. '14') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '15') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '16') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '17') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '18') (Obsoleted by RFC 4306) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-00 == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-06 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-02 == Outdated reference: A later version (-11) exists of draft-ietf-ipsec-rfc2402bis-07 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-13 Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Touch 3 Internet-Draft USC/ISI 4 Expires: November 3, 2004 May 5, 2004 6 ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks 7 draft-touch-anonsec-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 except that the right to 13 produce derivative works is not granted. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 3, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 Recent attacks on core Internet infrastructure indicate an increased 39 vulnerability of TCP connections to spurious resets (RSTs). TCP has 40 always been susceptible to such RST spoof attacks, which were 41 indirectly protected by checking that the RST sequence number was 42 inside the current receive window, as well as via the obfuscation of 43 TCP endpoint and port numbers. For pairs of well-known endpoints 44 often over predictable port pairs, such as BGP, increases in the path 45 bandwidth-delay product of a connection have sufficiently increased 46 the receive window space that off-path third parties can guess a 47 viable RST sequence number. This document addresses this 48 vulnerability, discussing proposed solutions at the transport level 49 and their inherent challenges, as well as existing network level 50 solutions and the feasibility of their deployment. Finally, it 51 proposes an extension to IPsec configuration called ANONsec that 52 intends to efficiently and scalably secure any transport protocol 53 from such off-path third-party spoofing attacks. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1 Recent BGP Attacks Using TCP RSTs . . . . . . . . . . . . 5 60 2.2 TCP RST Vulnerability . . . . . . . . . . . . . . . . . . 6 61 2.3 What Changed -- the Ever Opening Window . . . . . . . . . 6 62 3. Proposed solutions . . . . . . . . . . . . . . . . . . . . . . 10 63 3.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . 10 64 3.1.1 TCP MD5 Authentication . . . . . . . . . . . . . . . . 10 65 3.1.2 TCP RST Window Attenuation . . . . . . . . . . . . . . 10 66 3.1.3 TCP Timestamp Authentication . . . . . . . . . . . . . 11 67 3.1.4 Other TCP Cookies . . . . . . . . . . . . . . . . . . 12 68 3.1.5 Other TCP Considerations . . . . . . . . . . . . . . . 12 69 3.1.6 Other Protocols . . . . . . . . . . . . . . . . . . . 13 70 3.2 Network Layer (IP) . . . . . . . . . . . . . . . . . . . . 13 71 4. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.1 Transport Layer (e.g., TCP) . . . . . . . . . . . . . . . 14 73 4.2 Network Layer (IP) . . . . . . . . . . . . . . . . . . . . 15 74 4.3 Application Layer . . . . . . . . . . . . . . . . . . . . 16 75 4.4 Shim Transport/Application Layer . . . . . . . . . . . . . 16 76 4.5 Link Layer . . . . . . . . . . . . . . . . . . . . . . . . 16 77 4.6 Need for Alternate Security Levels . . . . . . . . . . . . 16 78 5. Anonymous IPsec (ANONsec) . . . . . . . . . . . . . . . . . . 18 79 5.1 Overview of ANONsec . . . . . . . . . . . . . . . . . . . 18 80 5.1.1 Anonymous IKE (ANONike) . . . . . . . . . . . . . . . 18 81 5.1.2 Anonymous Authentication Modes . . . . . . . . . . . . 18 82 5.2 Benefits of ANONsec . . . . . . . . . . . . . . . . . . . 20 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 88 9.2 Informative References . . . . . . . . . . . . . . . . . . . 25 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 90 Intellectual Property and Copyright Statements . . . . . . . . 26 92 1. Introduction 94 The Internet infrastructure has recently seen a flurry of attacks on 95 BGP connections between core routers using an attack known for nearly 96 six years [1][2]. These connections, typically using TCP, can be 97 susceptible to off-path (non man-in-the-middle) third-party reset 98 (RST) segments, which terminate the TCP connection. BGP routers react 99 to a terminated TCP connection in various ways, ranging from 100 restarting the connection to deciding that the other router is 101 unreachable and thus flushing the BGP routes. The impact on Internet 102 infrastructure has been substantial, and warrants immediate 103 attention. 105 TCP, like many other protocols, has been susceptible to off-path 106 third-party attacks. Such attacks rely on the increase of commodity 107 platforms supporting public access to previously privileged 108 resources, such as root-level access. Given such access, it is 109 trivial for anyone to generate a packet with any header desired. 110 This, coupled with the lack of sufficient ingress filtering to drop 111 such spoofed traffic, has resulted in an increase in off-path 112 third-party spoofing attacks. As a result, a number of proposed 113 solutions have been developed in collaboration among the Internet 114 research and commercial router communities. The foremost of these 115 modifies TCP processing to defeat off-path third-party spoofs by 116 further limiting viable sequence numbers in the RST segment. 118 Such modifications are, at best, temporary patches to the ubiquitous 119 vulnerability to spoofing attacks. The obvious solution to spoofing 120 is to validate the segments of a connection, either at the transport 121 level (which the patch provides, weakly) or the network level. IPsec 122 already intends to provide authentication of a network level packet 123 and its contents, but its deployment overhead can be prohibitive. 124 E.g., it is not feasible for BGP routers to be configured with the 125 appropriate certificate authorities of hundreds of thousands of peers 126 [AUTH - this is from posts on the IPsec mailing list; does anyone 127 have a confirmation?], many of whom need to be configured rapidly 128 without external assistance. 130 The remainder of this document outlines the attack in detail, and 131 describes a new solution -- ANONsec: Anonymous IPsec. ANONsec allows 132 IPsec association establishment, e.g., via IKE, without needing 133 pre-shared keys (e.g., for new certificate authorities). ANONsec 134 establishes a shared cookie between endpoints, sufficient to assert, 135 "the other end is reachable and I know it from the cookie we share." 136 Such security, together with the use of a range of authentication, 137 including null authentication, provides efficient and scalable 138 protection from off-path (and, depending on configuration, 139 man-in-the-middle) third-party attacks for all protocols from the 140 network layer up. 142 2. Background 144 The recent attacks on BGP have raised the issue of TCP's 145 vulnerability to off-path third-party spoofing attacks [1]. A number 146 of such attacks have been known for several years, including sending 147 RSTs, SYNs, and even ACKs in an attempt to affect an existing 148 connection or to load down servers. Overall, such attacks are 149 countered by the use of some form of authentication at the network 150 (IPsec), transport (SYN cookies), or other layers. TCP already 151 includes a weak form of such authentication in its check of segment 152 sequence numbers. Increases in the bandwidth-delay product for 153 certain long connections has made sufficiently weakened this 154 authentication in recent weeks, rendering it moot. 156 2.1 Recent BGP Attacks Using TCP RSTs 158 BGP represents a particular vulnerability to spoofing attacks. Most 159 TCP connections are protected by multiple levels of obfuscation 160 except at the endpoints of the connection: 162 o Both endpoint addresses are usually not well-known; although 163 server addresses are advertised, clients are somewhat anonymous. 165 o Both port numbers are usually not well-known; the server's usually 166 is advertised (representing the service), but the client's is 167 typically sufficiently unpredictable to an off-path third-party. 169 o Valid sequence number space is not well-known. 171 o Connections are relatively short-lived and valid sequence space 172 changes, so any guess of the above information is unlikely to be 173 useful. 175 BGP (somewhat) uniquely represents an exception to the above 176 criteria. Both endpoints are well-known, notably as part of an AS 177 path. The destination port is typically fixed to indicate the BGP 178 service. The source port used by a BGP router is sometimes fixed and 179 advertised to enable firewall configuration; even when not fixed, 180 there are only 65,000 valid source ports which may be exhaustively 181 attacked. Connections are long-lived, and as noted before some BGP 182 implementations interpret successive TCP connection failures as 183 routing failures, discarding the corresponding routing information. 184 As importantly and as will be shown below, the valid sequence number 185 space once thought to provide some protection has been rendered 186 useless by increasing congestion window sizes. 188 2.2 TCP RST Vulnerability 190 TCP has a known vulnerability to third-party spoofed segments. SYN 191 flooding consumes server resources in half-open connections, 192 affecting the server's ability to open new connections. ACK spoofing 193 can cause connections to transmit too much data too quickly, creating 194 network congestion and segment loss, causing connections to slow to a 195 crawl. In the most recent attacks on BGP, RSTs cause connections to 196 be dropped. As noted earlier, some BGP implementations interpret TCP 197 connection termination, or a series of such failures, as a network 198 failure. This causes routers to drop the BGP routing information 199 already exchanged, in addition to inhibiting their ongoing exchanges. 200 The result can affect routing paths throughout the Internet. 202 The dangerous effects of RSTs on TCP have been known for many years, 203 even when used by the legitimate endpoints of a connection. TCP RSTs 204 cause the receiver to drop all connection state; because the source 205 is not required to maintain a TIME_WAIT state, such a RST can cause 206 premature reuse of address/port pairs, potentially allowing segments 207 from a previous connection to contaminate the data of a new 208 connection, known as TIME_WAIT assassination [3]. In this case, 209 assassination occurs inadvertently as the result of duplicate 210 segments from a legitimate source, and can be avoided by blocking RST 211 processing while in TIME_WAIT. However, assassination can be useful 212 to deliberately reduce the state held at servers; this requires that 213 the source of the RSTs go into TIME_WAIT state to avoid such hazards, 214 and that RSTs are not blocked in the TIME_WAIT state [4]. 216 Firewalls and load balancers, so-called 'middleboxes', sometimes emit 217 RSTs on behalf of transited connections to optimize server 218 performance [5]. This is a 'man in the middle' RST attack, where the 219 RSTs are sent for benign or beneficial intent. There are numerous 220 hazards with such use of RSTs, outlined in that RFC. 222 2.3 What Changed -- the Ever Opening Window 224 RSTs represent a hazard to TCP, especially when completely unchecked. 225 Fortunately, there are a number of obfuscation mechanisms that make 226 it difficult for off-path third parties to forge (spoof) valid RSTs, 227 as noted earlier. We have already shown it is easy to learn both 228 endpoint addresses and ports for some protocols, notably BGP. The 229 final obfuscation is the sequence number. 231 TCP segments include a sequence number which enables out-of-order 232 receiver processing, as well as duplicate detection. The sequence 233 number space is also used to manage congestion, and indicates the 234 index of the next byte to be transmitted or received. For RSTs, this 235 is relevant because legitimate RSTs use the next sequence number in 236 the transmitter window, and the receiver checks that incoming RSTs 237 have a sequence number in the expected receive window. Such 238 processing is intended to eliminate duplicate segments (somewhat moot 239 for RSTs, though), and to drop RSTs which were part of previous 240 connections. 242 TCP uses two window mechanisms, a primary mechanism which uses a 243 space of 32 bits, and a secondary mechanism which scales this window 244 [6][7]. The valid receive window is a fraction, not to exceed 245 approximately half, of this space, or ~2,000,000,000. Under typical 246 use, the majority of TCP connections open to a very small fraction of 247 this space, e.g., 10,000-60,000 (approximately 5-100 segments). On a 248 low-loss path, the window should open to around the path 249 bandwidth-delay product, including buffering delays (assume 1 packet/ 250 hop). Many paths in the Internet have end-to-end bandwidths of under 251 1 Mbps, latencies under 100ms, and are under 15 hops, resulting in 252 fairly small windows as above (under 35,000 bytes). Under these 253 conditions, and further assuming that the initial sequence number is 254 suitably (pseudo-randomly) chosen, a valid guessed sequence number 255 would have odds of 1 in 57,000. Put differently, a blind (non 256 man-in-the-middle) attacker would need to send 57,000 RSTs with 257 suitably spaced sequence number guesses to successfully reset a 258 connection. At 1 Mbps, 57,000 (40 byte) RSTs would take over 50 259 minutes to transmit, and, as noted earlier, most current connections 260 are fairly brief by comparison. 262 Recent use of high bandwidth paths of 10 Gbps and result in 263 bandwidth-delay products over 125 MB - approximately 1/10 of TCP's 264 overall window size excluding scale, assuming the receiver allocates 265 sufficient buffering (to be discussed later). Even under networks 266 that are ten times slower (1 Gbps), the active receiver window covers 267 1/100th of the overall window size. At these speeds, it takes only 268 10-100 packets, or under 32 microseconds, to correctly guess a valid 269 sequence number and kill a connection. A table of corresponding 270 exposure to various amounts of RSTs is shown below, for various line 271 rates, assuming the more conventional 100ms latencies: 273 BW BW*delay RSTs needed Time needed 274 ------------------------------------------------------------ 275 10 Gbps 125 MB 35 1 us (microsecond) 276 1 Gbps 12.5 MB 344 110 us 277 100 Mbps 1.25 MB 3,436 10 ms (millisecond) 278 10 Mbps 0.125 MB 34,360 1 second 279 1 Mbps 0.0125 MB 343,598 2 minutes 280 100 Kbps 0.00125 MB 3,435,974 3 hours 282 Figure 1: Time needed to kill a connection 284 This table demonstrates that the effect of bandwidth on the 285 vulnerability is squared; for every increase in bandwidth, there is a 286 linear decrease in the number of sequence number guesses needed, as 287 well as a linear decrease in the time needed to send a set of 288 guesses. Notably, as inter-router link bandwidths approach 1 Mbps, an 289 'exhaustive' attack becomes practical. Checking that the RST sequence 290 number is somewhere in the valid window (bw*delay) out of the overall 291 window (2^32) is an insufficient obfuscation. 293 Note that this table makes a number of assumptions: 295 1. the overall bandwidth-delay product is relatively fixed 297 2. traffic losses are negligible (insufficient to affect the 298 congestion window over most of the connection) 300 3. the receive socket buffers do not limiting the receive window 302 4. the attack bandwidth is similar to the end-to-end path bandwidth 304 Of these assumptions, the last two are more notable. The issue of 305 receive socket buffers will be addressed later. The issue of the 306 attack bandwidth is considered reasonable as follows: 308 1. RSTs are substantially easier to send than data; they can be 309 precomputed and they are smaller than data packets (40 bytes). 311 2. although susceptible connections use somewhat less ubiquitous 312 high-bandwidth paths, the attack may be distributed, at which 313 point only the ingress link of the attack is the primary 314 limitation 316 3. for the purposes of the above table, we assume that the ingress 317 at the attack has the same bandwidth as the path, as an 318 approximation 320 The previous sections discussed the nature of the recent attacks on 321 BGP due to the vulnerability of TCP to RST spoofing attacks, due 322 largely to recent increases in the fraction of the TCP window space 323 in use for a single, long-lived connection. 325 3. Proposed solutions 327 TCP currently authenticates received RSTs using the address and port 328 pair numbers, and checks that the sequence number is inside the valid 329 receiver window. The previous section demonstrated how TCP has become 330 more vulnerable to RST spoofing attacks due to the increases in the 331 receive window size. There are a number of current and proposed 332 solutions to this vulnerability, all centering on increasing the 333 authentication of received RSTs. 335 3.1 Transport Layer 337 The transport layer represents the last place that segments can be 338 authenticated before they affect connection management. TCP has a 339 variety of current and proposed mechanisms to increase the 340 authentication of segments, protecting against both off-path 341 third-party spoofs and man-in-the-middle attacks. SCTP also has 342 mechanisms to authenticate segments. 344 3.1.1 TCP MD5 Authentication 346 An extension to TCP supporting MD5 authentication was developed 347 around six years ago specifically to authenticate BGP connections 348 [2]. The extension relies on a pre-shared secret key to authenticate 349 the entire TCP segment, including the data, TCP header, and TCP 350 pseudo-header (certain fields of the IP header). All segments are 351 protected, including RSTs, which are accepted only when their 352 signature matches. This option, although widely deployed in Internet 353 routers, is considered undeployable for widespread use because the 354 need for pre-shared keys. It further is considered computationally 355 expensive for either hosts or routers due to the overhead of MD5 356 [8][9]. 358 3.1.2 TCP RST Window Attenuation 360 A recent proposal extends TCP to further constrain received RST to 361 match the expected next sequence number [20]. This restores TCP's 362 resistance to spurious RSTs, effectively limiting the receive window 363 for RSTs to a single number. As a result, an attacker would need to 364 send 2^32 different packets to correctly guess the sequence number. 365 The extension further modifies the RST receiver to react to 366 incorrectly-numbered RSTs, by sending a zero-length ACK. If the RST 367 source is legitimate, upon receipt of an ACK the closed source would 368 presumably emit a RST with the sequence number matching the ACK, 369 correctly resetting the intended recipient. There are a number of 370 concerns with this proposal, including the platitude "think twice 371 before modifying TCP, then don't" [10], notably because this 372 modification adds arcs to the TCP state diagram (in contrast to 373 adding MD5 signatures, which is orthogonal to the state machine 374 altogether). For example, there may be complications between RSTs of 375 different connections between the same pair of endpoints because RSTs 376 flush the TIME-WAIT (as mentioned earlier). Further, this modifies 377 TCP so that under some circumstances a RST causes a reply, in 378 violation of generally accepted practice, if not gentle 379 recommendation. The advantage to this proposal is that it can be 380 deployed incrementally and has benefit to the endpoint on which it is 381 deployed. 383 A variant of this proposal uses a different value to attenuate the 384 window of viable RSTs. It requires RSTs to carry the initial sequence 385 number rather than the next expected sequence number, i.e., the value 386 negotiated on connection establishment [11]. This proposal has the 387 advantage of using an explicitly negotiated value, but at the cost of 388 changing the behavior of an unmodified endpoint to a currently valid 389 RST. It would thus be more difficult, without additional mechanism, 390 to deploy incrementally. 392 The most obvious other variant of this proposal involves increasing 393 TCP's window space, rather than decreasing the valid range for RSTs, 394 i.e., increasing the sequence space from 32 bits to 64 bits. This has 395 the equivalent effect - the ratio of the valid sequence numbers for 396 any segment to the overall sequence number space is significantly 397 reduced. The use of the larger space, as with current schemes to 398 establish weak authentication using initial sequence numbers (ISNs), 399 is contingent on using suitably random values for the ISN. Such 400 randomness adds additional complexity to TCP both in specification 401 and implementation, and provides only very weak authentication at 402 best. While there are many reasons to increase the TCP sequence 403 number space, we believe authentication is not one of them. Finally, 404 such a modification is not obviously backward compatible, and would 405 be thus difficult to deploy. 407 3.1.3 TCP Timestamp Authentication 409 Another way to authenticate TCP segments is to utilize its timestamp 410 option, using the value as a sort of authentication [11]. This 411 requires that the receiver TCP discard values whose timestamp is 412 outside the accepted window, which is derived from the timestamps of 413 other packets from the same connection. This technique uses an 414 existing TCP option, but also requires modified RST processing and 415 may be difficult to deploy incrementally without further 416 modifications. Additionally, the timestamp value may be easier to 417 guess because it is derived from a predictable value. 419 3.1.4 Other TCP Cookies 421 All of the above techniques are variants of cookies, otherwise 422 nonsensical data whose value is used to validate the packet. In the 423 case of MD5 checksums, the cookie is computed based on a shared 424 secret. Even a signature can be guessed, and presents a 1 in 425 2^(cookie length) probability of attack anyway. The primary 426 difference is that MD5 signatures are effectively one-time cookies, 427 not predictable based on man-in-the-middle snooping. Window 428 attenuation sequence numbers can be guessed by snooping the sequence 429 number of current packets, and timestamps can may be guessed even 430 more remotely. These variants of cookies are similar in spirit to TCP 431 SYN cookies, again patching a vulnerability to off-path third-party 432 spoofing attacks based on a (fairly weak, excepting MD5) form of 433 authentication. Another form of cookie is the source port itself, 434 which can be randomized but provides only 16 bits of protection 435 (65,000 combinations), which may be exhaustively attacked. This can 436 be combined with destination port randomization as well, but that 437 would require a separate coordination mechanism (so both parties know 438 which ports to use), which is equivalent to (and as infeasible for 439 large-scale deployments as) exchanging a shared secret. 441 3.1.5 Other TCP Considerations 443 The analysis of the potential for RST spoofing above assumes that the 444 receive window opens to the maximum extent suggested by the 445 bandwidth-delay product of the end-to-end path, and that the window 446 opens to an appreciable fraction of the overall sequence number 447 space. As noted earlier, for most common cases, connections are too 448 brief or over bandwidths too low to for such a large window to occur. 449 Expanding TCP's sequence number space is a direct way to further 450 avoid such vulnerability, even for long connections over emerging 451 bandwidths. 453 Finally, it is often sufficient for the endpoint to limit the receive 454 window in other ways, notably using 'socket options'. If the receive 455 socket buffer is limited, e.g., to the ubiquitous default of 65KB, 456 the receive window cannot grow to vulnerable sizes even for very long 457 connections over very high bandwidths. The consequence is lower 458 sustained throughput, where only one window's worth of data per round 459 trip time (RTT) is exchanged. Although this will keep the connection 460 open longer, it also reduces the receive window; for long-lived 461 connections with continuous sourced data, this may continue to 462 present an attack opportunity, albeit a sparse and slow-moving 463 target. For the most recent case where BGP data is being exchanged 464 between Internet routers, the data is bursty and the aggregate 465 traffic is small (i.e., unlikely to cover a substantial portion of 466 the sequence space, even if long-lived), so is difficult to consider 467 where smaller receive buffers would not sufficiently address the 468 immediate problem. 470 3.1.6 Other Protocols 472 Segment authentication has been addressed at the transport layer in 473 other protocols. Both SCTP and DCCP* include cookies for connection 474 establishment and uses them to authenticate a variety of other 475 control messages [12][21]. The inclusion of such mechanism at the 476 transport protocol, although emerging as standard practice, 477 unnecessarily complicates the design and implementation of new 478 protocols. As new attacks are discovered (SYN floods, RSTs, etc.), 479 each protocol must be modified individually to compensate. We 480 consider a network solution more appropriate and efficient. 482 *[AUTH - DCCP may be removing cookies from the spec for the 483 redundancies discussed above, because the use of cookies at the 484 transport layer primarily supports connection mobility (a design goal 485 of SCTP, but not DCCP) rather than security. 487 3.2 Network Layer (IP) 489 TCP is susceptible to RSTs, but also to other spoofing and 490 man-in-the-middle attacks, including SYN attacks. Other transport 491 protocols, such as UDP and RTP are equally susceptible. Although 492 emerging transport protocols attempt to defeat such attacks at the 493 transport layer, it is clear that such attacks are fundamentally a 494 network layer issue. The packet is coming from an endpoint who is 495 spoofing another endpoint, either upstream or somewhere else in the 496 Internet. IPsec was designed specifically to establish and enforce 497 authentication of a packet's source and contents, which most 498 directly, explicitly, and completely addresses this security 499 vulnerability. 501 The larger problem with IPsec is that of CA key distribution and use. 502 IPsec is often cumbersome, and has only recently been supported in 503 many end-system operating systems. More importantly, it relies on 504 signed X.509 certificates to establish and exchange keying 505 information (e.g., via IKE). These present challenges when using 506 IPsec to secure traffic to a well-known server, whose clients may not 507 support IPsec or may not have registered with a previously-known 508 certificate authority (CA). 510 4. Issues 512 There are a number of existing and proposed solutions addressing the 513 vulnerability of transport protocols in general, and TCP in specific, 514 to off-path third-party spoofing attacks. As shown, these operate at 515 the transport or network layer. These solutions are not a sufficient 516 long-term strategy to dealing with such attacks, however. Transport 517 solutions require pervasive modification of every transport protocol 518 and address the problem of packet origin identification at the wrong 519 layer. Current network solutions are computationally intensive and 520 require pervasive registration of certificate authorities with every 521 possible endpoint. Neither application-layer nor link-layer solutions 522 suffice to protect either the network or transport layers. This 523 section explains these observations in detail, in advance of 524 presenting a modified network layer solution called ANONsec. 526 4.1 Transport Layer (e.g., TCP) 528 Transport solutions rely on shared cookies to authenticate segments, 529 including data, transport header, and even pseudo-header (e.g., fixed 530 portions of the outer IP header in TCP). Because the Internet relies 531 on stateless network protocols, it makes sense to rely on state 532 establishment and maintenance available in some transport layers not 533 only for the connection but for authentication state. Three-way 534 handshakes and heartbeats can be used to negotiate authentication 535 state in conjunction with connection parameters, which can be stored 536 with connection state easily. 538 As noted earlier, transport layer solutions require pervasive 539 modification of all transport protocols to include authentication. 540 Not all transport layers support negotiated endpoint state (e.g., 541 UDP), and legacy protocols are notoriously hard to safely augment 542 (e.g., TCP). Not all authentication solutions are created equal 543 either, and relying on a variety of transport solutions exposes 544 end-systems to increased potential for incorrectly specified or 545 implemented solutions. Transport authentication has often been 546 developed piece-wise, in response to specific attacks, e.g., SYN 547 cookies and RST window attenuation [13][20]. 549 Transport layer solutions are not only per-protocol, but often 550 per-connection. Each connection needs to negotiate and maintain 551 authentication state separately. Overhead is not amortized over 552 multiple connections - this includes overheads in packet exchanges, 553 design complexity, and implementation complexity. Finally, because 554 the authentication happens later in packet processing than is 555 required, additional endpoint resources are consumed needlessly, 556 e.g., in demultiplexing received packets, indexing connection 557 identifiers, etc. 559 4.2 Network Layer (IP) 561 A network layer solution avoids the hazards of multiple transport 562 variants, using a single shared endpoint authentication mechanism 563 early in receiver packet processing to discard unauthenticated 564 packets quickly. Network solutions protect all transport protocols, 565 including both legacy and emerging protocols, and reduces the 566 complexity of these protocols as well. A shared solution also reduces 567 protocol overhead, and decouples the management (and refreshing) of 568 authentication state from that of individual transport connections. 569 Finally, a network layer solution protects not only the transport 570 layer but the network layer as well, e.g., from ICMP, IGMP, etc. 571 spoofing attacks. 573 The ubiquitous protocol for network layer authentication is IPsec 574 [14][22]. IPsec specifies the overall architecture, including header 575 authentication (AH) [15][23] and encapsulation (ESP) modes [16]. AH 576 authenticates both the IP header and IP data, whereas ESP 577 authenticates only the IP data (e.g., transport header and payload). 578 ESP is somewhat deprecated, as a result, since AH is somewhat of a 579 superset of ESP's capabilities. These two modes describe the security 580 applied to individual packets within the IPsec system; key exchange 581 and management is performed either out-of-band (via pre-shared keys) 582 or by an automated key exchange protocol IKE [17][24]. 584 IPsec already provides authentication of an IP header and its data 585 contents sufficient to defeat both man-in-the-middle and off-path 586 third-party spoofing attacks. IKE can configure authentication 587 between two endpoints on a per-endpoint, per-protocol, or 588 per-connection basis, as desired. IKE also can perform automatic 589 periodic re-keying, further defeating crypto-analysis based on 590 snooping (clandestine data collection). The use of IPsec is already 591 commonly strongly recommended for protected infrastructure. 593 IPsec does not suffice for many uses of BGP, however. It is 594 computationally intensive both in key management and individual 595 packet authentication [8]. As importantly, IKE is not anonymous; keys 596 can be exchanged between parties only if they trust each others' 597 X.509 certificates. These certificates provide identification (the 598 other party knows who you are) only where the certificates themselves 599 are signed by certificate authorities (CAs) that both parties already 600 trust. To a large extent, the CAs themselves are the pre-shared keys 601 which help IKE establish security association keys, which are then 602 used in the authentication algorithms. 604 IPsec, although widely available both in commercial routers and 605 commodity end-systems, is not often utilized except between parties 606 that already have a preexisting relationship (employee/employer, 607 between two ISPs, etc.) Servers to anonymous clients (e.g., customer/ 608 business) or more open services (e.g., BGP, where routers may have 609 hundreds of thousands of peers) are unmanageable, due to the breadth 610 and flux of CAs. New endpoints cannot establish IPsec associations 611 with such servers unless their certificate is signed by a CA already 612 trusted by the server. Different servers - even within the same 613 overall system (e.g., BGP) - often cannot or will not trust 614 overlapping subsets of CAs in general. 616 4.3 Application Layer 618 There are a number of application layer authentication mechanisms, 619 often implicit within end-to-end encryption. Application-layer 620 security (e.g., TLS, SSH, or MD5 checksums within a BGP stream) 621 provides the ultimate protection of application data from all 622 intermediaries, including network routers as well as exposure at 623 other layers in the end-systems. It is the only way to protect the 624 application data, ultimately. 626 Application authentication cannot protect either the network or 627 transport protocols from spoofing attacks, however. Spoofed packets 628 interfere with network processing or reset transport connections 629 before the application ever gets to check the data. Authentication 630 needs to winnow these packets and drop them before they interfere at 631 these lower layers. 633 4.4 Shim Transport/Application Layer 635 Security can also be provided over the transport layer but below the 636 application layer, in a kind of 'shim' protocol, such as SSL or TLS. 637 These protocols provide data protection for a variety of applications 638 over a single, legacy transport protocol, such as SSL/TCP for HTTPS. 639 Unfortunately, like application authentication, they do not protect 640 the transport layer against spoofing attacks. 642 4.5 Link Layer 644 Link layer security operates separately on each hop of an Internet. 645 Such security can be critical in protecting link resources, such as 646 bandwidth and link management protocols. Protection at this layer 647 cannot suffice for network or transport layers, because it cannot 648 authenticate the endpoint source of a packet. Link authentication 649 ensures only the source of the current hop where it is examined. 651 4.6 Need for Alternate Security Levels 653 The issues raised in this section suggest the need for alternate 654 security levels. While it is already widely recognized that security 655 needs to occur simultaneously at many protocol layers, the need for a 656 variety of strengths at a single layer. IPsec already supports a 657 variety of algorithms (MD5, SHA, etc. for authentication), but always 658 assumes that: 660 1. the entire body of the packet is secured 662 2. security associations are established only where identity is 663 authenticated by a know certificate authority or other pre-shared 664 key 666 3. both man-in-the-middle and off-path third-party spoofing attacks 667 must be defeated 669 These assumptions are prohibitive, especially in many cases of 670 spoofing attacks. For spoofing, the primary issue is whether packets 671 are coming from the same party the server can reach. Only the IP 672 header is fundamentally in question, so securing the entire packet 673 (1) is computational overkill. It is sufficient to authenticate the 674 other party as "a party you have exchanged packets with", rather than 675 establishing their trusted identity ("Bill" vs. "Bob") as in (2). 676 Finally, many cookie systems use clear-text (unencrypted), fixed 677 cookie values, providing reasonable (1 in 2^{cookie-size}) protection 678 against off-path third-party spoofs, but not addressing 679 man-in-the-middle at all. 681 5. Anonymous IPsec (ANONsec) 683 We believe it would be useful to allow IPsec where CAs are not 684 pre-shared and to allow a lower-overhead authentication. The former 685 is a kind of anonymous IKE, where a key is negotiated and exchanged 686 but without requiring pre-agreed CAs. The latter can be supported 687 using null-mode or header-only authentication modes. The two in 688 combination can provide a high-performance, easily managed protection 689 from spoofing attacks. Although this proposal, called "Anonymous 690 IPsec (ANONsec)", requires extensions to both IKE and AH processing, 691 we believe it is the most appropriate response to recent attacks. 693 5.1 Overview of ANONsec 695 Anonymous IPsec, ANONsec for short, augments IPsec to enable its use 696 by cooperating but otherwise anonymous parties. It relies on no 697 pre-shared information and operates at a variety of performance 698 levels, providing a variety of levels of authentication and/or 699 encryption. To avoid pre-shared information, it uses ANONike, a 700 variant of IKE that avoids the use of CAs. To provide a variety of 701 performance and strength levels, it uses variants of existing IPsec 702 authentication modes: full (fullANON, equivalent to current AH), 703 headerANON (header only AH), and nullANON (no authentication modes). 705 5.1.1 Anonymous IKE (ANONike) 707 IKE establishes a shared key between Internet endpoints, based on 708 X.509 certificates and shared agreement on certificate authorities 709 (CAs) who have signed those certificates.* We propose a new mode of 710 IPsec (details to be provided in a separate document if recommended) 711 which relaxes this requirement, called "Anonymous IKE" or ANONike for 712 short. ANONike allows endpoints to specify a certificate or to leave 713 the field blank. Upon receipt of an ANONike message, an endpoint 714 decides whether to reply (e.g., if ANONike is enabled). If permitted, 715 the remainder of IKE proceeds as currently specified, except that the 716 value "O" (or a sufficiently padded nonce, or other fixed value, TBD) 717 is used in place of the certificate throughout IKE processing. 719 *[AUTH - It appears this requirement is because IKE is based on 720 ISAKMP, which itself requires CAs [18] - if this is not required, or 721 if IKEv2 [24] relaxes this constraint, we would be glad to utilize 722 that and remove this portion of the proposal] 724 5.1.2 Anonymous Authentication Modes 726 ANONsec uses three authentication modes together with ANONike. 727 FullANON is just existing AH, which authenticates the fixed portions 728 of the IP header as well as the entire IP payload. HeaderANON 729 protects only the IP (and possibly TCP) header. Both fullANON and 730 headerANON protect from all third-party spoofing attacks; nullANON, 731 which uses a fixed cookie rather than a hash algorithm, protects only 732 against off-path third-party attacks, but has very low computational 733 cost. 735 5.1.2.1 Full Authentication (fullANON) 737 Full anonymous authentication (fullANON) uses ANONike together with 738 conventional AH processing. In this case, the fixed portions of the 739 IP header together with the entire IP payload is authenticated using 740 existing algorithms, e.g., MD5, SHA, etc. FullANON provides full 741 protection of both all headers and data against all third-party 742 spoofing, as well as tampering. Unfortunately, this alternative is as 743 computationally expensive as other forms of authentication, e.g., TCP 744 MD5, since similar algorithms are used over the bulk of the packet 745 [8][9]. FullANON is already supported in IPsec, i.e., it is just AH 746 in default mode, assuming ANONike configures the association. 748 5.1.2.2 Header-only Authentication (headerANON) 750 Header-only authentication (headerANON) uses ANONike together with 751 truncated AH processing, where only the fixed portions of the IP 752 header (possibly with some short prefix of the payload, for padding 753 and to avoid small-block hash problems). This mode protects the IP 754 header from all third-party spoofing and tampering. It does not 755 protect the IP payload (outside that optionally used to pad the hash) 756 from tampering. When using a short prefix of the payload, headerANON 757 also usually protects the TCP header as well (when the IP header + 758 TCP header is less than the hash block size, e.g., 64 bytes in MD5), 759 which completely protects against RST attacks. HeaderANON does not 760 protect from man-in-the-middle replay of signed headers with 761 alternate payloads. For packets substantially larger than the hash 762 block size (again, 64 bytes for MD5), headerANON can represent a 763 significant computational savings over full-packet authentication. 765 HeaderANON would require an extension to AH to indicate that only the 766 fixed portions of the IP header or a fixed length beginning at that 767 header be authenticated. This extension would constitute a new mode 768 for AH, to be negotiated during security association establishment. 770 5.1.2.3 Null Authentication (nullANON) 772 Null authentication ignores the context of individual packets 773 completely when computing the authentication signature. The signature 774 may be fixed or vary (if this is even possible). The signature is 775 effectively a cookie; it may even be the case that the SPI itself is 776 a sufficient cookie for this purpose, though we do not recommend that 777 variant (SPI values are not chosen pseudo-randomly). The cookie may 778 be based on the nonces exchanged via ANONike. The benefit of nullANON 779 is performance; only header modification is required, avoiding all 780 computational overhead. NullAnon protects only from off-path 781 third-party spoofing. 783 NullANON does not require an extension AH, which already supports 784 null-mode [19]. This mode is currently restricted to use in 785 combination with encryption, i.e., null authentication with non-null 786 encryption. NullANON describes the need for null authentication alone 787 to support IPsec cookies to protect against off-path third-party 788 spoofing attacks, which are not addressed in RFC2401 [14]. 790 *[AUTH- is that the same as with null encryption, or just null auth 791 alone?] 793 5.2 Benefits of ANONsec 795 ANONsec provides a way to establish security associations using IKE 796 without requiring endpoints to agree in advance on CAs. Its various 797 authentication modes enable a spectrum of protection that trades 798 various levels of vulnerability for performance and computational 799 overhead. All variants of ANONsec require IPsec keying and key 800 indexing, which itself can be computationally intensive. We believe 801 such keying is not substantially harder than connection 802 demultiplexing (e.g., based on ports), and since a single IKE session 803 can secure all transport connections between two endpoints, there 804 should be much fewer SAs than connection blocks. 806 ANONsec attempts to make IPsec sufficiently attractive, both 807 computationally and managerially, to operators of ubiquitous Internet 808 services. It provides sufficient protection against spoofing attacks 809 at the appropriate level where masquerading occurs, and can be 810 accomplished with very minor and orthogonal modifications to the 811 IPsec protocol suite. While we appreciate that there is substantial 812 (and understandable) inertia in IPsec, it has less inertia than TCP 813 and we believe these modifications involve less of a change in 814 protocol operation and are a better long-term solution to the recent 815 spoofing attacks. 817 6. Security Considerations 819 This entire document focuses on increasing the security of transport 820 protocols and their resistance to spoofing attacks. Security is 821 addressed throughout. 823 This document describes a number of techniques for defeating spoofing 824 attacks. Those relying on clear-text cookies, either explicit or 825 implicit (e.g., window sequence attenuation) do not protect from 826 man-in-the-middle spoofing attacks, since valid values can be learned 827 from prior traffic. Those relying on true authentication algorithms 828 are stronger, protecting even from man-in-the-middle, because the 829 authentication hash in a single packet approaches the behavior of 830 "one time" cookies. 832 Security at various levels of the protocol stack are addressed. 833 Spoofing attacks are fundamentally identity masquerading, so we 834 believe the most appropriate solutions defeat these at the network 835 layer, where end-to-end identity lies. Some transport protocols 836 subsume endpoint identity information from the network layer (e.g., 837 TCP pseudo-headers), while others establish per-connection identity 838 based on exchanged nonces (e.g., SCTP). It is reasonable, if not 839 recommended, to address security at all layers of the protocol stack. 840 We believe that the current attacks are most directly addressed at 841 the network layer, thus the focus of the solutions in this document. 843 This document presents a security solution which weakens overall 844 security compared to existing solutions. We note, however, that a 845 stronger solution which is not deployed, due to its complexity or 846 performance, is equivalent to no security at all. We believe 847 providing a more easily deployed anonymous variant of IKE together 848 with authentication that can be adjusted to trade strength for 849 performance constitutes an overall benefit toward the increased 850 deployment of security solutions. 852 7. Conclusions 854 This document describes the details of the recent BGP spoofing 855 attacks involving spurious RSTs used to shutdown TCP connections. It 856 summarizes and discusses a variety of current and proposed solutions 857 at various protocol layers. Finally, it presents ANONsec, a 858 modification of IPsec that enables anonymous IPsec using automatic 859 (IKE) key exchange and using a variety of levels of authentication. 860 We believe ANONsec is the most appropriate and direct response to the 861 recent issue of spoofing attacks, both for the current case and for 862 the long term benefit of the Internet as a whole. 864 8. Acknowledgments 866 This document was inspired by discussions on the about the recent 868 spoofed RST attacks on BGP routers, including R. Stewart's draft 869 [11][20]. The analysis of the attack issues, alternate solutions, and 870 ANONsec proposed solution were the result of discussions on that list 871 as well as with USC/ISI's T. Faber, A. Falk, G. Finn, and Y. Wang. 873 9. References 875 9.1 Normative References 877 [1] "Technical Cyber Security Alert TA04-111A: Vulnerabilities in 878 TCP -- http://www.us-cert.gov/cas/techalerts/TA04-111A.html", 879 , April 20 2004. 881 [2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 882 Signature Option", RFC 2385, August 1998. 884 [3] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, 885 May 1992. 887 [4] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 888 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 889 1573-1583, March 1999. 891 [5] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 892 60, RFC 3360, August 2002. 894 [6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 895 September 1981. 897 [7] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for 898 High Performance", RFC 1323, May 1992. 900 [8] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995. 902 [9] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995 903 77-86., March 1999. 905 [10] O'Malley, S. and L. Peterson, "TCP Extensions Considered 906 Harmful", RFC 1263, October 1991. 908 [11] "IETF TCPM Working Group and mailing list - http:// 909 www.ietf.org/html.charters/tcpm-charter.html", . 911 [12] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 912 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 913 "Stream Control Transmission Protocol", RFC 2960, October 2000. 915 [13] Bernstein, D., "SYN cookies -- http://cr.yp.to/ 916 syncookies.html", , 1997. 918 [14] Kent, S. and R. Atkinson, "Security Architecture for the 919 Internet Protocol", RFC 2401, November 1998. 921 [15] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 922 November 1998. 924 [16] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 925 (ESP)", RFC 2406, November 1998. 927 [17] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 928 RFC 2409, November 1998. 930 [18] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 931 Association and Key Management Protocol (ISAKMP)", RFC 2408, 932 November 1998. 934 [19] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its 935 Use With IPsec", RFC 2410, November 1998. 937 9.2 Informative References 939 [20] Stewart, R., "Transmission Control Protocol security 940 considerations", draft-ietf-tcpm-tcpsecure-00 (work in 941 progress), April 2004. 943 [21] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 944 draft-ietf-dccp-spec-06 (work in progress), February 2004. 946 [22] Kent, S. and K. Seo, "Security Architecture for the Internet 947 Protocol", draft-ietf-ipsec-rfc2401bis-02 (work in progress), 948 April 2004. 950 [23] Kent, S., "IP Authentication Header", 951 draft-ietf-ipsec-rfc2402bis-07 (work in progress), March 2004. 953 [24] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 954 draft-ietf-ipsec-ikev2-13 (work in progress), March 2004. 956 Author's Address 958 Joe Touch 959 USC/Information Sciences Institute 960 4676 Admiralty Way 961 Marina del Rey, CA 90292-6695 962 U.S.A. 964 Phone: +1 (310) 448-9151 965 Fax: +1 (310) 448-9300 966 EMail: touch@isi.edu 967 URI: http://www.isi.edu/touch 969 Intellectual Property Statement 971 The IETF takes no position regarding the validity or scope of any 972 intellectual property or other rights that might be claimed to 973 pertain to the implementation or use of the technology described in 974 this document or the extent to which any license under such rights 975 might or might not be available; neither does it represent that it 976 has made any effort to identify any such rights. Information on the 977 IETF's procedures with respect to rights in standards-track and 978 standards-related documentation can be found in BCP-11. Copies of 979 claims of rights made available for publication and any assurances of 980 licenses to be made available, or the result of an attempt made to 981 obtain a general license or permission for the use of such 982 proprietary rights by implementors or users of this specification can 983 be obtained from the IETF Secretariat. 985 The IETF invites any interested party to bring to its attention any 986 copyrights, patents or patent applications, or other proprietary 987 rights which may cover technology that may be required to practice 988 this standard. Please address the information to the IETF Executive 989 Director. 991 Full Copyright Statement 993 Copyright (C) The Internet Society (2004). All Rights Reserved. 995 This document and translations of it may be copied and furnished to 996 others, and derivative works that comment on or otherwise explain it 997 or assist in its implementation may be prepared, copied, published 998 and distributed, in whole or in part, without restriction of any 999 kind, provided that the above copyright notice and this paragraph are 1000 included on all such copies and derivative works. However, this 1001 document itself may not be modified in any way, such as by removing 1002 the copyright notice or references to the Internet Society or other 1003 Internet organizations, except as needed for the purpose of 1004 developing Internet standards in which case the procedures for 1005 copyrights defined in the Internet Standards process must be 1006 followed, or as required to translate it into languages other than 1007 English. 1009 The limited permissions granted above are perpetual and will not be 1010 revoked by the Internet Society or its successors or assignees. 1012 This document and the information contained herein is provided on an 1013 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1014 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1015 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1016 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1017 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1019 Acknowledgment 1021 Funding for the RFC Editor function is currently provided by the 1022 Internet Society.