SIP Working Group H. Kaplan Internet Draft Acme Packet Intended status: Informational Expires: August 17, 2008 February 18, 2008 Why URIs Are Changed Crossing Domains draft-kaplan-sip-uris-change-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/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 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Kaplan Expires August 1, 2008 [Page 1] Why URI's Are Changed Crossing Domains February 2008 Abstract This document discusses the reasons SIP Service Providers change To and From URI's, to provide a basis for discussion of whether such From-URI hiding tactics as [E2E-SEC-MEDIA] have a chance of success. Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Applicability...............................................3 4. Analysis of why URI's are changed...........................3 4.1. Making calls work.......................................3 4.1.1 Changing URI Host Parts...............................3 4.1.2 Changing URI Username Parts...........................4 4.2. IP Address issues.......................................4 4.3. Topology Hiding.........................................5 4.4. Relationship Hiding.....................................5 5. Why this is important for Identity..........................6 6. Security Considerations.....................................6 7. Acknowledgments.............................................7 8. IANA Considerations.........................................7 9. References..................................................7 9.1. Informative References..................................7 Author's Address..................................................8 Intellectual Property Statement...................................9 Full Copyright Statement..........................................9 Acknowledgment....................................................9 1. Introduction SIP Identity, defined in [RFC4474], defines a mechanism for originating domains to sign SIP requests with a Certificate, in order to prove the legitimacy of the From identity and the request's body content. The motivation of the work derived from the need to provide a form of cryptographically strong end-to-end (or end-domain to end-domain) identity, in order to avoid malicious use of identity fraud. The existing SIP identity mechanism (RFC4474) relies on the From-URI and To-URI to stay consistent end-to-end, or else the signature becomes invalid. It has been pointed out that B2BUA's of various forms, particularly SBCs, modify such headers, thereby breaking [RFC4474], and its counterpart [RFC4916]. An alternative proposal, [E2E-SEC-MEDIA], copies and signs the copy of the original From-URI, in order to avoid SBCs changing it. In order for such a concept to Kaplan Expires - August 2007 [Page 2] Why URI's Are Changed Crossing Domains February 2008 work, SBCs must leave the signed copy alone, which seems to contradict their goals. Although many people point to SBCs as the source of such behavior, it is important to note that SBCs don't change URIs because they want to - they change them because they have to, because their owners want them to. If the SBCs don't change the headers, the SBC will simply be replaced by a product that will change the headers. The SBC owners want the headers changed for logical reasons, although those reasons may not be apparent to everyone. It is in fact the goal of this draft to make those reasons apparent. 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. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". 3. Applicability This draft applies to the Identity mechanisms in [RFC4474] SIP Identity, [RFC4916] Connected Identity, [IDENTITY-MEDIA], and [E2E- SEC-MEDIA]. 4. Analysis of why URI's are changed This section examines why SBC's are provisioned to change To and From URIs at domain borders. [Note: it may be that some SBCs change them by default, but in this author's experience, most do so only when explicitly provisioned to do so] The reasons listed here are based on feedback from large and small SIP service providers, of various vertical markets. Not all providers share the same views, and some markets and geographic regions appear to have common views within their particular market, for what it is worth. 4.1. Making calls work 4.1.1 Changing URI Host Parts The From-URI and To-URI host portions are changed to the local provider's own domain as requests enter the provider, and to the peer domain as they exit the provider, because the probability of successful signaling increases. This is due to different reasons, Kaplan Expires - August 2007 [Page 3] Why URI's Are Changed Crossing Domains February 2008 which are separated as follows because they have different implications: a. For whatever reason, there are SIP systems in deployment (e.g., application servers, softswitches, PSTN gateways) which cannot process a SIP request which has a From and To URI host portion that is different from their own domain. It is not clear if this limitation is caused by poor software design, or just that call routing tables are easier to manage if the domains match the local one. Regardless, this is one reason providers modify them as they enter their domain, and as they exit their domain. b. For requests exiting a service provider domain, it may well be that it is the peering operators which cause this need. The peer's equipment may be configured to only allow calls based on To/From whitelists. Ironically, they do this because there is little other identity information to base such decisions on. Were there to be a strong identity mechanism that worked across SBCs, this particular reason might become moot. 4.1.2 Changing URI Username Parts From-URI and To-URI username portions which are E.164-based are also frequently changed as SIP requests enter and exit service providers, often as part of number translation and normalization. Translation, which is also frequently done in SIP devices inside the service provider, is performed to convert numbers into or out of E.164 format, for example to strip the international dialing prefix (since it is country specific). Normalization is performed for similar reasons to that for host portions, to make it work with systems that expect it in a certain format, for example if they can only handle a SIP URI vs. a TEL URI, or cannot handle visual separators. 4.2. IP Address issues As much as standards promote the use of FQDNs and domain names, there is still significant use of IP Addresses in the From and To- URI host part. For example, when a call comes from a PSTN gateway, TDM gateway, or PBX. Even subscriber endpoint UAs generate them, when they are provisioned with an IP Address for their outbound proxy. For security reasons (noted in section 4.3), providers refuse to allow their own internal or their customer IP Addresses to be available outside of their own network, and thus they change the From/To-URI host portion. Ironically many of the providers seem to change the offending IP address to another IP Address (often the SBC's), instead of a domain name, so the problem isn't "fixed" at that hop either. Kaplan Expires - August 2007 [Page 4] Why URI's Are Changed Crossing Domains February 2008 4.3. Topology Hiding The concept behind Topology Hiding is documented in [SBC-FUNCTIONS], but it combines two different concepts: Topology Hiding and Relationship Hiding. The latter is explained in Section 4.4. The former, Topology Hiding, is the simple concept of security by obfuscation: remove any internal addresses/FQDNs from the SIP message as it exits the provider domain, including those in the From/To-URI. It is not strong security by itself, and is not meant to be - it's just one component of an overall scheme. The general idea is rooted in a traditional Enterprise security concept: create a separation between the inside "trusted" network, and the outside "untrusted" network. In Enterprise networks this separation possible to do physically, because there are very few entry/exit points for the IP network. In service providers it is not. They have numerous entry/exit points. If their SIP equipment is housed in a few "data centers" then they may well be so constrained, and even without it the provider can choose to not advertise the reachability of the internal addresses in BGP. An even simpler measure is to use RFC1918 private addresses for such internal SIP nodes, which is fairly popular. For these types of cases, Topology Hiding is performed purely as a redundancy measure, so that operator error does not cause disclosure of reachable internal IP addresses or FQDNs. Furthermore, most providers consider their residential subscribers and some Enterprise customers to be in a form of trusted network, separate from the trusted SIP network of their own SIP equipment, but also separate from other providers or the public Internet. There is a very real responsibility the providers have for the security of their customers, yet they do not have physical control over the customer equipment, and do not typically wish to block traffic at an IP layer. Topology Hiding is thus used to hide the information of the customers, so that outside parties cannot learn them for malicious use directly against the customers. An interesting distinction for Identity use is this form of Topology Hiding does not necessarily mean a provider is unwilling to pass on an Enterprise's From-URI domain, if it is just a domain name. What they won't do is expose an actual hostname of the Enterprise's equipment, whether IP Address or FQDN. 4.4. Relationship Hiding Relationship Hiding is not an industry term - I am using it merely to distinguish from Topology Hiding because it makes a difference with respect to Identity use. Relationship Hiding is the changing of From/To-URI host parts in order to hide the identity of the Kaplan Expires - August 2007 [Page 5] Why URI's Are Changed Crossing Domains February 2008 previous provider or Enterprise for business reasons. In transit provider cases it's often done to prevent customers from forming direct relationships with other carriers to save money. (i.e., prevent cutting out the middle-man) In some cases it's done for marketing reasons, to prevent customers from learning which transits a call came from. Within this entire category, there is actually an important distinction for Identity: a. Those that do it to hide transit relationships, but don't care about revealing the true call originator domain. b. Those that do it to hide all relationships. 5. Why this is important for Identity All of the reasons cited in section 4 except 4.4(b) are actually compatible with the general concept of providing strong identity. They are just not compatible with the Identity mechanism defined in [RFC4474] and [RFC4916]. It is possible that another mechanism for identity could work, if it could be defined such that it allows the To/From-URIs to be changed en route. Such a mechanism would also have to allow other portions of the message to be changed, not the least of which is a major stumbling block: SDP. The reasons for this are mostly covered in [SBC- FUNCTIONS]. It is important to note that [ICE] will not resolve this need, because NAT traversal is not the primary reason SBCs change SDP to relay media. [RFC4474] signs the entire SDP body, but [baiting-attack] shows this does not prevent malicious use. The only mechanisms proposed thus far which allow middle-boxes to change SDP while providing end-to-end Identity are documented in [IDENTITY-MEDIA] and [E2E-SEC-MEDIA]. In particular, [E2E-SEC- MEDIA] allows for the To/From-URI to be changed by middle-boxes. Unfortunately, both drafts require the use of [DTLS-SRTP] and [DTLS- SRTP-FRAMEWORK] on both the UAC and UAS ends, which severely limits the ability for Identity to be deployed incrementally and inexpensively. It remains to be seen if strong Identity can overcome such obstacles, or if another mechanism can be found. 6. Security Considerations The purpose of this draft is to identify the reasons why the SIP To/From-URIs are changed by middle-boxes, and is informational in nature only. As such, it does not take into account the security properties of such changes, beyond their implication for [RFC4474] and identity proof. Kaplan Expires - August 2007 [Page 6] Why URI's Are Changed Crossing Domains February 2008 7. Acknowledgments The blame/thanks goes to Dan Wing for asking me to write this, and for his comments on it. 8. IANA Considerations This document makes no request of IANA. 9. References 9.1. Informative References [RFC3261] 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. [RFC4474] Peterson, J., Jennings, C., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007. [DTLS-SRTP] McGrew, D., Rescorla, E., "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01.txt, November 2007. [DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., Rescorla, E., "Framework for Establishing an SRTP Security Context using DTLS" draft-ietf-sip-dtls-srtp-framework-00.txt, November 2007. [E2E-SEC-MEDIA] Fischer, K., "End-to-End Security for DTLS-SRTP", draft-fischer-sip-e2e-sec-media-00.txt, January 2008. [ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19.txt, October 2007. [IDENTITY-MEDIA] Wing, D., Kaplan, H., "SIP Identity using Media Path", draft-wing-sip-identity-media-01, November 2007. [SBC-FUNCTIONS] Hautakorpi, J., et al, "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", draft-ietf-sipping-sbc-funcs-04.txt Kaplan Expires - August 2007 [Page 7] Why URI's Are Changed Crossing Domains February 2008 Author's Address Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803, USA Email: hkaplan@acmepacket.com Kaplan Expires - August 2007 [Page 8] Why URI's Are Changed Crossing Domains February 2008 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kaplan Expires - August 2007 [Page 9]