NSIS X. Fu Internet-Draft I. Juchem Expires: September 7, 2006 C. Dickmann Univ. Goettingen H. Tschofenig Siemens March 6, 2006 Design Options of NSIS Diagnostics NSLP draft-fu-nsis-diagnostics-nslp-01 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 September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Next Steps in Signaling protocol suite aims to provide a way to communicate with network intermediaries. As such, it is desirable to offer generic diagnostics function for NSIS users and system administrators to make the functionality provided by the network more transparent (e.g., to identify particular NSLPs, to determine to Fu, et al. Expires September 7, 2006 [Page 1] Internet-Draft Diagnostics NSLP Design Options March 2006 which degree the network supports NSIS, GIST state or specific NSLP session information along a given path). Instead of suggesting one specific solution we highlight the different design options of some simple, stateless diagnostics functions from a querying node to a responding node. These preliminary thoughts should help the working group to have a more structure discussion in this problem space. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Information to be Diagnosed . . . . . . . . . . . . . . . . . 3 3. Information gathering and data transport options . . . . . . . 5 3.1. Basic prerequisites . . . . . . . . . . . . . . . . . . . 5 3.1.1. Basic message objects . . . . . . . . . . . . . . . . 7 3.2. NTLP state information . . . . . . . . . . . . . . . . . . 9 3.2.1. General GIST state information . . . . . . . . . . . . 10 3.2.2. SID-bound state information . . . . . . . . . . . . . 10 3.3. NSLP state information . . . . . . . . . . . . . . . . . . 11 3.3.1. NSLP state information object . . . . . . . . . . . . 11 3.4. Query available NSLPs . . . . . . . . . . . . . . . . . . 12 3.4.1. Available NSLPs object . . . . . . . . . . . . . . . . 12 3.5. Additional information . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Summary and Open Issues . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Fu, et al. Expires September 7, 2006 [Page 2] Internet-Draft Diagnostics NSLP Design Options March 2006 1. Introduction The lack of a unified mechanism for diagnostics capabilities in the NSIS protocol suite represents a substantial problem, for both the end user and the system administrator. As the number of vendors and operators deploying (and possibly extending) NSIS is expected to increase, the problem of diagnosing the multitude of devices from different signaling functions, both for general signaling transport and for particular signaling applications, escalates. Although some NSLP specifications set out the details of how a device can enquire some sort of diagnostics data, the extent to which this diagnostics data is used and converted to meaningful information by the specific NSLPs varies considerably from one NSLP to another. For instance, in the current version of QoS-NSLP specification [1], Query messages are used for detecting path characteristics information from any QNE towards a QNI. In the case of NATFW NSLP, current specification [2] defines a Query and Diagnostics Request message used by authorized NATFW NEs for querying and diagnosing installed NATFW states and it is still in discussion whether to exclude this feature from the base specification of the NATFW NSLP. On the other hand, GIST [3] does not provide an explicit diagnostics function to allow authorized entities to diagnose the GIST level information; it simply discovers the next GIST peer and delivers NSLP messages as its payload. It is expected that the additional administrative or development effort is required without diagnostic capabilities. RSVP's diagnostics functions (see [4]) allow any RSVP node to query a RSVP session's Path state and Resv state (if available). However they exhibit a lack of the the capability of performing authorized access, which may be desired to prevent the introduction of security vulnerabilities (see [5]). This document describes some key design considerations towards a set of simple, generic and secure diagnostics functions. The following aspects seem to be major design decisions: o Which information is going to be subject for diagnosis? o At which granularity of the information can be diagnosed? o Which transport mechanism should be used for delivering diagnostics messages, and whether to introduce/avoid GIST level and/or NSLP state o How to properly authorize a diagnostics operation and protect the diagnostics messages? Subsequent sections will discuss these aspects in more details. 2. Information to be Diagnosed Fu, et al. Expires September 7, 2006 [Page 3] Internet-Draft Diagnostics NSLP Design Options March 2006 The main purpose of diagnostics NSLP is to diagnose NSIS state information. One question is which state could and should be diagnosed, and how much granularity of the state should be possible to be diagnosed. Corresponding to the 2-layer architecture of NSIS, there are two types of NSIS states: GIST and NSLP state information. In case of GIST (or NTLP) state, we also distinguish between state information we want to collect for states corresponding to one single Session ID (SID), further labeled "SID-bound state information", and state information to be collected which is not directly corresponding to a SID (further called "General GIST state information". We will list a few state information elements below: General GIST state information: GIST state includes: MA information: The MA information might include a list of the message associations a GIST node has currently in use. This involves the properties of the MA, e.g. the used protocol stack, the address of the corresponding peer and the list of MRS using the MA. In addition a general information about the supported protocol stacks (in respect of the GIST stack proposal) should be included in the diagnostics data. GIST MRS information: An exhaustive list of the MRS table might cause the size of a diagnostics messages to increase dramatically, for example, when the core node supporting tens of thousands of sessions. It may also be not very helpful and also not secure without being scoped to a limited network domain. However, the total numbers of MRSs over an individual MAs in a GIST node may be of interest to the entity performing the diagnostics function. SID-bound state information: For state information which is directly corresponding to one single GIST Session ID/NSLPid tupel, more detailed information can be collected. This includes, but does not limit to, the following information: MA information: In contrast to the general GIST state case, the MA information for the SID-bound state information is limited to the message associations related to the specific SessionID/ NSLPID tupel. MRS information: The MRS data might include the MRI and information about the upstream and downstream peers, as well as configuration values, such as refresh intervals. Fu, et al. Expires September 7, 2006 [Page 4] Internet-Draft Diagnostics NSLP Design Options March 2006 NSLP state: It is likely possible to collect some information about the NSLP state corresponding to a particular session ID, if the authorization issue is addressed. However, it should not allow a diagnostics message from any querying node to query state belonging to other sessions or other NSLPs not being the present node (requestor). For NAT/FW NSLP, it may be interesting for a requestor to be able to diagnose the existence of NAT and FW devices (their IP addresses) and if possible, number or detailed information of NAT bindings or firewall entries, without a per- session basis. However, this is subject to authorization decisions in the protocol operation. Also, the QOS NSLP can be diagnosed for various information. In addition, collecting general information such as GIST supporting information (e.g., GIST node IP addresses) or in the case of QoS NSLP, QOSM ID supporting information in the QoS NSLP supporting nodes may be possible. Furthermore, if necessary, one can also calculate the processing delay information in GIST nodes, by putting timestamps to the diagnostics messages when they traverse a GIST node. This simple extension, similar to traceroute, can be added to diagnostics messages as discussed in [6]. The final information we propose to be gathered from NSIS nodes is their support for different NSLPs. For a network administrator it will be helpful to collect which NSLPs are running on a certain node within the domain. This will help finding out whether an NSLP he is diagnosing is still/has been running on said peer. Also, it will be possible to detect still active NSLPs on nodes within the domain which should no longer be running for security reasons. 3. Information gathering and data transport options This section will describe conditions and basic usage along with a proposed message format for GIST diagnostics client messages. It will also highlight practical usage for different scenarios. 3.1. Basic prerequisites It is desirable that a diagnostics function does not install any new state. However sometimes this is inevitable, for example state in GIST level, especially MRS state even no new MAs will be introduced. It is possible that the diagnostics messages will be transported in a stateless mode and the response messages are directly addressed to Fu, et al. Expires September 7, 2006 [Page 5] Internet-Draft Diagnostics NSLP Design Options March 2006 the requestor, if it is not necessary to maintain reverse routing information and modify/add results in the reverse direction. On the other hand, if a new MRS needs to be created in querying direction, then it should be removed in the response direction. Therefore, to avoid state creation on NTLP level, diagnostics messages should be kept as small as possible. Diagnostics messages should be limited to fit into a D-mode (e.g., UDP) message in size, thus no larger than 64k and likely limited by the link MTU. For simplicity and easy implementation we will continue NSIS' message object approach. This means that messages created by the diagnostic tool will consist of several objects which themselves could be compiled by adding various other message objects. By this, we also enable easy extensibility for further information gathering of yet unknown NSLPs. We will limit the diagnostic functions towards sysadmins diagnosing withing thei own domain only. Messages by the diagnostics tool consist of one common header followed by a Query object and a list of Hop objects: DIAGNOSTIC-message = Common header, Query object, [Hop object]* The Query object specifies the requested information every GIST node should add. A Hop object is added by every GIST node on the path and contains the requested information. The Hop object itself consists of a Hop-Header and a list of data objects: Hop-object = Hop header [IPv4 address object]* [IPv6 address object]* [General GIST information object] [SID-bound Response object] [NSLP state information object] [Available NSLPs object] [Additional information object] The procedure for the diagnostic tools will be as follows: 1. At querying node, compose and send query message with designated destination - the final GIST node along the path 2. GIST at querying node forwards message to next GIST node towards the destination Fu, et al. Expires September 7, 2006 [Page 6] Internet-Draft Diagnostics NSLP Design Options March 2006 3. Intermediate Diagnostic-NSLP-aware GIST nodes add queried information if message is on the downstream direction and forward to next peer 4. The destination GIST node adds queried information and forwards the message in the downstream direction The message flow is depicted in Figure 1. +----------+ +----------+ +----------+ | | | | | | |Diagnostic| |Diagnostic| |Diagnostic| | NSLP | | NSLP | | NSLP | | | | | | | +----------+ +----------+ +----------+ 1. || /\ 3. /\ || 4. /\ || \/ || || \/ || \/ +--------+2. +--------+ +--------+ +--------+ | |>>>>>>| |>>>>>>| |> .. >| | | GIST | | GIST | | GIST | | GIST | | node | | node | | node | | node | | |<<<<<<| |<<<<<<| |< .. <| | +--------+ +--------+ +--------+ +--------+ >> Upstream query message << Downstream response message Figure 1: Diagnostic NSLP message flow 3.1.1. Basic message objects 3.1.1.1. Common Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version : Identifier for diagnostic NSLP Length : Overall message length 3.1.1.2. Standard Object Format Each object begins with a fixed header giving the object Type and object Length. This is followed by the object Value, which is a whole number of 32-bit words long. Fu, et al. Expires September 7, 2006 [Page 7] Internet-Draft Diagnostics NSLP Design Options March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |r|r|r|r| Type |r|r|r|r| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Value // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 00 : Query object Type 01 : Hop object Type 02 : IPv4 address object Type 03 : IPv6 address object Type 04 : General GIST information object Type 05 : SID-bound Response object Type 06 : NSLP state information object Type 07 : Available NSLPs object Type 08 : Additional information object object 3.1.1.3. Hop object The hop object is just a container for the information objects requested in the Query object. 3.1.1.4. IPv4 address object Every Hop Object may contain any number of IPv4 address objects. Length: 4 bytes 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.1.5. IPv6 address object Every Hop Object may contain any number of IPv6 address objects. Length: 16 bytes Fu, et al. Expires September 7, 2006 [Page 8] Internet-Draft Diagnostics NSLP Design Options March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2. NTLP state information As described earlier, we distinguish between general GIST state information and SID-bound state information. When collecting general GIST state information, one has to be careful to limit the amount of gathered information to comply to the basic prerequisites, especially in terms of expected message sizes. For example, when querying for larger sized information the possible maximum amount of nodes the query collects data from and replies it to the querying node, has to be taken into account to not exceed the maximum allowed message size and thereby risk the loss of data. Therefore, mechanisms to prevent overlimits of message size caused by the computation of (informative data size + header sizes) * amount of queried nodes, need to be present. For example, intermediate peers that identify further information to exceed the maximum size could intercept the query process by sending already collected information back to the querying node and trigger a re-querying. The querying node can now start querying information from the intercepting node towards the destination. Hence we propose an extension to the message flow as shown in Figure 1 by introducing the possibility for every Diagnostic NSLP to act as a query intercepter: Fu, et al. Expires September 7, 2006 [Page 9] Internet-Draft Diagnostics NSLP Design Options March 2006 +----------+ +----------+ +-----------+ +----------+ | | | | |Diagnostic | | | |Diagnostic| |Diagnostic| | NSLP | |Diagnostic| | NSLP | | NSLP | | query | | NSLP | | | | | |intercepter| | | +----------+ +----------+ +-----------+ +----------+ 1. || /\ 3. /\ || 4. /\ || 5. 7. /\ || 6. \/ || || \/ || \/ || \/ +--------+2. +--------+ +--------+ +--------+ | |>>>>>>| |>>>>>>| |> .. >| | | GIST | | GIST | | GIST | | GIST | | node | | node | | node | | node | | |<<<<<<| |<<<<<<| |< .. <| | +--------+ +--------+ +--------+ +--------+ >> Upstream query message << Downstream response message Figure 2: Extended message flow with intercepting node Here we introduce 3 new actions: 1. At querying node, compose and send query message with designated destination - the final GIST node along the path 2. GIST at querying node forwards message to next GIST node towards the destination 3. Intermediate Diagnostic-NSLP-aware GIST nodes add queried information if message is on the downstream direction and forward to next peer 4. One peer discovers that adding the requested information would exceed the maximum message size and intercepts the querying process. 5. The intercepting node sends the already collected informational data downstream towards the querying node. 6. The querying node extracts the stores the data already collected along the path up to the intercepting node. It then sends a new query message directed at the destination node from the intercepting node on to collect data further along the path. 7. The destination GIST node adds queried information and forwards the message in the downstream direction 3.2.1. General GIST state information This will be discussed in a later version 3.2.2. SID-bound state information This will be discussed in a later version Fu, et al. Expires September 7, 2006 [Page 10] Internet-Draft Diagnostics NSLP Design Options March 2006 3.3. NSLP state information Which information to collect about states linked to a specific SID depends on the NSLP being queried. However, some basic information common to all NSLPs could still be gathered, for example the total amount of states connected to a specific SID. Querying of supported NSLP-IDs on each GIST node should be limited to Administrators only. 3.3.1. NSLP state information object NSLP state information object. Length: Variable 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSLP ID | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |InformationType| Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : |InformationType| Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NSLP ID: Identifier for queried NSLP Length : Overall message length InformationType : Identifier for information that is to be queried on GIST nodes up to destination Value : Value of queried information Information Type could be any data queried at a GIST node which could be used for diagnosis. Example: Total amount of states maintained by a QoS NSLP, Value would then contain that amount. When acting as a query message, only the InformationType fields will be present and contain the identifier. Intermediate GIST nodes and the destination GIST node will then enter the values accordingly. This would also allow for querying multiple types of information. GIST nodes not able to provide the requested information enter a value of 0 if they couldn't provide the information due to non availability and -1 if an error occured into the specific value field. Fu, et al. Expires September 7, 2006 [Page 11] Internet-Draft Diagnostics NSLP Design Options March 2006 3.4. Query available NSLPs This scenario can be expected to be most widely used. Also, it should be the most easiest one to deploy and implement aswell as gather the requested information. The diagnostics NSLP simply queries for other NSLP IDs on the GIST nodes, collects them and adds their values to the RESPONSE object together with the total amount of IDs and finally its IP address. 3.4.1. Available NSLPs object Available NSLPs object lists the NSLP IDs supported at the given GIST node. Length: Variable (depends on the number of NSLPs supported on the GIST node) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Reserved | ID of 1st NSLP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ID of 2nd NSLP | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Id of nth NSLP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length : Overall message length ID of Xth NSLP : NSIS ID of NSLP existing and supported by GIST node 3.5. Additional information Additional information can be gathered by computing the minimum, maximum and average delay of a roundtrip with values collected by running an instance of the PING Deamon. Other possible data to be queried for can include the software version of GIST, the OS running GIST, amount of known peers and other useful information. 4. Security Considerations Authorization and protection of the diagnostics messages seem to be two outstanding issues, among the various issues identified in [7]. Fu, et al. Expires September 7, 2006 [Page 12] Internet-Draft Diagnostics NSLP Design Options March 2006 On one hand, one may desire that only the state installer can query the session-specific state. For general information diagnostics, measures may be desired for allowing administrators only be able to make the operations across their own domains, or neighboring trusted domains. On the other hand, the diagnostics messages carry senstive information that needs to be integrity protected. Some measures may be utilized such as reusing the secure MAs (if available) between the neigboring GIST nodes, or add NSLP level security mechanisms such as CMS. A future version of this document will add more security relevant considerations. 5. Summary and Open Issues We have discussed in this document how diagnostics functions for NSIS implementations as a common NSLP could be designed. Our intention is to keep it as simple and secure as possible. Further possible additions to the diagnostics function could be diagnostics support for tunnelling and mobility devices. A new NSLP ID needs to be defined if a common NSLP for diagnostics functions is devised. 6. IANA Considerations A future version of this document will provide details about an IANA consideration. 7. Acknowledgments The authors would like to thank Sebastian Willert, Henning Peters, Luis Cordeiro and Bernd Schloer for the discussion and implementation of the early ideas. Moreover, Robert Braden, Scott Bradner, Robert Hancock, John Loughney, Jukka Manner, Andrew McDonald, David Oran and Martin Stiemerling provided valuable comments. 8. References Fu, et al. Expires September 7, 2006 [Page 13] Internet-Draft Diagnostics NSLP Design Options March 2006 8.1. Normative References [1] Manner, J., "NSLP for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp-09 (work in progress), February 2006. [2] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress), February 2006. [3] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", draft-ietf-nsis-ntlp-09 (work in progress), February 2006. 8.2. Informative References [4] Terzis, A., Braden, B., Vincent, S., and L. Zhang, "RSVP Diagnostic Messages", RFC 2745, January 2000. [5] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005. [6] Juchem, I., "A stateless Ping tool for simple tests of GIMPS implementations", draft-juchem-nsis-ping-tool-02 (work in progress), July 2005. [7] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005. Fu, et al. Expires September 7, 2006 [Page 14] Internet-Draft Diagnostics NSLP Design Options March 2006 Authors' Addresses Xiaoming Fu University of Goettingen Institute for Informatics Lotzestr. 16-18 Goettingen 37083 Germany Email: fu@cs.uni-goettingen.de Ingo Juchem University of Goettingen Institute for Informatics Lotzestr. 16-18 Goettingen 37083 Germany Email: ijuchem@cs.uni-goettingen.de Christian Dickmann University of Goettingen Institute for Informatics Lotzestr. 16-18 Goettingen 37083 Germany Email: mail@christian-dickmann.de Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Email: Hannes.Tschofenig@siemens.com Fu, et al. Expires September 7, 2006 [Page 15] Internet-Draft Diagnostics NSLP Design Options March 2006 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 (2006). 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. Fu, et al. Expires September 7, 2006 [Page 16]