Network Working Group U. Bodin Internet-Draft Operax Expires: September 2, 2007 A. Doria Lulea University of Technology B. Chatras France Telecom S. Norreys BT March 1, 2007 Auditing Functionality in Diameter draft-bodin-dime-auditing-reqs-02.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 September 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Diameter is being increasingly included in the work of other standards organizations and has become a key protocol in many architectures. One of the uses of Diameter includes setting and Bodin, et al. Expires September 2, 2007 [Page 1] Internet-Draft Auditing Functionality in Diameter March 2007 maintaining hard-state and soft-state during failover and in the event of delayed refresh messages respectively. Often there is a need to query for information on active sessions for backup or synchronization purposes. Table of Contents 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions of hard and soft state reservations . . . . . 3 2.2. Replication . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Diameter used for hard-state reservations . . . . . . . . 4 2.3.1. In the case of failover without replication . . . . . 4 2.3.2. In the case of failover with replication . . . . . . . 5 2.4. Diameter used for soft-state reservations . . . . . . . . 5 2.5. Required Mechanisms . . . . . . . . . . . . . . . . . . . 6 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Diameter Resource Management Extensions . . . . . . . . . . . 6 4.1. Original Abstract . . . . . . . . . . . . . . . . . . . . 7 4.2. Original Introduction . . . . . . . . . . . . . . . . . . 7 4.2.1. State synchronization . . . . . . . . . . . . . . . . 8 4.3. Command-Code Values . . . . . . . . . . . . . . . . . . . 9 4.3.1. Session-Resource-Query (SRQ) . . . . . . . . . . . . . 9 4.3.2. Session-Resource-Reply (SRR) . . . . . . . . . . . . . 9 4.4. Mandatory AVPs . . . . . . . . . . . . . . . . . . . . . . 10 4.4.1. Query-Index AVP . . . . . . . . . . . . . . . . . . . 10 4.4.2. Resource-Token AVP . . . . . . . . . . . . . . . . . . 10 4.4.3. Resource-Bag AVP . . . . . . . . . . . . . . . . . . . 11 4.5. Original IANA Considerations . . . . . . . . . . . . . . . 11 4.6. Original Security Considerations . . . . . . . . . . . . . 11 4.7. Original Acknowledgements . . . . . . . . . . . . . . . . 12 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Normative References . . . . . . . . . . . . . . . . . . . 12 5.2. Informational References . . . . . . . . . . . . . . . . . 12 Appendix A. Original References from draft-calhoun-diameter-res-mgmt-08.txt . . . . . . . 12 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 13 B.1. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 13 B.2. changes in -01 . . . . . . . . . . . . . . . . . . . . . . 13 Appendix C. IANA considerations . . . . . . . . . . . . . . . . . 13 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Bodin, et al. Expires September 2, 2007 [Page 2] Internet-Draft Auditing Functionality in Diameter March 2007 1. Terminology and Conventions The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Introduction Diameter has been widely adopted as a base protocol for different interfaces of next generation network (NGN) architectures developed by 3GPP, ETSI TISPAN and the ITU-T. Some of these interfaces are used to support hard state as well as to support soft state. For example, in the ETSI TISPAN NGN architecture the service policy decision function (SPDF) offers a Diameter based interface facing application functions over which they can issue resource reservation requests for various media flows. Such an application function can, e.g., be a SIP based soft-switch or a portal for media streaming. The interface between the SPDF and applications functions must support both hard and soft state. This contribution offers three failover use cases, two for hard-state and one for soft-state, that would benefit from the addition of an auditing function to Diameter. The primary requirement being set out in this draft is the requirement for retrieving state for failover and synchornization purposes. 2.1. Definitions of hard and soft state reservations In this draft, hard-state reservations and soft-state reservation will be used in the meanings documented by ETSI TISPAN[ETSI06]. o Hard-state reservation: type of reservation whereby the requested resources are reserved without time limit. Hard-state reservations are terminated if the DIAMETER session is terminated. o Soft-state reservation: type of reservation whereby the requested resources are reserved for a finite amount of time. Soft-state reservations are terminated when the DIAMETER session is terminated. 2.2. Replication The replication of session data can be performed regularly to facilitate instantiation of fresh server platform using replicated data. This approach is herein referred to as replication for warm standby. Another approach is to replicate session data in real-time to a parallel server platform, which immediately can take over the primary server's tasks in case it fails or becomes unavailable. This Bodin, et al. Expires September 2, 2007 [Page 3] Internet-Draft Auditing Functionality in Diameter March 2007 approach is referred to as replication for hot standby. The case when no session data is replicated, a fresh server platform taking over the primary server's tasks is referred to as a cold standby. It should be noted that refresh messages may be desirable not only for soft-state reservations. By having clients refreshing their active sessions before a timeout in the server it can be ensured that the clients remain in sync with the server. When a timeout occurs at the absence of an expected refresh message the server would, in this scenario, keep the session and issue a callback to the client informing it that a session exists that has not been refreshed accordingly. The client may then either provide a refresh or explicitly terminate the session by replying to this callback. The behavior of issuing a callback to the client when a session timeout occurs can clearly be useful also for soft-state sessions. For example, clients failing in refreshing sessions would with such callbacks not need to re-establish sessions that should not have been allowed to expire and handle possible consequences of session data being wrongly removed. Refresh failures may for example occur if a delayed refresh arrives after a session has already been deleted. However, in contrst to when hard-state is maintained, a soft-state server needs to eventually terminate a session which is not being refreshed in time (e.g. after a short period following a callback). Issuing a callback to ask whether a session is still active is generally a useful mechanism to assure that clients and their server remain syncronized. That is, a client or a server can benefit from the ability to issue such a question triggered by any internal or external event to make sure a particular session (or set of sessions) is still active in the peer node. For example, in case refresh messages are not used for a hard-state server, the Diameter server could issue a callback for sessions that have been active for a longer period to make sure they are still active in the corresponding client. 2.3. Diameter used for hard-state reservations There are at least two common use cases when Diameter is used for hard-state reservations: o without replication o with replication 2.3.1. In the case of failover without replication In cases where hard state is used over a Diameter interface in an environment where nodes have backups in case of failure, client nodes Bodin, et al. Expires September 2, 2007 [Page 4] Internet-Draft Auditing Functionality in Diameter March 2007 need a mechanism to audit their server for active sessions. That is, in case a Diameter client node crashes, its backup needs to audit the server node for active sessions. Otherwise the backup node cannot know which states are active and can't terminate them when they are no longer needed. These cases show that an auditing mechanism is needed to support hard-state whenever session information is replicated for resilience purposes. It is also clear that the auditing mechanisms needs to be symmetrical in order to support both the client auditing for session information in the server and the server auditing the client. 2.3.2. In the case of failover with replication A Diameter client, server, or both may replicate session state information over several database instances at different nodes to facilitate seamless node failovers. Replication of data over several database instances are often done asynchronously to keep response times low. That is, with asynchronous replication (i.e., unacknowledged database writes) a Diameter server can answer immediately to a client request instead of waiting for data to be properly replicated before answering. When using hard-state Diameter clients and their server face the risk of getting out of sync after a failover. As a consequence of asynchronous replication, session state requested and established in a Diameter server node may not have been properly replicated before the server crashes and is seamlessly replaced by its backup (e.g., through IP takeover or SCTP multi-homing). The server may, however, have responded to the request before crashing. The Diameter client could, therefore, record that lost (hard) session state is still active in the server when it is not. On the other hand, in case the client is terminating an active session and the server fails in replicating the state removal before crashing the backup server node will maintain a hard session state of which the client is unaware and which is invalid. 2.4. Diameter used for soft-state reservations In the case of soft-state reservations, an auditing mechanism can still be beneficial at failover between servers and between clients. At failover between servers the backup server taking over can request clients to re-establish their sessions. Instead waiting for refresh messages to arrive is likely to increase the time needed to get in sync. This is particularly true when long timeout periods are used. At failover between clients that do not replicate data (i.e., cold standby), an auditing mechanism would may allow a backup client to Bodin, et al. Expires September 2, 2007 [Page 5] Internet-Draft Auditing Functionality in Diameter March 2007 re-establish at least part of the original session data. In case all or part of the data possible to obtain from the server is useless to the backup client, it can choose to explicitly terminate the corresponding sessions. This would shorten the period at which clients and their server are out of sync after a failover. 2.5. Required Mechanisms The cases outlined above require that auditing mechanisms support both queries for a list of active sessions and support specific queries for detailed session information kept by the queried node (i.e., either the client or the server node). A further requirement for an auditing mechanism is that it must be able to work in parallel with the basic runtime operation of the Diameter signaling and interrupt that signaling. For example, in case a large number of audit messages is needed to synchronize, the rate of those messages must be possible to limit leaving enough capacity to the basic runtime signaling to handle ordinary session setup and teardown. Support for queries to check if a particular session or a set (list) of sessions are still active in the peer node is also required (i.e. either the server or a client node). 3. Proposal In keeping with the charter goal of updating Diameter in support with its current uses, the DIME WG is requested to add support of a two step approach to its list of work items. After the requirements have been discussed, updated and verified as being of interest to enough of the participants, the DIME WG is then requested to make the necessary changes to the base protocol to support auditing functionality. It is also suggested the DIME WG coordinate with other SDOs, especially those who have integrated Diameter into their architectures, in establishing the auditing functionality requirements. 4. Diameter Resource Management Extensions The contents of this section are a verbatim copy of draft-calhoun-diameter-res-mgmt-08.txt [id-res-mgmt] which was submitted in March 2001 by Pat R. Calhoun. The recommendation of the authors of this draft is that we use this solution as the starting point for meeting the requirements listed above. Bodin, et al. Expires September 2, 2007 [Page 6] Internet-Draft Auditing Functionality in Diameter March 2007 The text of the original draft is included as is in this version of the draft but may be edited in later versions to reflect the requirements and discussions in the Dime WG. Note: All of the references in this section are the original references and have not yet been updated to reflect changes in the document since the draft was published in 2001. This will be updated in the next version of the draft. 4.1. Original Abstract Diameter is an authentication, authorization and accounting (AAA) protocol used for network access services, such as dial-up (NASREQ) and Mobile IP. Some Diameter servers maintain state information of active sessions on the access servers, which is used mostly to enforce some local policy decisions. This extension describes an extension to the Diameter protocol that allows the server to query for active session state information from access servers in order to rebuild state information should it be lost for any reason. 4.2. Original Introduction Diameter [1] is an authentication, authorization and accounting (AAA) protocol used for network access services, such as dial-up (NASREQ) [2] and Mobile IP [3]. The NASREQ AAA requirements [6] require that AAA servers maintain session state information. This is typically used to enfore a local policy decision, such as limiting the number of simultaneous sessions for a specific user, maintaining IP address pools, etc. The AAA WG's network access requirements [5] require that an AAA protocol be able to query for session state information, in the event that this information is lost. This extension describes an extension to the Diameter protocol that allows a Diameter node to query for active session state information from its peers in order to rebuild state information. Although it is envisioned that this would be used when state information was lost, and needed to be rebuilt, it is possible for a node to periodically query for state information in order to ensure that its state is current. This document only concerns itself with the ability to query for session state information. Resources are actually reserved when a user is successfully authorized. Therefore, relevant application- specific extensions, such as [2] and [3], MUST define what resources are to be managed, by specifying what AVPs MUST be present in the Resource-Token AVP. Bodin, et al. Expires September 2, 2007 [Page 7] Internet-Draft Auditing Functionality in Diameter March 2007 The Extension number for this draft is three (3). Diameter nodes conforming to this specification MUST include an Extension-Id AVP with a value of three in the Device-Reboot-Ind Command [1]. 4.2.1. State synchronization When a Diameter node determines that it is has lost all state information it had for a specific peer, it SHOULD issue a Session- Resource-Query message to the peer. The node in question MAY postpone all authorization messages from the peer until state has been restored. Upon receipt of the Session-Resource-Query, all Resource-Token AVPs for the requested sessions, indicated via one or more Session-Id AVP, MUST be returned in a Session-Resource-Reply. The absence of any Session-Id AVP is an indication that all active sessions are to be returned. If the node is unable to send all of the information within a single message, it MUST include the Query-Index AVP, with a value that has local significance. A node that receives a Session-Resource-Reply with a Query-Index AVP SHOULD issue another Session-Resource-Query message with the Query-Index AVP intact, requesting the rest of the state information. +----------+ SRQ (no Query-Index AVP) ---> +----------+ | | <--- SRR (Query-Index AVP = x) | | | Diameter | SRQ (Query-Index AVP = x) ---> | Diameter | | Node A | <--- SRR (Query-Index AVP = y) | Node B | | | SRQ (Query-Index AVP = y) ---> | | +----------+ <--- SRR (no Query-Index AVP) +----------+ Session State Exchange The above example depicts Diameter Node a issuing an SRQ to Node B. Upon replying with an SRR, node B determines that it is unable to include all of the Resource-Token AVPs in a single reply, and therefore includes the Query-Index AVP with a value of x. Upon receipt of the response, node A processes all Resource-Token AVPs and issues a subsequent SRQ with the Query-Index AVP set to x. Node B receives the SRQ, and using the Query-Index AVP determines which sessions need to be included in the corresponding SRR. This exchange continues until node B returns an SRR that does not include the Query-Index AVP, indicating that there is no further session state information to be returned. Bodin, et al. Expires September 2, 2007 [Page 8] Internet-Draft Auditing Functionality in Diameter March 2007 4.3. Command-Code Values This section defines Command-Code [1] values that MUST be supported by all Diameter implementations conforming to this specification. The following Command Codes are defined in this specification: +------------------------+---------+------+---------------+ | Command Name | Abbrev. | Code | Reference | +------------------------+---------+------+---------------+ | Session-Resource-Query | SRQ | 277 | Section 4.3.1 | | Session-Resource-Reply | SRR | 278 | Section 4.3.2 | +------------------------+---------+------+---------------+ 4.3.1. Session-Resource-Query (SRQ) The Session-Resource-Query (SRQ), indicated by the Command-Code field set to 277, MAY be sent by a Diameter node to any of its peer to request a state update. The presence of one or more Session-Id AVPs in the Session-Resource-Query message indicates that the server only wants to receive the Resource-Token for the specified session(s). Message Format ::= < Diameter Header: 277 > { Extension-Id } { Origin-FQDN } { Origin-Realm } { Destination-Realm } * [ Session-Id ] * [ Destination-FQDN ] 0*1[ Query-Index ] * [ AVP ] * [ Proxy-State ] * [ Route-Record ] * [ Routing-Realm ] 0*1< Integrity-Check-Value > 4.3.2. Session-Resource-Reply (SRR) The Session-Resource-Reply (SRR), indicated by the Command-Code field set to 278, is sent in response to a SRQ message. The SRR message contains a Resource-Token for each active session that was requested via the Session-Id AVP. The absence of any Session-Id AVP in the SRQ implies that Resource-Tokens for all active sessions MUST be returned. In the event that all of the state information cannot be sent at once, the SRR message MUST include the Query-Index AVP. Bodin, et al. Expires September 2, 2007 [Page 9] Internet-Draft Auditing Functionality in Diameter March 2007 ::= < Diameter Header: 278 > { Extension-Id } { Origin-FQDN } { Origin-Realm } { Result-Code } [ Destination-FQDN ] 0*1[ Query-Index ] * [ Resource-Token ] * [ AVP ] * [ Proxy-State ] * [ Route-Record ] * [ Routing-Realm ] 0*1< Integrity-Check-Value > 4.4. Mandatory AVPs The following table describes the Diameter AVPs defined in the Resource Management extension, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Query-Index 500 4.4.1 Unsigned32 | M | P | | V | Y | Resource-Bag 502 4.4.3 OctetString| M | P | | V | Y | Resource-Token 501 4.4.2 Grouped | M | P | | V | Y | 4.4.1. Query-Index AVP The Query-Index AVP (AVP Code 500) is of type Unsigned32 and MUST only be present in the Session-Resource-Query and the Session- Resource-Reply messages. The Query-Index AVP has local significance to the issuer of the Session-Resource-Reply message, and is used to identify the state information that remains to be sent in a subsequent SRR message. 4.4.2. Resource-Token AVP The Resource-Token AVP (AVP Code 501) is of type Grouped. The value is a set of AVPs used to track state information that is pertinent to an active session. The issuer of the SRR message is responsible for creating a Resource-Token AVP for all active sessions requested. The following describes the minimum number of AVPs that MUST be present in a Resource-Token AVP. Service-specific AVPs MAY also be Bodin, et al. Expires September 2, 2007 [Page 10] Internet-Draft Auditing Functionality in Diameter March 2007 present, as defined in the appropriate service extension document. resource-token = sid host user timestamp extension-id optional sid = Session-Id AVP ; See [1], Section 3.1. host = Host-Name AVP ; See [1], Section 2.3.1. user = User-Name AVP ; See [1], Section 3.3. timestamp = Timestamp AVP ; See [1], Section 7.3. extension-id = Extension-Id AVP ; See [1], Section 2.6.3. optional = Resource-Bag AVP ; See Section 3.3 The Host-Name AVP contains the NAI of the access router that is servicing the user, while the timestamp AVP contains the time at which the successful Diameter authorization response was received, and the service was initiated. 4.4.3. Resource-Bag AVP This AVP allows encapsulation of arbitrarily many AVPs to be included in a Resource-Token. These AVPs are defined in service specific extensions to Diameter. The only restrictions to the AVPs is that they MUST NOT be interpreted so as to conflict with the other fields of the Resource-Token Group value, namely, the Session-Id, Host-Name, User-Name, Timestamp or Extension-Id AVPs. The Resource-Bag AVP (AVP Code = 502) is of type OctetString. The AVP encapsulates an arbitrary of AVPs, each with its own header and value. 4.5. Original IANA Considerations The command codes defined in Section 2.0 are values taken from the Command-Code [1] address space and extended in [2], [4] and [8]. IANA should record the values as defined in Section 4.3 The AVPs defined in section 3.0 were alllocated from from the AVP numbering space defined in [1], and extended in [2], [4] and [8]. IANA should record the values as defined in Section 4.4. 4.6. Original Security Considerations This Diameter extension assumes that the Resource Management data is secured either through a hop-by-hop authentication mechanism, as described in [1], or using a strong authentication mechanism as defined in [9]. Bodin, et al. Expires September 2, 2007 [Page 11] Internet-Draft Auditing Functionality in Diameter March 2007 4.7. Original Acknowledgements The authors wish to thank Erik Guttman for providing some very useful proposed text to handle the change in data types. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. Informational References [ETSI06] ETSI TISPAN, "Telecommunications and Internet converged Services and Protocols for Advanced Networking", 2006. [id-res-mgmt] Pat, P., "Diameter - Resource Management Extensions", 2001. Appendix A. Original References from draft-calhoun-diameter-res-mgmt-08.txt Note: In future versions of this draft, the references that are kept need to be researched to refer to current versions of the documents wherever possible. [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base Protocol", draft-calhoun-diameter-17.txt, IETF work in progress, September 2000. [2] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in progress, September 2000. [3] Calhoun, Zorn, Pan, Akhtar, "Diameter Framework", draft-calhoun- diameter-framework-07.txt, IETF work in progress, April 2000. [4] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- tember 2000. [5] Aboba et al, "Network Access AAA Evaluation Criteria", draft- ietf-aaa-na-reqts-07.txt, IETF work in progress, August 2000. Bodin, et al. Expires September 2, 2007 [Page 12] Internet-Draft Auditing Functionality in Diameter March 2007 [6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work in progress, June 2000. [8] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "Diameter Accounting Extension", draft-calhoun-diameter-accounting-08.txt, IETF work in progress, September 2000. [9] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security Extension", draft-calhoun-diameter-strong-crypto-05.txt, IETF work in progress, September 2000. Appendix B. Changes This section to be removed if and when this I-D is approved for publication as an RFC. B.1. Changes in -02 1. Added contents of draft-calhoun-diameter-res-mgmt-08.txt 2. Added TOC B.2. changes in -01 1. Add some specificity on the purpose of the requirements 2. Added a soft state use case for synchronization. 3. Added a section on replication 4. Added informational reference to ETSI ES 283 026 with definitions of soft and hard state Appendix C. IANA considerations TBD Appendix D. Acknowledgements The authors and editors of this specification thank Pat Calhoun for allowing us to use, include and buld on his proposed Diameter Resource Mnagement Extension draft. Bodin, et al. Expires September 2, 2007 [Page 13] Internet-Draft Auditing Functionality in Diameter March 2007 Authors' Addresses Ulf Bodin Operax Lulea S-977 75 Sweden Email: Ulf.Bodin@operax.com URI: www.operax.com Avri Doria Lulea University of Technology Lulea Sweden Email: avri@ltu.se URI: psg.com/~avri Bruno Chatras France Telecom Email: bruno.chatras@orange-ft.com URI: Steve Norreys BT Email: steve.norreys@bt.com URI: Bodin, et al. Expires September 2, 2007 [Page 14] Internet-Draft Auditing Functionality in Diameter March 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). Bodin, et al. Expires September 2, 2007 [Page 15]