SIMPLE Working Group C. Holmberg
Internet-Draft Ericsson
Updates: 4975 (if approved) S. Blau
Intended status: Standards Track Ericsson AB
Expires: December 3, 2010 June 1, 2010
Session Matching Update for the Message Session Relay Protocol (MSRP)
draft-ietf-simple-msrp-sessmatch-06.txt
Abstract
This document updates the session matching procedure defined in
sections 5.4 and 7.3 of RFC 4975, so that an Message Session Relay
Protocol (MSRP) User Agent (UA) only uses the session-id part of the
MSRP URI in order to perform the consistency checks. The update
allows intermediaries, Application Layer Gateways (ALGs), to modify
the address information in the MSRP URI of the Session Description
Protocol (SDP) a=path attribute, without the need for the
intermediaries to terminate and do the correlating modifications in
the associated MSRP messages.
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 December 3, 2010.
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
publication of this document. Please review these documents
Holmberg & Blau Expires December 3, 2010 [Page 1]
Internet-Draft MRSP June 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3
4. Normative update of RFC 4975 . . . . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. RFC4975: 5.4 MSRP Connection Model . . . . . . . . . . . . 4
4.3. RFC4975: 7.3 Receiving Requests . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Holmberg & Blau Expires December 3, 2010 [Page 2]
Internet-Draft MRSP June 2010
1. Introduction
The Message Session Relay Protocol (MSRP) [RFC4975] is designed to
use MSRP relays [RFC4976] as a means for NAT traversal and policy
enforcement.
Many networks in which MSRP usage is emerging also contain generic
Application Layer Gateways (ALGs), which might control media relays
and perform tasks such as performance monitoring, lawful intercept,
address domain bridging, interconnect Service Layer Agreement (SLA)
policy enforcement, etc. An example here 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 Session Initiation Protocol (SIP) session media (voice,
video, MSRP, etc).
The Session Description Protocol (SDP) a=path attribute is used to
establish the routeset for the MSRP messages associated with the
session. Due to the fact that MSRP UAs check consistency between
address information in the MSRP messages and in the SDP a=path
attribute, when an ALG modifies the address information of the a=path
attribute, it forces the media relay of the ALG to act as an MSRP
Back-To-Back User Agent (B2BUA) in order to perform the corresponding
modifications in the MSRP messages, whereas for other media types the
media relay only needs to modify the IP and transport headers.
In order to use general NAT traversal methods and ALGs, this document
updates the session matching procedures defined in section 7.3 of
[RFC4975], so that MSRP endpoints only use the session-id part when
they compare the MSRP URI in the SDP a=path attribute with the
corresponding MSRP URI in MSRP messages.
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].
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 interwork with remote
MSRP UAs in a network where intermediaries might modify the address
information in the MSRP URI of the SDP a=path attribute.
Holmberg & Blau Expires December 3, 2010 [Page 3]
Internet-Draft MRSP June 2010
4. Normative update of RFC 4975
4.1. General
This section replaces the text for the 10th paragraph of section 5.4
(MSRP Connection Model), and the first paragraph of section 7.3
(Receiving Requests), of [RFC4975].
4.2. RFC4975: 5.4 MSRP Connection Model
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: 7.3 Receiving Requests
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, as specified in
Section 6.1 (point 4) of [RFC4975]. 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
Due to the change of the session matching procedure, MSRP endpoints
can only check that the session-id part of the MSRP URI carried in
the MSRP messages matches the session-id which was provided in the
associated SDP a=path attribute. Differing from [RFC4975], the host/
domain part of the MSRP URI is thus not checked. However, since a
man-in-the-middle would in any case be able to modify the domain
information in both the SDP and the MSRP messages, e.g. in order to
insert itself in the MSRP signalling path or to route MSRP messages
to non-intended entities, this does not introduce any new security
risks.
Holmberg & Blau Expires December 3, 2010 [Page 4]
Internet-Draft MRSP June 2010
An MSRP UA treats its session URI as a shared secret to determine
that an incoming transport connection is indeed from the signaled
peer device. An MSRP session URI therefore needs to be hard to
guess. However, [RFC4975] already requires the session-id part of
the URI to be sufficiently hard to guess. Furthermore, the
addressing information in the domain part of the URI is relatively
easy to guess. This makes the difficulty in guessing the session-id
roughly equivalent to the difficulty of guessing the entire URI.
With this update, MSRP entities no longer use the MSRP URI domain
part to perform session matching. But if intermediaries modify the
a=path attribute in the SDP, but do not modify the corresponding
information in the associated MSRP messages, then the endpoints can
determine that such modifications have been performed by comparing
the domain information in the SDP with the domain information in the
MSRP messages. Based on this information, users can trigger some
actions in order to check whether network entities work correctly, or
whether a man-in-the-middle has modified the SDP a=path attribute,
for the same reasons as described earlier.
If an intermediary modifies the host part of an a=path attribute URI,
there might be TLS authentication impacts depending on what type of
certificates are used. If self signed certificates are used, a
modification would not impact TLS, since the host part is not used
for the certificate matching.
If public certificates are used, a modification of the host part
(without performing similar modifications in the associated MSRP
messages) would in most cases trigger a certificate matching error,
since the host part is used in order to match the certificate. This
mismatch would cause the MSRP session setup to fail. This does not
apply if the host part is modified between two MSRP relays, since
relays do not have access to the SDP information and use the To-Path
and From-Path hosts for certificate matching purpose.
6. IANA Considerations
This document updates section 7.3 of [RFC4975]
7. Acknowledgements
Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel
Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto and Shida
Schubert for their guidance and input in order to produce this
document.
Holmberg & Blau Expires December 3, 2010 [Page 5]
Internet-Draft MRSP June 2010
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
[3GPP.23.228]
3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 23.228 10.0.0, March 2010.
Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Staffan Blau
Ericsson AB
P.O Box 407
Sweden
Email: staffan.blau@ericsson.com
Holmberg & Blau Expires December 3, 2010 [Page 6]