idnits 2.17.1 draft-ietf-sipping-sbc-funcs-03.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 990. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1014. 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 (April 17, 2007) is 6212 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 2327 (ref. '6') (Obsoleted by RFC 4566) 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: October 19, 2007 R. Penfield 6 Acme Packet 7 A. Hawrylyshen 8 Ditech Networks Inc. 9 M. Bhatia 10 3CLogic 11 April 17, 2007 13 Requirements from SIP (Session Initiation Protocol) Session Border 14 Control Deployments 15 draft-ietf-sipping-sbc-funcs-03.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 October 19, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 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 Shaping . . . . . . . . . . . . . . . . . . 10 71 3.2.1. General Information and Requirements . . . . . . . . . 10 72 3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . 16 85 3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 17 86 3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 17 87 3.6.1. General Information and Requirements . . . . . . . . . 17 88 3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 18 89 3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 18 90 3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 18 91 3.7.1. General Information and Requirements . . . . . . . . . 18 92 3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 19 93 3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19 94 4. Derived Requirements for Future SIP Standardization Work . . . 20 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 100 8.2. Informational References . . . . . . . . . . . . . . . . . 21 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 102 Intellectual Property and Copyright Statements . . . . . . . . . . 23 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, shaping, and QoS). Some of 147 these functions may also get integrated into other SIP elements (like 148 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. 179 2.1. Peering Scenario 181 A typical peering scenario involves two network operators who 182 exchange traffic with each other. For example, in a toll bypass 183 application, a gateway in operator A's network sends an INVITE that 184 is routed to the softswitch (proxy) in operator B's network. The 185 proxy responds with a redirect (3xx) message back to the originating 186 gateway that points to the appropriate terminating gateway in 187 operator B's network. The originating gateway then sends the INVITE 188 to the terminating gateway. 190 Operator A . Operator B 191 . 192 . 2) INVITE 193 +-----+ . /--------------->+-----+ 194 | SSA | . / 3) 3xx (redir.) | SSB | 195 +-----+ . / /---------------+-----+ 196 . / / 197 +-----+ 1) INVITE +-----+--/ / +-----+ 198 |GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1| 199 +-----+ +-----+---------------------->+-----+ 200 . 201 +-----+ . +-----+ 202 |GW-A2| . |GW-B2| 203 +-----+ . +-----+ 205 Figure 2: Peering with SBC 207 Figure 2 illustrates the peering arrangement with a SBC where 208 Operator A is the outer network, and Operator B is the inner network. 209 Operator B can use the SBC, for example, to control access to its 210 network, protect its gateways and softswitches from unauthorized use 211 and DoS attacks, and monitor the signaling and media traffic. It 212 also simplifies network management by minimizing the number ACL 213 (Access Control List) entries in the gateways. The gateways do not 214 need to be exposed to the peer network, and they can restrict access 215 (both media and signaling) to the SBCs. The SBC helps ensure that 216 only media from sessions the SBC authorizes will reach the gateway. 218 2.2. Access Scenario 220 In an access scenario, presented in Figure 3, the SBC is placed at 221 the border between the access network (outer network) and the 222 operator's network (inner network) to control access to the 223 operator's network, protect its components (media servers, 224 application servers, gateways, etc.) from unauthorized use and DoS 225 attacks, and monitor the signaling and media traffic. Also, since 226 the SBC is call stateful, it may provide access control functions to 227 prevent over subscription of the access links. Endpoints are 228 configured with the SBC as their outbound proxy address. The SBC 229 routes requests to one or more proxies in the operator network. 231 Access Network Operator Network 233 +-----+ 234 | UA1 |<---------\ 235 +-----+ \ 236 \ 237 +-----+ \------->+-----+ +-------+ 238 | UA2 |<-------------------->| SBC |<----->| proxy |<-- - 239 +-----+ /--->+-----+ +-------+ 240 / 241 +-----+ +-----+ / 242 | UA3 +---+ NAT |<---/ 243 +-----+ +-----+ 245 Figure 3: Access scenario with SBC 247 The SBC may be hosted in the access network (e.g,. this is common 248 when the access network is an enterprise network), or in the operator 249 network (e.g., this is common when the access network is a 250 residential or small business network). 252 Some endpoints may be behind enterprise or residential NATs. In 253 cases where the access network is a private network, the SBC is the 254 NAT for all traffic. The proxy usually does authentication and/or 255 authorization for registrations and outbound calls. The SBC modifies 256 the REGISTER request so that subsequent requests to the registered 257 address-of-record are routed to the SBC. This is done either with a 258 Path header, or by modifying the Contact to point at the SBC. 260 The scenario presented in this section is a general one, and it 261 applies also to other similar settings. One example from a similar 262 setting is the one where an access network is the open internet, and 263 the operator network is the network of a SIP service provider. 265 3. Functions of SBCs 267 This section lists those functions that are used in SBC deployments 268 in current communication networks. Each subsection describes a 269 particular function or feature, the operators' requirements for 270 having it, explanation of any impact to the end-to-end SIP 271 architecture, and a concrete implementation example. Each section 272 also discusses potential concerns specific to that particular 273 implementation technique. Suggestions for alternative implementation 274 techniques that may be more architecturally compatible with SIP are 275 outside the scope of this document. 277 All the examples given in this section are simplified; only the 278 relevant header lines from SIP and SDP [6] messages are displayed. 280 3.1. Topology Hiding 282 3.1.1. General Information and Requirements 284 Topology hiding consists of limiting the amount of topology 285 information given to external parties. Operators have a requirement 286 for this functionality because they do not want the IP addresses of 287 their equipment (proxies, gateways, application servers, etc) to be 288 exposed to outside parties. This may be because they do not want to 289 expose their equipment to DoS (Denial of Service) attacks, they may 290 use other carriers for certain traffic and do not want their 291 customers to be aware of it or they may want to hide their internal 292 network architecture from competitors or partners. In some 293 environments, the operator's customers may wish to hide the addresses 294 of their equipment or the SIP messages may contain private, non- 295 routable addresses. 297 The most common form of topology hiding is the application of header 298 privacy (see Section 5.1 of [2]), which involves stripping Via and 299 Record-Route headers, replacing the Contact header, and even changing 300 Call-IDs. However, in deployments which use IP addresses instead of 301 domain names in headers that cannot be removed (e.g. From and To 302 headers), the SBC may replace these IP addresses with its own IP 303 address or domain name. 305 3.1.2. Architectural Issues 307 This functionality is based on a hop-by-hop trust model as opposed to 308 an end-to-end trust model. The messages are modified without 309 subscriber consent and could potentially modify or remove information 310 about the user's privacy, security requirements and higher layer 311 applications which are communicating end-to-end using SIP. Neither 312 user agent in an end-to-end call has any way to distinguish the SBC 313 actions from a Man-In-The-Middle (MitM) attack. 315 Topology hiding function does not work well with Authenticated 316 Identity Management [3]. The Authenticated Identity Management 317 mechanism is based on a hash value that is calculated from parts of 318 From, To, Call-Id, CSeq, Date, and Contact header fields plus from 319 the whole message body. If the authentication service is not 320 provided by the SBC itself, the modification of the forementioned 321 header fields and the message body is in violation with [3]. Some 322 forms of topology hiding are in violation, because they are e.g., 323 replacing the Contact header of a SIP message. 325 3.1.3. Example 327 The current way of implementing topology hiding consists of having an 328 SBC act as a B2BUA (Back-to-Back User Agents) and remove all traces 329 of topology information (e.g., Via and Record-Route entries) from 330 outgoing messages. 332 Imagine the following example scenario: The SBC 333 (p4.domain.example.com) receives an INVITE request from the inner 334 network, which in this case is an operator network. The received SIP 335 message is shown in Figure 4. 337 INVITE sip:callee@u2.domain.example.com SIP/2.0 338 Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK48jq9w9174131.1 339 Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1 340 Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1 341 Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1 342 Contact: sip:caller@u1.example.com 343 Record-Route: 344 Record-Route: 345 Record-Route: 347 Figure 4: INVITE Request Prior to Topology Hiding 349 Then the SBC performs a topology hiding function. In this scenario, 350 the SBC removes and stores all existing Via and Record-Route headers, 351 and then inserts a Via and Record-Route header fields with its own 352 SIP URI. After the topology hiding function, the message could 353 appear as shown in Figure 5. 355 INVITE sip:callee@u2.domain.example.com SIP/2.0 356 Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w1230129.1 357 Contact: sip:caller@u1.example.com 358 Record-Route: 360 Figure 5: INVITE Request After Topology Hiding 362 Like a regular proxy server that inserts a Record-Route entry, the 363 SBC handles every single message of a given SIP dialog. If the SBC 364 loses state (e.g., the SBC restarts for some reason), it may not be 365 able to route messages properly. For example, if the SBC removes 366 "Via" entries from a request and then restarts, thus losing state, 367 the SBC may not be able to route responses to that request; depending 368 on the information that was lost when the SBC restarted. 370 This is only one example of topology hiding. In some cases, SBCs may 371 modify other headers, including the Contact header field values. The 372 header fields containing identity information is listed in Section 373 4.1 of [2]. 375 3.2. Media Traffic Shaping 377 3.2.1. General Information and Requirements 379 Media traffic shaping is the function of controlling media traffic. 380 Network operators may require this functionality in order to control 381 the traffic being carried on their network on behalf of their 382 subscribers. Traffic shaping helps the creation of different kinds 383 of billing models (e.g., video telephony can be priced differently to 384 voice-only calls) and it also makes it possible for operators to 385 enforce the usage of selected codecs. Additionally, traffic shaping 386 can be used to implement intercept capabilities where required to 387 support audit or legal obligations. 389 Since the media path is independent of the signaling path, the media 390 may not traverse through the operator's network unless the SBC 391 modifies the session description. By modifying the session 392 description the SBC can force the media to be sent through a media 393 relay which may be co-located with the SBC. This kind of traffic 394 shaping can be done, for example, to ensure a certain QoS (Quality of 395 Service) level. 397 Some operators do not want to reshape the traffic (e.g., allowing 398 only certain codecs), but only to monitor it for collecting 399 statistics and making sure that they are able to meet any business 400 service level agreements with their subscribers and/or partners. The 401 protocol techniques needed for monitoring media traffic are the same 402 as for reshaping media traffic. 404 SBCs on the media path are also capable of dealing with the "lost 405 BYE" issue if either endpoint dies in the middle of the session. The 406 SBC can detect that the media has stopped flowing and issue a BYE to 407 both sides to cleanup any state in other intermediate elements and 408 the endpoints. 410 One possible form of media traffic shaping is that SBCs terminate 411 media streams and SIP dialogs by generating BYE requests. This kind 412 of procedure can take place, for example, in a situation where 413 subscriber runs out of credits. 415 3.2.2. Architectural Issues 417 Implementing traffic shaping in this manner requires the SBC to 418 access and modify the session descriptions (i.e., offers and answers) 419 exchanged between the user-agents. Consequently, this approach does 420 not work if user-agents encrypt or integrity-protect their message 421 bodies end-to-end. Again, messages are modified without subscriber 422 consent, and user-agents do not have any way to distinguish the SBC 423 actions from an attack by a MitM. Furthermore, this is in violation 424 with [3], see Section 3.1.2. 426 In this application, the SBC may originate messages that the user may 427 not be able to authenticate as coming from the dialog peer or the SIP 428 Registrar/Proxy. 430 3.2.3. Example 432 Traffic shaping may be performed in the following way: The SBC 433 behaves as a B2BUA and inserts itself, or some other entity under the 434 operator's control, in the media path. In practice, the SBC modifies 435 the session descriptions carried in the SIP messages. As a result, 436 the SBC receives media from one user-agent and relays it to the other 437 user-agent and performs the identical operation with media traveling 438 in the reverse direction. 440 As mentioned in Section 3.2.1, codec restriction is a form of traffic 441 shaping. The SBC restricts the codec set negotiated in the offer/ 442 answer exchange [4] between the user-agents. After modifying the 443 session descriptions, the SBC can check whether or not the media 444 stream corresponds to what was negotiated in the offer/answer 445 exchange. If it differs, the SBC has the ability to terminate the 446 media stream or take other appropriate (configured) actions (e.g. 447 raise an alarm). 449 Consider the following example scenario: The SBC receives an INVITE 450 request from the outer network, which in this case is an access 451 network. The received SIP message contains the SDP session 452 descriptor shown in Figure 6. 454 v=0 455 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 456 c=IN IP4 192.0.2.4 457 m=audio 49230 RTP/AVP 96 98 458 a=rtpmap:96 L8/8000 459 a=rtpmap:98 L16/16000/2 461 Figure 6: Request Prior to Media Shaping 463 In this example, the SBC performs the media traffic shaping function 464 by rewriting the 'm' line, and removing one 'a' line according to 465 some (external) policy. Figure 7 shows the session description after 466 the traffic shaping function. 468 v=0 469 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 470 c=IN IP4 192.0.2.4 471 m=audio 49230 RTP/AVP 96 472 a=rtpmap:96 L8/8000 474 Figure 7: Request Body After Media Shaping 476 Media traffic shaping has a problem where the SBC needs to understand 477 the session description protocol and all extensions used by the user- 478 agents. This means that in order to use a new extension (e.g., an 479 extension to implement a new service) or a new session description 480 protocol, SBCs in the network may need to be upgraded in conjunction 481 with the endpoints. It is noteworthy that similar problem, but with 482 header fields, applies to, for example, topology hiding function, see 483 Section 3.1. Certain extensions that do not require active 484 manipulation of the session descriptors to facilitate traffic shaping 485 will be able to be deployed without upgrading existing SBCs, 486 depending on the degree of transparency the SBC implementation 487 affords. In cases requiring an SBC modification to support the new 488 protocol features, the rate of service deployment may be affected. 490 3.3. Fixing Capability Mismatches 492 3.3.1. General Information and Requirements 494 SBCs fixing capability mismatches enable communications between user- 495 agents with different capabilities or extensions. For example, user- 496 agents on networks which implement SIP differently (for example 3GPP 497 or Packet Cable etc) or those that support different IP versions, 498 different codecs, or that are in different address realms. Operators 499 have a requirement and a strong motivation for performing capability 500 mismatch fixing, so that they can provide transparent communication 501 across different domains. In some cases different SIP extensions or 502 methods to implement the same SIP application (like monitoring 503 session liveness, call history/diversion etc) may also be interworked 504 through the SBC. 506 3.3.2. Architectural Issues 508 SBCs fixing capability mismatches insert a media element in the media 509 path using the procedures described in Section 3.2. Therefore, these 510 SBCs have the same concerns as SBCs performing traffic shaping: the 511 SBC modifies SIP messages without explicit consent from any of the 512 user-agents. This may break end-to-end security and application 513 extensions negotiation. 515 The capability mismatch fixing is a fragile function in the long 516 term. The number of incompatibilities built into various network 517 elements is increasing the fragility and complexity over time. This 518 might lead to a situation where SBCs need to be able to handle a 519 large number of capability mismatches in parallel. 521 3.3.3. Example 523 Consider the following example scenario where the inner network is an 524 access network using IPv4 and the outer network is using IPv6. The 525 SBC receives an INVITE request with a session description from the 526 access network: 528 INVITE sip:callee@ipv6.domain.example.com SIP/2.0 529 Via: SIP/2.0/UDP 192.0.2.4 530 Contact: sip:caller@u1.example.com 532 v=0 533 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 534 c=IN IP4 192.0.2.4 535 m=audio 49230 RTP/AVP 96 536 a=rtpmap:96 L8/8000 538 Figure 8: Request Prior to Capabilities Match 540 Then the SBC performs a capability mismatch fixing function. In this 541 scenario the SBC inserts Record-Route and Via headers, and rewrites 542 the 'c' line from the sessions descriptor. Figure 9 shows the 543 request after the capability mismatch adjustment. 545 INVITE sip:callee@ipv6.domain.com SIP/2.0 546 Record-Route: 547 Via: SIP/2.0/UDP sip:[2001:DB8::801:201:2ff:fe94:8e10] 548 Via: SIP/2.0/UDP 192.0.2.4 549 Contact: sip:caller@u1.example.com 551 v=0 552 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 553 c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10 554 m=audio 49230 RTP/AVP 96 555 a=rtpmap:96 L8/8000 557 Figure 9: Request After Capability Match 559 This message is then sent by the SBC to the onward IPv6 network. 561 3.4. Maintaining SIP-related NAT Bindings 563 3.4.1. General Information and Requirements 565 NAT traversal in this instance refers to the specific message 566 modifications required to assist a user-agent in maintaining SIP and 567 media connectivity when there is a NAT device located between a user- 568 agent and a proxy/registrar and, possibly, any other user-agent. 570 An SBC performing a NAT (Network Address Translator) traversal 571 function for a user agent behind a NAT sits between the user-agent 572 and the registrar of the domain. NATs are widely deployed in various 573 access networks today, so operators have a requirement to support it. 574 When the registrar receives a REGISTER request from the user-agent 575 and responds with a 200 (OK) response, the SBC modifies such a 576 response decreasing the validity of the registration (i.e., the 577 registration expires sooner). This forces the user-agent to send a 578 new REGISTER to refresh the registration sooner that it would have 579 done on receiving the original response from the registrar. The 580 REGISTER requests sent by the user-agent refresh the binding of the 581 NAT before the binding expires. 583 Note that the SBC does not need to relay all the REGISTER requests 584 received from the user-agent to the registrar. The SBC can generate 585 responses to REGISTER requests received before the registration is 586 about to expire at the registrar. Moreover, the SBC needs to 587 deregister the user-agent if this fails to refresh its registration 588 in time, even if the registration at the registrar would still be 589 valid. 591 Operators implement this functionality in an SBC instead of in the 592 registrar for several reasons: (i) preventing packets from 593 unregistered users to prevent chances of DoS attack, (ii) 594 prioritization and/or re-routing of traffic (based on user or 595 service, like E911) as it enters the network, and (iii) performing a 596 load balancing function or reducing the load on other network 597 equipment. 599 SBCs can also force traffic to go through a media relay for NAT 600 traversal purposes (more about media traffic shaping in Section 3.2). 601 A typical call has media streams to two directions. Even though SBCs 602 can force media streams from both directions to go through a media 603 relay, it is usually enough to relay only the media from one 604 direction. 606 3.4.2. Architectural Issues 608 This approach to NAT traversal does not work when end-to-end 609 confidentiality or integrity-protection is used. The SBC would be 610 seen as a MitM modifying the messages between the user-agent and the 611 registrar. 613 There is also a problem related to the method how SBCs choose the 614 value for the validity of a registration period. This value should 615 be as high as possible, but it still needs to be low enough to 616 maintain the NAT binding. Typically SBCs do not have any 617 deterministic method for choosing a suitable value. 619 3.4.3. Example 621 Consider the following example scenario: The SBC resides between the 622 UA and Registrar. Previously the UA has sent a REGISTER request to 623 Registrar, and the SBC receives the registration response shown in 624 Figure 10. 626 SIP/2.0 200 OK 627 From: Bob ;tag=a73kszlfl 628 To: Bob ;tag=34095828jh 629 CSeq: 1 REGISTER 630 Contact: ;expires=3600 632 Figure 10: Response Prior to NAT Maintenance Function 634 When performing the NAT traversal function, the SBC may re-write the 635 expiry time to coax the UA to re-register prior to the intermediating 636 NAT deciding to close the pinhole. Figure 11 shows a possible 637 modification of the response from Figure 10. 639 SIP/2.0 200 OK 640 From: Bob ;tag=a73kszlfl 641 To: Bob ;tag=34095828jh 642 CSeq: 1 REGISTER 643 Contact: ;expires=60 645 Figure 11: Manipulated Response for NAT Traversal 647 Naturally also other measures need to be taken in order to enable the 648 NAT traversal, but this example illustrates only one mechanism for 649 preserving the SIP related NAT bindings. 651 3.5. Access Control 653 3.5.1. General Information and Requirements 655 Network operators may wish to control what kind of signaling and 656 media traffic their network carries. There is strong motivation and 657 a requirement to do access control on the edge of an operator's 658 network. Access control can be based on, for example, link-layer 659 identifiers, IP addresses or SIP identities. 661 This function can be implemented by protecting the inner network with 662 firewalls and configuring them so that they only accept SIP traffic 663 from the SBC. This way, all the SIP traffic entering the inner 664 network needs to be routed though the SBC, which only routes messages 665 from authorized parties or traffic that meets a specific policy that 666 is expressed in the SBC administratively. 668 Access control can be applied either only to the signaling, or to 669 both the signaling and media. If it is applied only to the 670 signaling, then the SBC might behave as a proxy server. If access 671 control is applied to both the signaling and media, then the SBC 672 behaves in a similar manner as explained in Section 3.2. A key part 673 of media-layer access control is that only media for authorized 674 sessions is allowed to pass through the SBC and/or associated media 675 relay devices. 677 In environments where there is limited bandwidth on the access links, 678 the SBC can compute the potential bandwidth usage by examining the 679 codecs present in SDP offers and answers. With this information, the 680 SBC can reject sessions before the available bandwidth is exhausted 681 to allow existing sessions to maintain acceptable quality of service. 682 Otherwise, the link could become over subscribed and all sessions 683 would experience a deterioration in quality of service. SBCs may 684 contact a policy server to determine whether sufficient bandwidth is 685 available on a per-session basis. 687 3.5.2. Architectural Issues 689 Since the SBC needs to handle all SIP messages, this function has 690 scalability implications. In addition, the SBC is a single point of 691 failure from an architectural point of view. Although, in practice, 692 many current SBCs have the capability to support redundant 693 configuration, which prevents the loss of calls and/or sessions in 694 the event of a failure on a single node. 696 If access control is performed only on behalf of signaling, then the 697 SBC is compatible with general SIP architectural principles, but if 698 it is performed for signaling and for media, then there are similar 699 problems as described in Section 3.2.2. 701 3.5.3. Example 703 Figure 12 shows a callflow where the SBC is providing both signaling 704 and media access control (ACKs omitted for brevity). 706 caller SBC callee 707 | | | 708 | Identify the caller | | 709 |<- - - - - - - - - - - >| | 710 | | | 711 | INVITE + SDP | | 712 |----------------------->| | 713 | [Modify the SDP] | 714 | | INVITE + modified SDP | 715 | |----------------------->| 716 | | | 717 | | 200 OK + SDP | 718 | |<-----------------------| 719 | [Modify the SDP] | 720 | | | 721 | 200 OK + modified SDP | | 722 |<-----------------------| | 723 | | | 724 | Media [Media inspection] Media | 725 |<======================>|<======================>| 726 | | | 728 Figure 12: Example Access Callflow 730 In this scenario, the SBC first identifies the caller, so it can 731 determine whether or not to give signaling access for the caller. 732 This might be achieved using information gathered during 733 registration, or by other means. Some SBCs may rely on the proxy to 734 authenticate the user-agent placing the call. After identification, 735 the SBC modifies the session descriptors in INVITE and 200 OK 736 messages in a way that the media is going to flow through SBC itself. 737 When the media starts flowing, the SBC can inspect whether the callee 738 and caller use the codec(s) that they had previously agreed on. 740 3.6. Protocol Repair 742 3.6.1. General Information and Requirements 744 SBC are also used to repair protocol messages generated by not-fully- 745 standard clients. Operators may wish to support protocol repair, if 746 they want to support as many clients as possible. It is noteworthy, 747 that this function affects only the signaling component of SBC, and 748 that protocol repair function is not the same as protocol conversion. 750 3.6.2. Architectural Issues 752 In most cases, this function can be seen as being compatible with SIP 753 architectural principles, and it does not violate the end-to-end 754 model of SIP. The SBC repairing protocol messages behaves as a proxy 755 server that is liberal in what it accepts and strict in what it 756 sends. 758 A similar problem related to increasing complexity, as explained in 759 Section 3.3.2, also affects protocol repair function. 761 3.6.3. Examples 763 The SBC can, for example, receive an INVITE message from a relatively 764 new SIP UA as illustrated in Figure 13. 766 INVITE sip:callee@sbchost.example.com 767 Via: SIP/2.0/UDP u1.example.com:5060;lr 768 From: Caller 769 To: Callee 770 Call-ID: 18293281@u1.example.com 771 CSeq: 1 INVITE 772 Contact: sip:caller@u1.example.com 774 Figure 13: Request from a relatively new client 776 If the SBC does protocol repair, it can re-write the 'lr' parameter 777 on the Via header field into the form 'lr=true', in order to support 778 some older, non-standard SIP stacks. It could also remove excess 779 white spaces to make the SIP message more human readable. 781 3.7. Media Encryption 783 3.7.1. General Information and Requirements 785 SBCs are used to perform media encryption / decryption at the edge of 786 the network. This is the case when media encryption is used only on 787 the access network (outer network) side and the media is carried 788 unencrypted in the inner network. Operators may have an obligation 789 to provide the ability to do legal interception, while they still 790 want to give their customers the ability to encrypt media in the 791 access network. This leads to a situation where operators have a 792 requirement to perform media encryption function. 794 3.7.2. Architectural Issues 796 While performing a media encryption function, SBCs need to be able to 797 inject either themselves, or some other entity to the media path. 798 Due to this, the SBCs have the same architectural issues as explained 799 in Section 3.2. 801 3.7.3. Example 803 Figure 14 shows an example where the SBC is performing media 804 encryption related functions (ACKs omitted for brevity). 806 caller SBC#1 SBC#2 callee 807 | | | | 808 | INVITE + SDP | | | 809 |------------------->| | | 810 | [Modify the SDP] | | 811 | | | | 812 | | INVITE + mod. SDP | | 813 | |------------------->| | 814 | | [Modify the SDP] | 815 | | | | 816 | | | INVITE + mod. SDP | 817 | | |------------------->| 818 | | | | 819 | | | 200 OK + SDP | 820 | | |<-------------------| 821 | | [Modify the SDP] | 822 | | | | 823 | | 200 OK + mod. SDP | | 824 | |<-------------------| | 825 | [Modify the SDP] | | 826 | | | | 827 | 200 OK + mod. SDP | | | 828 |<-------------------| | | 829 | | | | 830 | Encrypted | Plain | Encrypted | 831 | media [enc./dec.] media [enc./dec.] media | 832 |<==================>|<- - - - - - - - ->|<==================>| 833 | | | | 835 Figure 14: Media Encryption Example 837 First the UAC sends an INVITE request , and the first SBC modifies 838 the session descriptor in a way that it injects itself to the media 839 path. The same happens in the second SBC. Then the UAS replies with 840 a 200 OK response, the SBCs inject themselves in the returning media 841 path. After signaling the media start flowing, and both SBCs are 842 performing media encryption and decryption. 844 4. Derived Requirements for Future SIP Standardization Work 846 Some of the functions listed in this document are more SIP-unfriendly 847 than others. This list requirements that are derived from the 848 functions that break the principles of SIP in one way or another. 849 The derived requirements are: 851 Req-1: There should be a SIP-friendly way to hide network topology 852 information. Currently this is done by stripping and 853 replacing header fields, which is against the principles of 854 SIP. 855 Req-2: There should be a SIP-friendly way to direct media traffic 856 through intermediaries. Currently this is done without user 857 consent by modifying session descriptors, which is against 858 the principles of SIP. 859 Req-3: There should be a SIP-friendly way to fix capability 860 mismatches in SIP messages. This requirement is harder to 861 fulfill on complex mismatch cases, like the 3GPP/Packet Cable 862 mismatch. Currently this is done by modifying SIP messages, 863 which violates end-to-end security. 865 All the above-mentioned requirements are such that they do not have 866 an existing solution today. Thus, future work is needed in order to 867 develop solutions to these requirements. 869 5. Security Considerations 871 Many of the functions this document describes have important security 872 and privacy implications. One major security problem is that many 873 functions implemented by SBCs (e.g., topology hiding and media 874 traffic shaping) modify SIP messages and their bodies without the 875 user agents' consent. The result is that the user agents may 876 interpreted the actions taken by SBC as a MitM attack. 878 SBCs that place themselves (or another entity) on the media path can 879 be used to eavesdrop conversations. Since, often, user agents cannot 880 distinguish between the actions of an attacker and those of a SBC, 881 users cannot know whether they are being eavesdropped or a SBC on the 882 path is performing some other function. 884 A SBC is a single point of failure form the architectural point of 885 view. This makes it an attractive target for DoS attacks. The fact 886 that some functions of SBCs require those SBCs to maintain session 887 specific information makes the situation even worse. If the SBC 888 crashes (or is brought down by an attacker), ongoing sessions 889 experience undetermined behavior. 891 If the IETF decides to develop standard mechanisms to address the 892 requirements presented in Section 4, the security and privacy-related 893 aspects of those mechanisms will, of course, need to be taken into 894 consideration. 896 6. IANA Considerations 898 This document has no IANA considerations. 900 7. Acknowledgements 902 The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC 903 during the 61st IETF meeting, provided valuable input to this 904 document. Authors would also like to thank Sridhar Ramachandran, 905 Gaurav Kulshreshtha, and Rakendu Devdhar. Reviewers Spencer Dawkins 906 and Francois Audet also deserve special thanks. 908 8. References 910 8.1. Normative References 912 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 913 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 914 Session Initiation Protocol", RFC 3261, June 2002. 916 [2] Peterson, J., "A Privacy Mechanism for the Session Initiation 917 Protocol (SIP)", RFC 3323, November 2002. 919 [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated 920 Identity Management in the Session Initiation Protocol (SIP)", 921 RFC 4474, August 2006. 923 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 924 Session Description Protocol (SDP)", RFC 3264, June 2002. 926 8.2. Informational References 928 [5] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 929 5.15.0, June 2006. 931 [6] Handley, M. and V. Jacobson, "SDP: Session Description 932 Protocol", RFC 2327, April 1998. 934 Authors' Addresses 936 Jani Hautakorpi (editor) 937 Ericsson 938 Hirsalantie 11 939 Jorvas 02420 940 Finland 942 Email: Jani.Hautakorpi@ericsson.com 944 Gonzalo Camarillo 945 Ericsson 946 Hirsalantie 11 947 Jorvas 02420 948 Finland 950 Email: Gonzalo.Camarillo@ericsson.com 952 Robert F. Penfield 953 Acme Packet 954 71 Third Avenue 955 Burlington, MA 01803 956 US 958 Email: bpenfield@acmepacket.com 960 Alan Hawrylyshen 961 Ditech Networks Inc. 962 Suite 200, 1167 Kensington Cres NW 963 Calgary, Alberta T2N 1X7 964 Canada 966 Email: ahawrylyshen@ditechnetworks.com 968 Medhavi Bhatia 969 3CLogic 970 9700 Great Seneca Hwy. 971 Rockville, MD 20850 972 US 974 Email: mbhatia@3clogic.com 976 Full Copyright Statement 978 Copyright (C) The IETF Trust (2007). 980 This document is subject to the rights, licenses and restrictions 981 contained in BCP 78, and except as set forth therein, the authors 982 retain all their rights. 984 This document and the information contained herein are provided on an 985 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 986 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 987 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 988 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 989 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 990 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 992 Intellectual Property 994 The IETF takes no position regarding the validity or scope of any 995 Intellectual Property Rights or other rights that might be claimed to 996 pertain to the implementation or use of the technology described in 997 this document or the extent to which any license under such rights 998 might or might not be available; nor does it represent that it has 999 made any independent effort to identify any such rights. Information 1000 on the procedures with respect to rights in RFC documents can be 1001 found in BCP 78 and BCP 79. 1003 Copies of IPR disclosures made to the IETF Secretariat and any 1004 assurances of licenses to be made available, or the result of an 1005 attempt made to obtain a general license or permission for the use of 1006 such proprietary rights by implementers or users of this 1007 specification can be obtained from the IETF on-line IPR repository at 1008 http://www.ietf.org/ipr. 1010 The IETF invites any interested party to bring to its attention any 1011 copyrights, patents or patent applications, or other proprietary 1012 rights that may cover technology that may be required to implement 1013 this standard. Please address the information to the IETF at 1014 ietf-ipr@ietf.org. 1016 Acknowledgment 1018 Funding for the RFC Editor function is provided by the IETF 1019 Administrative Support Activity (IASA).