idnits 2.17.1 draft-ietf-sipping-sbc-funcs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1071. 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 Copyright Line does not match the current year -- 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 (March 25, 2008) is 5877 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4474 (ref. '3') (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '6') (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group J. Hautakorpi, Ed. 3 Internet-Draft G. Camarillo 4 Intended status: Informational Ericsson 5 Expires: September 26, 2008 R. Penfield 6 Acme Packet 7 A. Hawrylyshen 8 Ditech Networks Inc. 9 M. Bhatia 10 3CLogic 11 March 25, 2008 13 Requirements from SIP (Session Initiation Protocol) Session Border 14 Control Deployments 15 draft-ietf-sipping-sbc-funcs-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 26, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document describes functions implemented in Session Initiation 49 Protocol (SIP) intermediaries known as Session Border Controllers 50 (SBCs). The goal of this document is to describe the commonly 51 provided functions of SBCs. A special focus is given to those 52 practices that are viewed to be in conflict with SIP architectural 53 principles. This document also explores the underlying requirements 54 of network operators that have led to the use of these functions and 55 practices in order to identify protocol requirements and determine 56 whether those requirements are satisfied by existing specifications 57 or additional standards work is required. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Background on SBCs . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Peering Scenario . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Access Scenario . . . . . . . . . . . . . . . . . . . . . 6 65 3. Functions of SBCs . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 8 67 3.1.1. General Information and Requirements . . . . . . . . . 8 68 3.1.2. Architectural Issues . . . . . . . . . . . . . . . . . 8 69 3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.2. Media Traffic Management . . . . . . . . . . . . . . . . . 10 71 3.2.1. General Information and Requirements . . . . . . . . . 10 72 3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 11 73 3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.3. Fixing Capability Mismatches . . . . . . . . . . . . . . . 12 75 3.3.1. General Information and Requirements . . . . . . . . . 12 76 3.3.2. Architectural Issues . . . . . . . . . . . . . . . . . 13 77 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 13 78 3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 14 79 3.4.1. General Information and Requirements . . . . . . . . . 14 80 3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 15 81 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15 82 3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 16 83 3.5.1. General Information and Requirements . . . . . . . . . 16 84 3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 17 85 3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 17 86 3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 18 87 3.6.1. General Information and Requirements . . . . . . . . . 18 88 3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 19 89 3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 19 90 3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 19 91 3.7.1. General Information and Requirements . . . . . . . . . 19 92 3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 20 93 3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 20 94 4. Derived Requirements for Future SIP Standardization Work . . . 21 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 100 8.2. Informational References . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 102 Intellectual Property and Copyright Statements . . . . . . . . . . 25 104 1. Introduction 106 In the past few years there has been a rapid adoption of the Session 107 Initiation Protocol (SIP) [1] and deployment of SIP-based 108 communications networks. This has often outpaced the development and 109 implementation of protocol specifications to meet network operator 110 requirements. This has led to the development of proprietary 111 solutions. Often, these proprietary solutions are implemented in 112 network intermediaries known in the marketplace as Session Border 113 Controllers (SBCs) because they typically are deployed at the border 114 between two networks. The reason for this is that network policies 115 are typically enforced at the edge of the network. 117 Even though many SBCs currently behave badly in a sense that they 118 break end-to-end security and impact feature negotiations, there is 119 clearly a market for them. Network operators need many of the 120 features current SBCs provide and often there are no standard 121 mechanisms available to provide them. 123 The purpose of this document is to describe functions implemented in 124 SBCs. A special focus is given to those practices that are 125 conflicting with SIP architectural principles in some way. The 126 document also explores the underlying requirements of network 127 operators that have led to the use of these functions and practices 128 in order to identify protocol requirements and determine whether 129 those requirements are satisfied by existing specifications or 130 additional standards work is required. 132 2. Background on SBCs 134 The term SBC is relatively non-specific, since it is not standardized 135 or defined anywhere. Nodes that may be referred to as SBCs but do 136 not implement SIP are outside the scope of this document. 138 SBCs usually sit between two service provider networks in a peering 139 environment, or between an access network and a backbone network to 140 provide service to residential and/or enterprise customers. They 141 provide a variety of functions to enable or enhance session-based 142 multi-media services (e.g., Voice over IP). These functions include: 143 a) perimeter defense (access control, topology hiding, and DoS 144 prevention and detection); b) functionality not available in the 145 endpoints (NAT traversal, protocol interworking or repair); and c) 146 network management (traffic monitoring, management, and QoS). Some 147 of these functions may also get integrated into other SIP elements 148 (like pre-paid platforms, 3GPP P-CSCF [5], 3GPP I-CSCF, etc). 150 SIP-based SBCs typically handle both signaling and media and can 151 implement behavior which is equivalent to a "privacy service" (as 152 described in[2]) performing both Header Privacy and Session Privacy). 153 SBCs often modify certain SIP headers and message bodies that proxies 154 are not allowed to modify. Consequently, they are, by definition, 155 B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs 156 varies depending on the functions they perform. For example, some 157 SBCs modify the session description carried in the message and insert 158 a Record-Route entry. Other SBCs replace the value of the Contact 159 header field with the SBCs address, and generate a new Call-ID and 160 new To and From tags. 162 +-----------------+ 163 | SBC | 164 [signaling] | +-----------+ | 165 <------------|->| signaling |<-|----------> 166 outer | +-----------+ | inner 167 network | | | network 168 | +-----------+ | 169 <------------|->| media |<-|----------> 170 [media] | +-----------+ | 171 +-----------------+ 173 Figure 1: SBC architecture 175 Figure 1 shows the logical architecture of an SBC, which includes a 176 signaling and a media component. In this document, the terms outer 177 and inner network are used for describing these two networks. An SBC 178 is logically associated to the inner network, and it typically 179 provides functions such as controlling and protecting access to the 180 inner network from the outer network. 182 2.1. Peering Scenario 184 A typical peering scenario involves two network operators who 185 exchange traffic with each other. For example, in a toll bypass 186 application, a gateway in operator A's network sends an INVITE that 187 is routed to the softswitch (proxy) in operator B's network. The 188 proxy responds with a redirect (3xx) message back to the originating 189 gateway that points to the appropriate terminating gateway in 190 operator B's network. The originating gateway then sends the INVITE 191 to the terminating gateway. 193 Operator A . Operator B 194 . 195 . 2) INVITE 196 +-----+ . /--------------->+-----+ 197 | SSA | . / 3) 3xx (redir.) | SSB | 198 +-----+ . / /---------------+-----+ 199 . / / 200 +-----+ 1) INVITE +-----+--/ / +-----+ 201 |GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1| 202 +-----+ +-----+---------------------->+-----+ 203 . 204 +-----+ . +-----+ 205 |GW-A2| . |GW-B2| 206 +-----+ . +-----+ 208 Figure 2: Peering with SBC 210 Figure 2 illustrates the peering arrangement with an SBC where 211 Operator A is the outer network, and Operator B is the inner network. 212 Operator B can use the SBC, for example, to control access to its 213 network, protect its gateways and softswitches from unauthorized use 214 and DoS attacks, and monitor the signaling and media traffic. It 215 also simplifies network management by minimizing the number ACL 216 (Access Control List) entries in the gateways. The gateways do not 217 need to be exposed to the peer network, and they can restrict access 218 (both media and signaling) to the SBCs. The SBC helps ensure that 219 only media from sessions the SBC authorizes will reach the gateway. 221 2.2. Access Scenario 223 In an access scenario, presented in Figure 3, the SBC is placed at 224 the border between the access network (outer network) and the 225 operator's network (inner network) to control access to the 226 operator's network, protect its components (media servers, 227 application servers, gateways, etc.) from unauthorized use and DoS 228 attacks, and monitor the signaling and media traffic. Also, since 229 the SBC is call stateful, it may provide access control functions to 230 prevent over-subscription of the access links. Endpoints are 231 configured with the SBC as their outbound proxy address. The SBC 232 routes requests to one or more proxies in the operator network. 234 Access Network Operator Network 236 +-----+ 237 | UA1 |<---------\ 238 +-----+ \ 239 \ 240 +-----+ \------->+-----+ +-------+ 241 | UA2 |<-------------------->| SBC |<----->| proxy |<-- - 242 +-----+ /--->+-----+ +-------+ 243 / 244 +-----+ +-----+ / 245 | UA3 +---+ NAT |<---/ 246 +-----+ +-----+ 248 Figure 3: Access scenario with SBC 250 The SBC may be hosted in the access network (e.g,. this is common 251 when the access network is an enterprise network), or in the operator 252 network (e.g., this is common when the access network is a 253 residential or small business network). 255 Some endpoints may be behind enterprise or residential NATs. In 256 cases where the access network is a private network, the SBC is a NAT 257 for all traffic. It is noteworthy that SIP traffic may have to 258 traverse more that one NAT. The proxy usually does authentication 259 and/or authorization for registrations and outbound calls. The SBC 260 modifies the REGISTER request so that subsequent requests to the 261 registered address-of-record are routed to the SBC. This is done 262 either with a Path header, or by modifying the Contact to point at 263 the SBC. 265 The scenario presented in this section is a general one, and it 266 applies also to other similar settings. One example from a similar 267 setting is the one where an access network is the open internet, and 268 the operator network is the network of a SIP service provider. 270 3. Functions of SBCs 272 This section lists those functions that are used in SBC deployments 273 in current communication networks. Each subsection describes a 274 particular function or feature, the operators' requirements for 275 having it, explanation of any impact to the end-to-end SIP 276 architecture, and a concrete implementation example. Each section 277 also discusses potential concerns specific to that particular 278 implementation technique. Suggestions for alternative implementation 279 techniques that may be more architecturally compatible with SIP are 280 outside the scope of this document. 282 All the examples given in this section are simplified; only the 283 relevant header lines from SIP and SDP [6] messages are displayed. 285 3.1. Topology Hiding 287 3.1.1. General Information and Requirements 289 Topology hiding consists of limiting the amount of topology 290 information given to external parties. Operators have a requirement 291 for this functionality because they do not want the IP addresses of 292 their equipment (proxies, gateways, application servers, etc) to be 293 exposed to outside parties. This may be because they do not want to 294 expose their equipment to DoS (Denial of Service) attacks, they may 295 use other carriers for certain traffic and do not want their 296 customers to be aware of it or they may want to hide their internal 297 network architecture from competitors or partners. In some 298 environments, the operator's customers may wish to hide the addresses 299 of their equipment or the SIP messages may contain private, non- 300 routable addresses. 302 The most common form of topology hiding is the application of header 303 privacy (see Section 5.1 of [2]), which involves stripping Via and 304 Record-Route headers, replacing the Contact header, and even changing 305 Call-IDs. However, in deployments which use IP addresses instead of 306 domain names in headers that cannot be removed (e.g. From and To 307 headers), the SBC may replace these IP addresses with its own IP 308 address or domain name. 310 3.1.2. Architectural Issues 312 This functionality is based on a hop-by-hop trust model as opposed to 313 an end-to-end trust model. The messages are modified without 314 subscriber consent and could potentially modify or remove information 315 about the user's privacy, security requirements and higher layer 316 applications which are communicating end-to-end using SIP. Neither 317 user agent in an end-to-end call has any way to distinguish the SBC 318 actions from a Man-In-The-Middle (MitM) attack. 320 Topology hiding function does not work well with Authenticated 321 Identity Management [3]. The Authenticated Identity Management 322 mechanism is based on a hash value that is calculated from parts of 323 From, To, Call-Id, CSeq, Date, and Contact header fields plus from 324 the whole message body. If the authentication service is not 325 provided by the SBC itself, the modification of the forementioned 326 header fields and the message body is in violation of [3]. Some 327 forms of topology hiding are in violation, because they are e.g., 328 replacing the Contact header of a SIP message. 330 3.1.3. Example 332 The current way of implementing topology hiding consists of having an 333 SBC act as a B2BUA (Back-to-Back User Agent) and remove all traces of 334 topology information (e.g., Via and Record-Route entries) from 335 outgoing messages. 337 Imagine the following example scenario: The SBC 338 (p4.domain.example.com) receives an INVITE request from the inner 339 network, which in this case is an operator network. The received SIP 340 message is shown in Figure 4. 342 INVITE sip:callee@u2.domain.example.com SIP/2.0 343 Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK48jq9w9174131.1 344 Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1 345 Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1 346 Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1 347 Contact: sip:caller@u1.example.com 348 Record-Route: 349 Record-Route: 350 Record-Route: 352 Figure 4: INVITE Request Prior to Topology Hiding 354 Then the SBC performs a topology hiding function. In this scenario, 355 the SBC removes and stores all existing Via and Record-Route headers, 356 and then inserts Via and Record-Route header fields with its own SIP 357 URI. After the topology hiding function, the message could appear as 358 shown in Figure 5. 360 INVITE sip:callee@u2.domain.example.com SIP/2.0 361 Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w1230129.1 362 Contact: sip:caller@u1.example.com 363 Record-Route: 365 Figure 5: INVITE Request After Topology Hiding 367 Like a regular proxy server that inserts a Record-Route entry, the 368 SBC handles every single message of a given SIP dialog. If the SBC 369 loses state (e.g., SBC restarts for some reason), it may not be able 370 to route messages properly (note: some SBCs preserve the state 371 information also on restart). For example, if the SBC removes "Via" 372 entries from a request and then restarts, thus losing state, the SBC 373 may not be able to route responses to that request; depending on the 374 information that was lost when the SBC restarted. 376 This is only one example of topology hiding. Besides topology hiding 377 (i.e., information related to network elements is beeing hidden), 378 SBCs may also do identity hiding (i.e., information related to 379 identity of subscribers in beeing hidden). While performing identity 380 hiding, SBCs may modify Contact header field values and other header 381 fields containing identity information. The header fields containing 382 identity information is listed in Section 4.1 of [2]. Since the 383 publication of [2], the following header fields containing identity 384 information have been defined: "P-Asserted-Identity", "Referred-By", 385 "Identity", and "Identity-Info". 387 3.2. Media Traffic Management 389 3.2.1. General Information and Requirements 391 Media traffic management is the function of controlling media 392 traffic. Network operators may require this functionality in order 393 to control the traffic being carried on their network on behalf of 394 their subscribers. Traffic management helps the creation of 395 different kinds of billing models (e.g., video telephony can be 396 priced differently to voice-only calls) and it also makes it possible 397 for operators to enforce the usage of selected codecs. Additionally, 398 traffic management can be used to implement intercept capabilities 399 where required to support audit or legal obligations. 401 Since the media path is independent of the signaling path, the media 402 may not traverse through the operator's network unless the SBC 403 modifies the session description. By modifying the session 404 description the SBC can force the media to be sent through a media 405 relay which may be co-located with the SBC. This kind of traffic 406 management can be done, for example, to ensure a certain QoS (Quality 407 of Service) level, or to ensure that subscribers are using only 408 allowed codecs. 410 Some operators do not want to manage the traffic, but only to monitor 411 it for collecting statistics and making sure that they are able to 412 meet any business service level agreements with their subscribers 413 and/or partners. The protocol techniques needed for monitoring media 414 traffic are the same as for managing media traffic. 416 SBCs on the media path are also capable of dealing with the "lost 417 BYE" issue if either endpoint dies in the middle of the session. The 418 SBC can detect that the media has stopped flowing and issue a BYE to 419 both sides to cleanup any state in other intermediate elements and 420 the endpoints. 422 One possible form of media traffic management is that SBCs terminate 423 media streams and SIP dialogs by generating BYE requests. This kind 424 of procedure can take place, for example, in a situation where the 425 subscriber runs out of credits. Media management is needed to ensure 426 that the subscriber cannot just ignore the BYE request generated by 427 the SBC and continue their media sessions. 429 3.2.2. Architectural Issues 431 Implementing traffic management in this manner requires the SBC to 432 access and modify the session descriptions (i.e., offers and answers) 433 exchanged between the user-agents. Consequently, this approach does 434 not work if user-agents encrypt or integrity-protect their message 435 bodies end-to-end. Again, messages are modified without subscriber 436 consent, and user-agents do not have any way to distinguish the SBC 437 actions from an attack by a MitM. Furthermore, this is in violation 438 of Authenticated Identity Management [3], see Section 3.1.2. 440 Media traffic management function also hinders innovations. The 441 reason for the hinderance is that in many cases SBCs need to be able 442 to support new ways of communicating (e.g., extensions to the SDP 443 protocol) before new services can be taken into use, and that slows 444 down the adoption of innovations. 446 In this application, the SBC may originate messages that the user may 447 not be able to authenticate as coming from the dialog peer or the SIP 448 Registrar/Proxy. 450 3.2.3. Example 452 Traffic management may be performed in the following way: The SBC 453 behaves as a B2BUA and inserts itself, or some other entity under the 454 operator's control, in the media path. In practice, the SBC modifies 455 the session descriptions carried in the SIP messages. As a result, 456 the SBC receives media from one user-agent and relays it to the other 457 user-agent and performs the identical operation with media traveling 458 in the reverse direction. 460 As mentioned in Section 3.2.1, codec restriction is a form of traffic 461 management. The SBC restricts the codec set negotiated in the offer/ 462 answer exchange [4] between the user-agents. After modifying the 463 session descriptions, the SBC can check whether or not the media 464 stream corresponds to what was negotiated in the offer/answer 465 exchange. If it differs, the SBC has the ability to terminate the 466 media stream or take other appropriate (configured) actions (e.g. 467 raise an alarm). 469 Consider the following example scenario: The SBC receives an INVITE 470 request from the outer network, which in this case is an access 471 network. The received SIP message contains the SDP session 472 descriptor shown in Figure 6. 474 v=0 475 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 476 c=IN IP4 192.0.2.4 477 m=audio 49230 RTP/AVP 96 98 478 a=rtpmap:96 L8/8000 479 a=rtpmap:98 L16/16000/2 481 Figure 6: Request Prior to Media Management 483 In this example, the SBC performs the media traffic management 484 function by rewriting the 'm' line, and removing one 'a' line 485 according to some (external) policy. Figure 7 shows the session 486 description after the traffic management function. 488 v=0 489 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 490 c=IN IP4 192.0.2.4 491 m=audio 49230 RTP/AVP 96 492 a=rtpmap:96 L8/8000 494 Figure 7: Request Body After Media Management 496 Media traffic management has a problem where the SBC needs to 497 understand the session description protocol and all extensions used 498 by the user-agents. This means that in order to use a new extension 499 (e.g., an extension to implement a new service) or a new session 500 description protocol, SBCs in the network may need to be upgraded in 501 conjunction with the endpoints. It is noteworthy that a similar 502 problem, but with header fields, applies to, for example, topology 503 hiding function, see Section 3.1. Certain extensions that do not 504 require active manipulation of the session descriptors to facilitate 505 traffic management will be able to be deployed without upgrading 506 existing SBCs, depending on the degree of transparency the SBC 507 implementation affords. In cases requiring an SBC modification to 508 support the new protocol features, the rate of service deployment may 509 be affected. 511 3.3. Fixing Capability Mismatches 513 3.3.1. General Information and Requirements 515 SBCs fixing capability mismatches enable communications between user- 516 agents with different capabilities or extensions. For example, user- 517 agents on networks which implement SIP differently (for example 3GPP 518 or SIP [1] network etc) or those that support different IP versions, 519 different codecs, or that are in different address realms. Operators 520 have a requirement and a strong motivation for performing capability 521 mismatch fixing, so that they can provide transparent communication 522 across different domains. In some cases different SIP extensions or 523 methods to implement the same SIP application (like monitoring 524 session liveness, call history/diversion etc) may also be interworked 525 through the SBC. 527 3.3.2. Architectural Issues 529 SBCs fixing capability mismatches insert a media element in the media 530 path using the procedures described in Section 3.2. Therefore, these 531 SBCs have the same concerns as SBCs performing traffic management: 532 the SBC modifies SIP messages without explicit consent from any of 533 the user-agents. This may break end-to-end security and application 534 extensions negotiation. 536 The capability mismatch fixing is a fragile function in the long 537 term. The number of incompatibilities built into various network 538 elements is increasing the fragility and complexity over time. This 539 might lead to a situation where SBCs need to be able to handle a 540 large number of capability mismatches in parallel. 542 3.3.3. Example 544 Consider the following example scenario where the inner network is an 545 access network using IPv4 and the outer network is using IPv6. The 546 SBC receives an INVITE request with a session description from the 547 access network: 549 INVITE sip:callee@ipv6.domain.example.com SIP/2.0 550 Via: SIP/2.0/UDP 192.0.2.4 551 Contact: sip:caller@u1.example.com 553 v=0 554 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 555 c=IN IP4 192.0.2.4 556 m=audio 49230 RTP/AVP 96 557 a=rtpmap:96 L8/8000 559 Figure 8: Request Prior to Capabilities Match 561 Then the SBC performs a capability mismatch fixing function. In this 562 scenario the SBC inserts Record-Route and Via headers, and rewrites 563 the 'c' line from the sessions descriptor. Figure 9 shows the 564 request after the capability mismatch adjustment. 566 INVITE sip:callee@ipv6.domain.com SIP/2.0 567 Record-Route: 568 Via: SIP/2.0/UDP sip:[2001:DB8::801:201:2ff:fe94:8e10] 569 Via: SIP/2.0/UDP 192.0.2.4 570 Contact: sip:caller@u1.example.com 572 v=0 573 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 574 c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10 575 m=audio 49230 RTP/AVP 96 576 a=rtpmap:96 L8/8000 578 Figure 9: Request After Capability Match 580 This message is then sent by the SBC to the onward IPv6 network. 582 3.4. Maintaining SIP-related NAT Bindings 584 3.4.1. General Information and Requirements 586 NAT traversal in this instance refers to the specific message 587 modifications required to assist a user-agent in maintaining SIP and 588 media connectivity when there is a NAT device located between a user- 589 agent and a proxy/registrar and, possibly, any other user-agent. The 590 primary purpose of NAT traversal function is to keep up a control 591 connection to user-agents behind NATs. This can, for example, be 592 achieved by generating periodic network traffic that keeps bindings 593 in NATs alive. SBCs' NAT traversal function is required in scenarios 594 where the NAT is outside the SBC (i.e., not in cases where SBC itself 595 acts as a NAT). 597 An SBC performing a NAT (Network Address Translator) traversal 598 function for a user agent behind a NAT sits between the user-agent 599 and the registrar of the domain. NATs are widely deployed in various 600 access networks today, so operators have a requirement to support it. 601 When the registrar receives a REGISTER request from the user-agent 602 and responds with a 200 (OK) response, the SBC modifies such a 603 response decreasing the validity of the registration (i.e., the 604 registration expires sooner). This forces the user-agent to send a 605 new REGISTER to refresh the registration sooner that it would have 606 done on receiving the original response from the registrar. The 607 REGISTER requests sent by the user-agent refresh the binding of the 608 NAT before the binding expires. 610 Note that the SBC does not need to relay all the REGISTER requests 611 received from the user-agent to the registrar. The SBC can generate 612 responses to REGISTER requests received before the registration is 613 about to expire at the registrar. Moreover, the SBC needs to 614 deregister the user-agent if this fails to refresh its registration 615 in time, even if the registration at the registrar would still be 616 valid. 618 SBCs can also force traffic to go through a media relay for NAT 619 traversal purposes (more about media traffic management in 620 Section 3.2). A typical call has media streams to two directions. 621 Even though SBCs can force media streams from both directions to go 622 through a media relay, in some cases it is enough to relay only the 623 media from one direction (e.g., in a scenario where only the other 624 endpoint is behind a NAT). 626 3.4.2. Architectural Issues 628 This approach to NAT traversal does not work if end-to-end 629 confidentiality or integrity-protection mechanisms are used (e.g., 630 S/MIME). The SBC would be seen as a MitM modifying the messages 631 between the user-agent and the registrar. 633 There is also a problem related to the method how SBCs choose the 634 value for the validity of a registration period. This value should 635 be as high as possible, but it still needs to be low enough to 636 maintain the NAT binding. Typically SBCs do not have any 637 deterministic method for choosing a suitable value. However, SBCs 638 can just use a sub-optimal, relatively small value which usually 639 works. 641 3.4.3. Example 643 Consider the following example scenario: The SBC resides between the 644 UA and Registrar. Previously the UA has sent a REGISTER request to 645 Registrar, and the SBC receives the registration response shown in 646 Figure 10. 648 SIP/2.0 200 OK 649 From: Bob ;tag=a73kszlfl 650 To: Bob ;tag=34095828jh 651 CSeq: 1 REGISTER 652 Contact: ;expires=3600 654 Figure 10: Response Prior to NAT Maintenance Function 656 When performing the NAT traversal function, the SBC may re-write the 657 expiry time to coax the UA to re-register prior to the intermediating 658 NAT deciding to close the pinhole. Figure 11 shows a possible 659 modification of the response from Figure 10. 661 SIP/2.0 200 OK 662 From: Bob ;tag=a73kszlfl 663 To: Bob ;tag=34095828jh 664 CSeq: 1 REGISTER 665 Contact: ;expires=60 667 Figure 11: Manipulated Response for NAT Traversal 669 Naturally also other measures could be taken in order to enable the 670 NAT traversal (e.g., non-SIP keepalive messages), but this example 671 illustrates only one mechanism for preserving the SIP-related NAT 672 bindings. 674 3.5. Access Control 676 3.5.1. General Information and Requirements 678 Network operators may wish to control what kind of signaling and 679 media traffic their network carries. There is strong motivation and 680 a requirement to do access control on the edge of an operator's 681 network. Access control can be based on, for example, link-layer 682 identifiers, IP addresses or SIP identities. 684 This function can be implemented by protecting the inner network with 685 firewalls and configuring them so that they only accept SIP traffic 686 from the SBC. This way, all the SIP traffic entering the inner 687 network needs to be routed though the SBC, which only routes messages 688 from authorized parties or traffic that meets a specific policy that 689 is expressed in the SBC administratively. 691 Access control can be applied either only to the signaling, or to 692 both the signaling and media. If it is applied only to the 693 signaling, then the SBC might behave as a proxy server. If access 694 control is applied to both the signaling and media, then the SBC 695 behaves in a similar manner as explained in Section 3.2. A key part 696 of media-layer access control is that only media for authorized 697 sessions is allowed to pass through the SBC and/or associated media 698 relay devices. 700 Operators implement some functionalities, like NAT traversal for 701 example, in an SBC instead of other elements in the inner network for 702 several reasons: (i) preventing packets from unregistered users to 703 prevent chances of DoS attack, (ii) prioritization and/or re-routing 704 of traffic (based on user or service, like E911) as it enters the 705 network, and (iii) performing a load balancing function or reducing 706 the load on other network equipment. 708 In environments where there is limited bandwidth on the access links, 709 the SBC can compute the potential bandwidth usage by examining the 710 codecs present in SDP offers and answers. With this information, the 711 SBC can reject sessions before the available bandwidth is exhausted 712 to allow existing sessions to maintain acceptable quality of service. 713 Otherwise, the link could become over-subscribed and all sessions 714 would experience a deterioration in quality of service. SBCs may 715 contact a policy server to determine whether sufficient bandwidth is 716 available on a per-session basis. 718 3.5.2. Architectural Issues 720 Since the SBC needs to handle all SIP messages, this function has 721 scalability implications. In addition, the SBC is a single point of 722 failure from an architectural point of view. Although, in practice, 723 many current SBCs have the capability to support redundant 724 configuration, which prevents the loss of calls and/or sessions in 725 the event of a failure on a single node. 727 If access control is performed only on behalf of signaling, then the 728 SBC is compatible with general SIP architectural principles, but if 729 it is performed for signaling and for media, then there are similar 730 problems as described in Section 3.2.2. 732 3.5.3. Example 734 Figure 12 shows a callflow where the SBC is providing both signaling 735 and media access control (ACKs omitted for brevity). 737 caller SBC callee 738 | | | 739 | Identify the caller | | 740 |<- - - - - - - - - - - >| | 741 | | | 742 | INVITE + SDP | | 743 |----------------------->| | 744 | [Modify the SDP] | 745 | | INVITE + modified SDP | 746 | |----------------------->| 747 | | | 748 | | 200 OK + SDP | 749 | |<-----------------------| 750 | [Modify the SDP] | 751 | | | 752 | 200 OK + modified SDP | | 753 |<-----------------------| | 754 | | | 755 | Media [Media inspection] Media | 756 |<======================>|<======================>| 757 | | | 759 Figure 12: Example Access Callflow 761 In this scenario, the SBC first identifies the caller, so it can 762 determine whether or not to give signaling access for the caller. 763 This might be achieved using information gathered during 764 registration, or by other means. Some SBCs may rely on the proxy to 765 authenticate the user-agent placing the call. After identification, 766 the SBC modifies the session descriptors in INVITE and 200 OK 767 messages in a way so that the media is going to flow through the SBC 768 itself. When the media starts flowing, the SBC can inspect whether 769 the callee and caller use the codec(s) that they had previously 770 agreed on. 772 3.6. Protocol Repair 774 3.6.1. General Information and Requirements 776 SBCs are also used to repair protocol messages generated by not- 777 fully-standard compliant or badly implemented clients. Operators may 778 wish to support protocol repair, if they want to support as many 779 clients as possible. It is noteworthy, that this function affects 780 only the signaling component of an SBC, and that the protocol repair 781 function is not the same as protocol conversion (i.e., making 782 translation between two completely different protocols). 784 3.6.2. Architectural Issues 786 In most cases, this function can be seen as being compatible with SIP 787 architectural principles, and it does not violate the end-to-end 788 model of SIP. The SBC repairing protocol messages behaves as a proxy 789 server that is liberal in what it accepts and strict in what it 790 sends. 792 A similar problem related to increasing complexity, as explained in 793 Section 3.3.2, also affects protocol repair function. 795 3.6.3. Examples 797 The SBC can, for example, receive an INVITE message from a relatively 798 new SIP UA as illustrated in Figure 13. 800 INVITE sip:callee@sbchost.example.com 801 Via: SIP/2.0/UDP u1.example.com:5060;lr 802 From: Caller 803 To: Callee 804 Call-ID: 18293281@u1.example.com 805 CSeq: 1 INVITE 806 Contact: sip:caller@u1.example.com 808 Figure 13: Request from a relatively new client 810 If the SBC does protocol repair, it can re-write the 'lr' parameter 811 on the Via header field into the form 'lr=true', in order to support 812 some older, badly implemented SIP stacks. It could also remove 813 excess white spaces to make the SIP message more human readable. 815 3.7. Media Encryption 817 3.7.1. General Information and Requirements 819 SBCs are used to perform media encryption / decryption at the edge of 820 the network. This is the case when media encryption (e.g., Secure 821 Real-time Transport Protocol (SRTP)) is used only on the access 822 network (outer network) side and the media is carried unencrypted in 823 the inner network. Operators may have an obligation to provide the 824 ability to do legal interception, while they still want to give their 825 customers the ability to encrypt media in the access network. This 826 leads to a situation where operators have a requirement to perform 827 media encryption function. 829 3.7.2. Architectural Issues 831 While performing a media encryption function, SBCs need to be able to 832 inject either themselves, or some other entity to the media path. It 833 must be noted that this kind of behavior is the same as a classical 834 MitM attack. Due to this, the SBCs have the same architectural 835 issues as explained in Section 3.2. 837 3.7.3. Example 839 Figure 14 shows an example where the SBC is performing media 840 encryption related functions (ACKs omitted for brevity). 842 caller SBC#1 SBC#2 callee 843 | | | | 844 | INVITE + SDP | | | 845 |------------------->| | | 846 | [Modify the SDP] | | 847 | | | | 848 | | INVITE + mod. SDP | | 849 | |------------------->| | 850 | | [Modify the SDP] | 851 | | | | 852 | | | INVITE + mod. SDP | 853 | | |------------------->| 854 | | | | 855 | | | 200 OK + SDP | 856 | | |<-------------------| 857 | | [Modify the SDP] | 858 | | | | 859 | | 200 OK + mod. SDP | | 860 | |<-------------------| | 861 | [Modify the SDP] | | 862 | | | | 863 | 200 OK + mod. SDP | | | 864 |<-------------------| | | 865 | | | | 866 | Encrypted | Plain | Encrypted | 867 | media [enc./dec.] media [enc./dec.] media | 868 |<==================>|<- - - - - - - - ->|<==================>| 869 | | | | 871 Figure 14: Media Encryption Example 873 First the UAC sends an INVITE request , and the first SBC modifies 874 the session descriptor in a way that it injects itself to the media 875 path. The same happens in the second SBC. Then the UAS replies with 876 a 200 OK response and the SBCs inject themselves in the returning 877 media path. After signaling the media starts flowing, and both SBCs 878 are performing media encryption and decryption. 880 4. Derived Requirements for Future SIP Standardization Work 882 Some of the functions listed in this document are more SIP-unfriendly 883 than others. This list of requirements is derived from the functions 884 that break the principles of SIP in one way or another. The derived 885 requirements are: 887 Req-1: There should be a SIP-friendly way to hide network topology 888 information. Currently this is done by stripping and 889 replacing header fields, which is against the principles of 890 SIP (see Section 3.1). 891 Req-2: There should be a SIP-friendly way to direct media traffic 892 through intermediaries. Currently this is done without user 893 consent by modifying session descriptors, which is against 894 the principles of SIP (see Section 3.2, Section 3.4, 895 Section 3.5, and Section 3.7). 896 Req-3: There should be a SIP-friendly way to fix capability 897 mismatches in SIP messages. This requirement is harder to 898 fulfill on complex mismatch cases, like the 3GPP/SIP [1] 899 network mismatch. Currently this is done by modifying SIP 900 messages, which violates end-to-end security (see Section 3.3 901 and Section 3.6). 903 Req-1 and Req-3 do not have an exiting solution today. There is 904 ongoing work in the IETF for addressing Req-2, such as SIP session 905 policies, Traversal Using Relays around NAT (TURN), and Interactive 906 Connectivity Establishment (ICE). Nonetheless, future work is needed 907 in order to develop solutions to these requirements. 909 It is noteworthy that a subset of the functions of SBCs will remain 910 as non-standardized functions, because it is not reasonable, or 911 feasible to develop a standardized solutions to replace them. 912 Examples from this kind of functions are the ability to enforce the 913 usage of a specific codec and the protocol repair (see Section 3.6) 914 functionality. 916 5. Security Considerations 918 Many of the functions this document describes have important security 919 and privacy implications. One major security problem is that many 920 functions implemented by SBCs (e.g., topology hiding and media 921 traffic management) modify SIP messages and their bodies without the 922 user agents' consent. The result is that the user agents may 923 interpret the actions taken by an SBC as a MitM attack. SBCs modify 924 SIP messages because it allows them to, for example, protect elements 925 in the inner network from direct attacks. 927 SBCs that place themselves (or another entity) on the media path can 928 be used to eavesdrop on conversations. Since, often, user agents 929 cannot distinguish between the actions of an attacker and those of an 930 SBC, users cannot know whether they are being eavesdropped or an SBC 931 on the path is performing some other function. SBCs place themselves 932 on the media path because it allows them to, for example, perform 933 legal interception. 935 On a general level SBCs prevent the use of end-to-end authentication. 936 This is because SBCs need to be able to perform actions that look 937 like MitM attacks, and in order for user agents to communicate, they 938 must allow those type of attacks. It other words, user agents can 939 not use end-to-end security. This is especially harmful because also 940 other network element, besides SBCs, are then able to do similar 941 attacks. 943 An SBC is a single point of failure from the architectural point of 944 view. This makes it an attractive target for DoS attacks. The fact 945 that some functions of SBCs require those SBCs to maintain session- 946 specific information makes the situation even worse. If the SBC 947 crashes (or is brought down by an attacker), ongoing sessions 948 experience undetermined behavior. 950 If the IETF decides to develop standard mechanisms to address the 951 requirements presented in Section 4, the security and privacy-related 952 aspects of those mechanisms will, of course, need to be taken into 953 consideration. 955 6. IANA Considerations 957 This document has no IANA considerations. 959 7. Acknowledgements 961 The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC 962 during the 61st IETF meeting, provided valuable input to this 963 document. Authors would also like to thank Sridhar Ramachandran, 964 Gaurav Kulshreshtha, and Rakendu Devdhar. Reviewers Spencer Dawkins 965 and Francois Audet also deserve special thanks. 967 8. References 968 8.1. Normative References 970 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 971 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 972 Session Initiation Protocol", RFC 3261, June 2002. 974 [2] Peterson, J., "A Privacy Mechanism for the Session Initiation 975 Protocol (SIP)", RFC 3323, November 2002. 977 [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated 978 Identity Management in the Session Initiation Protocol (SIP)", 979 RFC 4474, August 2006. 981 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 982 Session Description Protocol (SDP)", RFC 3264, June 2002. 984 8.2. Informational References 986 [5] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 987 5.15.0, June 2006. 989 [6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 990 Description Protocol", RFC 4566, July 2006. 992 Authors' Addresses 994 Jani Hautakorpi (editor) 995 Ericsson 996 Hirsalantie 11 997 Jorvas 02420 998 Finland 1000 Email: Jani.Hautakorpi@ericsson.com 1002 Gonzalo Camarillo 1003 Ericsson 1004 Hirsalantie 11 1005 Jorvas 02420 1006 Finland 1008 Email: Gonzalo.Camarillo@ericsson.com 1009 Robert F. Penfield 1010 Acme Packet 1011 71 Third Avenue 1012 Burlington, MA 01803 1013 US 1015 Email: bpenfield@acmepacket.com 1017 Alan Hawrylyshen 1018 Ditech Networks Inc. 1019 825 E Middlefield Rd 1020 Mountain View, CA 1021 US 1023 Email: alan.ietf@polyphase.ca 1025 Medhavi Bhatia 1026 3CLogic 1027 9700 Great Seneca Hwy. 1028 Rockville, MD 20850 1029 US 1031 Email: mbhatia@3clogic.com 1033 Full Copyright Statement 1035 Copyright (C) The IETF Trust (2008). 1037 This document is subject to the rights, licenses and restrictions 1038 contained in BCP 78, and except as set forth therein, the authors 1039 retain all their rights. 1041 This document and the information contained herein are provided on an 1042 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1043 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1044 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1045 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1046 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1047 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1049 Intellectual Property 1051 The IETF takes no position regarding the validity or scope of any 1052 Intellectual Property Rights or other rights that might be claimed to 1053 pertain to the implementation or use of the technology described in 1054 this document or the extent to which any license under such rights 1055 might or might not be available; nor does it represent that it has 1056 made any independent effort to identify any such rights. Information 1057 on the procedures with respect to rights in RFC documents can be 1058 found in BCP 78 and BCP 79. 1060 Copies of IPR disclosures made to the IETF Secretariat and any 1061 assurances of licenses to be made available, or the result of an 1062 attempt made to obtain a general license or permission for the use of 1063 such proprietary rights by implementers or users of this 1064 specification can be obtained from the IETF on-line IPR repository at 1065 http://www.ietf.org/ipr. 1067 The IETF invites any interested party to bring to its attention any 1068 copyrights, patents or patent applications, or other proprietary 1069 rights that may cover technology that may be required to implement 1070 this standard. Please address the information to the IETF at 1071 ietf-ipr@ietf.org. 1073 Acknowledgment 1075 Funding for the RFC Editor function is provided by the IETF 1076 Administrative Support Activity (IASA).