SIMPLE Working Group C. Holmberg
Internet-Draft Ericsson
Updates: 4975 (if approved) S. Blau
Intended status: Standards Track Ericsson AB
Expires: March 26, 2011 September 22, 2010
Session Matching Update for the Message Session Relay Protocol (MSRP)
draft-ietf-simple-msrp-sessmatch-07.txt
Abstract
This document updates the Message Session Relay Protocol (MSRP)
session matching procedure of MSRP endpoints. The update extends the
applicability of MSRP peer-to-peer communication to network scenarios
where Application Layer Gateway (ALG) functions modify the Session
Description Protcoll (SDP) MSRP address information.
The update is backwards compatible. In the absence of ALGs RFC 4975
compliant MSRP User Agents (UAs) can interwork with MSRP UAs
compliant with this specification. In the presence of ALGs RFC 4975
compliant MSRP UAs can normally not establish MSRP sessions.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 26, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Holmberg & Blau Expires March 26, 2011 [Page 1]
Internet-Draft MRSP September 2010
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability statement . . . . . . . . . . . . . . . . . . . . 4
4. Normative update of RFC 4975 . . . . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. RFC4975: 5.4 MSRP Connection Model . . . . . . . . . . . . 4
4.2.1. 5th paragraph . . . . . . . . . . . . . . . . . . . . . 4
4.2.2. 10th paragraph . . . . . . . . . . . . . . . . . . . . 5
4.3. RFC4975: 6. MSRP URIs . . . . . . . . . . . . . . . . . . . 5
4.3.1. 6th paragraph . . . . . . . . . . . . . . . . . . . . . 5
4.4. RFC4975: 6.1 MSRP URI Comparison . . . . . . . . . . . . . 5
4.4.1. 1st paragraph . . . . . . . . . . . . . . . . . . . . . 5
4.5. RFC4975: 7.3 Receiving Requests . . . . . . . . . . . . . . 6
4.5.1. 1st paragraph . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5.1. MSRP URI as shared secret . . . . . . . . . . . . . . . . . 6
5.2. Uniqueness of the session-id . . . . . . . . . . . . . . . 7
5.3. Man in the middle . . . . . . . . . . . . . . . . . . . . . 7
5.4. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Holmberg & Blau Expires March 26, 2011 [Page 2]
Internet-Draft MRSP September 2010
1. Introduction
The Message Session Relay Protocol (MSRP) [RFC4975] is designed to
use MSRP relays [RFC4976] as a means for Network Address Translation
(NAT) traversal and policy enforcement.
However, many Session Initiation Protocol (SIP) [RFC3261] networks,
in which MSRP usage is emerging, also contain generic Application
Layer Gateways (ALGs), which might control media relays and perform
tasks such as NAT traversal, performance monitoring, lawful
intercept, address domain bridging, interconnect Service Layer
Agreement (SLA) policy enforcement, etc. An example is the
Interconnect Border Control Function (IBCF) [3GPP.23.228] defined by
the 3rd Generation Partnership Project (3GPP), which controls a media
relay that handles all types of SIP session media (voice, video,
MSRP, etc).
MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], does
not work when such ALGs are present between the SIP/MSRP endpoints,
unless the ALGs act as MSRP Back-To-Back User Agents (B2BUAs). The
reason is that MSRP UAs, when they receive an MSRP message, use MSRP
URI comparision [RFC4975] in order to match the MSRP message to an
MSRP session. That requires consistency between the address
information the the MSRP messages and the MSRP URI carried in the SDP
a=path attribute. The matching will fail if an ALG modifies the
address information of the SDP a=path attribute, but does not perform
the corresponding modification in the MSRP message (which requires
MSRP B2BUA functionaltiy). However, few ALGs implement MSRP B2BUA
functionality, due to complexity and poor scalability.
In order to allow usage of MSRP use in SIP networks where ALGs are
present, this document updates the session matching procedures
defined in RFC 4975. Instead of using the MSRP URI comparision
procedure for matching an incoming MSRP message to an MSRP session,
only the MSRP URI session-id part is used.
The updated procedures defined in this specification allow the usage
of non-MSRP B2BUA ALGs in MSRP peer-to-peer connections, with the
restriction that TLS with name based authentication can not be used
with such ALGs. TLS with fingerprint based authentication can be
used with such ALGs, however. In case TLS name based authentication
is used for peer-to-peer MSRP, or MSRP relays with or without TLS are
used, ALGs still need to implement MSRP B2BUA functionality in order
to prevent MSRP communication from failing.
NOTE: Peer-to-peer MSRP, unprotected or TLS protected with
fingerprint based TLS authentication, are considered to be the most
common choises for MSRP communication in network environments where
Holmberg & Blau Expires March 26, 2011 [Page 3]
Internet-Draft MRSP September 2010
ALGs are deployed.
2. Conventions
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 BCP 14, RFC 2119
[RFC2119].
In this specification the terminology "fingerprint based TLS
authentication" and "name based TLS authentication" are used to refer
to the two cases where:
1 An endpoint use a self-signed TLS certificate and sends a
certificate fingerprint in SDP (fingerprint based TLS
authentication).
2. An endpoint use a certificate from a well known certificate
authority and the other endpoint matches the hostname in the received
TLS communication SubjectAltName parameter towards the hostname
received in the MSRP URI in SDP (name based TLS authentication).
3. Applicability statement
This document updates sections 5.4 (MSRP Connection Model) and 7.3
(Receiving Requests) of [RFC4975]. An MSRP UA MUST implement the
procedures defined in this document in order to interoperate with
remote MSRP UAs in a network where intermediaries might modify the
address information in the MSRP URI of the SDP a=path attribute.
4. Normative update of RFC 4975
4.1. General
This section replaces the text for the 5th and 10th paragraph of
section 5.4 (MSRP Connection Model), the 6th paragraph of section 6
(MSRP URIs), the 1st section of section 6.1 (MSRP URI Comparison) and
the first paragraph of section 7.3 (Receiving Requests), of RFC 4975.
4.2. RFC4975: 5.4 MSRP Connection Model
4.2.1. 5th paragraph
The rules on certificate name matching and CA signing MAY be relaxed
when using TLS peer-to-peer. In this case, a mechanism to ensure
Holmberg & Blau Expires March 26, 2011 [Page 4]
Internet-Draft MRSP September 2010
that the peer used a correct certificate MUST be used. See Section
14.4 for details. It is strongly RECOMMENDED that MSRP endpoints,
when using peer-to-peer MSRP with TLS, use the mechanism described in
section 14.4, in order to be able to establish MSRP sessions in
networks where Application Layer Gateways (ALGs) are deployed.
4.2.2. 10th paragraph
When the first request arrives, its To-Path header field should
contain a URI with a session-id part that the listening element
provided in the SDP for a session. The element that accepted the
connection looks up the session-id part of the URI in the received
request, and determines which session it matches. If a match exists,
the node MUST assume that the host that formed the connection is the
host to which this URI was given. If no match exists, the node MUST
reject the request with a 481 response. The node MUST also check to
make sure the session is not already in use on another connection.
If the session is already in use, it MUST reject the request with a
506 response.
4.3. RFC4975: 6. MSRP URIs
4.3.1. 6th paragraph
The MSRP URI authority field identifies a particular MSRP host
device. If the authority field contains a numeric IP address, it
MUST also contain a port. The MSRP URI session-id field identifies a
particular session at the host device, and a particular value of
session-id is only meaningful in the context of the particular MSRP
host device that created it. An MSRP URI that does not include a
session-id is a reference to an MSRP host device, not to any
particular session at that device.
4.4. RFC4975: 6.1 MSRP URI Comparison
4.4.1. 1st paragraph
In the context of the MSRP protocol, MSRP URI comparisons MUST be
performed according to the following rules:
1. The scheme MUST match. Scheme comparison is case insensitive.
2. If the authority component contains an explicit IP address and/or
port, these are compared for address and port equivalence. Percent-
encoding normalization [10] applies; that is, if any percent-encoded
non-reserved characters exist in the authority component, they must
be decoded prior to comparison. Userinfo parts are not considered
for URI comparison. Otherwise, the authority component is compared
Holmberg & Blau Expires March 26, 2011 [Page 5]
Internet-Draft MRSP September 2010
as a case-insensitive character string.
3. If the port exists explicitly in either URI, then it MUST match
exactly. A URI with an explicit port is never equivalent to another
with no port specified.
4. The session-id part is compared as case sensitive. A URI without
a session-id part is never equivalent to one that includes one.
5. URIs with different "transport" parameters never match. Two URIs
that are identical except for transport are not equivalent. The
transport parameter is case insensitive.
Path normalization [10] is not relevant for MSRP URIs.
This specification does not define any usage for the MSRP URI
comparison rules. However, if an extension mechanism requires MSRP
URI comparison, it MUST use the rules defined in this section.
NOTE: The MSRP URI comparison rules are not used to match MSRP
messages with MSRP sessions. As defined in Section 4.5, only the
MSRP URI session-id part is used for the session matching.
4.5. RFC4975: 7.3 Receiving Requests
4.5.1. 1st paragraph
The receiving endpoint MUST first check the URI in the To-Path to
make sure the request belongs to an existing session. When the
request is received, the To-Path will have exactly one URI, of which
the session-id part MUST map to an existing session that is
associated with the connection on which the request arrived. The
session-id part is compared as case sensitive. If this is not true,
then the receiver MUST generate a 481 error and ignore the request.
Note that if the Failure-Report header field had a value of "no",
then no error report would be sent.
5. Security Considerations
5.1. MSRP URI as shared secret
An MSRP UA compliant to RFC 4975 uses the complete MSRP URI (scheme,
authority, transport, session-id) as a shared secret in order to
determine that an incoming transport connection originates from the
intended peer device. The shared secret needs to be hard to guess,
but in reality only the session-id part with it's minimum 80 bit of
randomness that is hard to guess. Using only the MSRP URI session-id
Holmberg & Blau Expires March 26, 2011 [Page 6]
Internet-Draft MRSP September 2010
part as shared secret is therfore roughly as good as using the
complete URI.
5.2. Uniqueness of the session-id
An MSRP URI session-id value only needs to be unique within the scope
of the MSRP device that created it, so in order to make the
session-id unique there is no need to scope its namespace by the MSRP
URI authority part.
5.3. Man in the middle
In order for a device to insert itself as a man in the middle in the
MSRP communication path, it needs to be in the SIP/SDP signalling
path and modify the SDP MSRP URI information associated with the MSRP
session. When communicating with RFC 4975 compliant MSRP UAs, such
device also needs to implement MSRP B2BUA functionality, since it
needs to modify the MSRP To-Path and From-Path header fields, in
order to match the SDP modification. This insertion of a man in the
middle might not be detected by MSRP end devices.
Due to the update in this specification a man in the middle no longer
need to implement an MSRP B2BUA in order to be transparently in the
MSRP communication path. However, a man in the middle that does not
implement MSRP B2BUA functionality, and does not locally terminate
the TCP/MSRP connection, has very limited impact on the MSRP
connection. It could potentially monitor unprotected MSRP
communication, but any kind of flexible fraudulent endpoint
transparent modification of the MSRP communication is likely much
easier done by using MSRP B2BUA functionality.
5.4. TLS
This specification does not in any way modify the TLS security
procedures for MSRP.
TLS with fingerprint based authentication is not affected by the
presence of intermediaries that modify the SDP MSRP URI information.
TLS with name based authentication can only be used in presence of
ALGs if these implement MSRP B2BUA functionality. Otherwise TLS
authentication will fail. That applies to MSRP in general, and is
not specific to the updates defined in this specification.
6. IANA Considerations
This document updates 5.4, 6, 6.1 and 7.3 of [RFC4975]
Holmberg & Blau Expires March 26, 2011 [Page 7]
Internet-Draft MRSP September 2010
7. Acknowledgements
Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel
Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert,
Ted Hardie and Richard L Barnes for their guidance and input in order
to produce this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007.
8.2. 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.
[3GPP.23.228]
3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 23.228 10.1.0, June 2010.
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg & Blau Expires March 26, 2011 [Page 8]
Internet-Draft MRSP September 2010
Staffan Blau
Ericsson AB
P.O Box 407
Sweden
Email: staffan.blau@ericsson.com
Holmberg & Blau Expires March 26, 2011 [Page 9]
