idnits 2.17.1 draft-ietf-simple-msrp-sessmatch-01.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 'Intended status' indicated for this document; assuming Proposed Standard 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 (December 17, 2009) is 5244 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) == Unused Reference: 'RFC2606' is defined on line 180, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 183, but no explicit reference was found in the text == Unused Reference: 'RFC4572' is defined on line 186, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) Summary: 2 errors (**), 0 flaws (~~), 6 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 Expires: June 20, 2010 December 17, 2009 8 Session Matching Update for the Message Session Relay Protocol (MSRP) 9 draft-ietf-simple-msrp-sessmatch-01.txt 11 Abstract 13 This document updates the session matching procedure defined in 14 section 7.3 of RFC 4975, so that an MSRP UA only uses the session-id 15 part of the MSRP URI in order to perform the consistency checks. The 16 update allows intermediaries (ALGs) to modify the address information 17 in the MSRP URI of the SDP a=path attribute, without the need for the 18 intermediaries to terminate and do the correlating modifications in 19 the associated MSRP messages. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on June 20, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 3 64 4. Normative update of RFC 4975 . . . . . . . . . . . . . . . . . 3 65 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.2. RFC4975: 7.3 Receiving Requests . . . . . . . . . . . . . . 4 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1. Introduction 77 MSRP [RFC4975] is designed to use MSRP relays [RFC4976] as a means 78 for NAT traversal and policy enforcement. 80 Many networks in which MSRP usage is emerging also contain generic 81 ALGs, which might control media relays and perform tasks such as 82 performance monitoring, lawful intercept, address domain bridging, 83 interconnect SLA policy enforcement, etc. An example here is the 84 Interconnect Border Control Function (IBCF) [3GPP TS23.228] defined 85 by 3GPP, which controls a media relay that handles all types of SIP 86 session media (voice, video, MSRP, etc). 88 Due to the fact that MSRP UAs check consistency between address 89 information in the MSRP messages and in the SDP a=path attribute, 90 this forces the IBCF/media relay to act as an SDP aware MSRP B2BUA, 91 whereas for basically all other UDP and TCP transported based media 92 sessions it can acts as an SDP aware Relay- NAPT - which is much 93 simpler than having to act as an MSRP B2BUA. 95 In order to use general NAT traversal methods and ALGs, this document 96 updates the session matching procedures defined in section 7.3 of 97 [RFC4975], so that MSRP endpoints only use the session-id part when 98 they compare the MSRP URI in the SDP a=path attribute with the 99 corresponding MSRP URI in MSRP messages. 101 2. Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in BCP 14, RFC 2119 106 [RFC2119]. 108 3. Applicability statement 110 This document updates section 7.3 (Receiving Requests) of [RFC4975]. 111 An MSRP UA MUST implement the procedures defined in this document in 112 order to interwork with remote MSRP UAs in a network where 113 intermediaries might modify the address information in the MSRP URI 114 of the SDP a=path attribute. 116 4. Normative update of RFC 4975 117 4.1. General 119 This section defines the updated text for section 7.3 (Receiving 120 Requests) of [RFC4975]. 122 4.2. RFC4975: 7.3 Receiving Requests 124 The receiving endpoint MUST first check the URI in the To-Path to 125 make sure the request belongs to an existing session. When the 126 request is received, the To-Path will have exactly one URI, of which 127 the session-id part MUST map to an existing session that is 128 associated with the connection on which the request arrived. The 129 session-id part is compared as case sensitive, as specified in 130 Section 6.1 (point 4) of [RFC4975]. If this is not true, then the 131 receiver MUST generate a 481 error and ignore the request. Note that 132 if the Failure-Report header field had a value of "no", then no error 133 report would be sent. 135 5. Security Considerations 137 Due to the change of the session matching procedure, MSRP endpoints 138 can only check that the session-id part of the MSRP URI carried in 139 the MSRP messages matches the session-id which was provided in the 140 associated SDP a=path attribute. Differing from [RFC4975], the host/ 141 domain part of the MSRP URI is thus not checked. However, since a 142 man-in-the-middle would in any case be able to modify the domain 143 information in both the SDP and the MSRP messages, this does not 144 introduce any new security risk. 146 Even if MSRP entities do not use the MSRP URI domain part to perform 147 session matching, if the domain information is different in the SDP 148 a=path attribute and the associated MSRP messages the MSRP entities 149 might be able to determine whether one or more intermediaries have 150 been inserted in the message path. With the current session matching 151 procedures, intermediaries would have to modify both the domain part 152 of the MSRP URI both in the SDP a=path attribute and the associated 153 MSRP messages, which means that MSRP entities cannot compare the 154 domain information in order to determine whether intermediaries have 155 been inserted in the message path. 157 When intermediaries are used, MSRP endpoints which uses security 158 mechanisms might not be able to determine whether security is 159 provided end-to-end. However, that issue is generic to all types of 160 media. 162 6. IANA Considerations 164 This document updates section 7.3 of [RFC4975] 166 7. Acknowledgements 168 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 169 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto and Shida 170 Schubert for their guidance and input in order to produce this 171 document. 173 8. References 175 8.1. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, March 1997. 180 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 181 Names", BCP 32, RFC 2606, June 1999. 183 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 184 Initiation Protocol (SIP)", RFC 3323, November 2002. 186 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 187 Transport Layer Security (TLS) Protocol in the Session 188 Description Protocol (SDP)", RFC 4572, July 2006. 190 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 191 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 193 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 194 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 195 September 2007. 197 8.2. Informative References 198 Authors' Addresses 200 Christer Holmberg 201 Ericsson 202 Hirsalantie 11 203 Jorvas 02420 204 Finland 206 Email: christer.holmberg@ericsson.com 208 Staffan Blau 209 Ericsson AB 210 P.O Box 407 211 Sweden 213 Email: staffan.blau@ericsson.com