idnits 2.17.1 draft-ietf-straw-b2bua-taxonomy-03.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 abstract seems to contain references ([RFC5853], [RFC3261]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2013) is 3836 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STRAW Working Group H. Kaplan 3 Internet-Draft Oracle 4 Intended status: Informational V. Pascual 5 Expires: April 21, 2014 Quobis 6 October 18, 2013 8 A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents 9 draft-ietf-straw-b2bua-taxonomy-03 11 Abstract 13 In many SIP deployments, SIP entities exist in the SIP signaling path 14 between the originating and final terminating endpoints, which go 15 beyond the definition of a SIP Proxy, performing functions not 16 defined in standards-track RFCs. The only term for such devices 17 provided in [RFC3261] is for a Back-to-Back User Agent (B2BUA), which 18 is defined as the logical concatenation of a SIP User Agent Server 19 (UAS) and User Agent Client (UAC). 21 There are numerous types of SIP Back-to-Back User Agents, performing 22 different roles in different ways. For Example IP-PBXs, Session 23 Border Controllers (SBC) [RFC5853] and Application Servers (AS). 24 This document identifies several common Back-to-Back User Agent 25 roles, in order to provide taxonomy other documents can use and 26 reference. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 21, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. B2BUA Role Types . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Signaling-plane B2BUA Roles . . . . . . . . . . . . . . . 3 66 3.1.1. Proxy-B2BUA . . . . . . . . . . . . . . . . . . . . . 4 67 3.1.2. Signaling-only . . . . . . . . . . . . . . . . . . . 4 68 3.1.3. SDP-Modifying Signaling-only . . . . . . . . . . . . 4 69 3.2. Media-plane B2BUA Roles . . . . . . . . . . . . . . . . . 5 70 3.2.1. Media-relay . . . . . . . . . . . . . . . . . . . . . 5 71 3.2.2. Media-aware . . . . . . . . . . . . . . . . . . . . . 5 72 3.2.3. Media-termination . . . . . . . . . . . . . . . . . . 6 73 4. Mapping SIP Device Types to B2BUA Roles . . . . . . . . . . . 6 74 4.1. SIP PBXs and Softswitches . . . . . . . . . . . . . . . . 6 75 4.2. Application Servers . . . . . . . . . . . . . . . . . . . 6 76 4.3. Session Border Controllers . . . . . . . . . . . . . . . 6 77 4.4. Transcoders . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.5. Conference Servers . . . . . . . . . . . . . . . . . . . 7 79 4.6. P-CSCF and IBCF Functions . . . . . . . . . . . . . . . . 7 80 4.7. S-CSCF Function . . . . . . . . . . . . . . . . . . . . . 8 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 7. Informative References . . . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 In current SIP deployments, there are numerous forms of Back-to-Back 89 User Agents (B2BUAs), operating at various levels of transparency, 90 and for various purposes, and with widely varying behavior from a SIP 91 protocol perspective. Some act as pure SIP Proxies and only change 92 to the role of B2BUA in order to generate BYEs to terminate dead 93 sessions. Some are full User Agent stacks with only high-level event 94 and application logic binding the User Agent Server (UAS) and User 95 Agent Client (UAC) sides. Some B2BUAs operate only in the SIP 96 signaling plane, while others participate in the media plane as well. 98 As more SIP domains get deployed and interconnected the probability 99 of a single SIP session crossing multiple B2BUA's at both the 100 signaling and media planes increases significantly. 102 This document provides a taxonomy of several common B2BUA roles, so 103 that other documents may refer to them using their given names 104 without re-defining them in each document. 106 2. Terminology 108 The following terms are defined in [RFC3261], Section 6. 110 B2BUA: a SIP Back-to-Back User Agent, which is the logical 111 combination of a User Agent Server (UAS) and User Agent Client (UAC). 113 UAS: a SIP User Agent Server. 115 UAC: a SIP User Agent Client. 117 3. B2BUA Role Types 119 Within the context of this document, the classification refers to a 120 B2BUA role, not a particular system type. A given system type may 121 change its role in the middle of a SIP session, for example when a 122 Stateful Proxy tears-down a session by generating BYEs; or for 123 example when an SBC performs transcoding or REFER termination. 125 Furthermore, this document defines 'B2BUA' following the definition 126 provided in [RFC3261], which is the logical concatenation of a UAS 127 and UAC. A typical centralized conference server, for example, is 128 not a B2BUA because it is the target UAS of multiple UACs, whereby 129 the UACs individually and independently initiate separate SIP 130 sessions to the central conference server. Likewise, a third-party 131 call control transcoder as described in section 3.1 of [RFC5369] is 132 not a B2BUA; whereas an inline (conference bridge) transcoder based 133 on [RFC5370] is a B2BUA. 135 3.1. Signaling-plane B2BUA Roles 137 A Signaling-plane B2BUA is one that operates only on the SIP message 138 protocol layer, and only with SIP messages and headers but not the 139 media itself in any way. This implies that it does not modify 140 Session Description Protocol (SDP) bodies, although it may save them 141 and/or operate on other MIME body types. This category is further 142 subdivided into specific roles as described in this section. 144 It should be noted that there is a large variety of modifications 145 made by "Signaling-plane B2BUA's" 147 3.1.1. Proxy-B2BUA 149 A Proxy-B2BUA is one that appears, from a SIP protocol perspective, 150 to be a SIP Proxy based on [RFC3261] and its extensions, except that 151 it maintains sufficient dialog state to generate in-dialog SIP 152 messages on its own and does so in specific cases. The most common 153 example of this is a SIP Proxy which can generate BYE requests to 154 tear-down a dead session. 156 A Proxy-B2BUA does not modify the received header fields such as the 157 To, From, or Contact, and only modifies the Via and Record-Route 158 header fields following the rules in [RFC3261] and its extensions. 159 If a Proxy-B2BUA can generate in-dialog messages, then it will also 160 need to modify the CSeq header, after it has generated its own. A 161 Proxy-B2BUA neither modifies nor inspects MIME bodies (including 162 SDP), does not have any awareness of media, will forward any Method 163 type, etc. 165 3.1.2. Signaling-only 167 A Signaling-only B2BUA is one that operates at the SIP layer but in 168 ways beyond those of [RFC3261] Proxies, even for normally forwarded 169 requests. For example, such a B2BUA might replace the Contact URI, 170 modify or remove all Via and Record-Route headers, modify the To and 171 From header fields, modify or inspect specific MIME bodies, etc. No 172 SIP header field is guaranteed to be copied from the received request 173 on the UAS side to the generated request on the UAC side. 175 An example of such a B2BUA would be some form of Application Server 176 and PBX, such as a server which locally processes REFER requests and 177 generates new INVITEs on behalf of the REFER's target. Another 178 example would be an [RFC3323] Privacy Service Proxy performing the 179 'header' privacy function. 181 3.1.3. SDP-Modifying Signaling-only 183 An SDP-Modifying Signaling-only B2BUA is one that operates in the 184 signaling plane only and is not in the media path, but does modify 185 SDP bodies and is thus aware of and understands SDP syntax and 186 semantics. Some Application Servers and PBXs act in this role in 187 some cases, for example to remove certain codec choices or merge two 188 media endpoints into one SDP offer. 190 These B2BUAs don't do anything that changes the path that media takes 191 (in particular, they don't insert themselves on the media path), but 192 they may make SDP changes that affect what is sent on the media 193 plane. 195 3.2. Media-plane B2BUA Roles 197 A Media-plane B2BUA is one that operates at both the SIP and media 198 planes, not only on SIP messages but also SDP and potentially Real- 199 time Transport Protocol (RTP) / Real Time Control Protocol (RTCP) 200 [RFC3550] or other media. Such a B2BUA may or may not replace the 201 Contact URI, modify or remove all Via and Record-Route headers, 202 modify the To and From header fields, etc. No SIP header field is 203 guaranteed to be copied from the received request on the UAS side to 204 the generated request on the UAC side, and SDP will also be modified. 206 An example of such a B2BUA would be a Session Border Controller (SBC) 207 performing the functions defined in [RFC5853], a B2BUA transcoder as 208 defined in [RFC5370], a rich-ringtone Application Server, or a 209 recording system. Another example would be an [RFC3323] Privacy 210 Service Proxy performing the 'session' privacy function. 212 Note that a Media-plane B2BUA need not be instantiated in a single 213 physical system, but may be decomposed into separate signaling and 214 media functions. 216 The Media-plane B2BUA category is further subdivided into specific 217 roles as described in this section. 219 3.2.1. Media-relay 221 A B2BUA which performs a media-relay role is one that terminates the 222 media plane at the IP and transport (UDP/TCP) layers on its UAS and 223 UAC sides, but neither modifies nor restricts which forms of payload 224 are carried within the packets. Rather, the payload is transparently 225 copied from one side to the other. Such a role may only support UDP 226 or only TCP or both, as well as other transport types or not. Such a 227 role may involve policing the IP packets to fit within a bandwidth 228 limit, or converting from IPv4 to IPV6 or vice-versa. This is 229 typically similar to a NAT behavior, except a NAT operating in both 230 directions on both the source and destination information; it is 231 often found as the default behavior in SBCs. 233 3.2.2. Media-aware 235 A B2BUA which performs a media-aware role is similar to a media- 236 relay except that it inspects and potentially modifies the payload 237 carried in UDP or TCP (as it could be [RFC3550] RTP or RTCP) but it 238 does not at a codec or higher layer. An example of such a role is an 239 [RFC3711] SRTP terminator, which does not need to care about the RTP 240 payload but does care about the RTP header; or a device which 241 monitors RTCP for QoS information; or a device which multiplexes/de- 242 multiplexes RTP and RTCP packets on the same 5-tuple. 244 3.2.3. Media-termination 246 A B2BUA which performs a media-termination role is one that operates 247 at the media payload layer, such as RTP/RTCP codec or MSRP message 248 layer and higher. Such a role may only terminate/generate specific 249 RTP media, such as [RFC4733] DTMF packets, or it may convert between 250 media codecs, or act as a Back-To-Back [RFC4975] MSRP agent. This is 251 the role performed by transcoders, [RFC5366] based conference 252 servers, etc. 254 4. Mapping SIP Device Types to B2BUA Roles 256 Although the B2BUA roles defined previously do not define system 257 types, as discussed in section 3, some discussion of what common 258 system types perform which defined roles may be appropriate. This 259 section provides such a 'mapping' for general cases, to aid in 260 understanding of the roles. 262 4.1. SIP PBXs and Softswitches 264 SIP-enabled Private Branch eXchanges (SIP PBXs) and Softswitches are 265 market category terms, and not specified in any standard. In general 266 they can perform every role described in this document at any given 267 time, based on their architecture or local policy. Some are based on 268 architectures that make them the equivalent of a SIP UAS and UAC 269 connected with a logical PRI loopback; others are built as a SIP 270 Proxy core with optional modules to "do more". 272 4.2. Application Servers 274 Application Servers are a broad marketing term, and not specified in 275 any standard in general, although 3GPP and other organizations 276 specify some specific Application Server functions and behaviors. 277 Common examples of Application Servers functions are message-waiting 278 indication (MWI), find-me-follow-me services, privacy services, call- 279 center Automatic Call Distributor (ACD) services, call screening, and 280 Voice Call Continuity (VCC) services. Some only operate in the 281 signaling plane in either Proxy-B2BUA or Signaling- only B2BUA roles; 282 others operate as full Media-termination B2BUAs, such as when 283 providing Interactive Voice Recognition (IVR), rich-ringtone or 284 integrated voicemail services. 286 4.3. Session Border Controllers 288 Session Border Controllers (SBCs) are a market category term, and not 289 specified in any standard. Some of the common functions performed by 290 SBCs are described in [RFC5853], but in general they can perform 291 every role described in this document at any given time, based on 292 local policy. By default, most SBCs are either Media-relay or Media- 293 aware B2BUAs, and replace the Contact URI, remove the Via and Record- 294 Route headers, modify the Call-ID, To, From, and various other 295 headers, and modify SDP. Some SBCs remove all headers, all bodies, 296 and reject all Method types unless explicitly allowed by local 297 policy; other SBCs pass all such elements through unless explicitly 298 forbidden by local policy. 300 4.4. Transcoders 302 Transcoders perform the function of transcoding one audio or video 303 media codec type to another, such as G.711 to G.729. As such they 304 perform the Media-termination role, although they may only terminate 305 media in specific cases of codec mismatch between the two ends. 306 Although [RFC5369] and [RFC5370] define two types of SIP Transcoders, 307 in practice a popular variant of the [RFC5370] inline conference 308 bridge model is to behave as a SIP B2BUA without using the resource- 309 list mechanism, but rather simply route a normal INVITE request 310 through a B2BUA with built-in transcoder. SIP Transcoders 311 architectures are based on everything from SIP media servers, to 312 SBCs, to looped-back Time Division Multiplexing (TDM) gateways, and 313 thus run the gamut from replacing only specific headers/bodies and 314 SDP content needed to perform their function, to replacing almost all 315 SIP headers and SDP content. Some transcoders save and remove SDP 316 offers in INVITEs from the UAC, and wait for an offer in the response 317 from the UAS, similar to a 3PCC model; others just insert additional 318 codecs in SDP offers and only transcode if the inserted codec(s) are 319 selected in the answer. 321 4.5. Conference Servers 323 In general Conference Servers do not fall under the term 'B2BUA' as 324 defined by this document, since typically they involve multiple SIP 325 UACs initiating independent SIP sessions to the single conference 326 server UAS. However, a conference server supporting [RFC5366], 327 whereby the received INVITE triggers the conference focus UAS to 328 initiate multiple INVITEs as a UAC, would be in a Media-termination 329 B2BUA role when performing that function. 331 4.6. P-CSCF and IBCF Functions 333 Proxy-Call Session Control Function (P-CSCF) and Interconnection 334 Border Control Function (IBCF) are functions defined by 3GPP [IMS] 335 standards, and when coupled with the IMS media-plane gateways (IMS 336 Access Gateway IMS-AGW, Transition Gateway TrGW, etc.) typically form 337 a logical Media-relay or Media-aware B2BUA role. 339 4.7. S-CSCF Function 341 Serving-Call Session Control Function (S-CSCF) is a function defined 342 by 3GPP [IMS] standards, and typically follows a Proxy-B2BUA role. 344 5. Security Considerations 346 Security risks are specific to each type of B2BUA, so little can be 347 said in general. Of course, adding extra systems in the 348 communication path creates extra points of attack, reduces or 349 eliminates the ability to perform end to end encryption, decreases 350 the privacy of SIP communications, and complicates trust models. 351 Thus, every B2BUA design requires particular attention to security 352 analysis. 354 A few general points can be made: 356 1. The B2BUA processing of SDP and media packets is an impediment to 357 deployment of end-to-end SRTP, and reduces the ability to deploy 358 new, stronger forms of SRTP key exchange. 360 2. The ability for B2BUAs to modify any SIP header field value and 361 body impacts the ability to deploy SIP Identity and message 362 integrity. 364 3. The management and configuration mechanisms of B2BUAs are a 365 tempting point of attack, and must be strongly defended. 367 Further security considerations related to the functionality 368 described in this document are addressed in the relevant references. 370 6. IANA Considerations 372 This document makes no request of IANA. 374 7. Informative References 376 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 377 A., Peterson, J., Sparks, R., Handley, M., and E. 378 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 379 June 2002. 381 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 382 Initiation Protocol (SIP)", RFC 3323, November 2002. 384 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 385 Jacobson, "RTP: A Transport Protocol for Real-Time 386 Applications", STD 64, RFC 3550, July 2003. 388 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 389 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 390 RFC 3711, March 2004. 392 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 393 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 394 December 2006. 396 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 397 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 399 [RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment 400 Using Request-Contained Lists in the Session Initiation 401 Protocol (SIP)", RFC 5366, October 2008. 403 [RFC5369] Camarillo, G., "Framework for Transcoding with the Session 404 Initiation Protocol (SIP)", RFC 5369, October 2008. 406 [RFC5370] Camarillo, G., "The Session Initiation Protocol (SIP) 407 Conference Bridge Transcoding Model", RFC 5370, October 408 2008. 410 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 411 A., and M. Bhatia, "Requirements from Session Initiation 412 Protocol (SIP) Session Border Control (SBC) Deployments", 413 RFC 5853, April 2010. 415 [IMS] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2, 3GPP TS 416 23.228", 2013. 418 Authors' Addresses 420 Hadriel Kaplan 421 Oracle 423 Email: hadriel.kaplan@oracle.com 425 Victor Pascual 426 Quobis 428 Email: victor.pascual@quobis.com