OPSEC Working Group (proposed) G. Jones Internet-Draft The MITRE Corporation Expires: October 20, 2004 R. Callon Juniper Networks M. Kaeo Double Shot Security April 21, 2004 Framework for Operational Security Requirements for IP Network Infrastructure draft-jones-opsec-framework-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 20, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document outlines work to be done and documents to be produced by the proposed Operational Security Requirements (OPSEC) Working Group. The goal of the working group is to codify knowledge about feature sets that are required to securely deploy and operate managed network elements providing transit services at OSI layers 2 and 3, Jones, et al. Expires October 20, 2004 [Page 1] Internet-Draft OpSec Framework April 2004 i.e. switches and routers. The intent is to provide clear, concise documentation of requirements necessary for operating networks securely, to assist network operators in communicating their requirements to vendors, and to provide vendors with input that is useful for building more secure devices. The working group will produce requirements appropriate for large Internet Service Provider (ISP) and Enterprise Networks. This work is intended to refine RFCxxxx. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Intended Audience . . . . . . . . . . . . . . . . . . . . 4 1.5 Format and Definition of Requirements . . . . . . . . . . 4 1.6 Applicability . . . . . . . . . . . . . . . . . . . . . . 5 1.7 Intended Use . . . . . . . . . . . . . . . . . . . . . . . 5 1.8 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1 Standards Survey (info) . . . . . . . . . . . . . . . . . 10 2.2 In-Band management requirements (BCP) . . . . . . . . . . 10 2.3 Out-of-Band management requirements (BCP) . . . . . . . . 11 2.4 Filtering requirements (BCP) . . . . . . . . . . . . . . . 11 2.5 Event Logging Requirements document (BCP) . . . . . . . . 11 2.6 Configuration and Management Interface Requirements (BCP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.7 AAA requirements document (BCP) . . . . . . . . . . . . . 12 2.8 Documentation and Assurance requirements document (BCP) . 12 2.9 Miscellaneous requirements document (BCP) . . . . . . . . 12 2.10 Large ISP Operational Security Requirements Profile (info) . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.11 Large Enterprise Operational Security Requirements Profile (info) . . . . . . . . . . . . . . . . . . . . . 13 2.12 OPSEC Deliberation Summary document (info) . . . . . . . 13 3. Security Considerations . . . . . . . . . . . . . . . . . . 14 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 4.2 Non-normative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . 18 Jones, et al. Expires October 20, 2004 [Page 2] Internet-Draft OpSec Framework April 2004 1. Introduction 1.1 Goals The goal of the working group is to provide a clear, concise documentation of operational security requirements for the infrastructure of large IP networks, including routers and switches, to equipment vendors, service providers, and network operators. This framework document provides an overview of the work to be done by the working group, and describes the documents to be produced in this effort. 1.2 Motivation Network operators need the appropriate feature sets and tools on their infrastructure devices to ensure that they can effectively deploy and manage their networks securely while maintaining the ability to provide reliable service to their customers. Vendors need guidelines on which security features and functionality are critical for operators to be able to reach that goal. The threats which network infrastructure devices are most susceptible to encompass the following: o unauthorized access to the device which can lead to portions of the network infrastructure to be under malicious control o denial of service attacks where the device is rendered incapable of performing its intended function o spoofing attacks where malicious packets can lead to network traffic rerouting or network down-time Many of these threats are described in detail in [RFC2196]. [RFC3013] recommends security services and procedures for ISPs and provides a framework for discussion of security expectations. The documents which will be described in this framework document will complement these existing standards and will enumerate features which are required to implement many of the policies and procedures suggested in both. 1.3 Scope The working group will produce requirements appropriate for: o Internet Service Provider (ISP) Networks o Enterprise Networks The following classes of devices are excluded from the OPSEC working group charter at this time, and are therefore outside of the scope of Jones, et al. Expires October 20, 2004 [Page 3] Internet-Draft OpSec Framework April 2004 this document: o Wireless devices o SOHO devices o Security devices (firewalls, IDS, Authentication Servers) o Hosts The following are explicitly out of scope: o general purpose hosts that do not transit traffic including infrastructure hosts such as name/time/log/AAA servers, etc., o unmanaged devices, o customer managed devices (e.g. firewalls, Intrusion Detection System, dedicated VPN devices, etc.), o SOHO (Small Office, Home Office) devices (e.g. personal firewalls, Wireless Access Points, Cable Modems, etc.), o confidentiality of customer data, o integrity of customer data, o physical security. This means that while the requirements in the minimum profile (and others) may apply, additional requirements have not be added to account for their unique needs. While the examples given are written with IPv4 in mind, most of the requirements are general enough to apply to IPv6. 1.4 Intended Audience There are two intended audiences: the network operator who selects, purchases, and operates IP network equipment, and the vendors who create these devices. 1.5 Format and Definition of Requirements A separate document will be created for specific categories of requirements. Each individual requirement will have the following element: Requirement (what) The requirement describes a policy to be supported by the device. For example, "The device MUST support secure channels that allow in-band access to all management and configuration functions." Requirements should not refer to specific technologies. It is expected that requirements will change little over time. Justification (why) The justification tells why and in what context the requirement is important. Jones, et al. Expires October 20, 2004 [Page 4] Internet-Draft OpSec Framework April 2004 For example, "Secure channels are important because they insure confidentiality, and integrity. This is important in contexts where management is performed in-band over networks with potentially hostile users." The justification is intended to give operators information needed to determine the applicability of a requirement to their local environment. Examples (how) Examples are intended to give examples of technology and standards current at the time of writing that meet the requirement. Examples of configuration and usage may also be given. For example, "SSH provides access to management and configuration functions via secure channels. One way to meet this requirement might be to enable SSH for in-band management and to disable all insecure in-band management mechanisms (e.g. telnet, SNMPv1, etc.)" It is expected that the choice of implementations to meet the requirements will change over time. See [RFC3631] for a list of some current mechanisms. Warnings (if applicable) The warnings list operational concerns, deviation from standards, caveats, etc. For example, "If SSH is chosen as the mechanism to provide secure channels for remote management and configuration, then there are a number of issues which must be considered including key distribution and known vulnerabilities in various protocol versions." 1.6 Applicability These requirements are intended to give guidance on how best to protect communications infrastructure. Service Providers, Network Operators, and Equipment Suppliers are encouraged to study these requirements, and prioritize the extent and manner in which they may implement and/or deploy equipment supporting these requirements. Decisions of whether or not to support a specific requirement are intended to be left with the responsible organization (e.g., Service Provider, Network Operator, or Equipment Supplier). Due to the continuously evolving nature of security threats to networks, and due to significant variations in the specific security threats and requirements in different network environments, it is not appropriate to mandate implementation of these requirements through legislation or regulation, nor would any mandate be consistent with their intent. 1.7 Intended Use It is anticipated that the requirements in these documents will be Jones, et al. Expires October 20, 2004 [Page 5] Internet-Draft OpSec Framework April 2004 used for the following purposes: o as a checklist when evaluating networked products, o to create profiles of different subsets of the requirements which describe the needs of different devices, organizations, and operating environments, o to assist operators in clearly communicating their security requirements, o as high level guidance for the creation of detailed test plans. o as guidance for vendors to make appropriate decisions for engineering feature roadmaps. 1.8 Definitions NOTE: THE FOLLOWING DEFINITIONS NEED TO BE DISCUSSED AT THE WORKING GROUP BCP [XXX Discuss @ Working Group] Should we work on refining the definitions of "Current" and "Practice" ? Does "current" mean that it's widely implemented, that at least one vendor implements, other ??? Does "Practice" mean "requirement". See [RFC2026]. Requirement [XXX Discuss @ Working Group] See Section 1.5 for a definition and example of the term "Requirement" as it is used in this document. RFC 2119 Keywords [XXX Discuss @ Working Group] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. NOTE: THE FOLLOWING DEFINITIONS WERE COPIED DIRECTLY FROM THE OPSEC DRAFT AND IN SUBSEQUENT DRAFTS OF THE FRAMEWORK THEY MAY MOVE TO THE SPECIFIC DRAFT THAT DEALS WITH THE TERM DEFINED. THEY ARE LEFT HERE NOW TO INDICATE THAT THESE ARE AREAS THAT ARE LIKELY TO NEED DISCUSSION AND DEFINITION IN THE SUBSEQUENT EFFORTS OF THE WORKING GROUP. Bogon. A "Bogon" (plural: "bogons") is a packet with an IP source address in an address block not yet allocated by IANA or the Regional Internet Registries (ARIN, RIPE, APNIC...) as well as all addresses reserved for private or special use by RFCs. See [RFC3330] and [RFC1918]. CLI. Several requirements refer to a Command Line Interface (CLI). While this refers at present to a classic text oriented command interface, it is not intended to preclude other mechanisms which may meet all the requirements that reference "CLI". Console. Several requirements refer to a "Console". The model for this is the classic RS232 serial port which has, for the past 30 or more years, provided a simple, stable, reliable, well-understood and nearly ubiquitous management interface to network devices. Again, Jones, et al. Expires October 20, 2004 [Page 6] Internet-Draft OpSec Framework April 2004 these requirements are intended primarily to codify the benefits provided by that venerable interface, not to preclude other mechanisms that meet all the same requirements. Filter. In this document, a "filter" is defined as a group of one or more rules where each rule specifies one or more match criteria. In-Band management. "In-Band management" is defined as any management done over the same channels and interfaces used for user/customer data. Examples would include using SSH for management via customer or Internet facing network interfaces. High Resolution Time. "High resolution time" is defined in this document as "time having a resolution greater than one second" (e.g. milliseconds). IP. Unless otherwise indicated, "IP" refers to IPv4. Management. This document uses a broad definition of the term "management". In this document, "management" refers to any authorized interaction with the device intended to change its operational state or configuration. Data/Forwarding plane functions (e.g. the transit of customer traffic) are not considered management. Control plane functions such as routing, signaling and link management protocols and management plane functions such as remote access, configuration and authentication are considered to be management. Martian. Per [RFC1208] "Martian: Humorous term applied to packets that turn up unexpectedly on the wrong network because of bogus routing entries. Also used as a name for a packet which has an altogether bogus (non-registered or ill-formed) Internet address." For the purposes of this document Martians are defined as "packets having a source address that, by application of the current forwarding tables, would not have its return traffic routed back to the sender." "Spoofed packets" are a common source of martians. Note that in some cases, the traffic may be asymmetric, and a simple forwarding table check might produce false positives. See [RFC3704] Out-of-Band (OoB) management. "Out-of-Band management" is defined as any management done over channels and interfaces that are separate from those used for user/customer data. Examples would include a serial console interface or a network interface connected to a dedicated management network that is not used to carry customer traffic. Jones, et al. Expires October 20, 2004 [Page 7] Internet-Draft OpSec Framework April 2004 Open Review. "Open review" refers to processes designed to generate public discussion and review of technical solutions such as data communications protocols and cryptographic algorithms with the goals of improving and building confidence in the final solutions. For the purposes of this document "open review" is defined by [RFC2026]. All standards track documents are considered to have been through an open review process. It should be noted that organizations may have local requirements that define what they view as acceptable "open review". For example, they may be required to adhere to certain national or international standards. Such modifications of the definition of the term "open review", while important, are considered local issues that should be discussed between the organization and the vendor. It should also be noted that section 7 of [RFC2026] permits standards track documents to incorporate other "external standards and specifications". Service. A number of requirements refer to "services". For the purposes of this document a "service" is defined as "any process or protocol running in the control or management planes to which non-transit packets may be delivered". Examples might include an SSH server, a BGP process or an NTP server. It would also include the transport, network and link layer protocols since, for example, a TCP packet addressed to a port on which no service is listening will be "delivered" to the IP stack, and possibly result in an ICMP message being sent back. Secure Channel. A "secure channel" is a mechanism that ensures end-to-end integrity and confidentiality of communications. Examples include TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a console port using physically secure, shielded cable would provide confidentiality but possibly not integrity. Single-Homed Network. A "single-homed network" is defined as one for which * There is only one upstream connection * Routing is symmetric. See [RFC3704] for a discussion of related issues and mechanisms for multihomed networks. Spoofed Packet. A "spoofed packet" is defined as a packet that has a source address that does not correspond to any address assigned to the system which sent the packet. Spoofed packets are often "bogons" or "martians". Jones, et al. Expires October 20, 2004 [Page 8] Internet-Draft OpSec Framework April 2004 Secure Network For the purposes of these documents, a secure network is one in which: * The network keeps passing legitimate customer traffic (availability). * Traffic goes where it is supposed to go, and only where it is supposed to go (availability, confidentiality). * The network elements remain manageable (availability). * Only authorized users can manage network elements (authorization). * There is a record of all security related events (accountability). * The network operator has the necessary tools to detect and respond to illegitimate traffic. Jones, et al. Expires October 20, 2004 [Page 9] Internet-Draft OpSec Framework April 2004 2. Documents The following is a list of documents to be produced by OPSEC working group. Each document is intended to cover an area important to secure operation of large network infrastructure. 2.1 Standards Survey (info) Overview This document provides an overview of other efforts in developing standards, guidelines, best practices, or other information intended to facilitate improvement in network security. Any effort which is known, such as the ANSI T1.276, the NRIC V "Best Practices", ITU-T M.3016 and X.805, the T1S1 effort on securing signalling will be included. The intent is to provide a clear understanding of which efforts are complementary and/or contradictory such that any efforts of future cross-certification of standards may be facilitated. Security Considerations Any contradictory security requirements from varying standards bodies would seriously impact operator or vendor understanding of which features and functionalities are the most effective to deploy and operate secure networks. This documented survey will help to ensure that there is a consistent set of product requirements to follow. 2.2 In-Band management requirements (BCP) Overview Although there are known security issues with in-band management, there are many situations where in-band management makes sense, is used, and/or is the only option. The features recommended in this document will provide for a more secure means of using any in-band management functionality. Security Considerations Although in-band management has the advantage of lower cost (no extra interfaces or lines), it has significant security disadvantages: * Saturation of customer lines or interfaces can make the device unmanageable unless out-of-band management resources have been reserved * Since public interfaces/channels are used, it is possible for attackers to directly address and reach the device and to attempt management functions. * In-band management traffic on public interfaces may be intercepted, however this would typically require a significant compromise in the routing system. * Public interfaces used for in-band management may become unavailable due to bugs (e.g. buffer overflows being exploited) while out-of-band interfaces (such as a serial Jones, et al. Expires October 20, 2004 [Page 10] Internet-Draft OpSec Framework April 2004 console device) remain available The requirements from this document are meant to provide the means of securing in-band management traffic. 2.3 Out-of-Band management requirements (BCP) Overview This document will describe requirements related to out of band management of networked devices. Security Considerations Out-of-band management often provides a more secure means of managing networked devices. To ensure that all devices have the appropriate support, this document will set requirements as to what functionality is needed to effectively use out-of-band management. 2.4 Filtering requirements (BCP) Overview This document will describe requirements related to stateless filtering requirements for network elements providing transit service at OSI layers 2 and 3. Security Considerations Filtering is an important security functionality to permit or deny forwarding of traffic, or to specify special treatment of packets, depending on layer 2 or layer 3 header and forwarding information. It provides a basic means of implementing policies, such as policies that specify which traffic is allowed and which is not, and policies which specify special treatment such as setting CoS, rate limiting, or packet copying. It also provides a basic tool for responding to malicious traffic. 2.5 Event Logging Requirements document (BCP) Overview [Ed. The basic questions here are "what gets logged", "how does it get logged", "what are the security issues". There is work in progress (syslog) for the last two that can be cited. The "what gets logged" question needs work] This document will describe the recommended features when logging network device traffic and anomalies. The goal is to make it possible to correlate logging information from varying systems and making sure that logged information is useful and effective. Security Considerations Logging data provides a means for detecting malicious behavior. The logged information can also be used as evidence in legal prosecution cases against illegal network access and device compromises. Ineffective logging practices due to inconsistent functionality in many devices make it hard to get effective data. This document will help provide consistent logging functionality for more effective auditing. It will also point to privacy or Jones, et al. Expires October 20, 2004 [Page 11] Internet-Draft OpSec Framework April 2004 legal considerations when logging/monitoring user activity. 2.6 Configuration and Management Interface Requirements (BCP) Overview This document lists the security requirements for interfaces which allow for configuring and managing the network device. In most cases, this currently involves some sort of command line interface (CLI) and configuration files. It may be possible to meet these requirements with other mechanisms, for instance SNMP or a script-able HTML interface that provides full access to management and configuration functions. In the future, there may be others (e.g. XML based configuration). Security Considerations The interfaces used to manage and configure network elements need to be effectively secured to avoid a malicious user from being able to logically gain illegal access. In the past, many security vulnerabilities have been discovered, especially with SNMP and HTTP access to devices. These recommendations will help the user and vendor community mitigate any known risks in this area. 2.7 AAA requirements document (BCP) Overview This document will list the requirements for centralized authentication, authorization and accounting functionality. Security Considerations Keeping track of who has access to network devices is critical to any secure infrastructure. Mechanisms to provide authorized access upon successful authentication and also keeping track of what was done can provide important information in case of a device compromise. 2.8 Documentation and Assurance requirements document (BCP) Overview These requirements will list information which should be documented that will assist operators in evaluating and securely operating a device. Security Considerations Devices many times have default behavior which can cause a severe security vulnerability. Knowing which services are enabled by default or which commands impact other default behavior is essential knowledge that is necessary to effectively mitigate security risks. 2.9 Miscellaneous requirements document (BCP) Overview Jones, et al. Expires October 20, 2004 [Page 12] Internet-Draft OpSec Framework April 2004 This document will describe requirements which do not fit into any of the other documents, and which are brief enough that they don't justify their own document, but which are important enough that they should be documented. 2.10 Large ISP Operational Security Requirements Profile (info) Overview This document will provide a profile specifying which of the requirements outlined in the set of documents described above are most applicable to large Internet Service Providers offering transit service. 2.11 Large Enterprise Operational Security Requirements Profile (info) Overview This document will provide a profile specifying which of the requirements outlined in the set of documents described above are most applicable to large Enterprise networks. 2.12 OPSEC Deliberation Summary document (info) Overview This document will provide a summary of discussions that have taken place within the OPsec working group. The intent is to document ideas that were "left on the cutting room floor" in order to provide a possible starting point for future work. Jones, et al. Expires October 20, 2004 [Page 13] Internet-Draft OpSec Framework April 2004 3. Security Considerations Security is the entire focus of this document. Jones, et al. Expires October 20, 2004 [Page 14] Internet-Draft OpSec Framework April 2004 4. References 4.1 Normative References [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", RFC 1208, March 1991. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000. [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [RFC3631] Bellovin, S. and J. Schiller, "Security Mechanisms for the Internet", RFC 3631, December 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. 4.2 Non-normative References [I-D.savola-bcp38-multihoming-update] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", draft-savola-bcp38-multihoming-update-03 (work Jones, et al. Expires October 20, 2004 [Page 15] Internet-Draft OpSec Framework April 2004 in progress), December 2003. [Schneier] Schneier, B., "Applied Crytography, 2nd Ed., Publisher John Wiley & Sons, Inc.", 1996. Authors' Addresses George M. Jones The MITRE Corporation 7515 Colshire Drive, M/S WEST McLean, Virginia 22102-7508 U.S.A. Phone: +1 703 488 9740 EMail: gmjones@mitre.org Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886 U.S.A. Phone: +1 978 692 6724 EMail: rcallon@juniper.net Merike Kaeo Double Shot Security 520 Washington Blvd. #363 Marina Del Rey, CA 90292 U.S.A. Phone: +1 310 866 0165 EMail: kaeo@merike.com Jones, et al. Expires October 20, 2004 [Page 16] Internet-Draft OpSec Framework April 2004 Appendix A. Acknowledgments The authors gratefully acknowledge the contributions of: o Acknowledgments to be determined. o The MITRE Corporation for supporting development of this document. NOTE: The author's affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed by the editor. o This listing is intended to acknowledge contributions, not to imply that the individual or organizations approve the content of this document. o Apologies to those who commented on/contributed to the document and were not listed. Jones, et al. Expires October 20, 2004 [Page 17] Internet-Draft OpSec Framework April 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jones, et al. Expires October 20, 2004 [Page 18]