One document matched: draft-schwartz-sip-routing-managment-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-24 10:44:59 |