idnits 2.17.1 draft-ram-straw-b2bua-feature-tag-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3209 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) == Outdated reference: A later version (-18) exists of draft-ietf-siprec-protocol-17 == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-03 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STRAW R. Ravindranath 3 Internet-Draft T. Reddy 4 Intended status: Standards Track G. Salgueiro 5 Expires: January 7, 2016 Cisco 6 July 6, 2015 8 A Session Initiation Protocol (SIP) Feature Tag for Back-to-Back User 9 Agents (B2BUAs) 10 draft-ram-straw-b2bua-feature-tag-00 12 Abstract 14 The User Agent capabilities specification allows Session Initiation 15 Protocol (SIP) User Agents to convey their capabilities and 16 characteristics to other User Agents and to the registrar for its 17 domain. This information is conveyed as parameters of the Contact 18 header field. Amongst those capabilities are the type of User Agent 19 that is available at a SIP Uniform Resource Identifier (URI). This 20 document extends the User Agent capabilities specification to allow 21 indication of Back-to-Back User Agent (B2BUA) types. 23 Status of This Memo 25 This Internet-Draft is submitted 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 January 7, 2016. 40 Copyright Notice 42 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Overview and Motivation . . . . . . . . . . . . . . . . . 2 59 1.2. Document Goals . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 62 3.1. SIP Media Feature Tag for B2BUAs . . . . . . . . . . . . 4 63 3.2. Example Usage of SIP Media Feature Tag for B2BUAs . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 1.1. Overview and Motivation 76 In current Session Initiation Protocol (SIP)[RFC3261] deployments, 77 there are numerous forms of Back-to-Back User Agents (B2BUAs), 78 operating at various levels of transparency and for many differing 79 purposes, and with widely varying behaviors. Some act as pure SIP 80 proxies and only change to the role of B2BUA in order to generate 81 BYEs to terminate dead sessions. Some are full User Agent (UA) 82 stacks with only high-level event and application logic binding the 83 User Agent Server (UAS) and User Agent Client (UAC) sides. Some 84 B2BUAs operate only in the SIP signaling plane, while others 85 participate in the media plane as well. [RFC7092] provides a 86 taxonomy of several common B2BUA roles. 88 As more SIP domains are deployed and interconnected, the probability 89 of a single SIP session crossing multiple B2BUAs at both the 90 signaling and media planes increases significantly. B2BUAs, as 91 described in [RFC7092], modify SIP and Session Description Protocol 92 (SDP) [RFC4566] bodies and are also likely to be on the media path. 93 Such entities, when present in the signaling and/or media path, are 94 likely to take several actions of varying intrusiveness. For 95 example, some B2BUAs modify parts of the SDP body (like IP address, 96 port) and subsequently modify the Real-time Transport Protocol (RTP) 98 [RFC3550] headers as well. Given that a B2BUA can perform such a 99 wide variety of operations, a SIP UA originating a call may wish to 100 know that it is communicating with a B2BUA. The B2BUA type can be 101 used by a SIP UA to selectively disable identity validation 102 procedure. For B2BUAs functioning in the media termination mode or 103 media aware mode modifying the RTP/RTCP headers, the UA can disable 104 peer identity validation procedure. 106 There are specifications like [RFC3840] that allow a SIP User Agent 107 to convey its capabilities and characteristics to other User Agents 108 and to the registrar for its domain. This information is conveyed as 109 parameters in the Contact header field. Amongst those capabilities 110 is the type of UA that is available at a SIP URI. For example, 111 [RFC3840] has the isFocus indicator that is used in SIP signaling for 112 conference servers, a special case of B2BUA. There are also other 113 specifications that allow a B2BUA to indicate its capabilities, such 114 as in Session Recording Protocol [I-D.ietf-siprec-protocol]. 115 However, there may be more types of B2BUAs, as defined in [RFC7092]. 116 Prior to this document there is no support for allowing a UA to 117 indicate its type as a B2BUA. This document extends the User Agent 118 capabilities specification, defined in [RFC3840], to allow a UA to 119 indicate that it is a B2BUA as well as identify the specific type of 120 B2BUA. 122 1.2. Document Goals 124 The goal of this document is not to ensure end-to-end security of SIP 125 calls. The intent of this memo is, if a middlebox (like a B2BUA) 126 declares its existence, then that transparency is likely to improve 127 communication and operation overall. At a minimum, this will provide 128 indication to the caller and callee that it is talking to a B2BUA, 129 which can then decide on what to do with that information. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 The following generalized terms are defined in [RFC3261], Section 6. 139 B2BUA: a SIP Back-to-Back User Agent, which is the logical 140 combination of a User Agent Server (UAS) and User Agent Client 141 (UAC). 143 UAS: a SIP User Agent Server. 145 UAC: a SIP User Agent Client. 147 All of the pertinent B2BUA terminology and taxonomy used in this 148 document is based on [RFC7092]. 150 It is assumed the reader is already familiar with the SIP User Agent 151 capabilities specification defined in [RFC3840]. 153 3. Overview of Operation 155 3.1. SIP Media Feature Tag for B2BUAs 157 This section describes how a B2BUA, as defined in [RFC7092], can 158 convey its capabilities and characteristics to other User Agents and 159 to the registrar for its domain by leveraging and extending the 160 semantics of [RFC3840]. 162 A B2BUA is essentially comprised of two UAs, one acting as a UAC and 163 other a UAS. So, each side of a B2BUA, when it registers, can 164 indicate a subset of capabilities in a REGISTER message, as described 165 in [RFC3840], or in response to an OPTION message or in-dialog 166 messages. Along with those capabilities, the B2BUA MUST also 167 indicate its B2BUA type. This type will be indicated in a REGISTER 168 message to the registrar in the B2BUA domain. It can also be 169 indicated in response to an OPTION message. The B2BUA MUST also 170 indicate the type as part of in-dialog messaging (INVITE, UPDATE, 171 etc.). 173 The syntax of the B2BUA type MUST follow the [RFC3840] syntax, which 174 requires all new feature tags to have "+" followed by "sip.tag_name". 175 The Contact header of SIP messages from the B2BUA MUST have this new 176 feature tag. The tag MUST contain one or more of the below values: 178 sip.isSignalingB2BUA - This feature tag will be used by B2BUAs who 179 act only on the signaling plane (SIP and/or SDP modifying only), 180 as defined in Section 3.1 of [RFC7092]. 182 sip.isMediaRelayB2BUA - This feature tag will be used by B2BUAs 183 who act on the media plane as a media unaware relay, as defined in 184 Section 3.2.1 of [RFC7092]. 186 sip.isMediaAwareRelayB2BUA - This feature tag will be used by 187 B2BUAs who act on the media plane as a media aware relay, as 188 defined in Section 3.2.2 of [RFC7092]. 190 sip.isMediaAwareHeaderModifyingB2BUA - This feature tag will be 191 used by B2BUAs who act on the media plane as a media aware relay, 192 as defined in Section 3.2.2 of [RFC7092] and will likely modify 193 the media headers. 195 sip.isMediaTerminationB2BUA - This feature tag will be used by 196 B2BUAs who act on the media plane and terminate media, as defined 197 in section 3.2.3 of [RFC7092]. 199 3.2. Example Usage of SIP Media Feature Tag for B2BUAs 201 Below is example REGISTER message with the Contact header showing 202 B2BUA type feature tag. In this example, the B2BUA registering is a 203 media aware relay B2BUA. 205 REGISTER sip:example.com SIP/2.0 206 From: sip:user@example.com;tag=asd98 207 To: sip:user@example.com 208 Call-ID: hh89as0d-asd88jkk@host.example.com 209 CSeq: 1 REGISTER 210 Max-Forwards: 70 211 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8 212 Contact: ;audio;video; 213 methods="INVITE,BYE,OPTIONS,ACK,CANCEL"; 214 +sip.isMediaAwareRelayB2BUA 215 Content-Length: 0 217 Note that in the above example the B2BUA, apart from indicating other 218 capabilities it has, also indicates that it is a B2BUA that acts as 219 media aware relay. 221 [[NEEDS WG DISCUSSION: Do we need a separate feature tag for each 222 B2BUA type? It is feasible to do so, however the issue is a B2BUA 223 may likely play multiple roles described in [RFC7092], depending upon 224 call scenario. For example, for one scenario the B2BUA may be simple 225 media relay, for some other scenario, the same B2BUA may play a media 226 aware relay. So its tricky to indicate one specific type. Perhaps 227 should such a B2BUA indicate multiple feature tags?]] 229 4. Security Considerations 231 When present in a REGISTER request, this media feature tag gives 232 information on the set of supported application media streams. It is 233 possible that this information is sensitive, providing insight into 234 the capabilities of a product. These considerations are already 235 discussed in [RFC3840], and those considerations apply here as well. 237 Applications that utilize this media feature tag MUST provide a means 238 for ensuring its integrity. Similarly, the media feature tag should 239 only be trusted as valid when it comes from the user or User Agent 240 described by the feature tag. As a result, mechanisms for conveying 241 the feature tag MUST provide a mechanism for guaranteeing 242 authenticity. If B2BUA advertises any type other than 243 sip.isMediaTerminationB2BUA and sip.isMediaAwareHeaderModification 244 and the identity validation procedure [I-D.ietf-stir-rfc4474bis] by 245 the UA fails then it is an indication that the B2BUA or devices on 246 the other side are misbehaving or have malicious intents. 248 5. IANA Considerations 250 This section registers new media feature tags in the SIP tree, 251 defined in Section 12.1 of [RFC3840]. The following feature tags are 252 defined by this specification. 254 Media feature tag name: sip.isSignalingB2BUA. 256 Summary of the media feature indicated by this tag: This feature 257 tag will be used by B2BUAs who act only on the signaling plane 258 (SIP and/or SDP modifying only), as defined in Section 3.1 of 259 [RFC7092]. 261 Media feature tag name: sip.isMediaRelayB2BUA . 263 Summary of the media feature indicated by this tag: This feature 264 tag will be used by B2BUAs who act on the media plane as a media 265 unaware relay, as defined in Section 3.2.1 of [RFC7092]. 267 Media feature tag name: sip.isMediaAwareRelayB2BUA. 269 Summary of the media feature indicated by this tag: This feature 270 tag will be used by B2BUAs who act on the media plane as a media 271 aware relay, as defined in Section 3.2.2 of [RFC7092]. 273 Media feature tag name: sip.isMediaAwareHeaderModifyingB2BUA. 275 Summary of the media feature indicated by this tag: This feature 276 tag will be used by B2BUAs who act on the media plane as a media 277 aware relay, as defined in Section 3.2.2 of [RFC7092] and will 278 likely modify headers. 280 Media feature tag name: sip.isMediaTerminationB2BUA. 282 Summary of the media feature indicated by this tag: This feature 283 tag will be used by B2BUAs who act on the media plane and 284 terminate media, as defined in Section 3.2.3 of [RFC7092]. 286 Values appropriate for use with all the above feature tags: Boolean. 288 6. Acknowledgments 290 Special thanks to Stephen Farrel, whose IESG review (and subsequent 291 discussion) of [I-D.ietf-straw-b2bua-stun] led to the formulation of 292 this draft. Additionally, the authors would like to thanks all the 293 members of the STRAW WG for their comments and discussion that helped 294 improve this document. 296 7. References 298 7.1. Normative References 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 304 "Indicating User Agent Capabilities in the Session 305 Initiation Protocol (SIP)", RFC 3840, August 2004. 307 7.2. Informative References 309 [I-D.ietf-siprec-protocol] 310 Portman, L., Lum, H., Eckel, C., Johnston, A., and A. 311 Hutton, "Session Recording Protocol", draft-ietf-siprec- 312 protocol-17 (work in progress), July 2015. 314 [I-D.ietf-stir-rfc4474bis] 315 Peterson, J., Jennings, C., and E. Rescorla, 316 "Authenticated Identity Management in the Session 317 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-03 318 (work in progress), March 2015. 320 [I-D.ietf-straw-b2bua-stun] 321 R, R., Reddy, T., and G. Salgueiro, "Session Traversal 322 Utilities for NAT (STUN) Message Handling for Session 323 Initiation Protocol (SIP) Back-to-Back User Agents 324 (B2BUAs)", draft-ietf-straw-b2bua-stun-08 (work in 325 progress), May 2015. 327 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 328 A., Peterson, J., Sparks, R., Handley, M., and E. 329 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 330 June 2002. 332 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 333 Jacobson, "RTP: A Transport Protocol for Real-Time 334 Applications", STD 64, RFC 3550, July 2003. 336 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 337 Description Protocol", RFC 4566, July 2006. 339 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 340 Initiation Protocol (SIP) Back-to-Back User Agents", RFC 341 7092, December 2013. 343 Authors' Addresses 345 Ram Mohan Ravindranath 346 Cisco 347 Cessna Business Park 348 Sarjapur-Marathahalli Outer Ring Road 349 Bangalore, Karnataka 560103 350 India 352 Email: rmohanr@cisco.com 354 Tirumaleswar Reddy 355 Cisco 356 Cessna Business Park, Varthur Hobli 357 Sarjapur Marathalli Outer Ring Road 358 Bangalore, Karnataka 560103 359 India 361 Email: tireddy@cisco.com 363 Gonzalo Salgueiro 364 Cisco Systems, Inc. 365 7200-12 Kit Creek Road 366 Research Triangle Park, NC 27709 367 US 369 Email: gsalguei@cisco.com