SIP D. Schwartz Internet-Draft Kayote Networks Expires: August 29, 2006 J. Barkan DigitalSchtick February 26, 2006 End-to-End Route Management in the Session Initiation Protocol draft-schwartz-sip-routing-managment-00 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 August 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract While much attention has been given in Session Initiation Protocol (SIP) to the process of securing caller identity end-to-end, SIP routing headers (e.g. via, route etc) have not garnered the same attention and have gone largly unchanged since RFC 3261. Since SIP promotes the routing directives to the application layer it is imperative that these decisions not be tampered with by a malicious party. Specifically, Route and Via headers are passed "in the clear" without any security mechanism to insure the integrity of the information. This draft summarizes the problems with the existing Schwartz Expires August 29, 2006 [Page 1] Internet-Draft Routing Management February 2006 clear text routing mechanism as seen from the eyes of a network operator and provides some requirements for a solution. Schwartz Expires August 29, 2006 [Page 2] Internet-Draft Routing Management February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Vulnerablities in SIP Routing . . . . . . . . . . . . . . . . 4 3. Attack Scenarios...... . . . . . . . . . . . . . . . . . . . . 5 4. Route Management and Existing SIP Security Mechanisms. . . . . 8 5. Solution Requirements . . . . . . . . . . . . . . . . . . . . .8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Informative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Schwartz Expires August 29, 2006 [Page 3] Internet-Draft Routing Management February 2006 1. Introduction SIP empowers proxies to make downstream routing decisions based on the routing headers and upstream routing decisions based on Vias. In section 26.1.5 of RFC 3261 [1] there is mention of possible vulnurabilities resulting from this property of SIP. The mention is with respect to Denial of Service attacks and is only one threat out of many resulting from this mechanism. In reality, the threats resulting from this vulnerability are many and must be addressed if we are to provide for secure, stable and scalable networks. There has been some work on privacy and topology hiding for route headers [2] and validation of via headers [3], however, this work has not progressed past the early stages. As a network operator it is our opinion that, given the ease of the attacks, these vulnerablities need to be addressed and this work should progress. This draft presents real life examples and analysis of some of the threats observed on our operational network in an attempt to provide guidelines for implementation of solutions. Finally this draft provides a set of requirements for fixing these problems without heavy policy or state embedded into the network. 2. Vulnerablities in SIP Routing As described in the RFC and illustrated in the scenario above, SIP empowers proxies to make downstream routing decisions, based on the routing headers. This mechanism leads the 3261 RFC to identify the following vulnerabilities: "Attackers can create bogus requests that contain a falsified source IP address and a corresponding Via header field that identify a targeted host as the originator of the request and then send this request to a large number of SIP network elements, thereby using hapless SIP UAs or proxies to generate denial-of- service traffic aimed at the target." "Similarly, attackers might use falsified Route header field values in a request that identify the target host and then send such messages to forking proxies that will amplify messaging sent to the target. Record-Route could be used to similar effect when the attacker is certain that the SIP dialog initiated by the request will result in numerous transactions originating in the backwards direction." Proxies unwind via list to make upstream decisions and are unaware of tampering or bogus lists. The ability to validate the via list is restricted to loop detection using the branch tag. These vulnerabilities stem from the following traits of the SIP routing mechanism: Schwartz Expires August 29, 2006 [Page 4] Internet-Draft Routing Management February 2006 A. Any element can insert/delete/alter routing headers, undetected. A SIP server or UA can only verify routing to its immediate peers, and has no way to validate a set of routing headers that it is forwarding as part of the SIP request. Thus, a malicious server or UA can inject malicious routing information or alter routing information. This results in attacks which would be similar in spirit to ARP spoofing, but done at the SIP level. B. Proxies route statelessly without call-route state or global route knowledge SIP Proxies will route the message based on the message headers, according to the strict or loose routing algorithms in the RFC. In most cases, the SIP proxies used for routing are stateless, and have no knowledge of the call state. There is also no framework to associate a call with global route information or policy. C. There is no authoritative, trusted element for end-to-end routing policy SIP does not provide a trust model for routing, as it does for identity. An attack could be launched by a rogue UA, SIP Proxy or other Server element, and there is no framework for validation or verification as there is with end-to-end identity. D. SIP privacy directives allow for stripping of route information. Route information may be altered along the flow at the network boundaries in keeping with privacy directives. As such, there is no way to differentiate legal or malicious deletion or replacement of routing headers. 3. Attack Scenarios This section provides examples of some of the attacks on a network that are currently possible in SIP with relative ease. Since much has been written about network based attacks the focus in this section is on UA based attacks only. A later revision of the draft may include the server generated attacks as well 3.1 UA generated attacks These attacks are broken down into network topology privacy (bypassing header stripping), "Toll fraud" and DOS based attacks. Schwartz Expires August 29, 2006 [Page 5] Internet-Draft Routing Management February 2006 3.1.1 Network Topology privacy 3.1.1.1 B side UA inserts his own via under the network perimiter via Assume the following network architecture. In this architecture A and C are perimter elements that strip via and route information appearing inside the network. ********* ********* ********* ***** * * * * * * ***** *UA1***** A ***** B ***** C ****UA2* ***** * * * * * * ***** ********* ********* ********* The via list of reaching UA B would contain only C. If C's implementation was not careful and just appended its "stored" via list assuming that once C stripped his own via the via list was empty, there could be a scenario where UA2 would now see the rest of the list including all the via's in the network. The same could be done with route headers in a message originating from UA1. 3.1.2 Toll Fraud 3.1.2.1 UA inserts an element into the route In this scenario, a compromised or malicious UA inserts an element into the route. This introduces a man-in-the -middle element for all subsequent requests. This is possible in the initial INVITE signalling as well as in follow-on re-INVITE signaling. This attack is not a DoS attack and its sole purpose is to "sniff" and possibly alter internal state information that may be travelling between SIP elements of a network. Suppose an architecture where the first network element (A in figure below) authenticates the user and sends some call duration value to statefull network element B for mid ********* ********* ********* ***** * * * * * * ***** *UA1***** A ***** B ***** C ****UA2* ***** * * * * * * ***** ********* ********* ********* call teardown purposes. Having a man in the middle between A and B can enable a user to "modify" this information and get all the free calls he wishes. Schwartz Expires August 29, 2006 [Page 6] Internet-Draft Routing Management February 2006 3.1.2.2 UA removes a critical route in the network In the network diagram above, suppose that B is an entity that is responsible for writing CDR's for subsequent billing purposes. The Record-Route list would request that all subsequent traffic flow through B so that record routes could be generated correctly on a call by call basis. A malicious UA could remove the route associated with this entity so that no CDR's would be generated for his calls. 3.1.3 Denial of Service 3.1.3.1 UA creates route or via to attack another network In this scenario, a compromised or malicious UA rewrites the route headers and/or via headers, and the network proxies are used to send the request to an element in another network. This scenario can lead to a denial of service on the attacked network. 3.1.3.2 UA loads down network A clever manipulation of routes and or vias can accomplish loops and spirals that are take longer to detect. These include preloading the via list with many via's forcing much more processing for loop or spiral detection. 3.1.3.3 UA inserts various routes or vias to force loops and spirals that are hard to trace If a UA places itself is somewhere in the middle of the via stack it can rewrite the via list before forwarding so that loop goes undetected. Using the network diagram above, if UA2 can places "XXX" between network elements A and B than after B forwards upstream to XXX, XXX rewrite the via list to resemble the one sent by UA2 and forward "upstream" back to C. As far as C is concerned this is the first time that it appears in the via list and hence a loop is created. ********* ********* ********* ***** * * ***** * * * * ***** *UA1***** A ****XXX**** B ***** C ****UA2* ***** * * ***** * * * * ***** ********* ********* ********* Schwartz Expires August 29, 2006 [Page 7] Internet-Draft Routing Management February 2006 4. Route Management and Existing SIP Security Mechanisms The SIP specification discusses the use of standard mechanism for security. S/MIME is used to ensure end to end message integrity and confidentiality. TLS is used for hop-by-hop security. These mechanism do not provide solutions for the vulnerablities described above. S/MIME assumes that two end points, such as two UAs, need to communicate through a series of intermediaries, such as SIP Proxies, that cannot be trusted. It assumes trust between these end points. The S/MIME model does not take into account a compromised end point which would build rougue messages, including bogus routing headers. Additionally, routing headers must be available for modification by proxy servers, and are thus considered "outer headers", which would not be encrypted nor digested. The 3261 RFC states: "Proxy servers must therefore be trusted, to some degree, by SIP UAs" Unfortutnately, UAs on a public network cannot necessarily be trusted blindly by the servers. TLS provides an authenticated, secure channel for hop-by-hop communications. Referring to the need for UAs to trust the proxy servers, the 3261 RFC state: "...low-layer security mechanisms for SIP are recommended, which encrypt the entire SIP requests or responses on the wire on a hop-by -hop basis, and that allow endpoints to verify the identity of proxy servers to whom they send requests." TLS, and similarly IPSEC, would not provide any solution for trust of the UA. TLS solves the issues relating to someone in the netwrok misbehaving whereas the problems being highligted in this document are rooted in the UA. In addition, almost by definition the last hop to the terminating UA will never be a TLS connection. This leaves a hole for malicious entities to manipulate routing information as well. Privacy solutions - stateful proxies SBCs don't solve the problem either as these too can be put into the loops and spirals discussed above. 5. Solution Requirements In this section, we propose requirements for aa trusted routing REQ 1: The trusted routing mechanism should allow any element in a SIP network to verify the via, record-route and route headers for integrity and authenticity. Schwartz Expires August 29, 2006 [Page 8] Internet-Draft Routing Management February 2006 REQ 2: The mechanism should assume that a network element is only trusted to determine its own peer routing and not for any downstream routing or upstream tracking REQ 3: The mechanism should deter and allow detection of unauthorized insertion and deletion of routing headers, as described above REQ 4: The mechanism should be compliant with the RFC 3261 routing flows for UAs, proxies and servers, and require minimal modification REQ 5: The mechanism shall not require any element to maintain the state of the call or dialog Schwartz Expires August 29, 2006 [Page 9] Internet-Draft Routing Management February 2006 6. Security Considerations A document like this is meant to point out the vulnerabilities. This document includes requirements for such security functions. 7. IANA Considerations None. 8. Acknowledgements 9. Informative References [1] 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. [2] draft-byerly-sip-hide-route-00.txt [3] draft-shenoy-sip-via-validation-00.txt [4] http://www.ietf.org/rfc/rfc4189.txt Author's Address David Schwartz Malcha Technology Park Building 1, Box 21 Jerusalem 96951 Israel Phone: +972 52 347 4656 Email: david.schwartz@kayote.com Jeremy Barkan Malcha Technology Park Building 1, Box 21 Jerusalem 96951 Israel Schwartz Expires August 29, 2006 [Page 10] Internet-Draft Routing Management February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schwartz Expires August 29, 2006 [Page 11] Internet-Draft Routing Management February 2006