idnits 2.17.1 draft-ietf-simple-msrp-sessmatch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC4975, but the abstract doesn't seem to directly say this. It does mention RFC4975 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4975, updated by this document, for RFC5378 checks: 2003-05-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 18, 2010) is 5209 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Updates: RFC 4975 S. Blau 5 (if approved) Ericsson AB 6 Intended status: Standards Track January 18, 2010 7 Expires: July 22, 2010 9 Session Matching Update for the Message Session Relay Protocol (MSRP) 10 draft-ietf-simple-msrp-sessmatch-02.txt 12 Abstract 14 This document updates the session matching procedure defined in 15 sections 5.4 and 7.3 of RFC 4975, so that an Message Session Relay 16 Protocol (MSRP) User Agent (UA) only uses the session-id part of the 17 MSRP URI in order to perform the consistency checks. The update 18 allows intermediaries, Application Layer Gateways (ALGs), to modify 19 the address information in the MSRP URI of the Session Description 20 Protocol (SDP) a=path attribute, without the need for the 21 intermediaries to terminate and do the correlating modifications in 22 the associated MSRP messages. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on July 22, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 66 4. Normative update of RFC 4975 . . . . . . . . . . . . . . . . . 4 67 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.2. RFC4975: 5.4 MSRP Connection Model . . . . . . . . . . . . 4 69 4.3. RFC4975: 7.3 Receiving Requests . . . . . . . . . . . . . . 4 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 The Message Session Relay Protocol (MSRP) [RFC4975] is designed to 81 use MSRP relays [RFC4976] as a means for NAT traversal and policy 82 enforcement. 84 Many networks in which MSRP usage is emerging also contain generic 85 Application Layer Gateways (ALGs), which might control media relays 86 and perform tasks such as performance monitoring, lawful intercept, 87 address domain bridging, interconnect Service Layer Agreement (SLA) 88 policy enforcement, etc. An example here is the Interconnect Border 89 Control Function (IBCF) [3GPP.23.228] defined by the 3rd Generation 90 Partnership Project (3GPP), which controls a media relay that handles 91 all types of Session Initiation Protocol (SIP) session media (voice, 92 video, MSRP, etc). 94 Due to the fact that MSRP UAs check consistency between address 95 information in the MSRP messages and in the Session Description 96 Protocol (SDP) a=path attribute, this forces the IBCF/media relay to 97 act as an SDP aware MSRP Back-To-Back User Agent (B2BUA), whereas for 98 basically all other UDP and TCP transported based media sessions it 99 can acts as an SDP aware B2BUA, which is much simpler than having to 100 act as an MSRP B2BUA. 102 In order to use general NAT traversal methods and ALGs, this document 103 updates the session matching procedures defined in section 7.3 of 104 [RFC4975], so that MSRP endpoints only use the session-id part when 105 they compare the MSRP URI in the SDP a=path attribute with the 106 corresponding MSRP URI in MSRP messages. 108 2. Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in BCP 14, RFC 2119 113 [RFC2119]. 115 3. Applicability statement 117 This document updates sections 5.4 (MSRP Connection Model) and 7.3 118 (Receiving Requests) of [RFC4975]. An MSRP UA MUST implement the 119 procedures defined in this document in order to interwork with remote 120 MSRP UAs in a network where intermediaries might modify the address 121 information in the MSRP URI of the SDP a=path attribute. 123 4. Normative update of RFC 4975 125 4.1. General 127 This section replaces the text for the ninth paragraph of section 5.4 128 (MSRP Connection Model), and the first paragraph of section 7.3 129 (Receiving Requests), of [RFC4975]. 131 4.2. RFC4975: 5.4 MSRP Connection Model 133 When the first request arrives, its To-Path header field should 134 contain a URI with a session-id part that the listening element 135 provided in the SDP for a session. The element that accepted the 136 connection session-id part of the URI in the received request. If a 137 match exists, the node MUST assume that the host that formed the 138 connection is the host to which this URI was given. If no match 139 exists, the node MUST reject the request with a 481 response. The 140 node MUST also check to make sure the session is not already in use 141 on another connection. If the session is already in use, it MUST 142 reject the request with a 506 response. 144 4.3. RFC4975: 7.3 Receiving Requests 146 The receiving endpoint MUST first check the URI in the To-Path to 147 make sure the request belongs to an existing session. When the 148 request is received, the To-Path will have exactly one URI, of which 149 the session-id part MUST map to an existing session that is 150 associated with the connection on which the request arrived. The 151 session-id part is compared as case sensitive, as specified in 152 Section 6.1 (point 4) of [RFC4975]. If this is not true, then the 153 receiver MUST generate a 481 error and ignore the request. Note that 154 if the Failure-Report header field had a value of "no", then no error 155 report would be sent. 157 5. Security Considerations 159 Due to the change of the session matching procedure, MSRP endpoints 160 can only check that the session-id part of the MSRP URI carried in 161 the MSRP messages matches the session-id which was provided in the 162 associated SDP a=path attribute. Differing from [RFC4975], the host/ 163 domain part of the MSRP URI is thus not checked. However, since a 164 man-in-the-middle would in any case be able to modify the domain 165 information in both the SDP and the MSRP messages, this does not 166 introduce any new security risk. 168 An MSRP UA treats its session URI as a shared secret to determine 169 that an incoming transport connection is indeed from the signaled 170 peer device. An MSRP session URI therefore needs to be hard to 171 guess. However, [RFC4975] already requires the session-id part of 172 the URI to be sufficiently hard to guess. Furthermore, the 173 addressing information in the domain part of the URI is relatively 174 easy to guess. This makes the difficulty in guessing the session-id 175 roughly equivalent to the difficulty of guessing the entire URI. 177 Even if MSRP entities do not use the MSRP URI domain part to perform 178 session matching, if the domain information is different in the SDP 179 a=path attribute and the associated MSRP messages the MSRP entities 180 might be able to determine whether one or more intermediaries have 181 been inserted in the message path. With the current session matching 182 procedures, intermediaries would have to modify both the domain part 183 of the MSRP URI both in the SDP a=path attribute and the associated 184 MSRP messages, which means that MSRP entities cannot compare the 185 domain information in order to determine whether intermediaries have 186 been inserted in the message path. 188 6. IANA Considerations 190 This document updates section 7.3 of [RFC4975] 192 7. Acknowledgements 194 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 195 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto and Shida 196 Schubert for their guidance and input in order to produce this 197 document. 199 8. References 201 8.1. Normative References 203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 204 Requirement Levels", BCP 14, RFC 2119, March 1997. 206 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 207 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 209 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 210 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 211 September 2007. 213 8.2. Informative References 215 [3GPP.23.228] 216 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 217 TS 23.228 5.15.0, June 2006. 219 Authors' Addresses 221 Christer Holmberg 222 Ericsson 223 Hirsalantie 11 224 Jorvas 02420 225 Finland 227 Email: christer.holmberg@ericsson.com 229 Staffan Blau 230 Ericsson AB 231 P.O Box 407 232 Sweden 234 Email: staffan.blau@ericsson.com