One document matched: draft-kaplan-sip-uris-change-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 08:21:35 |