One document matched: draft-ietf-simple-msrp-sessmatch-03.txt

Differences from draft-ietf-simple-msrp-sessmatch-02.txt

SIMPLE Working Group                                         C. Holmberg
Internet-Draft                                                  Ericsson
Updates: 4975 (if approved)                                      S. Blau
Intended status: Standards Track                             Ericsson AB
Expires: September 6, 2010                                 March 5, 2010


 Session Matching Update for the Message Session Relay Protocol (MSRP)
                draft-ietf-simple-msrp-sessmatch-03.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), 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 September 6, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the



Holmberg & Blau         Expires September 6, 2010               [Page 1]

Internet-Draft                    MRSP                        March 2010


   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
   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 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 September 6, 2010               [Page 2]

Internet-Draft                    MRSP                        March 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 September 6, 2010               [Page 3]

Internet-Draft                    MRSP                        March 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 September 6, 2010               [Page 4]

Internet-Draft                    MRSP                        March 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.

   Even if MSRP entities do not use the MSRP URI domain part to perform
   session matching, if the domain information is different in the SDP
   a=path attribute and the associated MSRP messages the MSRP entities
   might be able to determine whether one or more intermediaries have
   been inserted in the message path.  With the current session matching
   procedures, intermediaries would have to modify both the domain part
   of the MSRP URI both in the SDP a=path attribute and the associated
   MSRP messages, which means that MSRP entities cannot compare the
   domain information in order to determine whether intermediaries have
   been inserted in the message path.

   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
   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
   From-Path URI host for the certificate matching.


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 September 6, 2010               [Page 5]

Internet-Draft                    MRSP                        March 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 5.15.0, June 2006.


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 September 6, 2010               [Page 6]