[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/