Network Working Group V. Narayanan, Ed. Internet-Draft Qualcomm, Inc. Intended status: Informational May 18, 2007 Expires: November 19, 2007 IPsec Gateway Failover and Redundancy - Problem Statement and Goals draft-vidya-ipsec-failover-ps-02 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 November 19, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Recovering from failure of IPsec gateways maintaining large numbers of SAs may take several minutes, if they need to re-establish the IPsec SAs by re-running the key management protocol, IKEv2. A similar problem arises in the event of a network outage resulting in the failure of several gateways and servers. The latency involved in this approach is significant, leading to a need for a faster and yet secure failover solution. This document describes the problem statement and the goals for an IPsec/IKEv2 gateway failover/ Narayanan Expires November 19, 2007 [Page 1]
Internet-Draft IPsec Failover/Redundancy PS May 2007 redundancy solution. Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Motivation and Background . . . . . . . . . . . . . . . . . . 4 4.1. Use of IPsec in 3G Networks . . . . . . . . . . . . . . . 4 4.1.1. Mobile IPv6 in 3G Networks and IPsec State Related Concerns . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Mobile IPv6 Home Agent Reliability and IPsec Failover . . 7 5. Applicability and Problem Statement . . . . . . . . . . . . . 8 5.1. Failover Cases . . . . . . . . . . . . . . . . . . . . . . 9 6. IPsec Failover Redundancy Solution Goals . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Narayanan Expires November 19, 2007 [Page 2]
Internet-Draft IPsec Failover/Redundancy PS May 2007 1. Contributors This document reflects contributions from and active discussions among the following individuals (in alphabetical order): Lakshminath Dondeti (ldondeti@qualcomm.com) Paul Hoffman (paul.hoffman@vpnc.org) Tero Kivinen (kivinen@iki.fi) Gregory Lebovitz (gregory.ietf@gmail.com) Marcus Leech (mleech@nortel.com) Cheryl Madson (cmadson@cisco.com) Michael Richardson (mcr@sandelman.ottawa.on.ca) Sheela Rowles (srowles@cisco.com) Yaron Sheffer (yaronf@checkpoint.com) Marcus Stenberg (mstenber@cisco.com) Brian Weis (bew@cisco.com) 2. Introduction The IKEv2 protocol, while more efficient and involves fewer round trips compared to its predecessor is quite computationally intensive, especially when entity authentication is by way of public-key based certificates. IKEv2 also needs 2-3 roundtrips when using PSKs or public keys for authentication and 4 or more roundtrips when EAP is used for client authentication. Thus, the process of setting up IPsec SAs is an expensive process, in terms of the number of messages exchanged between the initiator and responder. Aside from the number of messages, IKEv2 also uses Diffie-Hellman for key negotiation. Network or gateway failures that result in a large number of clients reconnecting to a gateway will potentially lead to expensive computation on the gateway due to too many D-H exchanges within a short time span. When an IPsec entity has a large number of SAs with various other endpoints, establishing all the SAs again upon a failure recovery condition takes a long time. Examples of entities that manage a Narayanan Expires November 19, 2007 [Page 3]
Internet-Draft IPsec Failover/Redundancy PS May 2007 large number of IPsec SAs include IPsec remote access gateways, and application servers that use IPsec for protection of signaling traffic. For efficient recovery from gateway or server failure, it might make sense to allow those entities to maintain copies of IPsec and IKEv2 state (SAD, SPD, and associated state) on other gateways (for stateful operation) or on the client itself (for stateless operation). Either the recovered IPsec entity or other entities in the gateway pool may retrieve the stored IPsec and IKEv2 state for faster recovery. There are a number of proprietary solutions for some part of this problem in the industry, however, those solutions do not interoperate. Applications that need IPsec failover capability, such as Mobile IPv6 have solutions under development for interoperable Home Agent (HA) failover. Without interoperable (client to server and server to server) IPsec failover capability, Home Agent failover solutions are incomplete. Thus, there is a need for an interoperable means of performing SA uploads and retrieval so that such IPsec redundancy can be implemented in an interoperable fashion. 3. 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 [1]. This document uses terminology defined in [2], [3], and [4]. In addition, this document uses the following terms: 4. Motivation and Background This work is motivated by the use of IPsec in 3G networks, where the protocols used are often optimized for efficient, low overhead, low latency operation. As will be noted from the rest of this document, this does not mean that a solution developed will only be applicable for use in such 3G networks. The intent is to develop a solution that will be applicable for any entities using IKEv2/IPsec. This section provides details on the motivation and background that will help understand the problem statement and goals that follow. 4.1. Use of IPsec in 3G Networks A high level view of a 3G network with the various IPsec components is shown in Figure 1. Narayanan Expires November 19, 2007 [Page 4]
Internet-Draft IPsec Failover/Redundancy PS May 2007 ------------ --------------- | Home Agent | | Other servers | |(MIP6,IPsec)| |(May use IPsec)| ------------ --------------- | | | | -------------------- ( ) ( IP Network ) ( ) -------------------- | | / \ / \ ---------------- ------------- / Trusted access \ | VPN Gateway | \ / | (IPsec) | ---------------- ------------- | | ------------------ / Untrusted access \ \ / \ ------------------ \ / \ / ---------------- | Mobile Station | | (IPsec Client) | ---------------- Figure 1: High Level Network View with IPsec Components There are multiple uses of IPsec being considered in next generation 3G networks. One is the use of IPsec in untrusted access networks - this is much like a remote access VPN, with a VPN gateway placed in the network to provide secure connectivity to mobile devices over an untrusted network. The second is the use of IPsec for Mobile IPv6 (MIP6) - here, the MIP6 signaling is protected using IPsec, as required by MIP6, between the mobile node and the Home Agent (HA). Additionally, data tunneled through the Home Agent may also be protected using IPsec. In both these cases, IKEv2 is the mode of establishing the IPsec SA and EAP is often used in IKEv2 for client authentication. A third use of IPsec is in the IP Multimedia Subsystem (IMS) - however, IKEv2 is not used to set up the IPsec SA for use in IMS and Narayanan Expires November 19, 2007 [Page 5]
Internet-Draft IPsec Failover/Redundancy PS May 2007 hence, that use is not considered in this document. It should be noted that these may only be a subset of the IPsec use cases; this document applies to any use of IPsec that uses IKEv2 for SA establishment. In all these cases, the execution of IKEv2 (especially with EAP for client authentication) takes up a number of message exchanges and reasonable computational expense. When executed once upon power up, it may not be a significant concern. However, if IKEv2/EAP needs to be executed during handoffs, it often adds an unacceptable handoff latency. Further, upon failure of the network or the IPsec gateway, there is significant time needed to bring all the clients back in service. Distributed network elements to which the clients can connect using IPsec allow distributed failovers without the need for a fully reduandant IPsec gateway. Even when a fully redundant IPsec gateway is used, the ability to failover to distributed gateways provides better site-level redundancy. 4.1.1. Mobile IPv6 in 3G Networks and IPsec State Related Concerns ------------ --------------- | Home Agent | | Other servers | ------------ --------------- | | | | -------------------- ( ) ( IP Network ) ( ) -------------------- | | | |_ _ _ _ _ _ _ _ _ | | ------------- ---------------- / Home Access \ / Roaming access \ \ / \ / ------------- ---------------- | | | | ---------------- ---------------- | Mobile Station | | Mobile Station | |(No MIP6; IPsec | -----> | (MIP6, IPsec | | unused) | | in use) | ---------------- ---------------- Narayanan Expires November 19, 2007 [Page 6]
Internet-Draft IPsec Failover/Redundancy PS May 2007 Figure 2: Mobile IPv6 with Home and Roaming Networks One potential use of MIP6 in 3G networks involves using the protocol only when the mobile node roams outside of the its home network. This is shown in Figure 2. There is a need to keep the handoff upon roaming seamless and hence, this makes the setting up of IPsec SAs upon roaming undesirable. It is also not always feasible to predict roaming well ahead of time, sufficiently enough to proactively set up an IPsec SA. For this reason, it is better to set up the SAs while the mobile node is still on the home network (for e.g., upon first attachment to the network). However, it is also the case that device roaming is unpredictable - so, if the Home Agent is required to maintain all the IPsec SAs for all the mobile nodes, that is a significant waste of resources on the Home Agent, given that it is maintaining state for several devices that may never roam. Hence, establishing the IPsec SA, losing the state on the Home Agent, and allowing resumption of state when needed is a more scalable approach to handling the scenario. This case, while does not constitute a true failure of any kind, can be viewed as an instance where the network lost the state meant for the client. In such circumstances, any stateless failover mechanisms defined can be used to quickly resume the IPsec SA when the mobile device roams and actually needs to use it. 4.2. Mobile IPv6 Home Agent Reliability and IPsec Failover There are ongoing efforts to standardize Mobile IP Home Agent reliability [5] mechanisms for interoperable MIP6 failovers. The scope of that work addresses having distributed home agents that share MIP6 state. IPsec state sharing is not assumed by the work, although some IPsec state may be shared across the gateways. For this work, it is assumed that the home agents will have different IP addresses, although, the client IP addresses will be preserved after failover. If the IPsec state is perfectly synchronized among the different home agents, it may be feasible to have a failover that is transparent to the clients from an IPsec perspective. Note that the failover is not exactly transparent from a Mobile IP perspective, due to the change in Home Agent IP address. However, per packet synchronization of IPsec state is very hard to achieve, especially across distributed entities and hence, a need for client involved IPsec failover also becomes essential in that case. In all the cases described above, the resumption of IKEv2/IPsec state needs to happen with minimal latency to avoid longer resumption times for applications in progress on the clients. Narayanan Expires November 19, 2007 [Page 7]
Internet-Draft IPsec Failover/Redundancy PS May 2007 5. Applicability and Problem Statement There are at least two cases where fast recovery from failure of an IPsec entity is applicable. IPsec Gateways -- The first case is that of an IPsec remote access gateway managing tunnel mode SAs with clients. The gateway may be enforcing access control to an enterprise network; this is the typical remote access use case. The gateway could also be enforcing service provider network access control. In that case, clients typically use EAP over IKEv2 to establish an IPsec session with a network access gateway. In either IPsec Gateway use case, the IPsec traffic itself flows from the VPN clients or Initiators to the VPN gateway; the gateway decapsulates the IPsec packets and forwards the cleartext packets based on inner IP headers. In the reverse direction, the VPN gateway uses the security policy database (SPD) or associated caches as per RFC4301, to lookup the relevant IPsec SA, encapsulates the packets and sends to the appropriate VPN client. Servers -- The second use is that of an IPsec entity acting as a server for an application such as Mobile IP. In these cases, Mobile IP messages are protected using IPsec. Each Mobile IP Home Agent (HA) maintains a large number of transport or tunnel mode IPsec sessions with their respective clients. In this case, IPsec protected signaling messages are sent end-to-end, between Mobile IP client and HA, respectively. In the security gateway mode, while there may be multiple security gateways serving a number of remote endpoints, a given remote endpoint is served by one security gateway. For instance, an IPsec VPN client typically maintains one or more SAs for remote access with one VPN gateway. However, when the serving gateway fails, it is desirable for one of the other gateways to seamlessly take over and serve the clients affected by the failure. In some deployments, there may be a backup gateway that can take over for the primary in case of a failure. Such gateways may be running a VRRP-like protocol to actually share the gateway IP address as known to the clients. In other deployments, a cluster of gateways may load balance to serve a number of clients. In such a case, one or more of the gateways in the cluster may take over clients associated with another gateway in the cluster in the event of a failure. When IPsec is used for protection of signaling between an application client and server, server redundancy is often an important consideration. As in the gateway model, it is necessary for another server to be able to seamlessly take over clients being served by a failed server. Narayanan Expires November 19, 2007 [Page 8]
Internet-Draft IPsec Failover/Redundancy PS May 2007 In cases of gateway or server failures, it may also be that the clients re-attach to the same gateway or server after recovery of the entity. The failover procedures must be able to support that type of recovery. In addition to server failures, massive network failures of a short duration (minutes), followed by network recovery are also a concern. The network failure results in all clients being disconnected first (e.g. because of dead-peer detection), and then simultaneously attempting to reconnect. This can be classified as a subset of the gateway failure case for the purpose of this effort. In all these cases outlined above, it is feasible to perform secure IPsec and IKEv2 state transfer across endpoints to provide smoother failure recovery. Today, such redundancy operations are performed in a vendor specific manner and are not interoperable. Also, lack of client involvement implies a failover mode that is transparent to the client. However, in the above cases, the failover may not always be transparent to the client and hence, an interoperable mechanism becomes very important. 5.1. Failover Cases -------------------------- ( ) ( Internet ) ( ) -------------------------- | | / \ / \ ---------- ---- ---------- |Operator X| ( ) |Operator X| | Site A | ( IP ) | Site B | | | ( ) | | | ------ | ( N ) | ------ | | |IPsec | | ( e ) | |IPsec | | | |GW A1 | |------( t )-----| |GW B1 | | | ------ | ( w ) | ------ | | ------ | ( o ) | ------ | | |IPsec | | ( r ) | |IPsec | | | |GW A2 | | ( k ) | |GW B2 | | | ------ | ( ) | ------ | | | ---- | | ---------- ---------- Narayanan Expires November 19, 2007 [Page 9]
Internet-Draft IPsec Failover/Redundancy PS May 2007 Figure 3: Various IPsec Entities in the Network Figure 3 shows the various possible IPsec gateways that may be present in an operator's network. This figure shows a two-site operator network, each of which may have multiple IPsec gateways. Even though the term "IPsec gateway" has been used in the figure, it is also representative of any application server serving as an IPsec endpoint. The following are applicable failover cases under consideration. 1. Intra-site gateways with no direct gateway-to-gateway state synchronization mechanisms: In this case, the IPsec state is either partially available (e.g., no per packet state synchronization, but, the IKE SA is available, etc.) or not available at all. However, this does not restrict any state synchronization of other applications (e.g., the Mobile IP state may still be fully sychronized). This would be a case where IPsec Gateway A2 or B2 is acting as the backup gateway for IPsec Gateway A1 or B1 respectively in Figure 3. 2. Inter-site gateways that are geographically distributed: It is assumed that complete IPsec state synchronization across inter- site gateways is either complicated or impractical. This again does not rule of synchronization of other state such as Mobile IP state. This would be a case where IPsec Gateway B1 or B2 is acting as the backup gateway for IPsec Gateway A1 or A2 or vice- versa in Figure 3. 3. Gateway reboots: This is the case of clients attaching to the same gateway after it has recovered from a failure. Often, the gateway has lost the relevant IPsec state in such cases. This would be a case where any single IPsec Gateway in Figure 3 recovers from a failure and has clients connecting to it again. 6. IPsec Failover Redundancy Solution Goals The following are goals for the IPsec Failover Redundancy solution. Note that the motivation for this effort is to develop mechanisms and perhaps protocols to facilitate failover capabilities. It is plausible that the design facilitates features such as load balancing, but additional signaling or protocol design to facilitate load balancing exclusively is outside the scope of this effort. 1. Distributed Failover Mechanism: Gateways may be located at different sites and may not share the same IP address or have the same view of the network. For instance, the various distributed gateways may be connected to different backend elements such as Narayanan Expires November 19, 2007 [Page 10]
Internet-Draft IPsec Failover/Redundancy PS May 2007 EAP servers, DHCP servers, etc. A failover mechanism must be able to allow such distributed gateways to take over the clients associated with a failed gateway. The idea here is that there is no need for a fully redundant gateway that only starts functioning in the event of a failure. It is more cost-effective to allow such failover to distributed gateways that may be functional on their own, serving other clients. The temporary increase in load on some gateways in the system may be acceptable to many deployments in the event of a failure. Such a mechanism across distributed gateways may also be used for client handoff to other gateways due to other reasons, e.g., load balancing. Gateways located on the same link with the same view of the network may be viewed as a subset. 2. Client Involvement: Given that the gateways may be distributed, the failover is not intended to be transparent to the client. There may be times when the client, from its perspective, sees the gateway as unavailable and therefore needs to take some action to use a new gateway. The goal is to allow the option for the client to initiate the switch to a different gateway. In some cases, such as the Mobile IPv6 Home Agent reliability process, the Home Agent, acting as the IPsec gateway, may initiate the switch. This is due to the fact that the MIP6 Home Agent reliability procedures would allow a new Home Agent to detect the failure of an old Home Agent and trigger communication with its clients. 3. Low Latency failover: One of the major goals is to allow a low latency failover, without having to re-establish all the IKEv2 and IPsec state all over again. The bottleneck here is the new IPsec gateway trying to handle a flood of IKEv2 exchanges upon a failover. Further, for applications such as Mobile IPv6 that use IKEv2/IPsec for securing the signaling, re-establishment of IKEv2 often adds unacceptable latencies. Ideally, a mechanism that does not need any new messages to exclusively support failover is desired. In general, the goal is to have significantly lower latency and to incur a lower computational overhead than a regular IKEv2 exchange. In cases where EAP is used for client authentication in IKEv2, the failover should not require EAP authentication, to avoid AAA overloading and possible user interaction. This may mean that any attributes returned from the AAA server as a result of EAP must also be stored as part of the state, if those are required for IPsec operation. 4. Application Usage of IPsec: When IPsec is used to protect other protocols, the extent of failover interoperability that can be expected by such protocols greatly hinge on the interoperability of IPsec failover mechanisms. For e.g., Mobile IP Home Agent Narayanan Expires November 19, 2007 [Page 11]
Internet-Draft IPsec Failover/Redundancy PS May 2007 reliability [5] mechanisms are intended to be standardized for interoperability. However, it is incomplete without IPsec failover. So, it is important to allow applications that use IPsec to take advantage of the IPsec failover mechanism. It is not expected that the IPsec failover solution will address this, but a guidance needs to be provided to allow application specifications to specify the appropriate interface/interaction needed (e.g., if synchronization between application state and IPsec state is needed). 5. Interoperability: Client-gateway and gateway-gateway interoperability is required. Note that the gateway-gateway interoperability does not refer to any full SA state synchronization mechanisms across gateways. Interoperability across gateways is, however, needed from the perspective of having a standard state format that multi-vendor gateways would be able to use for failover, for example. 6. Stateless Gateway Operation: The IPsec failover mechanism should specify a mode of operation that will allow the backup gateways to not have to maintain state for clients it is not serving. A gateway must need to acquire and store state for a client that is otherwise served by a different gateway, only when a failover occurs or during a temporary service interruption with the client's old gateway. This will allow for better scalability of the solution, since a given gateway only needs to store state for clients that are being served by it. This requires for an equally secure means of storing state in the clients and allowing the client to present it to the gateway for recovery. 7. Support for IPsec transport and tunnel modes: As noted in the applicability section of this document, the IPsec infrastructure endpoint may either be an IPsec VPN gateway employing tunnel mode SAs with the client or an application server that uses IPsec transport or tunnel mode to protect signaling exchanges with the client. Hence, a solution developed for failover must support failover of both transport and tunnel mode SAs. 7. Security Considerations This document provides the problem description and goals for an IPsec failover solution. The solution must ensure secure operation and there are several important points to consider for that. We highlight a few of the important ones below : o First, any SA storage and retrieval mechanisms specified between the backend entities must be protected with a secure channel that Narayanan Expires November 19, 2007 [Page 12]
Internet-Draft IPsec Failover/Redundancy PS May 2007 has the following properties: confidentiality, integrity protection, and replay protection. o In a client-server model, where the client always initiates the secure communication, the client is always the IKEv2 initiator. Solutions for failover in such cases, may allow the client to find the new gateway IP address through external means. Subsequently, the client must be able to verify that the new gateway possesses the IKEv2 key material. A client should be able to initiate a new IKEv2 SA with one or more auxiliary gateways without interrupting a connection to the currently used primary gateway. The client must consider the new gateway as a provisional one until it has verified a new gateway is the appropriate replacement for the primary gateway. o Any solution must adequately describe the consequences to replay protection as a result of IPsec failover. For replay protection, it may be best for the replacement gateway to assume that the IPsec SA state is outdated and reestablish the IPsec SA using an IKEv2 CREATE_CHILD_SA exchange. o IPsec failover facilitates the replacement of an IPsec GW serving a client with another GW. The design must take into account the possibility of an adversary creating a ping-ponging scenario where a client may be forced to move between two or more GWs persistently. o It may be plausible for an attacker to force failover of a client to a gateway that is more advantageous to the attacker. The design must provide a means of verifying that a particular gateway belongs to the secure domain that the client may attach to using the same IKE SA. 8. IANA Considerations No IANA action is required for this document. 9. Acknowledgments We thank Russ Housley, Jun Wang, Marcello Lioy, and Raymond Hsu for technical discussions and/or help with standardization aspects related to this work. We thank Steve Kent for his review of the draft. We also thank Kuntal Chowdhury, Vijay Devarapalli and Kent Leung for their discussions on the applicability to Mobile IPv6 and 3G networks in general. Narayanan Expires November 19, 2007 [Page 13]
Internet-Draft IPsec Failover/Redundancy PS May 2007 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. 10.2. Informative References [5] Wakikawa, R., "Home Agent Reliability Protocol", draft-ietf-mip6-hareliability-01 (work in progress), March 2007. Author's Address Vidya Narayanan (editor) Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Narayanan Expires November 19, 2007 [Page 14]
Internet-Draft IPsec Failover/Redundancy PS May 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). Narayanan Expires November 19, 2007 [Page 15]