Internet Draft A. Roychowdhury draft-roychowdhury-sipping-pathtrace-reqts-00 Hughes Software Systems Category: Informational Expires: December 2002 August 2002 Requirement for Analysis of SIP Paths Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract There is no defined mechanism today by which SIP proxies can insert path related information in a SIP message that is being routed across a network. As an example, a network administrator may want to trace the path as a SIP message traverses across her network to detect failure points. As another example, a user may want to discover capabilities of servers in the path of a call. Although there is an informal mention of using the OPTIONS method to achieve the latter example [1], there is no defined way to achieve the same today. Roychowdhury Expires December 2002 [Page 1] INTERNET DRAFT August 2002 This draft describes the requirements that need to be met for introducing a scheme that allows SIP based entities to record path related information. Roychowdhury Expires - December 2002 [Page 2] INTERNET DRAFT August 2002 Table of Contents 1. Terminology....................................................4 2. Overview.......................................................4 2.1 Background.................................................4 2.2 Clarification of terms used................................4 2.3 Categorization of path information.........................5 2.4 Categorization of network entities.........................5 3. Requirement specifications.....................................6 3.1 Originating client side requirements.......................6 3.2 Server side requirements...................................6 3.3 Path information requirements..............................7 3.4 Security requirements......................................7 4. Trust Assumptions..............................................8 5. Security Considerations........................................8 6. Open/Pending Issues............................................8 7. References.....................................................9 8. Acknowledgments................................................9 9. Author's Addresses.............................................9 10. Full Copyright Statement.....................................10 Roychowdhury Expires - December 2002 [Page 3] INTERNET DRAFT August 2002 1. 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 [2]. 2. Overview 2.1 Background SIP[1] has no defined mechanism to allow in-path proxies to insert path related information. As a simple but important example, if a network administrator is experience misrouted or looping packets in some node of her SIP network, a SIP level traceroute functionality would be an important analysis tool. However, there is no provision in SIP by which proxies can insert their own address as a part of the SIP message which gets finally gets routed back to the UA (in this case, the network administrator). Extending this concept further, the internet address of in route servers is probably just one of many properties that a UA may be interested in discovering. Other properties such as SIP extensions supported by proxies may be of interest as well. The SIP specification [1] refers to the usage of the OPTIONS method to discover capabilities of servers but does not elaborate further. This documents attempts to establish the requirements for a generalized approach to allow for such path related information to be requested and responded to. 2.2 Clarification of terms used Path: refers to the route that a SIP request traverses as the it is being proxied from the source to the destination. Path-information: refers to the information that each proxy in the path of the route inserts. This information is preserved and returned back to the requesting entity (UA) in the SIP response. Path-information Request: refers to the SIP request that a UA sends requesting for path-information. Roychowdhury Expires - December 2002 [Page 4] INTERNET DRAFT August 2002 2.3 Categorization of path information Two broad categories of path related information have been identified: - Identification information - Capability information Identification information: inserted by proxies that identify their address to the requesting entity. This may be as simple as an internet address. Capability information: inserted by proxies that identify their capability set (for example, supported SIP extensions) 2.4 Categorization of network entities In addition to categorizing the kind of information that is inserted, it is also essential to categorize the entities that play a part in requesting and recording such information. Network entities can be categorized as: - Originating entity - In-route entity - Terminating entity Originating entity: SIP user agents that send a SIP message to the network requesting for path-information. In-route entity: SIP proxies that insert path-information in the message and forward it to the next-hop entity. Terminating entity: SIP proxy or UAS that acts as the final destination for the path-information request. Roychowdhury Expires - December 2002 [Page 5] INTERNET DRAFT August 2002 3. Requirement specifications 3.1 Originating client side requirements CLI-1. A client MUST be able to indicate the scope of information it requests from servers. CLI-2. A client MUST be able to provide identification information about itself to the in-path proxies (this may be useful for the proxies to decide how much of information it may wish to insert). CLI-3. A client MUST be able to specify the behaviour of proxies that do not support this extension - whether the request should be returned back or proxied forward like a normal SIP request. CLI-4. A client MUST be able to specify the behaviour after a proxy inserts path-information as per the request - whether the path should be terminated there (useful if the client is asking for the first server that meets a criteria) or whether the request should be propagated further for other proxies to insert their information. 3.2 Server side requirements This section describes the requirements for the in-route and terminating proxy/UAS. SRV-1. A server on receiving a path-information request MAY decide to include only a subset (including a null set) of the requested information. SRV-2. A server MUST NOT include any path-information in addition to those requested by the originating client. SRV-3. If a server that receives a path-information request does not understand this extension, it MUST forward the request to the next hop server or act as the terminating entity and respond with a final response. SRV-4. A server that inserts path-information MUST also insert the internet address of the previous hop as is seen by it (this helps in case certain in-between proxies do not support path- information. This way, the client receiving the request will atleast know that there may have been some in-between servers that did not participate in the request). Roychowdhury Expires - December 2002 [Page 6] INTERNET DRAFT August 2002 3.3 Path information requirements PATH-1. An originating client MUST be able to request 'identification' and 'capability' information independent of each other or combined together in one request. PATH-2. The identification path-information request and response SHOULD only be restricted to inserting the internet address of in-path servers. PATH-3. The capability information format MUST be flexible so that in future, further attributes could be defined that could be inserted by in-path servers. PATH-4. The path-information request MUST NOT traverse each node more than once during the life cycle of one such request (unless the SIP route has been configured in such a way, for example, a spiral.) 3.4 Security requirements SEC-1. The path-information request and response SHOULD be protected against man in the middle and hijacking attempts SEC-2. The servers that insert information about themselves in a path-information request SHOULD be judicious about the sensitivity of the enclosed information. Roychowdhury Expires - December 2002 [Page 7] INTERNET DRAFT August 2002 4. Trust Assumptions It is assumed in this document that a network where such path related information is requested has an implicit trust level associated with it. This model works under the assumption that both client side and server side nodes are willing to participate in information exchange. The reasoning is similar to how traceroute works - if a traceroute operation is to be useful, the network should not block ICMP pings. This again assumes that the request is being carried out in a network which has been configured to process such a trace request. The above line of thought is mostly valid when the path-information relates to ćidentificationĆ information. It may be valid to assume that such requests are generally sent by network administrators and they would have sufficient control over their network to be able to receive a useful response. Capability path-information, however, will most likely be requested by regular users who want to ćdiscoverĆ the properties of servers in the network. In this case, the information that is returned will completely depend on how the network has been set up and the policies that govern the response from in-route servers. The amount of information that is inserted by in-path servers depends on the policies and security configurations of those servers and is out of scope of this document. 5. Security Considerations Security considerations are covered in section 3.4. No further security considerations beyond those already in place for SIP have been identified as of now. 6. Open/Pending Issues 1. Can this be aligned with sip-request-history draft ? 2. We need to do more work defining the scope of 'capability' 3. Is the trust model described above reasonable or does this need to be expanded ? 4. Besides usual SIP security, what else is needed here ? Roychowdhury Expires - December 2002 [Page 8] INTERNET DRAFT August 2002 7. References [1] Rosenberg, J., Schulzrinne, Camarillo, Johnston, Peterson, Sparks, Handley and Schooler, "SIP: Session Initiation Protocol", Internet Draft draft-ietf-sip-rfc2543bis-09, February 2002. [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8. Acknowledgments The author would like to thank Sean Olson and Dean Willis for their comments and suggestions. 9. Author's Addresses Arjun Roychowdhury Hughes Software Systems 11717 Exploration Lane Germantown MD 20876 USA Phone: +1 301 212 7860 E-mail: aroychow@hss.hns.com Roychowdhury Expires - December 2002 [Page 9] INTERNET DRAFT August 2002 10. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docuí ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developí ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limí ited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISí CLAIMS 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. Roychowdhury Expires - December 2002 [Page 10]