idnits 2.17.1 draft-ietf-rpsec-bgpsecrec-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 3978, Section 5.5 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 510. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 526), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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. 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 210: '...REGATE attribute SHOULD be set. This ...' RFC 2119 keyword, line 228: '...a security system in operation, SHOULD...' RFC 2119 keyword, line 234: '... SHOULD NOT be impacted by the secur...' RFC 2119 keyword, line 235: '... verification MAY be offered for the...' RFC 2119 keyword, line 237: '...e UPDATE message SHOULD be authenticat...' (28 more instances...) 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 (Feb 2004) is 7376 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) ** Downref: Normative reference to an Informational RFC: RFC 2196 (ref. '1') ** Obsolete normative reference: RFC 1771 (ref. '3') (Obsoleted by RFC 4271) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Protocol Security B. Christian, Ed. 3 Requirements KMC Telecom Solutions 4 Internet-Draft Feb 2004 5 Expires: August 1, 2005 7 BGP Security Requirements 8 draft-ietf-rpsec-bgpsecrec-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, in accordance with Section 6 of RFC 15 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 1, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 The security of BGP is critical to the proper operation of 42 large-scale internetworks, both public and private. While securing 43 the information transmitted between two BGP speakers is a relatively 44 easy technical matter, securing BGP, as a routed system, is more 45 complex. This document describes a set of requirements for securing 46 BGP, including securing peering relationships between BGP speakers, 47 and authenticating the routing information carried within BGP. 49 1. Introduction 51 1.1 System Description 53 BGP is described in RFC1771 [3] as a routing protocol. Essentially, 54 BGP speakers exchange information about reachable destinations in an 55 internetwork through a peering session. Once this information has 56 been exchanged, each BGP speaker locally determines a loop free path 57 to each reachable destination, based on local policy, policy 58 indicators (or policies) carried in the update, and the AS Path 59 carried in the BGP update. 61 1.2 Threats 63 Threats to networking protocols generally fall under one of the three 64 categories as defined in RFC 2196 [1]: 65 o Unauthorized access to resources and/or information 66 o Unintended and/or unauthorized disclosure of information 67 o Denial of service 69 A number of attacks can be realized which, if exploited, can lead to 70 one of the above mentioned threats. These are typically classified 71 as passive attacks and active attacks. Passive attacks are ones 72 where an attacker simply reads information off the network and 73 obtains confidential and/or private information. Active attacks are 74 ones where the attacker writes data to the network and can include 75 replay attacks, message insertion, message deletion, message 76 modification and man-in-the-middle attacks. These attacks are often 77 combined. 79 Attacks that do not involve direct manipulation of BGP, and the 80 information contained within it, are outside the scope of this 81 document. When possible, the requirements will attempt to minimize 82 the extent of the damage that occurs when end systems come under 83 attack. 85 The intent of this requirements document is to prevent attacks that 86 originate false data or create invalid routing paths and therefore 87 addresses issues relating to data integrity and peer entity 88 authentication. As described in RFC 3552 [2], data integrity 89 protection ensures that data is not modified in transit and peer 90 entity authentication ensures that there is a reasonable guarantee 91 that the sender and recipient of the data are the intended parties. 93 Guaranteed packet delivery is not part of the BGP protocol security 94 model. Just because a packet is addressed to a specific destination 95 does not mean it will be received, even with a "secure" route. For 96 example: an attacker could have compromised an intermediate router 97 and installed a static route for target address A.B.C.D pointing to 98 an inappropriate direction or an attacker might splice into a circuit 99 between two secure routers and install a device that diverts A.B.C.D 100 traffic without requiring the compromise of control plane devices. 102 1.3 Areas to secure 104 There are two primary points where BGP may be secured. If we examine 105 the system description presented above those points are as follows. 106 o The session between two BGP speakers can be secured such that the 107 BGP data received by the BGP speakers can by cryptographically 108 verified to have been transmitted by the other speaker. 109 o The originator and the propagators of prefix information may have 110 their policy information verified such that the intent of the 111 policy with respect to the specific prefix is preserved 113 There are also several questions we can ask about the information 114 contained within a received update. 115 o Is the originating Autonomous system authorized to propagate the 116 prefix we have received? 117 o Is the AS path, received via an UPDATE, valid? 119 The verification of AS-Path validity falls into three distinct 120 categories. 121 o Does the AS-Path specified actually exist and, based on the 122 AS-PATH, is it possible to traverse that path to reach a given 123 prefix? 124 o Has the update actually travelled the path? 125 o Was the update authorized to traverse the given path by the 126 originator of the prefix? 128 In this draft we do not attempt to set requirements dealing with the 129 third question presented above. However, the needs of the operators 130 of the systems that use BGP are such that the first two questions are 131 of key importance to any secured interdomain routing system. 133 2. Application Concepts 135 In order to properly identify security requirements it is important 136 to cover the fundamental aspects of BGP as related to security 137 requirements. The following list presents the basic parameters and 138 application concepts of BGP that will be covered by this document. 139 o Peer Communication: BGP traffic travels over TCP between peers, so 140 BGP speakers assume the TCP data delivery guarantees of TCP in a 141 benign environment. This includes ordered, error-free delivery of 142 application traffic from a peer identified by an IP address, plus 143 integrity of the control aspects of TCP. From a security 144 perspective, these guarantees need to be enforced in the context 145 of possible active wiretapping. 146 o Routing and Reachability: BGP is a protocol used to convey routing 147 and reachability information both internal and external to an 148 Autonomous System. Typically, internal BGP is used to distribute 149 prefix reachability information in conjunction with an IGP and is 150 used by a distinct network administrative entity to convey 151 internal routing policy regarding external and internal 152 information. External BGP is typically used to distribute route/ 153 prefix reachability information between two distinct routing 154 entities and is used to signal forwarding preferences and policy 155 decisions. 156 o Inter-AS UPDATE Message assumptions: When an AS distributes 157 reachability information to a peer it is done with the intent of 158 affecting routing decisions by the peer. For example, an AS-A 159 sends peer AS-B a less specific advertisement and peer AS-C a 160 "more" specific advertisement. This prefix distribution decision 161 may have been made to provide a means for failure resolution 162 between AS-A and AS-C. Update messages are sent between AS peers 163 with the implicit assumption that those messages will be forwarded 164 to others. A notable exception to this assumption is the use of 165 various policy based mechanisms between peers such as the 166 NO-EXPORT community. In this document an important aspect of the 167 UPDATE message to note is that the specific UPDATE message itself 168 is typically not re-transmitted. Instead, the specific UPDATE 169 message is regenerated continually as it passes from BGP speaker 170 to BGP speaker. Furthermore, UPDATE messages have no mechanism 171 for freshness (i.e timestamps or sequence numbers). This 172 indicates that messages may appear valid at any point in the life 173 of a BGP peering session. 174 o Inter-AS withdraw message assumptions: The processing model of BGP 175 RFC1771 [3] indicates that only the peer advertising NLRI 176 information may withdraw it. There are several instances where a 177 withdraw may occur. Typical reasons for withdraw include the 178 determination of a better path, peer session failure, or local 179 policy change. There is no specified mechanism for indicating, to 180 an external peer, the reason for a route withdraw. Each withdraw 181 received from a valid peering session must be taken at face value. 182 There is no, existing, method to ensure that an AS will properly 183 propagate withdraw messages received from it's external peers. 184 o AS-Path assumptions: Aside from the use of AS-Set, the AS-Path is 185 typically considered to be an ordered list of the Autonomous 186 Systems that an update has traversed. In most cases the first AS 187 in the list is the origin AS, or at least the AS responsible for 188 the management of the NLRI information associated with the first 189 AS. Specifications state that the AS topology must be loop free. 190 This indicates that the appearance of the local AS in an update 191 received from an external peer is generally not permitted. The 192 prepending of AS information for received updates and transmitted 193 updates is generally permitted and is common practice. Prepended 194 AS information on inbound advertisements (where the external peers 195 AS is prepended) and outbound advertisements (where the local AS 196 number is prepended) is a commonly used method to effect 197 forwarding changes. 198 o Route Origination: Originating a route without the ability to 199 forward the traffic associated with that route is, in most cases, 200 in conflict with the intent of the BGP specification. BGP 201 speakers may originate routes based on various internal and 202 external data. An Autonomous System should only originate a 203 prefix to it's external peers if that prefix has been somehow 204 allocated to the administrators of that system, or authorized by 205 the prefix holders. 206 o Aggregation: Aggregation, and deaggregation, of prefixes can cause 207 significant issues with proposed security mechanisms. According 208 to RFC 1771, if a BGP speaker chooses to aggregate a set of more 209 specific prefixes into a less specific prefix then the 210 ATOMIC_AGGREGATE attribute SHOULD be set. This creates a 211 significant potential loophole in an attempt to secure BGP based 212 on the RFC specifications. 214 3. Deployment Requirements 216 We have determined, through discussion with several large 217 internetwork operators and equipment vendors, that the following 218 attributes are important to the ongoing performance of interdomain 219 routing systems such as BGP 221 3.1 Convergence speed 223 Convergence speed is a major concern to many operators of large scale 224 internetworking systems. Networks, and internetworks, are carrying 225 ever increasing amounts of information that is time and delay 226 sensitive; increasing convergence times can adversely affect the 227 usability of the network, and the ability of an internetwork to grow. 228 BGP's convergence speed, with a security system in operation, SHOULD 229 be equivalent to BGP running without the security system in 230 operation. This includes the preservation of optimizations currently 231 used to produce acceptable convergence speeds on current hardware, 232 including update packing, peer groups, and others. Current timers, 233 including hold timers, keepalive timers, and the peering process, 234 SHOULD NOT be impacted by the security system. Two types of 235 verification MAY be offered for the NLRI and the AS_PATH in order to 236 allow for a selection of optimizations: 237 o Contents of the UPDATE message SHOULD be authenticated in 238 real-time as the UPDATE message is processed. 239 o The route information base MAY be authenticated periodically or in 240 an event driven manner by scanning the data and verifying the 241 originating AS and the verifiability of the AS-PATH list. 243 All BGP implementations that implement security MUST utilize at least 244 one of the above methods for validating routing information. Real 245 time verification is preferred in order to prevent transitive 246 failures based on periodic or event driven scan intervals. 248 3.2 Incremental deployment 250 We will not be able to deploy a newly secured BGP protocol 251 instantaneously and will be unable to dictate a partitioning of large 252 internetworks by the operators. Because of this, there are several 253 requirements that any proposed mechanism to secure BGP must consider. 254 o BGP MUST support transmitting, receiving, and acting on both 255 secured and unsecured routing information with the security system 256 in place. 257 o The security system MUST allow the forming of peering 258 relationships between peers regardless of whether the security 259 system is in place 260 o MUST be backward compatible in the message formatting, 261 transmission, and processing of routing information carried 262 through a mixed security environment. Message formatting in a 263 fully secured environment MAY be handled in a non-backward 264 compatible fashion. 265 o In an environment where both secured and non-secured systems are 266 interoperating a mechanism MUST exist for secured systems to 267 identify whether an originator intended the information to be 268 secured. 270 3.3 Conditions for initialization 272 A key factor in the robust nature of the existing internal and 273 external relationships maintained in todays Internet provider space 274 is the ability to maintain and return to a significantly converged 275 state without the need to rely on systems external to the routing 276 system (the physical equipment that is performing the forwarding). 277 In order to ensure the rapid initialization and/or return to service 278 of failed nodes it is important to reduce reliance on external 279 systems to the greatest extent possible. Therefore, proposed systems 280 SHOULD NOT require connections to external systems, beyond those 281 directly involved in peering relationships, in order to return to 282 full service. Proposed systems MAY require post initialization 283 synchronization with external systems in order to synchronize 284 security information. 286 3.4 Trust level variability 288 Each secured environment may have different levels of requirements in 289 terms of what is acceptable or unacceptable. In environments that 290 require strict security it may not be acceptable to temporarily route 291 to a destination while waiting for security verification to be 292 performed. However, in many commercial environments the rapidity of 293 route installation may be of paramount importance; in order to 294 facilitate the more common occurence of route withdrawl due to 295 network failure. Based on the two divergent requirements, the 296 following criteria apply. 297 o The security system MUST support a range of possible outputs for 298 local determination of the trust level for a specific route. Any 299 given route should be trustable to a locally configured degree, 300 based on the completeness of security information for the update 301 and other factors. 302 o The security system SHOULD allow the operator to determine whether 303 the speed of convergence is more important than security 304 operations, or security operations are more important than the 305 speed of convergence. This facilitates the incremental deployment 306 of security on systems not designed to support increased 307 processing requirements imposed by the security system. 309 4. The Trust Model 311 In examining the various environments in which BGP is deployed, and 312 through discussions with various operators working with the context 313 of the public Internet, and other internetworks, it is apparent that 314 trust models are largely environment specific. For instance, in the 315 public Internet, a distributed trust model, following the current 316 transitive trust pattern of contractual and peering arrangements, 317 would fit the the business models of the participants. In other 318 environments a hierarchical trust model would work better. Thus, any 319 trust system specified in a security mechanism designed for BGP must 320 be flexible, and support both a true distributed trust model and a 321 fully hierarchical trust model. 323 Since hierarchical trust models are a subset (or a special case of) a 324 distributed trust model, any security system designed for BGP MUST 325 support a distributed trust model, and MUST also support a 326 hierarchical trust model, if desired. 328 If two internetworks using differing trust models are interconnected 329 they MUST be able to interoperate using locally determined levels of 330 trust to compensate for differences in their trust models. 332 5. The AS-Path Attribute and NLRI Authentication 334 BGP distributes routing information across the Internet (between BGP 335 speakers) using BGP UPDATE messages. The UPDATE message contains 336 withdrawn routes, path attributes and one or more NLRIs (Network 337 Layer Reachability Information is synonymous with advertised prefix). 338 For the remainder of this section, we will focus on the AS-Path 339 Attribute and the NLRI. Attributes such as local pref are locally 340 specific and, as such, are protected by BGP session security. 342 The AS_PATH for specific prefixes must be protected in any proposed 343 security system in three ways: 344 o Authorization of Originating AS: For all prefixes announced in 345 BGP, the originating AS MUST be verifiable through the trust model 346 as the authorized announcer of the prefix. The verification 347 mechanism must account for existing BGP mechanisms such as 348 summarization. For the purpose of this document the term 349 verifiable is defined as the resultant of a secured routing 350 systems as described in this document. The term specifically 351 indicates the ability to validate the originator of a specific 352 prefix (or block of IP addresses) and the ability to validate the 353 session through which the prefix was received 354 o The AS_PATH list MUST correspond to a verifiable list of 355 autonomous systems based on the peering topology of the network. 356 o Announcing AS Check: For all BGP peers, a BGP Implementation MUST 357 ensure that the first element of the AS_PATH list corresponds to 358 the locally configured AS of that peer. 359 o Routing information carried through BGP SHOULD include information 360 that can be used to verify the readvertisement or modification by 361 each autonomous system through which the UPDATE has passed. 363 There are many ways in which a differential between the speed of 364 prefix/AS path attribute propagation and the information validating 365 the the prefix/AS path attribute information can be exploited to 366 attack the routing system on a temporary basis. These types of 367 attacks are dominantly exploitative of the moment in time it takes to 368 follow the withdraw of a NLRI with an update. As a result of this 369 potential for temporary disruption, BGP security solutions MUST 370 propagate security information at the same rate as the BGP updates 371 and withdrawls. The following items are required to propagate at the 372 same rate: 373 o The distribution of key information used by individual actors 374 within the system, including the keys used by individual 375 autonomous systems to sign certificates and other objects 376 o The distribution of information about the AS authorized to 377 advertise a given block of IP addresses (or an address space) 378 o The distribution of information about connectivity between 379 autonomous systems and autonomous system polices, if such 380 information is to be distributed within the security system. 382 6. Address Allocation and advertisement 384 As part of the regular operation of the Internet, addresses that are 385 allocated to an organization may be, and are quite commonly, 386 advertised by a different organizations. Common reasons for this 387 practice include multi-homing and route reduction for the purposes of 388 resource conservation. There are two modes of delegation: 389 o A BGP speaker and listener have chosen to restrict the amount of 390 received prefixes for the listener. The listener has chosen to 391 honor route announcements sent in a summary fashion by the 392 speaker. 393 o Address space that is being delegated is part of a larger 394 allocation that is owned by an autonomous system. The owner then 395 delegates the smaller block to another AS for purposes of 396 advertisement. This mode is commonly observed in multi-homing. 398 These two modes lead to a single common requirement: Any BGP Security 399 solution MUST support delegation of an address block of any size 400 regardless of its relationship to other address blocks to another 401 entity via verifiable means. 403 An associated delegation criteria is the requirement to allow for 404 non-BGP IP end user implementations. As a result, all secured BGP 405 implementations MUST allow for the propagation of a prefix by more 406 than one originator AS within normal network convergence times. 408 7. NLRI and Path Attribute Tracking 410 The ability for a receiver to know exactly who originated and 411 forwarded a routing update, is a desirable trait. In order to 412 rapidly identify agressors and parties at fault for route table 413 disruption it is important to track and log prefix origination 414 information along with associated security information. 416 Any security system SHOULD provide a method to allow the receiver of 417 an update to verify that the originator actually originated the 418 update, and that the AS's listed in the AS_PATH actually forwarded 419 the update. 421 The data generated by logging may be very large depending on the 422 number of peers, the number of prefixes received, the authentication 423 model used, and routing policies. As such, efficient data structures 424 and storage mechanisms MUST be developed to allow for an effective 425 means of reproducing incidents and outages 427 Path and NLRI attributes MUST be logged using a standard format. The 428 format must be scalable with the amount of data logged and the 429 frequency of log generation. The frequency of log generation should 430 be controllable by the operator. The logging mechanisms for the 431 tracked information MUST be standardized across all platforms. 432 Logging ability both on and off line is considered highly desirable. 434 8. Transport Protection 436 Transport protection is an important aspect of BGP routing protocol 437 security. The potential to create a linked transport/NLRI/AS-PATH 438 authentication mechanism should not be overlooked and may provide for 439 the accelerated deployment of a BGP security system. Current 440 security mechanisms for BGP transport are inadequate and require 441 significant operator interaction to maintain a respectable level of 442 security. 444 Any proposed security mechanism MUST include provisions for securing 445 both internal BGP and external BGP peering sessions. Key maintenance 446 can be especially onerous to the operators. The number of keys 447 required and the maintenance of keys (update/withdraw/renew) may have 448 an additive affect to a barrier to deployment. A highly securable 449 BGP routing system SHOULD require no more than three keys and each 450 key should be updateable within similar timeframes as prefix 451 propagation. The preferred number of keys is ONE per AS. 453 Transport protection systems SHOULD function as a component of the 454 BGP routing protocol security mechanism. This includes the use of 455 the same key generation/management systems as the rest of the 456 security system. 458 9 References 460 [1] Fraser, "RFC 2196 - Site Security Handbook", September 1997. 462 [2] Rescorla, Korver and Internet Architecture Board, "RFC 3552 - 463 Guidelines for Writing RFC Text on Security Considerations", 464 July 2003. 466 [3] Rekhter and Li, "RFC 1771 - A Border Gateway Protocol 4 467 (BGP-4)", March 1995. 469 Author's Address 471 Blaine Christian (editor) 472 KMC Telecom Solutions 473 1545 U.S. Highway 206 474 Bedminster, NJ 07921 475 US 477 Appendix A. Acknowledgements 479 The following individuals contributed to the development and review 480 of this draft. Steve Kent, Russ White, Sandy Murphy, Jeff Haas, Bora 481 Akyol, Susan Hares, Mike Tibodeau, Thomas Renzy, Kaarthik Sivakumar, 482 Tao Wan, Radia Perlman, and Merike Kaeo. 484 This draft was developed based on conversations with various network 485 operators including Chris Morrow, Jared Mauch, Tim Battles, and Ryan 486 McDowell. 488 Intellectual Property Statement 490 The IETF takes no position regarding the validity or scope of any 491 Intellectual Property Rights or other rights that might be claimed to 492 pertain to the implementation or use of the technology described in 493 this document or the extent to which any license under such rights 494 might or might not be available; nor does it represent that it has 495 made any independent effort to identify any such rights. Information 496 on the procedures with respect to rights in RFC documents can be 497 found in BCP 78 and BCP 79. 499 Copies of IPR disclosures made to the IETF Secretariat and any 500 assurances of licenses to be made available, or the result of an 501 attempt made to obtain a general license or permission for the use of 502 such proprietary rights by implementers or users of this 503 specification can be obtained from the IETF on-line IPR repository at 504 http://www.ietf.org/ipr. 506 The IETF invites any interested party to bring to its attention any 507 copyrights, patents or patent applications, or other proprietary 508 rights that may cover technology that may be required to implement 509 this standard. Please address the information to the IETF at 510 ietf-ipr@ietf.org. 512 Disclaimer of Validity 514 This document and the information contained herein are provided on an 515 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 516 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 517 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 518 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 519 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 520 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 522 Copyright Statement 524 Copyright (C) The Internet Society (2004). This document is subject 525 to the rights, licenses and restrictions contained in BCP 78, and 526 except as set forth therein, the authors retain all their rights. 528 Acknowledgment 530 Funding for the RFC Editor function is currently provided by the 531 Internet Society.