Network Working Group S. Hanna Internet-Draft Juniper Networks Expires: June 24, 2006 T. Hardjono Signacert Inc. S. Thomson Cisco Systems December 21, 2005 Network Endpoint Assessment (NEA) Problem Statement draft-thomson-nea-problem-statement-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 June 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Network endpoint assessment (NEA) is a system that enables the network to learn the posture (state) of an endpoint device, and optionally use that information to influence a network admission decision. Posture information may include information about the OS and security applications running on the endpoint. This document Hanna, et al. Expires June 24, 2006 [Page 1] Internet-Draft NEA Problem Statement December 2005 describes the problem network endpoint assessment is intending to address, and identifies interfaces that are candidates for standardization. Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 6 5.1. Wired LAN access . . . . . . . . . . . . . . . . . . . . . 6 5.2. Wireless LAN Access . . . . . . . . . . . . . . . . . . . 6 5.3. Remote access VPN . . . . . . . . . . . . . . . . . . . . 6 5.4. Gateway Access . . . . . . . . . . . . . . . . . . . . . . 7 6. Components and Interfaces . . . . . . . . . . . . . . . . . . 7 6.1. Relationship to EAP and AAA Architecture . . . . . . . . . 8 6.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2.1. NEA Agent . . . . . . . . . . . . . . . . . . . . . . 8 6.2.2. Network enforcer . . . . . . . . . . . . . . . . . . . 9 6.2.3. NEA server . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3.1. Posture Attribute interface (IF-PA) . . . . . . . . . 11 6.3.2. Posture Broker Interface (IF-PB) . . . . . . . . . . . 11 6.3.3. Posture Transport Interface (IF-PT) . . . . . . . . . 11 6.3.4. Network Access Enforcement Interface (IF-NAE) . . . . 11 6.3.5. Other . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4. System Flow . . . . . . . . . . . . . . . . . . . . . . . 12 7. Scope of Standardization . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9.1. Secure channel between the NEA Agent Broker and Server Broker . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Authorization for Plug-in/Broker interaction . . . . . . . 13 9.3. Self-Integrity of the NEA Agent and NEA Server . . . . . . 14 9.4. Protection of parameters exchanged across Interfaces . . . 14 9.5. Identity authentication of communicating end-points . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Hanna, et al. Expires June 24, 2006 [Page 2] Internet-Draft NEA Problem Statement December 2005 1. Introduction Network endpoint assessment (NEA) is a system that enables the network to learn the posture (state) of an endpoint device, and optionally use that information to influence a network admission decision. Endpoint posture may include information about the operating system as well as information about security applications running on the endpoint such as anti-virus software, personal firewalls and host intrusion protection systems. An organization may use posture information for several purposes including monitoring and enforcing compliance of endpoints to the organization's security policy, and supplementing and updating information in asset tracking databases. The document describes the problem network endpoint assessment is intending to address, defines terminology and concepts, and identifies interfaces that are candidates for standardization. Note that this document is not intended to define a new architecture or framework for network endpoint assessment. There are already several existing architectures for this purpose. The network endpoint assessment effort aims only to identify common interfaces that are used in these architectures, and define standard protocols that can be used by the existing architectures to reduce duplication and achieve interoperability. 2. Terminology Endpoint: An endpoint is a host connected to the network. This broad definition includes (but is not limited to) desktop or laptop computers, servers, mobile phones, printers. Posture: Posture refers to the state of an endpoint as it pertains to an organization's security policy. Endpoint state may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. NEA agent: The NEA agent is a software component on the endpoint that requests access to the network. The NEA agent comprises three logical components: NEA agent plug-in, NEA agent broker and Network access requestor. Network enforcer: The Network enforcer is a network device that controls endpoint access to the upstream network. It implements authorization decisions from the Network access authority. Hanna, et al. Expires June 24, 2006 [Page 3] Internet-Draft NEA Problem Statement December 2005 NEA server: The NEA server is a server that assesses the posture of an endpoint device and provides network authorization decisions. The NEA server comprises three logical components: NEA posture server, NEA server broker and Network Access Authority. NEA agent plug-in: A NEA agent plug-in is the component of the NEA agent that is responsible for collecting and maintaining posture information about the endpoint device. There may be multiple NEA agent plug-ins on an endpoint device each targeted at a particular security application from a particular vendor. NEA agent broker: A NEA agent broker is the component of the NEA agent that aggregates posture information from multiple NEA agent plug-ins. Network access requestor: The Network access requestor is the component of the NEA agent responsible for requesting access to the network. Network access authority: The Network access authority is the component of the NEA server that authorizes endpoints based on a number of criteria including the identity of an endpoint machine and/or user as well as the results of posture assessment NEA server broker: A NEA server broker is the component of the NEA server that aggregates posture information from multiple NEA posture servers. NEA posture server: A NEA posture server is the logical component of the NEA server that assesses posture information from a NEA agent plug-in and determines the result of the assessment. There may be multiple NEA posture servers each targeted at a particular security application from a particular vendor. 3. Problem Statement Viruses and worms are a top cause of financial loss due to disruption of business activities and loss of employee productivity. Endpoints are vulnerable to such attacks and, once infected, may in turn infect others. To protect against infection (and re-infection), corporate security policy often requires that hosts run an IT-specified OS configuration and have certain security applications enabled, e.g. anti-virus software, host intrusion protection systems, personal firewalls, and patch management software. However, ensuring compliance of all endpoints to corporate security policy is still time-consuming and difficult. Not all endpoints are Hanna, et al. Expires June 24, 2006 [Page 4] Internet-Draft NEA Problem Statement December 2005 managed by a corporation's IT organization, e.g. lab assets, guest machines. Even for assets that are managed, they may not receive updates in a timely fashion because they are not permanently attached to the corporate network, e.g. laptops. Also, for organizations that attempt to keep track of their assets, inventory databases tend to be incomplete and out-of-date. The purpose of network endpoint assessment technology is to allow the network to supplement the role that security applications already play in protecting endpoints. First, the network is able to detect when an endpoint accesses the network, thus providing an opportunity to assess an endpoint both prior to granting network access as well as while the endpoint remains connected to the network. Second, the network can be used to enforce compliance. Endpoints that are not compliant with security policy and are considered a risk to the network may be given restricted access until remediated. Today, most network access technologies, e.g. 802.1x, PPP and IPSEC VPN, authenticate an endpoint prior to granting network access, and if authentication succeeds, allow an authorization decision to be made based on the identity of the endpoint. Common interoperable standards should be defined for assessing the posture of an endpoint device in addition to performing authentication as part of network access control. 4. Goals The goals of network assessment technology are to support the following: o Support assessment of endpoints across a range of network access technologies, leveraging existing technology to the extent possible o Support authorization decisions based on authentication of user or endpoint device, assessment of the state of the endpoint device, or both o Support endpoint assessment at various locations in the network i.e. at a L2 hop or a L3 hop, both of which may be a single hop or multiple hops away from the endpoint. o Support endpoint assessment at possibly multiple hops on a path e.g. at both a L2 and a L3 hop o Support network isolation of non-compliant endpoints from compliant endpoints for remediation or other purposes Hanna, et al. Expires June 24, 2006 [Page 5] Internet-Draft NEA Problem Statement December 2005 o Support endpoint re-assessment when state of endpoints change, or rules in the NEA server change o Enable integration of 3rd-party security applications so that one or more applications can assess the posture of an endpoint and the aggregate of all results can be used in network admission decisions. o Support endpoints with a NEA agent and without an agent 5. Deployment Scenarios Network assessment has been targeted primarily at enterprise deployment scenarios to date.The deployment scenarios include: 5.1. Wired LAN access In this deployment scenario, network admission control would typically take place at the first L2 hop from the endpoint i.e. a switch port. However, there are cases where the first L2 device may not support network endpoint assessment for some reason, and network endpoint assessment may happen behind the first hop, e.g. a switch behind a wireless access point. Wired LAN access deployment scenarios may need to support single or multiple hosts per switch port. Deployment scenarios with multiple hosts per port include IP phones + PC, or multiple PCs connected behind a hub. 802.1x is an example of a standards-based network access technology that supports access control based on authentication for a single host per port in first L2 hop deployment scenarios. 5.2. Wireless LAN Access In this deployment scenario, network admission control would typically take place at the first L2 hop from the endpoint i.e. a wireless access point. Wireless LAN access supports multiple hosts per wireless access point. 802.11 is a standards-based network access technology that supports wireless access control based on authenticating the endpoint. 5.3. Remote access VPN In this deployment scenario, network admission control is done at the VPN concentrator that acts as the gateway between remote users and Hanna, et al. Expires June 24, 2006 [Page 6] Internet-Draft NEA Problem Statement December 2005 access to the enterprise network. IPSEC VPN and SSL VPN are example of network access technologies that support remote access VPN deployment scenarios. 5.4. Gateway Access In this deployment scenario, network admission control is enforced at a L3 boundary in a distributed campus network. The L3 boundary may be one or more L3 hops away from the endpoint. This deployment scenario may be used during the transition period while an organization gradually upgrades network equipment to support network endpoint assessment. In some cases, the technology may not be available immediately for first-hop L2 or L3 deployments and a general-purpose gateway deployment e.g. at a router behind a VPN concentrator, may be a reasonable first step. This deployment scenario may also be used between network security domains e.g. at the border between a less trusted/managed branch office and main campus, at the border between main campus or a visitor site and access to the Internet, at the border between extranet and intranet, and on access to protected servers in a data center. It follows from this deployment scenario that there may be multiple network enforcers on any path that an endpoint may use in a network, thus resulting in it being authorized more than once. It is also possible that different posture rules may be assessed at different network locations and a different authorization decision made. 6. Components and Interfaces Figure 1 shows the components of the NEA system and identifies specific interfaces. Hanna, et al. Expires June 24, 2006 [Page 7] Internet-Draft NEA Problem Statement December 2005 |-------------| |----------------| | NEA Plug-in | <-------IF-PA-------> | NEA Posture | | | | Server | |-------------| |----------------| |-------------| |----------------| | NEA Agent | <-------IF-PB-------> | NEA Server | | Broker | | Broker | |--------- ---| |----------------| |-------------| <------IF-PT-------> |----------------| | | | | | Network | |--------| | Network | | Access | |Network | | Access | | Requestor | |Enforcer| <-IF-NAE-> | Authority | |-------------| |--------| |----------------| NEA AGENT NEA SERVER Figure 1: NEA Components and Interfaces 6.1. Relationship to EAP and AAA Architecture Network endpoint assessment technology can build on the EAP and AAA architectures, so that existing technologies can be used to the extent possible including EAP, Radius, 802.1x, PPP, IPSEC VPN. 6.2. Components 6.2.1. NEA Agent The NEA Agent resides on an endpoint device and comprises the following components: o NEA Agent Plug-in o NEA Agent Broker o Network Access Requestor 6.2.1.1. NEA Agent Plug-in The NEA agent plug-in is software that provide posture information about the endpoint device to the NEA agent broker. There may be many plug-ins in an agent, one per vendor and application type. Examples of plug-ins include a host plug-in that provides information about the OS and patch levels, anti-virus plug-in that provides information Hanna, et al. Expires June 24, 2006 [Page 8] Internet-Draft NEA Problem Statement December 2005 about the anti-virus application, firewall plug-in that provides information about the configuration of the personal firewall. An agent plug-in is responsible for: o Receiving and responding to requests for posture information on a per vendor and application type basis o Receiving a notification of the result of the posture assessment and information any actions to perform e.g. URL of a remediation server o Indicating when the posture of the host has changed 6.2.1.2. NEA Agent Broker The NEA agent broker aggregates posture information from multiple NEA agent plug-ins. The NEA agent broker is responsible for: o Maintaining a record of agent plug-ins o Multiplexing and demultiplexing posture messages between the NEA server and the relevant plug-ins o Determining from plug-ins when posture has changed and triggering re-assessment where supported by the underlying transport o Providing user notifications 6.2.1.3. Network access requestor The Network access requestor is responsible for communicating with the NEA server (likely via the enforcer) to transport the necessary information to gain access to the network and for subsequent re- assessment. 6.2.2. Network enforcer The Network enforcer is a network device that controls access of endpoints to the upstream network. The NEA enforcer implements authorization decisions from the Network access authority. 6.2.3. NEA server The NEA server comprises the following logical components (which may or may not be co-located on a single server): Hanna, et al. Expires June 24, 2006 [Page 9] Internet-Draft NEA Problem Statement December 2005 o Network access authority o NEA server broker o NEA server plug-in 6.2.3.1. Network access authority The Network access authority is responsible for authorizing endpoints based on a number of criteria including the identity of an endpoint and/or user as well as the results of posture assessment 6.2.3.2. NEA server broker The NEA server broker aggregates posture information from potentially multiple server plug-ins. Responsibilities of the NEA server broker include: o Maintaining a record of server plug-ins o Multiplexing and demultiplexing posture messages between the NEA agent and the relevant plug-ins o Aggregating posture assessment results from all plug-ins into an overall system result o Triggering posture reassessment where supported 6.2.3.3. NEA posture server A NEA posture server is a server that is responsible for assessing information from the corresponding NEA agent plug-in and determining the result of the assessment. There may be multiple posture servers each targeted at a particular security application from a particular vendor. A NEA posture server is responsible for the following: o Requesting and receiving posture information from a particular NEA agent plug-in o Assessing the posture of the NEA agent plug-in and providing a result to the NEA agent plug-in along with any information on remediation actions to be taken o Indicating to the NEA server broker when posture reassessment may be needed Hanna, et al. Expires June 24, 2006 [Page 10] Internet-Draft NEA Problem Statement December 2005 6.3. Interfaces 6.3.1. Posture Attribute interface (IF-PA) The IF-PA is a protocol between the NEA agent plug-in and the NEA posture server. The interface is used to pass information about the posture of a plug-in, the results of the assessment and information needed for remediation. 6.3.2. Posture Broker Interface (IF-PB) The IF-PB is a protocol that carries aggregated posture information between all requested plug-ins on an endpoint and the corresponding posture servers. This protocol also carries the overall system posture result from the NEA server broker to the agent broker. 6.3.3. Posture Transport Interface (IF-PT) The IF-PT is the transport protocol between the Network access requestor and the Network access authority that carries the IF-PB protocol. In network endpoint assessment systems that use EAP, this interface would be an EAP method running over typically a combination of underlying network transports, e.g. EAP over 802.1x, EAP over Radius. 6.3.4. Network Access Enforcement Interface (IF-NAE) The IF-NAE is the protocol between the Network enforcer and Network access authority used to carry network access decisions between the Network enforcer and the Network access authority. 6.3.5. Other Interfaces also exist between the logical components that make up the NEA agent and the NEA server themselves. For example, an interface exists between the plug-in and broker components on the agent, as well as between the broker and network access requestor components. Similarly, an interface exists between the posture server and broker components on the NEA server as well as the broker and network access authority components. The interfaces on the NEA agent are likely local APIs. This may be true on the NEA server as well, but deployments where components are not co-located are also possible. Since these interfaces do not fall clearly within the purview of the IETF, standardization efforts are initially focused on the interfaces explicitly identified above. Standardization of some of these other interfaces may be called for in the future. Hanna, et al. Expires June 24, 2006 [Page 11] Internet-Draft NEA Problem Statement December 2005 6.4. System Flow TBD. 7. Scope of Standardization Interfaces that are candidates for standardization in the IETF include the following : o Posture attributes interface (IF-PA): This interface can be defined independently of the underlying transport interfaces, while keeping in mind performance and other constraints imposed by the underlying protocols. Many of the posture attributes will be vendor-specific and need only be understood by the corresponding a plug-in and its associated posture server. However. there are common attributes that would benefit from standardization. o Posture broker interface (IF-PB): This interface is also largely independent of the underlying transport, although it should be defined in such a way that it can be used in posture transport interfaces that are likely to be used, such as EAP tunneling methods based on TLS e.g. by using the same TLV framing that is already used in these methods today. o Posture transport interface (IF-PT): While different posture transport interfaces may be used to support network endpoint assessment, one likely choice of transport is EAP. The benefits of EAP are that it can be used to meet a range of deployment scenarios since it is designed to be independent of the underlying network transport, and is extensible to supporting both authentication and posture assessment in making a network access decision. Standardization of certain EAP methods for authentication is the proposed charter of the EMU WG. The need to support posture assessment in addition to authentication may place additional requirements on the EAP methods that need to be standardized. In particular, standardization of tunnel EAP methods is a high priority. Also, there is no standard EAP transport to support gateway and other "multi-hop" deployment scenarios as defined in this document. The PANA WG has proposed a specification of EAP over an IP transport, although not explicitly for this use case. Non-standardized protocols have been designed and used for this purpose. o Network access enforcement interface (IF-NAE): Existing standards exist including Radius and Diameter. The Radext WG has the charter to standardize Radius extensions. Its not clear that NEA would require any extensions that fall outside of the scope of the Hanna, et al. Expires June 24, 2006 [Page 12] Internet-Draft NEA Problem Statement December 2005 existing charter of that WG. As mentioned earlier, the remaining interfaces that have been identified will likely not be within the scope of standardization efforts, at least not initially. This could be revised in future. 8. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 9. Security Considerations A NEA system includes a number of functional components and interfaces, and thus there are a number of security aspects pertaining to the system as a whole which need to be highlighted. Some of these are discussed in the following sections. 9.1. Secure channel between the NEA Agent Broker and Server Broker The NEA Agent Broker needs to be able to communicate the posture information regarding the NEA Agent to the NEA Server Broker with communications integrity and confidentiality. One possible avenue towards establishing this secure channel (at the peer layer of the NEA Agent Broker and Server Broker) is to establish it end-to-end between Network Access Requestor (NAR) and the Network Access Authority (NAA). This end-to-end secure channel would prevent any intermediate entity, including the Network Enforcer from gaining access to the posture information. The exact implementation of this secure channel is dependent on the domain of application and network configuration. 9.2. Authorization for Plug-in/Broker interaction There is a functional separation between the NEA Agent Plug-in and the NEA Agent Broker (at the NEA Agent side) and also between NEA Posture Server and the NEA Server Broker (at the NEA Server side). It is important that a NEA Agent Broker be allowed to communicate with only the authorized NEA Agent Plug-ins. Similarly, the NEA Server Broker should only communicate with authorized NEA Posture Server. Recall that the NEA Agent Plug-in is software that provides posture information about the endpoint device to the NEA Agent Broker. Note that there may be many plug-ins in an agent, one per vendor and application type. Without protection, bogus NEA Agent Hanna, et al. Expires June 24, 2006 [Page 13] Internet-Draft NEA Problem Statement December 2005 Plug-in (NEA Posture Server) can open communications with the NEA Agent Broker (NEA Server Broker), thereby opening the possibility of a Denial-of-Service attack (at the very least) against the NEA Agent Broker and NEA Server Broker respectively. 9.3. Self-Integrity of the NEA Agent and NEA Server The trustworthiness of the posture information being reported by the NEA Agent to the NEA Server is dependent on and is only as good as the self-integrity of the NEA Agent and NEA Server respectively. If malicious code or other malware are present in the NEA Agent actively modifying posture information being communicated by the NEA Agent, the NEA Server may be basing its decision-making on inaccurate or bogus posture information. Thus, it is important that both the NEA Agent and the NEA Server are protected against attacks that illegally modify the system configurations and system components of these entities. 9.4. Protection of parameters exchanged across Interfaces An important aspect of the NEA sytem is the protection of parameters being communicated between the various interfaces defined in the architecture. Examples of the parameters being exchanged include, but not limited to, state change notifications between the NEA Agent Broker and NEA Agent Plug-in, state change notifications between the NEA Server Broker and NEA Posture Server, the parameters and messages exchanged between two peer entities (on the NEA Agent and NEA Server respectively) across IF-PA and IF-PB, and in general parameters and messages exchanged across interfaces IF-PT, and IF-NAE. 9.5. Identity authentication of communicating end-points In order for the NEA Server to accept access requests and posture information being reported to by the NEA Agent, the NEA Server may need to authenticate the NEA Agent in some manner. Similarly, within some network environments there may be the requirement that the NEA Agent also authenticate the NEA Server with whom it is communicating. Although the process of evaluating an access request may combine together the notion of authentication and integrity state evaluation (through posture information), it is important from a security perspective and useful from a good engineering practices perspective to be able to separate end-point authentication (includling both machine and user authentication) from end-point posture assessment. 10. Acknowledgements TBD Hanna, et al. Expires June 24, 2006 [Page 14] Internet-Draft NEA Problem Statement December 2005 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Hanna, et al. Expires June 24, 2006 [Page 15] Internet-Draft NEA Problem Statement December 2005 Authors' Addresses Steve Hanna Juniper Networks shanna@juniper.net Thomas Hardjono Signacert Inc. thardjono@signacert.com Susan Thomson Cisco Systems sethomso@cisco.com Hanna, et al. Expires June 24, 2006 [Page 16] Internet-Draft NEA Problem Statement December 2005 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 (2005). 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. Hanna, et al. Expires June 24, 2006 [Page 17]