P2PSIP Working Group J. Hautakorpi Internet-Draft Ericsson Intended status: Informational J. Koskela Expires: January 3, 2008 HIIT July 2, 2007 Utilizing HIP (Host Identity Protocol) for P2PSIP (Peer-to-peer Session Initiation Protocol) draft-hautakorpi-p2psip-with-hip-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 January 3, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies best current practices on how Host Identity Protocol (HIP) can be utilized in Peer-to-Peer Session Initiation Protocol (P2PSIP) networks. The main focus is given to the Network Address Translation (NAT) functionality, even though HIP provides functionalities like mobility, multi-homing, and enhanced security as well. The HIP is utilized as it is and no additions or changes are Hautakorpi & Koskela Expires January 3, 2008 [Page 1] Internet-Draft Utilizing HIP for P2PSIP July 2007 proposed to it. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Short Overview of HIP . . . . . . . . . . . . . . . . . . . . 4 4. HIP's NAT Traversal Mechanism . . . . . . . . . . . . . . . . 4 5. HIP's NAT Traversal Mechanism for P2PSIP . . . . . . . . . . . 6 5.1. Joining Phase . . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. Approach to Distributing the Load of RVSs and HIP Relays . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Normal Operation Phase . . . . . . . . . . . . . . . . . . 9 5.3. Leaving Phase . . . . . . . . . . . . . . . . . . . . . . 11 6. Differences To HIP Layer Routing . . . . . . . . . . . . . . . 11 7. Other Benefits that HIP Can Provide for P2PSIP . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Hautakorpi & Koskela Expires January 3, 2008 [Page 2] Internet-Draft Utilizing HIP for P2PSIP July 2007 1. Introduction P2PSIP [1] is a mechanism which incorporates Peer-to-Peer (P2P) technologies and the Session Initiation Protocol (SIP) [2] signaling in a way which allows the transfer of proxy-registrar functionality to the end-hosts. In P2PSIP network, storage and routing services are provided by Peers which participate to the overlay. There is a requirement [3] that the peers must be able to communicate with each other by traversing NAT devices. This document describes the best current practices for using Host Identity protocol (HIP) [4], and especially HIP's NAT traversal mechanisms [5], in P2PSIP networks. A proposed NAT traversal mechanisms for P2PSIP [14] creates long- lived connections between the peers. The mechanism described in this document has similar notion of long-lived connection. Both mechanisms also use Interactive Connectivity Establishment (ICE) [6] methodology for discovering an optimal route between two nodes. The difference is that [14] uses SIP for setting up these connections, and the mechanism in this document uses HIP for the similar purpose. The complexity of the actual P2PSIP peer implementations decrease as they can utilize the ICE NAT traversal methodology built into HIP [5], without having to implement it on the application level. Using HIP provides many other transparent benefits for the application as well, such as mobility, multi-homing, and privacy. The idea of using HIP for P2PSIP is not new; [7] depicts a model where the overlay itself is run on the HIP layer constructing a secure and robust generic overlay from which all peer-to-peer applications (SIP-based or not) can benefit. Our approach differs as it keeps these separate, utilizing the already defined HIP rendezvous and relay extensions for routing control traffic instead of integrating a specific overlay technology into the HIP stack. It is the belief of the authors that the mechanism described in this document would provide more flexibility and thus more efficient systems as neither the HIP protocol or the peer-to-peer application is tied to a certain overlay technology. The remainder of this document is organized as follows. Section 3 gives a short overview to HIP and Section 4 describes HIP's NAT traversal mechanism on a general level. Section 5 present how HIP's NAT traversal can be utilized for P2PSIP. Section 6 discussess the differences between the mechanisms described in this document and other approaches. Section 7 lists other benefits, besides NAT traversal, that HIP could provide for P2PSIP networks. Finally Hautakorpi & Koskela Expires January 3, 2008 [Page 3] Internet-Draft Utilizing HIP for P2PSIP July 2007 Section 8 and Section 9 present security and IANA considerations respectively. 2. Terminology 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 [8]. Most of the terminology and concepts presented in this document are aligned with [1] and [5]. Other terms are defined when used. 3. Short Overview of HIP HIP [4] is a new communication architecture which introduces a protocol between the network and transport layers which binds connection end-points to cryptographicly generated identifiers instead of network addresses. HIP identifiers (HIs) are the public part of a public/private key pair owned by the host. More commonly used for representing the identity are Host Identity Tags (HITs), a 128-bit hash of the HI, presented as IPv6 addresses. The HIP protocol is used to securely set up and maintain connection states between two identifiers. The initial set up is performed using a four-way handshake called the base-exchange, which includes a Sigma-compliant Diffie-Hellman key exchange. The initiating party is referred to as the Initiator and the target as the Responder. The four packets sent during the base-exchange are named I1 and R1 - the initial packet and its response, I2 and R2 - the subsequental Initiator-originated packet and its response. After the state is set up, IP Encapsulating Security Payload (ESP) encapsulated data traffic is exchanged. Due to the identifier / locator split, HIP provides transparent mobility and multi-homing support for applications. The application- level connections (for example TCP) will pass uninterrupted through changes in the host's network location (IP address changes) as it only affects the encapsulating data connections, not the encapsulated application-level connections. 4. HIP's NAT Traversal Mechanism HIP cannot typically operate as-is across legacy NAT devices. Hautakorpi & Koskela Expires January 3, 2008 [Page 4] Internet-Draft Utilizing HIP for P2PSIP July 2007 Extensions has therefore been proposed to allow for HIP communication across NAT middleboxes. A current HIP NAT traversal proposal is based on utilizing the ICE methodology [6], transport-layer encapsulation of signalling, and the use of HIP rendezvous servers [9] and relays. RVSs act as public contact point for hosts that are not able to reliably receive HIP traffic due to frequent mobility. Hosts use the HIP registration extensions to register their HITs with an RVS, after which they will receive I1 packets intended for those HITs send to the RVS. Methods for locating RVS servers for a specific HIT include Domain Name System (DNS) and Distributed Hash Table (DHT) lookups [10] [11]. An RVS server may assist in rudimentary NAT traversal as it writes the locator of the Initiator to the forwarded I1 packet. The Responder use this locator to complete the base exchange without any further involvement of the RVS server. Combined with transport-layer encapsulation, this may successfully establish a peer-to-peer path depending on the type of NAT middleboxes involved. The RVS-based base exchange is illustrated in Figure 1 [9]. I1(RVS, R, HIT-I, HIT-R I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) +----------------------->| |--------------------+ | | RVS | | | | | | | +---------+ | | V +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ | |<---------------------------------------------| | | | | | | I | I2(I, R, HIT-I, HIT-R) | R | | |--------------------------------------------->| | | |<---------------------------------------------| | +-----+ R2(R, I, HIT-R, HIT-I) +-----+ Figure 1: RVS-based Base Exchange There is also an alternative to an RVS, and that is a HIP relay. A HIP relay is similar to an RVS in that they both forward HIP control traffic. The difference is that HIP relays forward all HIP control traffic in both directions and may also offer ESP relaying. During the base-exchange, hosts exchange a list of locators. These may include local network addresses, intermediate middleboxes and ESP relays or other locators that may route traffic to the peer. How these addresses are discovered and which are provided (e.g. filtering Hautakorpi & Koskela Expires January 3, 2008 [Page 5] Internet-Draft Utilizing HIP for P2PSIP July 2007 for security reasons) is discussed in [5]. After the base exchange, a path between the hosts is sought. This follows ICE methodology of pairing the exchanged candidate locators, prioritizing pairs and performing connectivity checks using HIP UPDATE probes to find the most optimal working pair. The process is depicted in figure Figure 2. In this scenario, both hosts are behind NATs and have completed the base exchange (with the last R2 packet illustrated). I Relay R | 2. R2(RELAY_TO) | 1. R2(RELAY_TO) | +<------------------------------+-------------------------------+ | | | 3. UPDATE(ECHO_REQUEST,FROM_PEER) NAT-R:DROP| +------------------------------------------------------------->X| | | | 4. UPDATE(ECHO_REQUEST,FROM_PEER) | |<--------------------------------------------------------------+ | | | 5. UPDATE(ECHO_RESP,TO_PEER) | +-------------------------------------------------------------->+ | | | 6. UPDATE(ECHO_REQUEST,FROM_PEER) | +-------------------------------------------------------------->| | | | 7. UPDATE(ECHO_RESP,TO_PEER) | |<--------------------------------------------------------------+ | | Figure 2: HIP Connectivity Checks A similar process is also performed when a peer changes its network location (peer mobility). The locators are exchanged then using HIP UPDATE packets instead of the base-exchange. 5. HIP's NAT Traversal Mechanism for P2PSIP HIP is used to setup and maintain connections between peers in the overlay. Each peer MUST setup and maintain connections to the neighboring peers with HIP. There MUST be an alive connection to each peer listed in the DHT Data Structure. The DHT data structure means, it this context, the data that describes the partial structure of the DHT network on each peer. If Chord [15] is used as a DHT, for example, then the Chord's Finger Table is the largest part of the DHT data structure. Hautakorpi & Koskela Expires January 3, 2008 [Page 6] Internet-Draft Utilizing HIP for P2PSIP July 2007 The peer MAY also setup and maintain other connections with HIP. The peer may, for example, setup a connection to all the nodes listed in the buddylist. +-------+-----------------------+ /--------------------\ | SIP : Peer Protocol / |<===>( DHT Data Structure ) | : Overlay Maintenance | \--------------------/ +-------+-----------------------+ | HIP | +-------------------------------+ | IPv4/v6 | +-------------------------------+ Figure 3: Protocol Layering The network protocol layering is illustrated in Figure 3. The actual peer protocol is outside the scope of this document, but the idea is that the peer protocol packets are transported inside the HIP initiated connections. Also the protocol for the maintenance of the DHT data structure is out of scope. A suitable peer protocol could be, for example, a LOCSER method [16] for SIP. The LOCSER method would provide also the maintenance of DHT data structure with its well-defined XML body. The operation of P2PSIP peer can be broken into three phases: joining, normal operation, and leaving phase. The following subsections describe how HIP's NAT traversal mechanism can be utilized by a P2PSIP peers in each phase. 5.1. Joining Phase The details of the joining phase is highly dependent on the overlay's logic (e.g., what DHT algorith is used). Generally speaking, it can roughly be divided into three parts: finding a contact point, establishing the initial connection, and possible protocol specific re-negotiations. Of these three, only the second part involves HIP. The first step is simply to acquire an address to a peer which provides the initial contact with the overlay (the bootstrap peer). This can be done manually, using DNS or DHT lookup, previously cached candidates or multicast. Neither HIP or the P2P overlay is yet involved. The second step is to establish a connection to the bootstrap peer. The connection MUST be formed by using the HIP protocol. It can be formed either directly or with the help of an RVS or HIP relay. At this point, the client will have a HIP-established connection to a member of the overlay which, although transparent for the Hautakorpi & Koskela Expires January 3, 2008 [Page 7] Internet-Draft Utilizing HIP for P2PSIP July 2007 application, might have traversed intermediate NAT middleboxes and can utilize all other benefits that HIP provides. The third step includes any authentication, connection re-negotiation or other procedures the overlay implementation might require to accept a new node. As described in [12], the bootstrap peer might refer the new node to another peer for admittance. Also, overlay implementations typically require the client to establish additional connections (such as the finger nodes of Chord). HIP is not involved in the logic of this, but will be called upon if additional connections are required. That is, the connections between the peers in the P2PSIP network MUST always be formed by using HIP. 5.1.1. Approach to Distributing the Load of RVSs and HIP Relays The methods described in the following section crosses somewhat the border between the HIP layer and client application's overlay. Our approach tries to keep these separate and comment only on how HIP could be utilized, steering clear of the overlay structure, logic or content. Our model is however reliant on the presence of RVS and HIP relays, which can be seen as the weak link of the approach. This compels us to address the issue to some extent, which is done in following method for decreasing the reliance on infrastructure, which involves the overlay to a small degree. As peers of the overlay might not be publicly accessible, HIP connections may have to be initiated through an RVS or HIP relay to traverse NAT and other middleboxes. However, peers may not have suitable infrastructure support, such as an RVS or HIP relay at their disposal. This could be solved by having peers of the overlay act as RVS or HIP relays (HIP middlebox for now). Peers who seem to be in a suitable position (public network address, no blocking firewall) could register themselves in the DHT overlay as such. As all of these supposedly suitable peers might not turn out to be so (due to incorrect probing, maliciousness or other reasons), clients would register to a number of these to increase the odds that at least one works correctly. The client resource record put in the DHT overlay would include all of these HIP middleboxes, which connecting peers would try one at a time. Depending on the overlay algorithm used, it might be needed to distribute the load on certain nodes caused by the quite frequent registrations of HIP middleboxes and subsequent lookups. One way is to utilize the HIP identity (HIT) as salt when generating the entry key. For example, consider an RVS with the HIT 0xa1b2c3d4e5 that's about to register itself in the DHT. For finding a service in Hautakorpi & Koskela Expires January 3, 2008 [Page 8] Internet-Draft Utilizing HIP for P2PSIP July 2007 general, there needs to be a pre-defined prefix used to construct the keys - here we use "rvs:". Initially, the RVS tries to register to the "root" entry of the service which is under the key constructed from the prefix alone - 'HASH("rvs:")'. If the amount of registered entries is under a certain limit (e.g., 100), the RVS will try the next "branch". The key for it is made by appending the first character of the host's HIT as expressed in hex to the common prefix - HASH("rvs:a"). The same check is performed - if the number of registered entries exceed the limit, the RVS tries yet the next branch, HASH("rvs:a1"), and continues until a suitable slot is found. When searching for an RVS, peers do the opposite - start from the outer-most branch and work their way to the root until enough entries are found. This way the most common operation (lookup of RVS) and burden of storing the registrations is distributed, at least partially, throughout the DHT. 5.2. Normal Operation Phase The idea is that peer protocol messages are always transported inside the HIP initiated connections. The following example, illustrated in Figure 4, presents a typical scenario where a media session is established between two users, Alice and Bob. The HIP initiated connections are illusrated with dotted lines in the Figure (e.g., PP1 message is transported inside a HIP initiated connection). Hautakorpi & Koskela Expires January 3, 2008 [Page 9] Internet-Draft Utilizing HIP for P2PSIP July 2007 Alice Bob Peer A Peer B Peer C Peer D | | | | | ............... | | | |------ PP1 ----->| ............... | | | ............... |------ PP2 ----->| | | | ............... |[Bob's ] | | | |[resource] | | | ............... |[record ] | | ............... |<----- PP3 ------| | |<----- PP4 ------| ............... | | | ............... | | | | | | | |<<---------- HIP base exchange (with ICE) --------->>| | | | | | ................................................... | |---------------------- INVITE ---------------------->| |<--------------------- 200 OK -----------------------| | | | | |<====================== Media ======================>| | ................................................... | | | | | Figure 4: Message Sequence Example When Alice calls to Bob, first she needs to acquire Bob's resource record. The resource record may contain multiple transport-level addresses associated to Bob, and some of them might be the addresses of Bob's HIP relay. Alice fetches the resource record by using a peer protocol, messages PP1-PP4 in the Figure 4. All the peer protocol messages are trasported inside the HIP initiated connections. That is, peer B is one of the "fingers" in peer A, and peer C is one of the "fingers" in peer B. When Alice has Bob's resource record, her user agent can launch a HIP base exchange [13] towards Bob's peer (peer D), and the signaling might go through Bob's HIP relay. HIP uses ICE, as described in [5], and is therefore able to setup a connection between peer A and D even if NATs exist between the peers. The SIP signalling used for media session setup can then traverse inside the newly created connection. It is noteworthy to mention that in the previous example the NAT traversal is handled on the HIP layer and the layers above that does not have to implement separate NAT traversal mechanisms. There are still some topics for further study, such as 1) should Peer C forward the peer protocol message (PP2) to the Peer D, and 2) should the media be transported outside the HIP initiatited connections? Hautakorpi & Koskela Expires January 3, 2008 [Page 10] Internet-Draft Utilizing HIP for P2PSIP July 2007 5.3. Leaving Phase When closing the application, all connections MUST be terminated in order to avoid wasting resources. Although HIP states can be active without any data traffic, the HIP stack should terminate the states using appropriate signalling. This prevents NAT keepalive or other maintanance traffic from being transmitted. As the data traffic has been encapsulated in HIP initiated connections, closing the HIP states prevents also unwanted traffic from being received. For example, normally a datagram-based media stream may continue to be sent (and delivered to the host) even after the receiving application is closed. This is harmful in mobile environments where it drains the battery and may be expensive without flat-rate pricing. Closing the HIP state will efficiently prevent packets from being routed forward at the sender. 6. Differences To HIP Layer Routing Using HIP for P2PSIP has been proposed before in [7]. The approach of that proposal is to examine the P2PSIP architecture and separate the P2P-related functionality. This P2P layer is analyzed and its characteristics is compared to what HIP natively provides. As HIP is already able to provide a good share of the required functionality, extensions are proposed for HIP to be able to cover the missing parts as well. The extensions of the previous proposal add overlay functionality to the HIP protocol, including overlay routing, data encapsulation and bootstrap procedures. This would efficiently and transparently provide the needed P2P layer for all applications. Also, as that overlay would support message routing, it could be used to exchange small amounts data between any two nodes of the overlay, such a the HIP control packets used to set up new direct connections which normally requires a straight path or a relay. Our approach differs as it keeps the overlay logic at the application-level, utilizing HIP only for the connections required by the overlay, not the overlay itself. HIP runs thus under and unaware of the overlay, and does not take part in any authentication, overlay routing or other related issues. For routing the HIP control packets between peers of the overlay, our approach utilizes the already defined HIP rendezvous and relay extensions instead of integrating the overlay management into the HIP stack. It is the belief of the authors that this would provide more flexibility and thus more efficient systems as neither the HIP Hautakorpi & Koskela Expires January 3, 2008 [Page 11] Internet-Draft Utilizing HIP for P2PSIP July 2007 protocol or the peer-to-peer application are tied to a certain overlay technology. As the overlay is run on top of HIP, the HIP protocol is kept clean and focused on its primary task - establishing robust connections. Applications may choose an overlay implementation with a routing algorithm and set of features optimized for their needs. For example, the data replication requirements for different applications, like for VoIP and file sharing, are quite different. 7. Other Benefits that HIP Can Provide for P2PSIP The Host Identity Protocol has more to offer for P2PSIP than merely NAT traversal, such as security and transparent support for mobility and multihoming. The following section provides a brief description of these features and will be completed in more detail in subsequent versions of this document. HIP uses public-key based identifiers as end-points for the connection states. The locators (IP addresses) are only parameters of the state, not uniquely identifying it (as in a TCP or UDP connection). The locators are negotiated during the base-exchange, and can be updated at any later point, providing transparent and uninterrupted mobility for the encapsulated data traffic (for example TCP or UDP). The HIP protocol state includes session keys which can be used for encrypting the encapsulated data traffic. In case of limited processing power, this feature can also be left unused (using null encryption algorithm). 8. Security Considerations The current version of the document contains only quite high level descriptions from the proposed mechanism. The security considerations are going to be studied in the coming versions. 9. IANA Considerations No IANA considerations. 10. References Hautakorpi & Koskela Expires January 3, 2008 [Page 12] Internet-Draft Utilizing HIP for P2PSIP July 2007 10.1. Normative References [1] Willis, D., "Concepts and Terminology for Peer to Peer SIP", draft-willis-p2psip-concepts-04 (work in progress), March 2007. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Jiang, X., "The requirement of P2PSIP Peer protocol", draft-jiang-p2psip-peer-protocol-requirement-00 (work in progress), February 2007. [4] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [5] Komu, M., Schuetz, S., and M. Stiemerling, "HIP Extensions for the Traversal of Network Address Translators", draft-ietf-hip-nat-traversal-02 (to appear) (work in progress), July 2007. [6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-15 (work in progress), March 2007. [7] Cooper, E., "A Distributed Transport Function in P2PSIP using HIP for Multi-Hop Overlay Routing", draft-matthews-p2psip-hip-hop-00 (work in progress), June 2007. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] Eggert, L. and J. Laganier, "Host Identity Protocol (HIP) Rendezvous Extensions", draft-eggert-hip-rvs-00 (work in progress), July 2004. [10] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", draft-nikander-hip-dns-00 (work in progress), July 2004. [11] Ahrenholz, J., "HIP DHT Interface", draft-ahrenholz-hiprg-dht-01 (work in progress), February 2007. [12] Cooper, E., "Bootstrap Mechanisms for P2PSIP", draft-matthews-p2psip-bootstrap-mechanisms-00 (work in progress), February 2007. Hautakorpi & Koskela Expires January 3, 2008 [Page 13] Internet-Draft Utilizing HIP for P2PSIP July 2007 [13] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07 (work in progress), February 2007. 10.2. Informative References [14] Cooper, E., "NAT Traversal for dSIP", draft-matthews-p2psip-dsip-nat-traversal-00 (work in progress), February 2007. [15] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Frans Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications", IEEE Transactions on Networking, 2003. [16] Hautakorpi, J. and G. Camarillo, "The Peer Protocol for P2PSIP Networks", draft-hautakorpi-p2psip-peer-protocol-00 (work in progress), February 2007. Authors' Addresses Jani Hautakorpi Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: jani.hautakorpi@ericsson.com Joakim Koskela Helsinki Institute for Information Technology Metsaenneidonkuja 4 Espoo 02130 Finland Email: joakim.koskela@hiit.fi Hautakorpi & Koskela Expires January 3, 2008 [Page 14] Internet-Draft Utilizing HIP for P2PSIP July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hautakorpi & Koskela Expires January 3, 2008 [Page 15]