idnits 2.17.1 draft-touch-tcp-antispoof-00.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.2b on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 969. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 959. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 975), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (July 10, 2004) is 7230 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) == Unused Reference: '20' is defined on line 898, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 901, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2385 (ref. '2') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 1337 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 793 (ref. '8') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (ref. '9') (Obsoleted by RFC 7323) ** Downref: Normative reference to an Informational RFC: RFC 1810 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Downref: Normative reference to an Informational RFC: RFC 1263 (ref. '12') -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 2960 (ref. '14') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 2401 (ref. '16') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '17') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '18') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '19') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (ref. '21') (Obsoleted by RFC 4306) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcpsecure-01 == 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-14 Summary: 19 errors (**), 0 flaws (~~), 9 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Touch 2 Internet-Draft USC/ISI 3 Expires: January 8, 2005 July 10, 2004 5 Defending TCP Against Spoofing Attacks 6 draft-touch-tcp-antispoof-00 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. This document may not be modified, and derivative works of 14 it may not be created. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 8, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 Recent attacks on core Internet infrastructure indicate an increased 41 vulnerability of TCP connections to spurious resets (RSTs). TCP has 42 always been susceptible to such RST spoof attacks, which were 43 indirectly protected by checking that the RST sequence number was 44 inside the current receive window, as well as via the obfuscation of 45 TCP endpoint and port numbers. For pairs of well-known endpoints 46 often over predictable port pairs, such as BGP, increases in the path 47 bandwidth-delay product of a connection have sufficiently increased 48 the receive window space that off-path third parties can guess a 49 viable RST sequence number. This document addresses this 50 vulnerability, discussing proposed solutions at the transport level 51 and their inherent challenges, as well as existing network level 52 solutions and the feasibility of their deployment. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1 Recent BGP Attacks Using TCP RSTs . . . . . . . . . . . . 4 59 2.2 TCP RST Vulnerability . . . . . . . . . . . . . . . . . . 5 60 2.3 What Changed -- the Ever Opening Window . . . . . . . . . 5 61 3. Proposed solutions . . . . . . . . . . . . . . . . . . . . . . 9 62 3.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . 9 63 3.1.1 TCP MD5 Authentication . . . . . . . . . . . . . . . . 9 64 3.1.2 TCP RST Window Attenuation . . . . . . . . . . . . . . 9 65 3.1.3 TCP Timestamp Authentication . . . . . . . . . . . . . 10 66 3.1.4 Other TCP Cookies . . . . . . . . . . . . . . . . . . 11 67 3.1.5 Other TCP Considerations . . . . . . . . . . . . . . . 11 68 3.1.6 Other Protocols . . . . . . . . . . . . . . . . . . . 12 69 3.2 Network Layer (IP) . . . . . . . . . . . . . . . . . . . . 12 70 4. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 4.1 Transport Layer (e.g., TCP) . . . . . . . . . . . . . . . 13 72 4.2 Network Layer (IP) . . . . . . . . . . . . . . . . . . . . 14 73 4.3 Application Layer . . . . . . . . . . . . . . . . . . . . 15 74 4.4 Shim Transport/Application Layer . . . . . . . . . . . . . 15 75 4.5 Link Layer . . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.6 Need for Alternate Security Levels . . . . . . . . . . . . 15 77 5. The Need for High-Performance Anonymous Security . . . . . . . 17 78 5.1 Anonymous Keying . . . . . . . . . . . . . . . . . . . . . 17 79 5.2 Alternatives for Performance . . . . . . . . . . . . . . . 17 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 85 9.2 Informative References . . . . . . . . . . . . . . . . . . . 24 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 87 Intellectual Property and Copyright Statements . . . . . . . . 26 89 1. Introduction 91 The Internet infrastructure has recently seen a flurry of attacks on 92 BGP connections between core routers using an attack known for nearly 93 six years [1][2]. These connections, typically using TCP, can be 94 susceptible to off-path (non man-in-the-middle) third-party reset 95 (RST) segments, which terminate the TCP connection. BGP routers 96 react to a terminated TCP connection in various ways, ranging from 97 restarting the connection to deciding that the other router is 98 unreachable and thus flushing the BGP routes. This sort of attack 99 affects other protocols besides BGP, involving any long-lived 100 connection between well-known endpoints. The impact on Internet 101 infrastructure has been substantial (esp. for the BGP case), and 102 warrants immediate attention. 104 TCP, like many other protocols, has been susceptible to off-path 105 third-party attacks. Such attacks rely on the increase of commodity 106 platforms supporting public access to previously privileged 107 resources, such as root-level access. Given such access, it is 108 trivial for anyone to generate a packet with any header desired. 109 This, coupled with the lack of sufficient ingress filtering to drop 110 such spoofed traffic, has resulted in an increase in off-path 111 third-party spoofing attacks. As a result, a number of proposed 112 solutions have been developed in collaboration among the Internet 113 research and commercial router communities. The foremost of these 114 modifies TCP processing to defeat off-path third-party spoofs by 115 further limiting viable sequence numbers in the RST segment. 117 Such modifications are, at best, temporary patches to the ubiquitous 118 vulnerability to spoofing attacks. The obvious solution to spoofing 119 is to validate the segments of a connection, either at the transport 120 level or the network level. TCP with MD5 extensions already provides 121 this authentication at the transport level, and IPsec already intends 122 to provide authentication of a network level, but in both cases their 123 deployment overhead can be prohibitive. E.g., it is not feasible for 124 BGP routers to be configured with the appropriate certificate 125 authorities of large numbers of peers (for IPsec using IKE), or 126 shared secrets (for IPsec in shared-secret mode, or TCP/MD5), because 127 many clients may need to be configured rapidly without external 128 assistance. The same is true for other uses of long-lived TCP 129 connections between well-known pairs. 131 The remainder of this document outlines the attack in detail and 132 describes and compares a variety of solutions, including existing 133 solutions based on TCP/MD5 and IPsec, as well as recently proposed 134 solutions, including modifications to TCP's RST processing [22], 135 modifications to TCP's timestamp processing [3], and modifications to 136 IPsec and TCP/MD5 keying [4]. 138 2. Background 140 The recent attacks on BGP have raised the issue of TCP's 141 vulnerability to off-path third-party spoofing attacks [1]. A number 142 of such attacks have been known for several years, including sending 143 RSTs, SYNs, and even ACKs in an attempt to affect an existing 144 connection or to load down servers. Overall, such attacks are 145 countered by the use of some form of authentication at the network 146 (IPsec), transport (SYN cookies), or other layers. TCP already 147 includes a weak form of such authentication in its check of segment 148 sequence numbers. Increases in the bandwidth-delay product for 149 certain long connections has made sufficiently weakened this 150 authentication in recent weeks, rendering it moot. 152 2.1 Recent BGP Attacks Using TCP RSTs 154 BGP represents a particular vulnerability to spoofing attacks. Most 155 TCP connections are protected by multiple levels of obfuscation 156 except at the endpoints of the connection: 158 o Both endpoint addresses are usually not well-known; although 159 server addresses are advertised, clients are somewhat anonymous. 161 o Both port numbers are usually not well-known; the server's usually 162 is advertised (representing the service), but the client's is 163 typically sufficiently unpredictable to an off-path third-party. 165 o Valid sequence number space is not well-known. 167 o Connections are relatively short-lived and valid sequence space 168 changes, so any guess of the above information is unlikely to be 169 useful. 171 BGP represents an exception to the above criteria (though not the 172 only case). Both endpoints are well-known, notably as part of an AS 173 path. The destination port is typically fixed to indicate the BGP 174 service. The source port used by a BGP router is sometimes fixed and 175 advertised to enable firewall configuration; even when not fixed, 176 there are only 65,000 valid source ports which may be exhaustively 177 attacked. Connections are long-lived, and as noted before some BGP 178 implementations interpret successive TCP connection failures as 179 routing failures, discarding the corresponding routing information. 180 As importantly and as will be shown below, the valid sequence number 181 space once thought to provide some protection has been rendered 182 useless by increasing congestion window sizes. 184 2.2 TCP RST Vulnerability 186 TCP has a known vulnerability to third-party spoofed segments. SYN 187 flooding consumes server resources in half-open connections, 188 affecting the server's ability to open new connections. ACK spoofing 189 can cause connections to transmit too much data too quickly, creating 190 network congestion and segment loss, causing connections to slow to a 191 crawl. In the most recent attacks on BGP, RSTs cause connections to 192 be dropped. As noted earlier, some BGP implementations interpret TCP 193 connection termination, or a series of such failures, as a network 194 failure. This causes routers to drop the BGP routing information 195 already exchanged, in addition to inhibiting their ongoing exchanges. 196 The result can affect routing paths throughout the Internet. 198 The dangerous effects of RSTs on TCP have been known for many years, 199 even when used by the legitimate endpoints of a connection. TCP RSTs 200 cause the receiver to drop all connection state; because the source 201 is not required to maintain a TIME_WAIT state, such a RST can cause 202 premature reuse of address/port pairs, potentially allowing segments 203 from a previous connection to contaminate the data of a new 204 connection, known as TIME_WAIT assassination [5]. In this case, 205 assassination occurs inadvertently as the result of duplicate 206 segments from a legitimate source, and can be avoided by blocking RST 207 processing while in TIME_WAIT. However, assassination can be useful 208 to deliberately reduce the state held at servers; this requires that 209 the source of the RSTs go into TIME_WAIT state to avoid such hazards, 210 and that RSTs are not blocked in the TIME_WAIT state [6]. 212 Firewalls and load balancers, so-called 'middleboxes', sometimes emit 213 RSTs on behalf of transited connections to optimize server 214 performance [7]. This is a 'man in the middle' RST attack, where the 215 RSTs are sent for benign or beneficial intent. There are numerous 216 hazards with such use of RSTs, outlined in that RFC. 218 2.3 What Changed -- the Ever Opening Window 220 RSTs represent a hazard to TCP, especially when completely unchecked. 221 Fortunately, there are a number of obfuscation mechanisms that make 222 it difficult for off-path third parties to forge (spoof) valid RSTs, 223 as noted earlier. We have already shown it is easy to learn both 224 endpoint addresses and ports for some protocols, notably BGP. The 225 final obfuscation is the sequence number. 227 TCP segments include a sequence number which enables out-of-order 228 receiver processing, as well as duplicate detection. The sequence 229 number space is also used to manage congestion, and indicates the 230 index of the next byte to be transmitted or received. For RSTs, this 231 is relevant because legitimate RSTs use the next sequence number in 232 the transmitter window, and the receiver checks that incoming RSTs 233 have a sequence number in the expected receive window. Such 234 processing is intended to eliminate duplicate segments (somewhat moot 235 for RSTs, though), and to drop RSTs which were part of previous 236 connections. 238 TCP uses two window mechanisms, a primary mechanism which uses a 239 space of 32 bits, and a secondary mechanism which scales this window 240 [8][9]. The valid receive window is a fraction, not to exceed 241 approximately half, of this space, or ~2,000,000,000. Under typical 242 use, the majority of TCP connections open to a very small fraction of 243 this space, e.g., 10,000-60,000 (approximately 5-100 segments). On a 244 low-loss path, the window should open to around the path 245 bandwidth-delay product, including buffering delays (assume 1 packet/ 246 hop). Many paths in the Internet have end-to-end bandwidths of under 247 1 Mbps, latencies under 100ms, and are under 15 hops, resulting in 248 fairly small windows as above (under 35,000 bytes). Under these 249 conditions, and further assuming that the initial sequence number is 250 suitably (pseudo-randomly) chosen, a valid guessed sequence number 251 would have odds of 1 in 57,000. Put differently, a blind (non 252 man-in-the-middle) attacker would need to send 57,000 RSTs with 253 suitably spaced sequence number guesses to successfully reset a 254 connection. At 1 Mbps, 57,000 (40 byte) RSTs would take over 50 255 minutes to transmit, and, as noted earlier, most current connections 256 are fairly brief by comparison. 258 Recent use of high bandwidth paths of 10 Gbps and result in 259 bandwidth-delay products over 125 MB - approximately 1/10 of TCP's 260 overall window size excluding scale, assuming the receiver allocates 261 sufficient buffering (to be discussed later). Even under networks 262 that are ten times slower (1 Gbps), the active receiver window covers 263 1/100th of the overall window size. At these speeds, it takes only 264 10-100 packets, or under 32 microseconds, to correctly guess a valid 265 sequence number and kill a connection. A table of corresponding 266 exposure to various amounts of RSTs is shown below, for various line 267 rates, assuming the more conventional 100ms latencies (though even 268 100ms is large for BGP cases): 270 BW BW*delay RSTs needed Time needed 271 ------------------------------------------------------------ 272 10 Gbps 125 MB 35 1 us (microsecond) 273 1 Gbps 12.5 MB 344 110 us 274 100 Mbps 1.25 MB 3,436 10 ms (millisecond) 275 10 Mbps 0.125 MB 34,360 1 second 276 1 Mbps 0.0125 MB 343,598 2 minutes 277 100 Kbps 0.00125 MB 3,435,974 3 hours 279 Figure 1: Time needed to kill a connection 281 This table demonstrates that the effect of bandwidth on the 282 vulnerability is squared; for every increase in bandwidth, there is a 283 linear decrease in the number of sequence number guesses needed, as 284 well as a linear decrease in the time needed to send a set of 285 guesses. Notably, as inter-router link bandwidths approach 1 Mbps, 286 an 'exhaustive' attack becomes practical. Checking that the RST 287 sequence number is somewhere in the valid window (bw*delay) out of 288 the overall window (2^32) is an insufficient obfuscation. 290 Note that this table makes a number of assumptions: 292 1. the overall bandwidth-delay product is relatively fixed 294 2. traffic losses are negligible (insufficient to affect the 295 congestion window over most of the connection) 297 3. the receive socket buffers do not limiting the receive window 299 4. the attack bandwidth is similar to the end-to-end path bandwidth 301 Of these assumptions, the last two are more notable. The issue of 302 receive socket buffers will be addressed later. The issue of the 303 attack bandwidth is considered reasonable as follows: 305 1. RSTs are substantially easier to send than data; they can be 306 precomputed and they are smaller than data packets (40 bytes). 308 2. although susceptible connections use somewhat less ubiquitous 309 high-bandwidth paths, the attack may be distributed, at which 310 point only the ingress link of the attack is the primary 311 limitation 313 3. for the purposes of the above table, we assume that the ingress 314 at the attack has the same bandwidth as the path, as an 315 approximation 317 The previous sections discussed the nature of the recent attacks on 318 BGP due to the vulnerability of TCP to RST spoofing attacks, due 319 largely to recent increases in the fraction of the TCP window space 320 in use for a single, long-lived connection. 322 3. Proposed solutions 324 TCP currently authenticates received RSTs using the address and port 325 pair numbers, and checks that the sequence number is inside the valid 326 receiver window. The previous section demonstrated how TCP has 327 become more vulnerable to RST spoofing attacks due to the increases 328 in the receive window size. There are a number of current and 329 proposed solutions to this vulnerability, all centering on increasing 330 the authentication of received RSTs. 332 3.1 Transport Layer 334 The transport layer represents the last place that segments can be 335 authenticated before they affect connection management. TCP has a 336 variety of current and proposed mechanisms to increase the 337 authentication of segments, protecting against both off-path 338 third-party spoofs and man-in-the-middle attacks. SCTP also has 339 mechanisms to authenticate segments. 341 3.1.1 TCP MD5 Authentication 343 An extension to TCP supporting MD5 authentication was developed 344 around six years ago specifically to authenticate BGP connections 345 [2]. The extension relies on a pre-shared secret key to authenticate 346 the entire TCP segment, including the data, TCP header, and TCP 347 pseudo-header (certain fields of the IP header). All segments are 348 protected, including RSTs, which are accepted only when their 349 signature matches. This option, although widely deployed in Internet 350 routers, is considered undeployable for widespread use because the 351 need for pre-shared keys. It further is considered computationally 352 expensive for either hosts or routers due to the overhead of MD5 353 [10][11]. 355 3.1.2 TCP RST Window Attenuation 357 A recent proposal extends TCP to further constrain received RST to 358 match the expected next sequence number [22]. This restores TCP's 359 resistance to spurious RSTs, effectively limiting the receive window 360 for RSTs to a single number. As a result, an attacker would need to 361 send 2^32 different packets to correctly guess the sequence number. 362 The extension further modifies the RST receiver to react to 363 incorrectly-numbered RSTs, by sending a zero-length ACK. If the RST 364 source is legitimate, upon receipt of an ACK the closed source would 365 presumably emit a RST with the sequence number matching the ACK, 366 correctly resetting the intended recipient. There are a number of 367 concerns with this proposal, including the platitude "think twice 368 before modifying TCP, then don't" [12], notably because this 369 modification adds arcs to the TCP state diagram (in contrast to 370 adding MD5 signatures, which is orthogonal to the state machine 371 altogether). For example, there may be complications between RSTs of 372 different connections between the same pair of endpoints because RSTs 373 flush the TIME-WAIT (as mentioned earlier). Further, this modifies 374 TCP so that under some circumstances a RST causes a reply, in 375 violation of generally accepted practice, if not gentle 376 recommendation. The advantage to this proposal is that it can be 377 deployed incrementally and has benefit to the endpoint on which it is 378 deployed. 380 A variant of this proposal uses a different value to attenuate the 381 window of viable RSTs. It requires RSTs to carry the initial 382 sequence number rather than the next expected sequence number, i.e., 383 the value negotiated on connection establishment [13]. This proposal 384 has the advantage of using an explicitly negotiated value, but at the 385 cost of changing the behavior of an unmodified endpoint to a 386 currently valid RST. It would thus be more difficult, without 387 additional mechanism, to deploy incrementally. 389 The most obvious other variant of this proposal involves increasing 390 TCP's window space, rather than decreasing the valid range for RSTs, 391 i.e., increasing the sequence space from 32 bits to 64 bits. This 392 has the equivalent effect - the ratio of the valid sequence numbers 393 for any segment to the overall sequence number space is significantly 394 reduced. The use of the larger space, as with current schemes to 395 establish weak authentication using initial sequence numbers (ISNs), 396 is contingent on using suitably random values for the ISN. Such 397 randomness adds additional complexity to TCP both in specification 398 and implementation, and provides only very weak authentication at 399 best. While there are many reasons to increase the TCP sequence 400 number space, we believe authentication is not one of them. Finally, 401 such a modification is not obviously backward compatible, and would 402 be thus difficult to deploy. 404 3.1.3 TCP Timestamp Authentication 406 Another way to authenticate TCP segments is to utilize its timestamp 407 option, using the value as a sort of authentication [3]. This 408 requires that the receiver TCP discard values whose timestamp is 409 outside the accepted window, which is derived from the timestamps of 410 other packets from the same connection. This technique uses an 411 existing TCP option, but also requires modified RST processing and 412 may be difficult to deploy incrementally without further 413 modifications. Additionally, the timestamp value may be easier to 414 guess because it is derived from a predictable value. 416 3.1.4 Other TCP Cookies 418 All of the above techniques are variants of cookies, otherwise 419 nonsensical data whose value is used to validate the packet. In the 420 case of MD5 checksums, the cookie is computed based on a shared 421 secret. Even a signature can be guessed, and presents a 1 in 422 2^(cookie length) probability of attack anyway. The primary 423 difference is that MD5 signatures are effectively one-time cookies, 424 not predictable based on man-in-the-middle snooping. Window 425 attenuation sequence numbers can be guessed by snooping the sequence 426 number of current packets, and timestamps can may be guessed even 427 more remotely. These variants of cookies are similar in spirit to 428 TCP SYN cookies, again patching a vulnerability to off-path 429 third-party spoofing attacks based on a (fairly weak, excepting MD5) 430 form of authentication. Another form of cookie is the source port 431 itself, which can be randomized but provides only 16 bits of 432 protection (65,000 combinations), which may be exhaustively attacked. 433 This can be combined with destination port randomization as well, but 434 that would require a separate coordination mechanism (so both parties 435 know which ports to use), which is equivalent to (and as infeasible 436 for large-scale deployments as) exchanging a shared secret. 438 3.1.5 Other TCP Considerations 440 The analysis of the potential for RST spoofing above assumes that the 441 receive window opens to the maximum extent suggested by the 442 bandwidth-delay product of the end-to-end path, and that the window 443 opens to an appreciable fraction of the overall sequence number 444 space. As noted earlier, for most common cases, connections are too 445 brief or over bandwidths too low to for such a large window to occur. 446 Expanding TCP's sequence number space is a direct way to further 447 avoid such vulnerability, even for long connections over emerging 448 bandwidths. 450 Finally, it is often sufficient for the endpoint to limit the receive 451 window in other ways, notably using 'socket options'. If the receive 452 socket buffer is limited, e.g., to the ubiquitous default of 65KB, 453 the receive window cannot grow to vulnerable sizes even for very long 454 connections over very high bandwidths. The consequence is lower 455 sustained throughput, where only one window's worth of data per round 456 trip time (RTT) is exchanged. Although this will keep the connection 457 open longer, it also reduces the receive window; for long-lived 458 connections with continuous sourced data, this may continue to 459 present an attack opportunity, albeit a sparse and slow-moving 460 target. For the most recent case where BGP data is being exchanged 461 between Internet routers, the data is bursty and the aggregate 462 traffic is small (i.e., unlikely to cover a substantial portion of 463 the sequence space, even if long-lived), so is difficult to consider 464 where smaller receive buffers would not sufficiently address the 465 immediate problem. 467 3.1.6 Other Protocols 469 Segment authentication has been addressed at the transport layer in 470 other protocols. Both SCTP and DCCP* include cookies for connection 471 establishment and uses them to authenticate a variety of other 472 control messages [14][23]. The inclusion of such mechanism at the 473 transport protocol, although emerging as standard practice, 474 unnecessarily complicates the design and implementation of new 475 protocols. As new attacks are discovered (SYN floods, RSTs, etc.), 476 each protocol must be modified individually to compensate. A network 477 solution may be more appropriate and efficient. 479 *[AUTH - DCCP may be removing cookies from the spec for the 480 redundancies discussed above, because the use of cookies at the 481 transport layer primarily supports dynamic multihoming (a design goal 482 of SCTP, but not DCCP) rather than security.] 484 3.2 Network Layer (IP) 486 TCP is susceptible to RSTs, but also to other spoofing and 487 man-in-the-middle attacks, including SYN attacks. Other transport 488 protocols, such as UDP and RTP are equally susceptible. Although 489 emerging transport protocols attempt to defeat such attacks at the 490 transport layer, it is clear that such attacks are fundamentally a 491 network layer issue. The packet is coming from an endpoint who is 492 spoofing another endpoint, either upstream or somewhere else in the 493 Internet. IPsec was designed specifically to establish and enforce 494 authentication of a packet's source and contents, which most 495 directly, explicitly, and completely addresses this security 496 vulnerability. 498 The larger problem with IPsec is that of CA key distribution and use. 499 IPsec is often cumbersome, and has only recently been supported in 500 many end-system operating systems. More importantly, it relies on 501 signed X.509 certificates to establish and exchange keying 502 information (e.g., via IKE). These present challenges when using 503 IPsec to secure traffic to a well-known server, whose clients may not 504 support IPsec or may not have registered with a previously-known 505 certificate authority (CA). 507 4. Issues 509 There are a number of existing and proposed solutions addressing the 510 vulnerability of transport protocols in general, and TCP in specific, 511 to off-path third-party spoofing attacks. As shown, these operate at 512 the transport or network layer. These solutions are not a sufficient 513 long-term strategy to dealing with such attacks, however. Transport 514 solutions require pervasive modification of every transport protocol 515 and address the problem of packet origin identification at the wrong 516 layer. Current network solutions are computationally intensive and 517 require pervasive registration of certificate authorities with every 518 possible endpoint. Neither application-layer nor link-layer 519 solutions suffice to protect either the network or transport layers. 520 This section explains these observations in detail. 522 4.1 Transport Layer (e.g., TCP) 524 Transport solutions rely on shared cookies to authenticate segments, 525 including data, transport header, and even pseudo-header (e.g., fixed 526 portions of the outer IP header in TCP). Because the Internet relies 527 on stateless network protocols, it makes sense to rely on state 528 establishment and maintenance available in some transport layers not 529 only for the connection but for authentication state. Three-way 530 handshakes and heartbeats can be used to negotiate authentication 531 state in conjunction with connection parameters, which can be stored 532 with connection state easily. 534 As noted earlier, transport layer solutions require pervasive 535 modification of all transport protocols to include authentication. 536 Not all transport layers support negotiated endpoint state (e.g., 537 UDP), and legacy protocols are notoriously hard to safely augment 538 (e.g., TCP). Not all authentication solutions are created equal 539 either, and relying on a variety of transport solutions exposes 540 end-systems to increased potential for incorrectly specified or 541 implemented solutions. Transport authentication has often been 542 developed piece-wise, in response to specific attacks, e.g., SYN 543 cookies and RST window attenuation [15][22]. 545 Transport layer solutions are not only per-protocol, but often 546 per-connection. Each connection needs to negotiate and maintain 547 authentication state separately. Overhead is not amortized over 548 multiple connections - this includes overheads in packet exchanges, 549 design complexity, and implementation complexity. Finally, because 550 the authentication happens later in packet processing than is 551 required, additional endpoint resources are consumed needlessly, 552 e.g., in demultiplexing received packets, indexing connection 553 identifiers, etc. 555 4.2 Network Layer (IP) 557 A network layer solution avoids the hazards of multiple transport 558 variants, using a single shared endpoint authentication mechanism 559 early in receiver packet processing to discard unauthenticated 560 packets quickly. Network solutions protect all transport protocols, 561 including both legacy and emerging protocols, and reduces the 562 complexity of these protocols as well. A shared solution also 563 reduces protocol overhead, and decouples the management (and 564 refreshing) of authentication state from that of individual transport 565 connections. Finally, a network layer solution protects not only the 566 transport layer but the network layer as well, e.g., from ICMP, IGMP, 567 etc. spoofing attacks. 569 The ubiquitous protocol for network layer authentication is IPsec 570 [16][24]. IPsec specifies the overall architecture, including header 571 authentication (AH) [17][25] and encapsulation (ESP) modes [18]. AH 572 authenticates both the IP header and IP data, whereas ESP 573 authenticates only the IP data (e.g., transport header and payload). 574 AH is deprecated since ESP is more efficient and the SPI includes 575 sufficient information to verify the IP header anyway. These two 576 modes describe the security applied to individual packets within the 577 IPsec system; key exchange and management is performed either 578 out-of-band (via pre-shared keys) or by an automated key exchange 579 protocol IKE [19][26]. 581 IPsec already provides authentication of an IP header and its data 582 contents sufficient to defeat both man-in-the-middle and off-path 583 third-party spoofing attacks. IKE can configure authentication 584 between two endpoints on a per-endpoint, per-protocol, or 585 per-connection basis, as desired. IKE also can perform automatic 586 periodic re-keying, further defeating crypto-analysis based on 587 snooping (clandestine data collection). The use of IPsec is already 588 commonly strongly recommended for protected infrastructure. 590 IPsec does not suffice for many uses of BGP, however. It is 591 computationally intensive both in key management and individual 592 packet authentication [10]. As importantly, IKE is not anonymous; 593 keys can be exchanged between parties only if they trust each others' 594 X.509 certificates. These certificates provide identification (the 595 other party knows who you are) only where the certificates themselves 596 are signed by certificate authorities (CAs) that both parties already 597 trust. To a large extent, the CAs themselves are the pre-shared keys 598 which help IKE establish security association keys, which are then 599 used in the authentication algorithms. 601 IPsec, although widely available both in commercial routers and 602 commodity end-systems, is not often utilized except between parties 603 that already have a preexisting relationship (employee/employer, 604 between two ISPs, etc.) Servers to anonymous clients (e.g., customer/ 605 business) or more open services (e.g., BGP, where routers may large 606 numbers of peers) are unmanageable, due to the breadth and flux of 607 CAs. New endpoints cannot establish IPsec associations with such 608 servers unless their certificate is signed by a CA already trusted by 609 the server. Different servers - even within the same overall system 610 (e.g., BGP) - often cannot or will not trust overlapping subsets of 611 CAs in general. 613 4.3 Application Layer 615 There are a number of application layer authentication mechanisms, 616 often implicit within end-to-end encryption. Application-layer 617 security (e.g., TLS, SSH, or MD5 checksums within a BGP stream) 618 provides the ultimate protection of application data from all 619 intermediaries, including network routers as well as exposure at 620 other layers in the end-systems. It is the only way to protect the 621 application data, ultimately. 623 Application authentication cannot protect either the network or 624 transport protocols from spoofing attacks, however. Spoofed packets 625 interfere with network processing or reset transport connections 626 before the application ever gets to check the data. Authentication 627 needs to winnow these packets and drop them before they interfere at 628 these lower layers. 630 4.4 Shim Transport/Application Layer 632 Security can also be provided over the transport layer but below the 633 application layer, in a kind of 'shim' protocol, such as SSL or TLS. 634 These protocols provide data protection for a variety of applications 635 over a single, legacy transport protocol, such as SSL/TCP for HTTPS. 636 Unfortunately, like application authentication, they do not protect 637 the transport layer against spoofing attacks. 639 4.5 Link Layer 641 Link layer security operates separately on each hop of an Internet. 642 Such security can be critical in protecting link resources, such as 643 bandwidth and link management protocols. Protection at this layer 644 cannot suffice for network or transport layers, because it cannot 645 authenticate the endpoint source of a packet. Link authentication 646 ensures only the source of the current hop where it is examined. 648 4.6 Need for Alternate Security Levels 650 The issues raised in this section suggest the need for alternate 651 security levels. While it is already widely recognized that security 652 needs to occur simultaneously at many protocol layers, the need for a 653 variety of strengths at a single layer. IPsec already supports a 654 variety of algorithms (MD5, SHA, etc. for authentication), but 655 always assumes that: 657 1. the entire body of the packet is secured 659 2. security associations are established only where identity is 660 authenticated by a know certificate authority or other pre-shared 661 key 663 3. both man-in-the-middle and off-path third-party spoofing attacks 664 must be defeated 666 These assumptions are prohibitive, especially in many cases of 667 spoofing attacks. For spoofing, the primary issue is whether packets 668 are coming from the same party the server can reach. Only the IP 669 header is fundamentally in question, so securing the entire packet 670 (1) is computational overkill. It is sufficient to authenticate the 671 other party as "a party you have exchanged packets with", rather than 672 establishing their trusted identity ("Bill" vs. "Bob") as in (2). 673 Finally, many cookie systems use clear-text (unencrypted), fixed 674 cookie values, providing reasonable (1 in 2^{cookie-size}) protection 675 against off-path third-party spoofs, but not addressing 676 man-in-the-middle at all. 678 5. The Need for High-Performance Anonymous Security 680 Internet servers need a form of anonymous security, to protect 681 established connections from spoofing attacks, but without the 682 heavyweight infrastructure typically assumed in conventional security 683 architectures. Such security would allow servers to interact with 684 clients without a-priori shared keys or a key signing hierarchy. It 685 would be useful to also support high-performance variants, especially 686 where only a nonce is sufficient to avoid off-path attacks. Both 687 these properties would address the concerns about deployability of 688 existing IPsec and TCP/MD5 solutions. There are a few different ways 689 to establish anonymous security; the details of these approaches are 690 discussed in detail elsewhere, and are briefly summarized here [4]. 692 5.1 Anonymous Keying 694 It would be useful to allow IPsec where CAs are not pre-shared, or 695 TCP/MD5 and/or IPsec shared-key mode without a-prior shared keys. 696 The former is a kind of anonymous IKE, where a key is negotiated and 697 exchanged but without requiring pre-agreed CAs. This is already 698 supported by IKE in shared-secret mode, where the shared secret is 699 open, i.e., a public string such as "password". IKE allows such a 700 public shared secret to be used to negotiate a pairwise private 701 secret via the Diffie-Hellman exchange. 703 TCP/MD5 would need to be augmented to support anonymous automatic 704 keying, since it currently assumes only manual keying. One solution 705 would be to use the TCP connection's Initial Sequence Number (ISN) as 706 the key, since it is visible only during connection establishment. 707 Another solution is to add a Diffie-Hellman exchange to the 708 connection establishment phase, inside the TCP/MD5 option. 710 Note that the ISN or key established by Diffie-Hellman both represent 711 shared, per-connection information that cannot be obtained after 712 connection establishment or keying, respectively. As such, either 713 can be used as the key itself if only off-path attacks are of 714 concern. 716 5.2 Alternatives for Performance 718 An independent impediment to deploying IPsec or TCP/MD5 is 719 performance; in both cases, there is a substantial impact on the 720 throughput of individual connections, as well as the computational 721 load of the endpoints. There are variants of IPsec and TCP/MD5 which 722 can address these performance issues, also discussed in further 723 detail elsewhere [4]. They involve protecting a subset of the packet 724 (focusing on the headers), and/or relaxing the authentication 725 algorithms. 727 Conventional authentication involves ESP or ESP-like processing. The 728 entire IP payload is authenticated using existing algorithms, e.g., 729 MD5, SHA, etc. This provides full protection of both all headers and 730 data against all third-party spoofing, as well as tampering. 731 Unfortunately, this alternative is as computationally expensive as 732 other forms of authentication, e.g., TCP MD5, since similar 733 algorithms are used over the bulk of the packet [10][11]. 735 Header-only authentication uses truncated ESP processing over only 736 the fixed portions of the IP (in IPsec) or IP/TCP (in TCP/MD5) 737 header, possibly with some short prefix of the payload, for padding 738 and to avoid small-block hash problems. This mode protects headers 739 from all third-party spoofing and tampering. It does not protect the 740 payload (outside that optionally used to pad the hash) from 741 tampering. Since the IP header is usually sufficiently smaller than 742 a typical hash block (e.g., 64 bytes for MD5), part or all of the TCP 743 header would typically be protected for either IPsec or TCP/MD5. 744 This then completely protects TCP against RST attacks. Header-only 745 mode does not protect from man-in-the-middle replay of signed headers 746 with alternate payloads. For packets substantially larger than the 747 hash block size (again, 64 bytes for MD5), header-only mode can 748 represent a significant computational savings over full-packet 749 authentication. 751 Both header-only and nonce mode authentication require modifications 752 to IPsec or TCP/MD5. These modes would be negotiated during IKE for 753 IPsec or at connection establishment for TCP/MD5. 755 Nonce authentication ignores the context of individual packets 756 completely when computing the authentication signature. The 757 signature may be fixed or vary, but is independent of the packet 758 header and contents. The signature is effectively a cookie; it may 759 even be the case that the SPI itself (for IKE) or ISN (for TCP/MD5) 760 are sufficient for this purpose, though we do not recommend either 761 (SPI values are not chosen pseudo-randomly, and ISNs are not always 762 chosen pseudorandomly). The cookie may the keys established during 763 IKE or the augmented auto-key version of TCP/MD5. The benefit of 764 nonce mode is performance; only header modification is required, 765 avoiding all computational overhead. Nonce mode protects only from 766 off-path third-party spoofing. 768 Conventional IPsec and TCP/MD5 and header-only mode both protect TCP 769 from all third-party spoofing attacks. Nonce-only mode TCP protects 770 only against off-path third-party attacks, but has much lower 771 computational cost. 773 In summary, there are two components needed to enable more widespread 774 use of existing IPsec or TCP/MD5 spoofing protection. Automatic 775 anonymous keying is already supported by IPsec using IKE with a 776 public shared secret; similar keying can be added to TCP/MD5 by 777 adding a Diffie-Hellman exchange therein, or even by just using the 778 TCP ISN. High-performance variants of both schemes are possible. 780 6. Security Considerations 782 This entire document focuses on increasing the security of transport 783 protocols and their resistance to spoofing attacks. Security is 784 addressed throughout. 786 This document describes a number of techniques for defeating spoofing 787 attacks. Those relying on clear-text cookies, either explicit or 788 implicit (e.g., window sequence attenuation) do not protect from 789 man-in-the-middle spoofing attacks, since valid values can be learned 790 from prior traffic. Those relying on true authentication algorithms 791 are stronger, protecting even from man-in-the-middle, because the 792 authentication hash in a single packet approaches the behavior of 793 "one time" cookies. 795 Security at various levels of the protocol stack are addressed. 796 Spoofing attacks are fundamentally identity masquerading, so we 797 believe the most appropriate solutions defeat these at the network 798 layer, where end-to-end identity lies. Some transport protocols 799 subsume endpoint identity information from the network layer (e.g., 800 TCP pseudo-headers), while others establish per-connection identity 801 based on exchanged nonces (e.g., SCTP). It is reasonable, if not 802 recommended, to address security at all layers of the protocol stack. 803 We believe that the current attacks are most directly addressed at 804 the network layer. 806 Some new solutions discussed weaken overall security compared to 807 existing solutions. However, a stronger solution which is not 808 deployed, due to its complexity or performance, is equivalent to no 809 security at all. Providing a more easily deployed anonymous variant 810 of IKE or TCP/MD5 together with authentication that can be adjusted 811 to trade strength for performance may constitute an overall benefit 812 toward the increased deployment of security solutions. 814 7. Conclusions 816 This document describes the details of the recent BGP spoofing 817 attacks involving spurious RSTs used to shutdown TCP connections. It 818 summarizes and discusses a variety of current and proposed solutions 819 at various protocol layers. 821 8. Acknowledgments 823 This document was inspired by discussions on the 824 about the 825 recent spoofed RST attacks on BGP routers, including R. Stewart's 826 draft [13][22]. The analysis of the attack issues, alternate 827 solutions, and the anonymous security proposed solutions were the 828 result of discussions on that list as well as with USC/ISI's T. 829 Faber, A. Falk, G. Finn, and Y. Wang. Ran Atkinson suggested the 830 UDP variant of TCP/MD5, and Paul Goyette suggested applying 831 headerANON-style processing to TCP/MD5 and using the ISN to seed TCP/ 832 MD5. Other improvements are due to the input of various members of 833 the IETF's TCPM WG. 835 9. References 837 9.1 Normative References 839 [1] "Technical Cyber Security Alert TA04-111A: Vulnerabilities in 840 TCP -- http://www.us-cert.gov/cas/techalerts/TA04-111A.html", 841 , April 20 2004. 843 [2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 844 Signature Option", RFC 2385, August 1998. 846 [3] Poon, K., "Use of TCP timestamp option to defend against blind 847 spoofing attack", (work in progress) , June 2004. 849 [4] Touch, J., "ANONsec: Anonymous Security to Defend Against 850 Spoofing Attacks", (work in progress) , July 2004. 852 [5] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, 853 May 1992. 855 [6] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 856 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 857 1573-1583, March 1999. 859 [7] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 860 60, RFC 3360, August 2002. 862 [8] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 863 September 1981. 865 [9] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions for 866 High Performance", RFC 1323, May 1992. 868 [10] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995. 870 [11] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995 871 77-86., March 1999. 873 [12] O'Malley, S. and L. Peterson, "TCP Extensions Considered 874 Harmful", RFC 1263, October 1991. 876 [13] "IETF TCPM Working Group and mailing list - 877 http://www.ietf.org/html.charters/tcpm-charter.html", . 879 [14] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 880 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 881 "Stream Control Transmission Protocol", RFC 2960, October 2000. 883 [15] Bernstein, D., "SYN cookies -- 884 http://cr.yp.to/syncookies.html", , 1997. 886 [16] Kent, S. and R. Atkinson, "Security Architecture for the 887 Internet Protocol", RFC 2401, November 1998. 889 [17] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 890 November 1998. 892 [18] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 893 (ESP)", RFC 2406, November 1998. 895 [19] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 896 RFC 2409, November 1998. 898 [20] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its 899 Use With IPsec", RFC 2410, November 1998. 901 [21] Maughan, D., Schneider, M. and M. Schertler, "Internet Security 902 Association and Key Management Protocol (ISAKMP)", RFC 2408, 903 November 1998. 905 9.2 Informative References 907 [22] Stewart, R., "Transmission Control Protocol security 908 considerations", draft-ietf-tcpm-tcpsecure-01 (work in 909 progress), June 2004. 911 [23] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 912 draft-ietf-dccp-spec-06 (work in progress), February 2004. 914 [24] Kent, S. and K. Seo, "Security Architecture for the Internet 915 Protocol", draft-ietf-ipsec-rfc2401bis-02 (work in progress), 916 April 2004. 918 [25] Kent, S., "IP Authentication Header", 919 draft-ietf-ipsec-rfc2402bis-07 (work in progress), March 2004. 921 [26] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 922 draft-ietf-ipsec-ikev2-14 (work in progress), June 2004. 924 Author's Address 926 Joe Touch 927 USC/Information Sciences Institute 928 4676 Admiralty Way 929 Marina del Rey, CA 90292-6695 930 U.S.A. 932 Phone: +1 (310) 448-9151 933 Fax: +1 (310) 448-9300 934 EMail: touch@isi.edu 935 URI: http://www.isi.edu/touch 937 Intellectual Property Statement 939 The IETF takes no position regarding the validity or scope of any 940 Intellectual Property Rights or other rights that might be claimed to 941 pertain to the implementation or use of the technology described in 942 this document or the extent to which any license under such rights 943 might or might not be available; nor does it represent that it has 944 made any independent effort to identify any such rights. Information 945 on the procedures with respect to rights in RFC documents can be 946 found in BCP 78 and BCP 79. 948 Copies of IPR disclosures made to the IETF Secretariat and any 949 assurances of licenses to be made available, or the result of an 950 attempt made to obtain a general license or permission for the use of 951 such proprietary rights by implementers or users of this 952 specification can be obtained from the IETF on-line IPR repository at 953 http://www.ietf.org/ipr. 955 The IETF invites any interested party to bring to its attention any 956 copyrights, patents or patent applications, or other proprietary 957 rights that may cover technology that may be required to implement 958 this standard. Please address the information to the IETF at 959 ietf-ipr@ietf.org. 961 Disclaimer of Validity 963 This document and the information contained herein are provided on an 964 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 965 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 966 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 967 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 968 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 969 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 971 Copyright Statement 973 Copyright (C) The Internet Society (2004). This document is subject 974 to the rights, licenses and restrictions contained in BCP 78, and 975 except as set forth therein, the authors retain all their rights. 977 Acknowledgment 979 Funding for the RFC Editor function is currently provided by the 980 Internet Society.