idnits 2.17.1 draft-ietf-tcpm-tcpsecure-01.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 469. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 485), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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? ** 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 == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 12) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 116: '... implementations SHOULD also introduce...' RFC 2119 keyword, line 183: '...ttling mechanism SHOULD be implemented...' RFC 2119 keyword, line 185: '...w. These values MUST be tunable to ac...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 92 has weird spacing: '... an artifac...' == Line 98 has weird spacing: '...otiated and i...' -- 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 (June 2, 2004) is 7239 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: '3' is defined on line 431, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2385 (ref. '2') (Obsoleted by RFC 5925) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Dalal 2 Internet-Draft Editor 3 Expires: December 1, 2004 June 2, 2004 5 Transmission Control Protocol security considerations 6 draft-ietf-tcpm-tcpsecure-01.txt 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. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 1, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 TCP (RFC793 [1]) is widely deployed and one of the most often used 40 reliable end to end protocols for data communication. Yet when it 41 was defined over 20 years ago the internet, as we know it, was a 42 different place lacking many of the threats that are now common. 43 Recently several rather serious threats have been detailed that can 44 pose new methods for both denial of service and possibly data 45 injection by blind attackers. This document details those threats 46 and also proposes some small changes to the way TCP handles inbound 47 segments that either eliminate the threats or at least minimize them 48 to a more acceptable level. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Blind reset attack using the RST bit . . . . . . . . . . . . . 5 54 2.1 Description of the attack . . . . . . . . . . . . . . . . 5 55 2.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Blind reset attack using the SYN bit . . . . . . . . . . . . . 7 57 3.1 Description of the attack . . . . . . . . . . . . . . . . 7 58 3.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Blind data injection attack . . . . . . . . . . . . . . . . . 9 60 4.1 Description of the attack . . . . . . . . . . . . . . . . 9 61 4.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 5. Backward Compatability and Other considerations . . . . . . . 10 63 6. Middlebox considerations . . . . . . . . . . . . . . . . . . . 12 64 6.1 Middlebox that cache RST's . . . . . . . . . . . . . . . . 12 65 6.2 Middleboxes that advance sequence numbers . . . . . . . . 12 66 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 70 9.2 Informative References . . . . . . . . . . . . . . . . . . . 16 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 72 Intellectual Property and Copyright Statements . . . . . . . . 17 74 1. Introduction 76 TCP (RFC793 [1]) is widely deployed and one of the most often used 77 reliable end to end protocols for data communication. Yet when it 78 was defined over 20 years ago the internet, as we know it, was a 79 different place lacking many of the threats that are now common. 80 Recently several rather serious threats have been detailed that can 81 pose new methods for both denial of service and possibly data 82 injection by blind attackers. This document details those threats 83 and also proposes some small changes to the way TCP handles inbound 84 segments that either eliminate the threats or at least minimize them 85 to a more acceptable level. 87 Most of these proposals modify handling procedures for DATA, RST and 88 SYN's as defined in RFC793 [1] but do not cause interoperability 89 issues. The authors feel that many of the changes proposed in this 90 document would, if TCP were being standardized today, be required to 91 be in the base TCP document and the lack of these procedures is more 92 an artifact of the time when TCP was developed than any strict 93 requirement of the protocol. 95 For some uses of TCP, an alternative protection against the threats 96 that these changes address has already been implemented and deployed 97 in the TCP MD5 Signature Option (RFC2385 [2]). Because this option 98 is not negotiated and is implemented with a manually established 99 shared key or password, it has been used for protecting uses of TCP 100 in which the endpoints are managed, such as for BGP peers. RFC3562 101 [2] provides importance guidance for users of RFC2385 [2] for 102 decreasing their vulnerability to key-guessing. 104 Yet another commonly known mitigation technique is cryptography, 105 especially IPSec. For IPSec to work, both ends of the connection 106 need to agree on the properties to use for the connection and also 107 agree upon a pre-shared key. In the absence of PKI infrastucture, 108 this may be incovenient. IPSec with manual keys can be used to avoid 109 using ISAKMP. However, this adds considerable burden on the 110 administration of such solution. If ISAKMP were to be used, this 111 would typically require all firewalls in the path between the two TCP 112 endpoints to allow UDP traffic for atleast ISAKMP to function. 113 Further, IPSec and NAT have long been known to have interoperability 114 issues. 116 TCP implementations SHOULD also introduce ephemeral port 117 randomization. By randomizing ephemeral ports an attacker would have 118 a less easy time in guessing the four tuples needed to mount a 119 successful attack. Since ephemeral ports are 16 bit values and are a 120 subset of the entire available port numbers, it is a weaker defense 121 than an exact sequence number match as proposed here which is a 122 32-bit value and changes dramatically within the life of a 123 connection. Neverthless, both of them are complimentary solutions 124 that will make it difficult to launch attacks discussed below. 126 This proposal provides immediate protection to a TCP session even 127 when implemented on only one peer. Alternative proposals, including 128 the use of cookies (or, use of the timestamp option as a cookie) 129 require both peers to implement the changes before any additional 130 protection can be realized. 132 2. Blind reset attack using the RST bit 134 2.1 Description of the attack 136 It has been traditionally thought that for a blind attacker to reset 137 a TCP connection the attacker would have to guess a single sequence 138 number in the TCP sequence space. This would in effect require an 139 attacker to generate (2^^32) segments in order to reset a connection. 140 Recent papers have shown this to not necessarily be the case. An 141 attacker need only guess a number that lies between the last sequence 142 number acknowledged and the last sequence number acknowledged added 143 to the receiver window (RCV.WND).([4]).Modern operating systems 144 normally default the RCV.WND to about 32,768 bytes. This means that 145 a blind attacker need only guess 65,535 RST segments (2^^32/RCV.WND) 146 in order to reset a connection. At DSL speeds this means that most 147 connections (assuming the attacker can accurately guess both ports) 148 can be reset in under 200 seconds (usually far less). With the rise 149 of broadband availability and increasing available bandwidth, many 150 Operating Systems have raised their default RCV.WND to as much as 151 64k, thus making these attacks even easier. 153 2.2 Solution 155 RFC793 [1] currently requires handling of a segment with the RST bit 156 when in a synchronized state to be processed as follows: 157 1) If the RST bit is set and the sequence number is outside the 158 expected window, silently drop the segment. 159 2) If the RST bit is set and the sequence number is acceptable i.e.: 160 (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then reset the connection. 162 Instead, the following changes should be made to provide some 163 protection against such an attack. 164 A) If the RST bit is set and the sequence number is outside the 165 expected window, silently drop the segment. 166 B) If the RST bit is set and the sequence number exactly matches the 167 next expected sequence number, reset the connection. 168 C) If the RST bit is set and the sequence number does not exactly 169 match the next expected sequence value, yet is within the 170 acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an 171 acknowledgment: 172 173 After sending the acknowledgment, drop the unacceptable segment 174 and return. 175 This solution forms a challenge/response with any RST where the 176 value does not exactly match the expected value and yet the RST is 177 within the window. In cases of a legitimate reset without the 178 exact sequence number, the consequences of this new challenge/ 179 response will be that the peer requires an extra round trip time 180 before the connection can be reset. 182 In order to alleviate multiple RSTs/SYNs from triggering multiple 183 challenge ACKs, a ACK throttling mechanism SHOULD be implemented. 184 Suggested values are to send no more than 10 challenge ACKs in a 5 185 second window. These values MUST be tunable to accomodate different 186 requirements. ACK throttling if implemented successfully can lead to 187 several advantages. Besides preventing the RST/ACK war outlined in 188 the section below, it can also alleviate spurious fast retransmits at 189 the remote end caused by flood of duplicate ACKs and also save 190 spurious processing required to send an ACK on the victim side. 192 3. Blind reset attack using the SYN bit 194 3.1 Description of the attack 196 Analysis of the reset attack, which uses the RST flag bit, highlights 197 another possible avenue for a blind attacker. Instead of using the 198 RST bit an attacker can use the SYN bit as well to tear down a 199 connection. Using the same guessing technique, repeated SYN's can be 200 generated with sequence numbers incrementing by an amount not larger 201 than the window size apart and thus eventually cause the connection 202 to be terminated. 204 3.2 Solution 206 RFC793 [1] currently requires handling of a segment with the SYN bit 207 set in the synchronized state to be as follows: 208 1) If the SYN bit is set and the sequence number is outside the 209 expected window, send an ACK back to the sender. 210 2) If the SYN bit is set and the sequence number is acceptable i.e.: 211 (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then send a RST segment to 212 the sender. 214 Instead, changing the handling of the SYN to the following will 215 provide complete protection from this attack: 216 1) If the SYN bit is set, irrespective of the sequence number, send 217 an ACK to the remote peer: 218 219 After sending the acknowledgment, drop the unacceptable segment 220 and return. 221 This solution agains forms a challenge response with the peer as 222 in the previous section. 224 By always sending an ACK to the sender, a challenge/response is setup 225 with the peer. A legitimate peer, after restart, would not have a 226 TCB in the synchronized state. Thus when the ACK arrives the peer 227 should send a RST segment with the sequence number derived from the 228 ACK field that caused the RST. 230 Note, there is one corner case for the SYN attack problem that will 231 prevent the successful reset of the connection. This is a result of 232 the RFC793 [1] specification and is nothing to do with the proposed 233 solution. In this problem, if a restarting host generates a SYN with 234 an initial sequence number that is exactly equal to RCV.NXT - 1 of 235 the remote TCP endpoint that is still in the established state and if 236 the SYN arrives at the peer that is still holding the stale 237 connection, an ACK will be generated. This ACK will have an ack 238 value of RCV.NXT and will be acceptable to the restarting host which 239 will accept the ACK and do nothing. The SYN will then be 240 retransmitted and the behavior will repeat. This could lead to an 241 initialization failure. Subsequent connection attempts will 242 hopefully succeed by choosing a new ISN that is not equal to RCV.NXT 243 - 1. A similar problem will be seen should the SYN contain data. 245 4. Blind data injection attack 247 4.1 Description of the attack 249 A third type of attack is also highlighted by both the RST and SYN 250 attacks. It is quite possible to inject data into a TCP connection 251 by simply guessing a sequence value that is within the window. The 252 ACK value of any data segment is considered valid as long as it does 253 not acknowledge data ahead of the next segment to send. In other 254 words an ACK value is acceptable if it is (SND.UNA-(2^^31-1)) <= 255 SEG.ACK <= SND.NXT). This means that an attacker simply need guess 256 two ACK values with every guessed sequence number so that the chances 257 of successfully injecting data into a connection are 1 in ((2^^32 / 258 RCV.WND) * 2). 260 When an attacker sucessfully injects data into a connection the data 261 will sit in the receiver's re-assembly queue until the peer sends 262 enough data to bridge the gap between the RCV.NXT value and the 263 injected data. At that point one of two things will occur either: 264 a) An ACK war will ensue with the receiver indicating that it has 265 received data up until RCV.NXT (which includes the attackers data) 266 and the sender sending a corrective ACK with a value less than 267 RCV.NXT (the real sequence number of the last byte sent). 268 b) The sender will send enough data to the peer which will move 269 RCV.NXT even further along past the injected data. 270 In either case the injected data will be made readable to the upper 271 layer and in case the connection will eventually be reset by one 272 of the sides. Note that the protections illustrated in this section 273 neither cause an ACK war nor prevent one from occuring if data is 274 actually injected into a connection. The ACK war is a natural 275 consequence of any data injection that is sucessful. 277 4.2 Solution 279 An additional input check should be added to any incoming segment. 280 The ACK value should be acceptable only if it is in the range of 281 ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). MAX.SND.WND is 282 defined as the largest window that the local receiver has ever 283 advertised to it's peer. This window is the scaled value i.e. the 284 value may be larger than 65,535 bytes. This small check will greatly 285 reduce the vulnerability of an attacker guessing a valid sequence 286 number since not only must he/she guess the sequence number in 287 window, but must also guess a proper ACK value within a scoped range. 288 This solution reduces but does not eliminate the ability to generate 289 false segments. It does however reduce the probability that invalid 290 data will be injected to a more acceptable level. For those 291 applications that wish to close this attack completely RFC2385 [2] 292 should be deployed between the two endpoints. 294 5. Backward Compatability and Other considerations 296 1) The proposed solution is backward compatible as it uses the 297 semantics laid down in RFC793 [1] to defend against it's own 298 weakness. Referring to the figure below, if we assume that the 299 RST (1.c) was in flight when the ACK (2) left TCP A, TCP B has no 300 way of knowing what triggered the ACK. For all it cares, the ACK 301 might have been a result of the data or the RST that it had sent 302 earlier. Hence in either case, TCP B must reply to this ACK with 303 an appropriate RST that is in keeping with RFC793 [1]. 305 2) Concerns have been raised that the challenge response mechanism 306 will lead to a reflector kind of attack. In this attack, it is 307 believed that an attacker with higher bandwidth can potentially 308 spoof SYN or RST packets within the window and cause ACK flooding 309 to a remote peer that may have a lower bandwidth. These concerns 310 are misplaced because it is trivial to cause a victim to generate 311 an ACK. A spoofer can simply send packets with sequence numbers 312 that are outside the acceptable window of the attacker or send an 313 ACK that acknowledges something that is not yet sent. Further, an 314 attacker can also simply generate data packets that fall within 315 the window to cause an ACK to be sent. RFC793 [1] also mandates 316 that an ACK be sent if the incoming SYN to an established 317 connection falls outside the acceptable window. All these 318 scenarios can be used to launch a flood attack. However, the 319 potential harm of such attacks are low and can be easily detected 320 due to the volume of packets generated. The latter is a strong 321 deterrant to such attacks. 323 3) There is a corner scenario in the above proposed solutions which 324 will require more than one round trip time to successfully abort 325 the connection as per the figure below. This scenario is similar 326 to the one in which the original RST was lost in the network. 328 TCP A TCP B 329 1.a. ESTABLISHED <-- <-- ESTABLISHED 330 b. (delayed) ... <-- ESTABLISHED 331 c. (in flight) ... <-- CLOSED 332 2. ESTABLISHED --> --> CLOSED 333 (ACK for 1.a) 334 ... <-- CLOSED 335 3. CHALLENGE --> --> CLOSED 336 (for 1.c) 337 ... <-- RESPONSE 338 4.a. ESTABLISHED <-- 1.b reaches A 339 b. ESTABLISHED --> 340 c. (in flight) ... <-- CLOSED 341 5. RESPONSE arrives at A, but is dropped because of being out of window. 343 6. ESTABLISHED <-- 4.c reaches A 344 7. CLOSED CLOSE 346 6. Middlebox considerations 348 The following scenarios were brought to notice by the tcpm working 349 group members as middlebox issues which may cause the proposed 350 solution to behave in an unexpected manner. 352 6.1 Middlebox that cache RST's 354 Consider a middlebox B tracking connection between two TCP endhosts A 355 and C. If C sends a RST with a sequence number that is within the 356 window but not an exact match to reset the connection and if B does 357 not have the fix proposed here, it will clear the connection and ask 358 A to do the same. If A does not have the fix it will clear the 359 connection and everything will be fine. However if A does have the 360 proposed fix above, it will send a challenge ACK. B being a 361 middlebox will intercept this ACK and resend the RST cached earlier 362 that was responsible for bringing down the connection. However, the 363 RST will again be not acceptable and will trigger a challenge ACK 364 again. This will cause a RST/ACK war to happen. However, we are not 365 aware of middleboxes that actually do this and believe the design 366 itself is flawed in that given the scenario that the RST from B to A 367 got lost on the way, A will continue to hold the connection and A 368 might send an ACK an arbitrary time after the connection was brought 369 down at B. In this case, B will have to cache the RST for an 370 arbitrary amount of time till its confirmed that the connection has 371 been cleared at A. 373 6.2 Middleboxes that advance sequence numbers 375 Some Middleboxes may compute RST sequence numbers at the higher end 376 of the acceptable window. The setup is the same as the earlier case, 377 but in this case instead of sending the cached RST, the middlebox 378 sends a RST that computes it's sequence number as a sum of the ack 379 field in the ACK and the window advertised by the ACK that was sent 380 by A to challenge the RST as depicted below. The difference in the 381 sequence numbers between step 1 and 2 below is due to data lost in 382 the network. 384 TCP A Middlebox 386 1. ESTABLISHED <-- <-- CLOSED 388 2. ESTABLISHED --> --> CLOSED 390 3. ESTABLISHED <-- <-- CLOSED 392 4. ESTABLISHED --> --> CLOSED 393 5. ESTABLISHED <-- <-- CLOSED 395 Although the authors are not aware of a working implementation that 396 does the above, it could be mitigated by implementing the RST 397 throttling mechanism described earlier. 399 7. Contributors 401 Mitesh Dalal and Amol Khare of Cisco Systems came up with the 402 solution for the RST/SYN attacks. Anantha Ramaiah and Randall 403 Stewart of Cisco Systems discovered the data injection vulnerability 404 and together with Patrick Mahan and Peter Lei of Cisco Systems found 405 solutions for the same. Paul Goyette, Mark Baushke, Frank 406 Kastenholz, Art Stine and David Wang of Juniper Networks provided the 407 insight that apart from RSTs, SYNs could also result in formidable 408 attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of 409 Wind River Systems and Xiaodan Tang of QNX Software along with the 410 folks above helped in ratifying and testing the interoperability of 411 the suggested solutions. 413 8. Acknowledgments 415 Special thanks to Sharad Ahlawat, Mark Allman, Steve Bellovin, Vern 416 Paxson, Allison Mankin, Damir Rajnovic, John Wong and the tcpm WG 417 members for suggestions and comments. 419 9. References 421 9.1 Normative References 423 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 424 September 1981. 426 [2] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 427 Signature Option", RFC 2385, August 1998. 429 9.2 Informative References 431 [3] Leech, M., "Key Management Considerations for the TCP MD5 432 Signature Option", RFC 3562, July 2003. 434 [4] Watson, P., ""Slipping in the Window: TCP Reset attacks"". 436 Author's Address 438 Mitesh Dalal 439 Editor 440 170 Tasman Drive 441 San Jose, CA 95134 442 USA 444 Phone: +1-408-853-5257 445 EMail: mdalal@cisco.com 447 Intellectual Property Statement 449 The IETF takes no position regarding the validity or scope of any 450 Intellectual Property Rights or other rights that might be claimed to 451 pertain to the implementation or use of the technology described in 452 this document or the extent to which any license under such rights 453 might or might not be available; nor does it represent that it has 454 made any independent effort to identify any such rights. Information 455 on the procedures with respect to rights in RFC documents can be 456 found in BCP 78 and BCP 79. 458 Copies of IPR disclosures made to the IETF Secretariat and any 459 assurances of licenses to be made available, or the result of an 460 attempt made to obtain a general license or permission for the use of 461 such proprietary rights by implementers or users of this 462 specification can be obtained from the IETF on-line IPR repository at 463 http://www.ietf.org/ipr. 465 The IETF invites any interested party to bring to its attention any 466 copyrights, patents or patent applications, or other proprietary 467 rights that may cover technology that may be required to implement 468 this standard. Please address the information to the IETF at 469 ietf-ipr@ietf.org. 471 Disclaimer of Validity 473 This document and the information contained herein are provided on an 474 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 475 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 476 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 477 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 478 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 479 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 481 Copyright Statement 483 Copyright (C) The Internet Society (2004). This document is subject 484 to the rights, licenses and restrictions contained in BCP 78, and 485 except as set forth therein, the authors retain all their rights. 487 Acknowledgment 489 Funding for the RFC Editor function is currently provided by the 490 Internet Society.