idnits 2.17.1 draft-ietf-simple-msrp-sessmatch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 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 (April 8, 2010) is 5126 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: 4975 (if approved) S. Blau 5 Intended status: Standards Track Ericsson AB 6 Expires: October 10, 2010 April 8, 2010 8 Session Matching Update for the Message Session Relay Protocol (MSRP) 9 draft-ietf-simple-msrp-sessmatch-04.txt 11 Abstract 13 This document updates the session matching procedure defined in 14 sections 5.4 and 7.3 of RFC 4975, so that an Message Session Relay 15 Protocol (MSRP) User Agent (UA) only uses the session-id part of the 16 MSRP URI in order to perform the consistency checks. The update 17 allows intermediaries, Application Layer Gateways (ALGs), to modify 18 the address information in the MSRP URI of the Session Description 19 Protocol (SDP) a=path attribute, without the need for the 20 intermediaries to terminate and do the correlating modifications in 21 the associated MSRP messages. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 10, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 60 4. Normative update of RFC 4975 . . . . . . . . . . . . . . . . . 4 61 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. RFC4975: 5.4 MSRP Connection Model . . . . . . . . . . . . 4 63 4.3. RFC4975: 7.3 Receiving Requests . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The Message Session Relay Protocol (MSRP) [RFC4975] is designed to 75 use MSRP relays [RFC4976] as a means for NAT traversal and policy 76 enforcement. 78 Many networks in which MSRP usage is emerging also contain generic 79 Application Layer Gateways (ALGs), which might control media relays 80 and perform tasks such as performance monitoring, lawful intercept, 81 address domain bridging, interconnect Service Layer Agreement (SLA) 82 policy enforcement, etc. An example here is the Interconnect Border 83 Control Function (IBCF) [3GPP.23.228] defined by the 3rd Generation 84 Partnership Project (3GPP), which controls a media relay that handles 85 all types of Session Initiation Protocol (SIP) session media (voice, 86 video, MSRP, etc). 88 Due to the fact that MSRP UAs check consistency between address 89 information in the MSRP messages and in the Session Description 90 Protocol (SDP) a=path attribute, this forces the IBCF/media relay to 91 act as an SDP aware MSRP Back-To-Back User Agent (B2BUA), whereas for 92 basically all other UDP and TCP transported based media sessions it 93 can act as an SDP aware B2BUA, which is much simpler than having to 94 act as an MSRP B2BUA. 96 In order to use general NAT traversal methods and ALGs, this document 97 updates the session matching procedures defined in section 7.3 of 98 [RFC4975], so that MSRP endpoints only use the session-id part when 99 they compare the MSRP URI in the SDP a=path attribute with the 100 corresponding MSRP URI in MSRP messages. 102 2. Conventions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in BCP 14, RFC 2119 107 [RFC2119]. 109 3. Applicability statement 111 This document updates sections 5.4 (MSRP Connection Model) and 7.3 112 (Receiving Requests) of [RFC4975]. An MSRP UA MUST implement the 113 procedures defined in this document in order to interwork with remote 114 MSRP UAs in a network where intermediaries might modify the address 115 information in the MSRP URI of the SDP a=path attribute. 117 4. Normative update of RFC 4975 119 4.1. General 121 This section replaces the text for the 10th paragraph of section 5.4 122 (MSRP Connection Model), and the first paragraph of section 7.3 123 (Receiving Requests), of [RFC4975]. 125 4.2. RFC4975: 5.4 MSRP Connection Model 127 When the first request arrives, its To-Path header field should 128 contain a URI with a session-id part that the listening element 129 provided in the SDP for a session. The element that accepted the 130 connection looks up the session-id part of the URI in the received 131 request, and determines which session it matches. If a match exists, 132 the node MUST assume that the host that formed the connection is the 133 host to which this URI was given. If no match exists, the node MUST 134 reject the request with a 481 response. The node MUST also check to 135 make sure the session is not already in use on another connection. 136 If the session is already in use, it MUST reject the request with a 137 506 response. 139 4.3. RFC4975: 7.3 Receiving Requests 141 The receiving endpoint MUST first check the URI in the To-Path to 142 make sure the request belongs to an existing session. When the 143 request is received, the To-Path will have exactly one URI, of which 144 the session-id part MUST map to an existing session that is 145 associated with the connection on which the request arrived. The 146 session-id part is compared as case sensitive, as specified in 147 Section 6.1 (point 4) of [RFC4975]. If this is not true, then the 148 receiver MUST generate a 481 error and ignore the request. Note that 149 if the Failure-Report header field had a value of "no", then no error 150 report would be sent. 152 5. Security Considerations 154 Due to the change of the session matching procedure, MSRP endpoints 155 can only check that the session-id part of the MSRP URI carried in 156 the MSRP messages matches the session-id which was provided in the 157 associated SDP a=path attribute. Differing from [RFC4975], the host/ 158 domain part of the MSRP URI is thus not checked. However, since a 159 man-in-the-middle would in any case be able to modify the domain 160 information in both the SDP and the MSRP messages, this does not 161 introduce any new security risk. 163 An MSRP UA treats its session URI as a shared secret to determine 164 that an incoming transport connection is indeed from the signaled 165 peer device. An MSRP session URI therefore needs to be hard to 166 guess. However, [RFC4975] already requires the session-id part of 167 the URI to be sufficiently hard to guess. Furthermore, the 168 addressing information in the domain part of the URI is relatively 169 easy to guess. This makes the difficulty in guessing the session-id 170 roughly equivalent to the difficulty of guessing the entire URI. 172 MSRP entities do not use the MSRP URL domain part to perform session 173 matching. If intermediaries modify the "a=path" attribute in the 174 SDP, but do not modify the corresponding information in the 175 associated MSRP messages, then the endpoints can determine that such 176 modifications have been performed by comparing the domain information 177 in the SDP with the domain information in the MSRP messages. 179 If an intermediary modifies the host part of an a=path attribute URI, 180 there might be TLS authentication impacts depending on what type of 181 certificates are used. If self signed certificates are used, a 182 modification would not impact TLS, since the host part is not used 183 for the certificate matching. 185 If public certificates are used, a modification of the host part 186 (without performing similar modifications in the associated MSRP 187 messages) would in most cases trigger a certificate matching error, 188 since the host part is used in order to match the certificate. This 189 mismatch would cause the MSRP session setup to fail. This does not 190 apply if the host part is modified between two MSRP relays, since 191 relays do not have access to the SDP information and use the To-Path 192 and From-Path hosts for certificate matching purpose. 194 6. IANA Considerations 196 This document updates section 7.3 of [RFC4975] 198 7. Acknowledgements 200 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 201 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto and Shida 202 Schubert for their guidance and input in order to produce this 203 document. 205 8. References 206 8.1. Normative References 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, March 1997. 211 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 212 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 214 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 215 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 216 September 2007. 218 8.2. Informative References 220 [3GPP.23.228] 221 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 222 TS 23.228 10.0.0, March 2010. 224 Authors' Addresses 226 Christer Holmberg 227 Ericsson 228 Hirsalantie 11 229 Jorvas 02420 230 Finland 232 Email: christer.holmberg@ericsson.com 234 Staffan Blau 235 Ericsson AB 236 P.O Box 407 237 Sweden 239 Email: staffan.blau@ericsson.com