SIMPLE Working Group C. Holmberg Internet-Draft Ericsson Updates: 4975 (if approved) S. Blau Intended status: Standards Track Ericsson AB Expires: October 10, 2010 April 8, 2010 Session Matching Update for the Message Session Relay Protocol (MSRP) draft-ietf-simple-msrp-sessmatch-04.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 October 10, 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 October 10, 2010 [Page 1]
Internet-Draft MRSP April 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 October 10, 2010 [Page 2]
Internet-Draft MRSP April 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). Due to the fact that MSRP UAs check consistency between address information in the MSRP messages and in the Session Description Protocol (SDP) a=path attribute, this forces the IBCF/media relay to act as an SDP aware MSRP Back-To-Back User Agent (B2BUA), whereas for basically all other UDP and TCP transported based media sessions it can act as an SDP aware B2BUA, which is much simpler than having to act as an MSRP B2BUA. 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 October 10, 2010 [Page 3]
Internet-Draft MRSP April 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, this does not introduce any new security risk. An MSRP UA treats its session URI as a shared secret to determine Holmberg & Blau Expires October 10, 2010 [Page 4]
Internet-Draft MRSP April 2010 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. MSRP entities do not use the MSRP URL domain part to perform session matching. 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. 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. 8. References Holmberg & Blau Expires October 10, 2010 [Page 5]
Internet-Draft MRSP April 2010 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 October 10, 2010 [Page 6]
