SIMPLE Working Group                                         C. Holmberg
Internet-Draft                                                  Ericsson
Updates: RFC 4975                                                S. Blau
(if approved)                                                Ericsson AB
Expires: May 22, 2010                                  November 18, 2009


 Sesstion Matching Update for the Message Session Relay Protocol (MSRP)
              draft-holmberg-simple-msrp-sessmatch-00.txt

Abstract

   This document updates the session matching procedure defined in
   section 7.3 of RFC 4975, so that an MSRP UA only uses the session-id
   part of the MSRP URI in order to perform the consistency checks.  The
   update allows intermediate network entities (ALGs) to modify the
   address information in the MSRP URI of the SDP a=path attribute,
   without the need for the intermediate 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 May 22, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Holmberg & Blau           Expires May 22, 2010                  [Page 1]


Internet-Draft                    MRSP                     November 2009


   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  . . . . . . . . . . . . . . . . . 3
     4.1.  General . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.2.  RFC4975: 7.3 Receiving Requests . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 5

























Holmberg & Blau           Expires May 22, 2010                  [Page 2]


Internet-Draft                    MRSP                     November 2009


1.  Introduction

   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
   ALGs, which might control media relays and perform tasks such as
   performance monitoring, lawful intercept, address domain bridging,
   interconnect SLA policy enforcement, etc.  An example here is the
   Interconnect Border Control Function (IBCF) [3GPP TS23.228] defined
   by 3GPP, which controls a media relay that handles all types of SIP
   session media (voice, video, MSRP, etc).

   Due to the fact that MSRP UAs check consistence between address
   information in the MSRP messages and in the SDP a=path attribute,
   this forces the IBCF/media relay to act as an SDP aware MSRP B2BUA,
   whereas for basically all other UDP and TCP transported based media
   sessions it can acts as an SDP aware Relay- NAPT - which is much
   simpler than having to act as an MSRP B2BUA.

   In order to use general NAT traversal methods, an 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 section 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
   intermediate network entities might modify the address information in
   the MSRP URI of the SDP a=path attribute.


4.  Normative update of RFC 4975






Holmberg & Blau           Expires May 22, 2010                  [Page 3]


Internet-Draft                    MRSP                     November 2009


4.1.  General

   This section defines the updated text for section 7.3 (Receiving
   Requests) of [RFC4975].

4.2.  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 component MUST map to an existing session that is
   associated with the connection on which the request arrived.  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.

   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 intermediates have
   been inserted in the message path.  With the current session matching
   procedures, intermediates 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 intermediates have
   been inserted in the message path.

   When intermediates are used, MSRP endpoints which uses security
   mechanisms might not be able to determine whether security is
   provided end-to-end.  However, that issue is generic to all types of
   media.


6.  IANA Considerations

   This document updates section 7.3 of [RFC4975]



Holmberg & Blau           Expires May 22, 2010                  [Page 4]


Internet-Draft                    MRSP                     November 2009


7.  Acknowledgements

   Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel
   Kaplan, Adam Roach and Robert Sparks 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.

   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
              Names", BCP 32, RFC 2606, June 1999.

   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
              Initiation Protocol (SIP)", RFC 3323, November 2002.

   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572, July 2006.

   [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


Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com








Holmberg & Blau           Expires May 22, 2010                  [Page 5]


Internet-Draft                    MRSP                     November 2009


   Staffan Blau
   Ericsson AB
   P.O Box 407
   Sweden

   Email: staffan.blau@ericsson.com













































Holmberg & Blau           Expires May 22, 2010                  [Page 6]