idnits 2.17.1 draft-ietf-sipping-sbc-funcs-00.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 on line 997. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 981. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 987. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (November 24, 2006) is 6356 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '4') (Obsoleted by RFC 4566) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 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 Expires: May 28, 2007 Ericsson 5 R. Penfield 6 Acme Packet 7 A. Hawrylyshen 8 Ditech Networks Inc. 9 M. Bhatia 10 NexTone Communications 11 November 24, 2006 13 Requirements from SIP (Session Initiation Protocol) Session Border 14 Control Deployments 15 draft-ietf-sipping-sbc-funcs-00.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 May 28, 2007. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This documents describes functions implemented in Session Initiation 49 Protocol (SIP) intermediaries known as Session Border Controllers 50 (SBCs). Although the goal of this document is to describe all the 51 functions of SBCs, a special focus is given to those practices that 52 are viewed to be in conflict with SIP architectural principles. It 53 also explores the underlying requirements of network operators that 54 have led to the use of these functions and practices in order to 55 identify protocol requirements and determine whether those 56 requirements are satisfied by existing specifications or additional 57 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 . . . . . . . . . . . . . . . . . . . . . 7 67 3.1.1. General Information and Requirements . . . . . . . . . 7 68 3.1.2. Architectural Issues . . . . . . . . . . . . . . . . . 8 69 3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.2. Media Traffic Shaping . . . . . . . . . . . . . . . . . . 9 71 3.2.1. General Information and Requirements . . . . . . . . . 9 72 3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 10 73 3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 13 79 3.4.1. General Information and Requirements . . . . . . . . . 13 80 3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 14 81 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 14 82 3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 15 83 3.5.1. General Information and Requirements . . . . . . . . . 15 84 3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 16 85 3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 16 86 3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 17 87 3.6.1. General Information and Requirements . . . . . . . . . 17 88 3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 17 89 3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 18 90 3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 19 91 3.7.1. General Information and Requirements . . . . . . . . . 19 92 3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 19 93 3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19 94 4. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 20 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 100 8.2. Informational References . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 102 Intellectual Property and Copyright Statements . . . . . . . . . . 24 104 1. Introduction 106 In the past few years there has been a rapid adoption of Session 107 Initiation Protocol (SIP) [1] and deployment of SIP-based 108 communications networks. This has often out-paced the development 109 and implementation of protocol specifications to meet network 110 operator requirements. This has led to the development of 111 proprietary solutions. Often these proprietary solutions are 112 implemented in network intermediaries known in the marketplace as 113 Session Border Controllers (SBCs) because they typically are deployed 114 at the border between two networks. The reason for this is that 115 network policies are typically enforced at the edge of the network. 117 Even though many SBCs currently break things like end-to-end security 118 and can impact feature negotiations, there is clearly a market for 119 them. Network operators need many of the features current SBCs 120 provide and many times there are no standard mechanisms available to 121 provide them in a better way. This document describes the most 122 common functions of current SBCs and the reasons that network 123 operators require them. It also describes the architectural issues 124 with these functions. Although this document focuses on functions 125 common to SBCs, many of the issues raised apply to other types of 126 Back-to-Back User Agents (B2BUAs.) 128 2. Background on SBCs 130 The term SBC is relatively non-specific, since it is not standardized 131 or defined anywhere. Nodes that may be referred to as SBCs but do 132 not implement SIP are outside the scope of this document. 134 SBCs usually sit between two service provider networks in a peering 135 environment, or between an access network and a backbone network to 136 provide service to residential and/or enterprise customers. They 137 provide a variety of functions to enable or enhance session-based 138 multi-media services (e.g., Voice over IP). These functions include: 139 a) perimeter defense (access control, topology hiding, DoS 140 prevention, and detection); b) functionality not available in the 141 endpoints (NAT traversal, protocol interworking or repair); and c) 142 network management (traffic monitoring, shaping, and QoS). Some of 143 these functions may also get integrated into other SIP elements (like 144 pre-paid platforms, 3GPP P-CSCF, 3GPP I-CSCF etc). 146 SIP-based SBCs typically handle both signaling and media and can 147 implement behavior which is equivalent to a "privacy service" (as 148 described in[2]) performing both Header Privacy and Session Privacy. 149 SBCs often modify certain SIP headers and message bodies that proxies 150 are not allowed to modify. Consequently, they are, by definition, 151 B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs 152 varies depending on the functions they perform. For example, some 153 SBCs modify the session description carried in the message and insert 154 a Record-Route entry. Other SBCs replace the value of the Contact 155 header field with the SBCs address, and generate a new Call-ID and 156 new To and From tags. 158 +-----------------+ 159 | SBC | 160 [signaling] | +-----------+ | 161 <------------|->| signaling |<-|----------> 162 outer | +-----------+ | inner 163 network | | | network 164 | +-----------+ | 165 <------------|->| media |<-|----------> 166 [media] | +-----------+ | 167 +-----------------+ 169 Figure 1: SBC architecture 171 Figure 1 shows the logical architecture of an SBC, which includes a 172 signaling and a media component. In this document, the terms outer 173 and inner network are used for describing these two networks. 175 2.1. Peering Scenario 177 A typical peering scenario involves two network operators who 178 exchange traffic with each other. For example, in a toll bypass 179 application, a gateway in operator A's network sends an INVITE that 180 is routed to the softswitch (proxy) in operator B's network. The 181 proxy responds with a redirect (3xx) message back to the originating 182 gateway that points to the appropriate terminating gateway in 183 operator B's network. The originating gateway then sends the INVITE 184 to the terminating gateway. 186 Operator A . Operator B 187 . 188 . 2) INVITE 189 +-----+ . /--------------->+-----+ 190 | SSA | . / 3) 3xx (redir.) | SSB | 191 +-----+ . / /---------------+-----+ 192 . / / 193 +-----+ 1) INVITE +-----+--/ / +-----+ 194 |GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1| 195 +-----+ +-----+---------------------->+-----+ 196 . 197 +-----+ . +-----+ 198 |GW-A2| . |GW-B2| 199 +-----+ . +-----+ 201 Figure 2: Peering with SBC 203 Figure 2 illustrates the peering arrangement with a SBC where 204 Operator A is the outer network, and Operator B is the inner network. 205 Operator B uses the SBC to control access to its network, protect its 206 gateways and softswitches from unauthorized use and DoS attacks, and 207 monitor the signaling and media traffic. It also simplifies network 208 management by minimizing the number ACL (Access Control List) entries 209 in the gateways. The gateways do not need to be exposed to the peer 210 network, and they can restrict access (both media and signaling) to 211 the SBCs. The SBC helps ensure that only media from sessions the SBC 212 authorizes will reach the gateway. 214 2.2. Access Scenario 216 In an access scenario, presented in Figure 3, the SBC is placed at 217 the border between the access network (outer network) and the 218 operator's network (inner network) to control access to the operator 219 network, protect its components (media servers, application servers, 220 gateways, etc.) from unauthorized use and DoS attacks, and monitor 221 the signaling and media traffic. Also, as a part of access control, 222 since the SBC is call stateful, it can prevent over subscription of 223 the access links. Endpoints are configured with the SBC as their 224 outbound proxy address. The SBC routes requests to one or more 225 proxies in the operator network. 227 Access Network . Operator Network 228 . 229 +-----+ . 230 | UA1 |<---------\ . 231 +-----+ \ . 232 \ . 233 +-----+ \------->+-----+ +-------+ 234 | UA2 |<-------------------->| SBC |<----->| proxy |<-- - 235 +-----+ /--->+-----+ +-------+ 236 / . 237 +-----+ +-----+ / . 238 | UA3 +---+ NAT |<---/ . 239 +-----+ +-----+ . 241 Figure 3: Access scenario with SBC 243 Some endpoints may be behind enterprise or residential NATs. In 244 cases where the access network is a private network, the SBC is the 245 NAT for all traffic. The proxy usually does authentication and/or 246 authorization for registrations and outbound calls. The SBC modifies 247 the REGISTER request so that subsequent requests to the registered 248 address-of-record are routed to the SBC. This is done either with a 249 Path header, or by modifying the Contact to point at the SBC. 251 3. Functions of SBCs 253 This section lists those functions that are used in SBC deployments 254 in current communication networks. Each subsection describes a 255 particular function or feature, the operators' requirements for 256 having it, explanation on any impact to the end-to-end SIP 257 architecture, and a concrete implementation example. Each section 258 also discusses potential concerns specific to that particular 259 implementation technique. Suggestions for alternative implementation 260 techniques that may be more architecturally compatible with SIP are 261 outside the scope of this document. 263 All the examples given in this section are simplified; only the 264 relevant header lines from SIP and SDP [4] messages are displayed. 266 3.1. Topology Hiding 268 3.1.1. General Information and Requirements 270 Topology hiding consists of limiting the amount of topology 271 information given to external parties. Operators have a requirement 272 for this functionality because they do not want the IP addresses of 273 their equipment (proxies, gateways, application servers, etc) to be 274 exposed to outside parties. This may be because they do not want to 275 expose their equipment to DoS (Denial of Service) attacks, they may 276 use other carriers for certain traffic and do not want their 277 customers to be aware of it or they may want to hide their internal 278 network architecture from competitors or partners. In some 279 environments, the operator's customers may wish to hide the addresses 280 of their equipment or the SIP messages may contain private, non- 281 routable addresses. 283 The most common form of topology hiding is the application of header 284 privacy (see Section 5.1 of [2]), which involves stripping Via and 285 Record-Route headers and replacing the Contact header. However, in 286 deployments which use IP addresses instead of domain names in headers 287 that cannot be removed (e.g. From and To headers), the SBC may 288 replace these IP addresses with its own IP address or domain name. 290 3.1.2. Architectural Issues 292 This functionality is based on a hop-by-hop trust model as opposed to 293 an end-to-end trust model. The messages are modified without 294 subscriber consent and could potentially modify or remove information 295 about the user's privacy, security requirements and higher layer 296 applications which are communicating end-to-end using SIP. Either 297 user in an end-to-end call may perceive this as a Man In The Middle 298 (MitM) attack. 300 Modification of IP addresses in Unifor Resource Indetifiers (URIs) 301 within SIP headers can lead to application failures if these URIs are 302 communicated to other SIP servers outside the current dialog. These 303 URIs could appear in a REFER request or in the body of NOTIFY request 304 as part of an event package. If these messages traverse the same 305 SBC, it has the opportunity to restore the original IP address. On 306 the other hand, if the REFER or NOTIFY message returns to the 307 original network through a different SBC that does not have access to 308 the address mapping, the recipient of the message will not see the 309 original address. This may cause the application function to 310 fail.[[Comment.1: Do we have a sane example of where this is a real 311 problem? It sounds somewhat contrived to me, but I agree it is a 312 theoretical concern - Alan.]][[Comment.2: I personally would like to 313 include this text, although it might be more of a theoretical 314 concern. - Jani]] 316 3.1.3. Example 318 The current way of implementing topology hiding consists of having an 319 SBC act as a B2BUA (Back-to-Back User Agents) and remove all traces 320 of topology information (e.g., Record-Route and Via entries) from 321 outgoing messages. 323 Imagine the following example scenario: The SBC 324 (p4.domain.example.com) is receiving an INVITE request from the inner 325 network, which in this case is an operator network. The received SIP 326 message is shown in Figure 4. 328 INVITE sip:callee@u2.domain.example.com SIP/2.0 329 Contact: sip:caller@u1.example.com 330 Record-Route: 331 Record-Route: 332 Record-Route: 334 Figure 4: INVITE Request Prior to Topology Hiding 336 Then the SBC performs a topology hiding function. In this scenario, 337 the SBC removes and stores all existing Record-Route headers, and 338 then inserts a Record-Route header field with its own SIP URI. After 339 the topology hiding function, the message could appear as shown in 340 Figure 5. 342 INVITE sip:callee@u2.domain.example.com SIP/2.0 343 Contact: sip:caller@u1.example.com 344 Record-Route: 346 Figure 5: INVITE Request After Topology Hiding 348 Like a regular proxy server that inserts a Record-Route entry, the 349 SBC handles every single message of a given SIP dialog. If the SBC 350 loses state (e.g., the SBC restarts for some reason), it may not be 351 able to route messages properly. For example, if the SBC removes 352 "Via" entries from a request and then restarts losing state, the SBC 353 may not be able to route responses to that request; depending on the 354 information that was lost when the SBC restarted. [[Comment.3: There 355 are techniques to mitigate this problem, not all SBCs suffer from 356 this. Is this worth capturing in the text? [Alan]]][[Comment.4: No, 357 not all suffer from this, but some do, so I believe we shouldn't 358 remove this text. - Jani]] 360 This is only one example of topology hiding, in some cases, SBCs may 361 modify other headers, including the Contact header field values. 363 3.2. Media Traffic Shaping 365 3.2.1. General Information and Requirements 367 Media traffic shaping is the act of controlling media traffic. 368 Network operators may require this functionality in order to control 369 the traffic being carried on their network on behalf of their 370 subscibers. Traffic shaping helps create different kinds of billing 371 models (e.g., video telephony can be priced differently than voice- 372 only calls). Additionally, traffic shaping can be used to implement 373 intercept capabilities where required to support audit or legal 374 obligations. 376 Since the media path is independent of the signaling path, the media 377 may not traverse through the operator's network unless the SBC 378 modifies the session description. By modifying the session 379 description the SBC can force the media to be sent through a media 380 relay which may be co-located with the SBC. 382 Some operators do not want to reshape the traffic, but only to 383 monitor it for collecting statistics and making sure that they are 384 able to meet any business service level agreements with their 385 subscribers and/or partners. The protocol techniques needed for 386 monitoring media traffic are the same as for reshaping media traffic. 388 SBCs on the media path are also capable of dealing with the "lost 389 BYE" issue if either endpoint dies in the middle of the session. The 390 SBC can detect that the media has stopped flowing and issue a BYE to 391 the both sides to cleanup any state in other intermediate elements 392 and the endpoints. 394 One possible form of media traffic shaping is that SBCs terminate 395 media streams and SIP dialogs by generating BYE requests. This kind 396 of procedure can take place e.g., in a situation where subscriber 397 runs out of credits. 399 3.2.2. Architectural Issues 401 Implementing traffic shaping in this manner requires the SBC to 402 access and modify the session descriptions (i.e., offers and answers) 403 exchanged between the user agents. Consequently, this approach does 404 not work if user agents encrypt or integrity-protect their message 405 bodies end-to-end. Again, messages are modified without subscriber 406 consent, and user agents do not have any way to distinguish the SBC 407 actions from an attack by a MitM (Man-in-the-Middle). 409 In this application, the SBC may originate messages that the user may 410 not be able to authenticate as coming from the dialog peer or the SIP 411 Registrar/Proxy. 413 3.2.3. Example 415 Traffic shaping may be performed in the following way: The SBC 416 behaves as a B2BUA and inserts itself, or some other entity under the 417 operator's control, in the media path. In practice, the SBC modifies 418 the session descriptions carried in the SIP messages. As a result, 419 the SBC receives media from one user agent and relays it to the other 420 user-agent and performs the identical operation with media traveling 421 in the reverse direction. 423 CODEC restriction is an example application of traffic shaping. The 424 SBC restricts the codec set negotiated in the offer/answer exchange 425 [3] between the user agents. After modifying the session 426 descriptions, the SBC can check whether or not the media stream 427 corresponds to what was negotiated in the offer/answer exchange. If 428 it differs, the SBC has the ability to terminate the media stream or 429 take other appropriate (configured) actions (e.g. alarming or 430 reporting). 432 Consider the following example scenario: The SBC receives an INVITE 433 request from the one network, which in this case is an access 434 network. The received SIP message contains the SDP session 435 descriptor shown in Figure 6. 437 v=0 438 o=mhandley 2890844526 2890842807 IN IP4 10.16.64.4 439 c=IN IP4 10.16.64.4 440 m=audio 49230 RTP/AVP 96 98 441 a=rtpmap:96 L8/8000 442 a=rtpmap:98 L16/16000/2 444 Figure 6: Request Prior to Media Shaping 446 In this example, the SBC performs the media traffic shaping function 447 by rewritting the 'm' line, and removing one 'a' line according to 448 some (external) policy. Figure 7 shows the session description after 449 the traffic shaping function. 451 v=0 452 o=mhandley 2890844526 2890842807 IN IP4 10.16.64.4 453 c=IN IP4 10.16.64.4 454 m=audio 49230 RTP/AVP 96 455 a=rtpmap:96 L8/8000 457 Figure 7: Request Body After Media Shaping 459 One problem with media traffic shaping is that the SBC needs to 460 understand the session description protocol and all extensions used 461 by the user agents. This means that in order to use a new extension 462 (e.g., an extension to implement a new service) or a new session 463 description protocol, SBCs in the network may need to be upgraded in 464 conjunction with the endpoints. Certain extensions that do not 465 require active manipulation of the session descriptors to facilitate 466 traffic shaping will be able to be deployed without upgrading 467 existing SBCs, depending on the degree of transparency the SBC 468 implementation affords. In cases requiring an SBC modification to 469 support the new protocol features, the rate of service deployment may 470 be affected. [[Comment.5: I do not think this will slow down 471 innovation; innovation is a distinct phase of development and 472 separable from operational network deployment. -Alan]][[Comment.6: I 473 don't quite get what you are suggesting. If you want to change the 474 text, go ahead. - Jani]] 476 3.3. Fixing Capability Mismatches 478 3.3.1. General Information and Requirements 480 SBCs fixing capability mismatches enable communications between user 481 agents with different capabilities, SIP profiles or extensions. For 482 example, user agents on networks which implement different SIP 483 Profiles (for example 3GPP or Packet Cable etc) or those that support 484 different IP versions, different codecs, or that are in different 485 address realms. Operators have a requirement and a strong motivation 486 for performing capability mismatch fixing, so that they can provide 487 transparent communication across different domains. In some cases 488 different SIP extensions or methods to implement the same SIP 489 application (like monitoring session liveness, call history/diversion 490 etc) may also be interworked through the SBC. 492 3.3.2. Architectural Issues 494 SBCs fixing capability mismatches insert a media element in the media 495 path using the procedures described in Section 3.2. Therefore, these 496 SBCs have the same concerns as SBCs performing traffic shaping: the 497 SBC modifies SIP messages without explicit consent from any of the 498 user agents. This may break end-to-end security and application 499 extensions negotiation. 501 [[Comment.7: I have removed the network engineering concern; this is 502 an unrealistic anti-Apple-Pie problem that could only arise through a 503 fundamental bug in either configuration or SBC implementation. 504 -Alan]][[Comment.8: Ok. - Jani]] 506 3.3.3. Example 508 Consider the following example scenario where the inner network is an 509 access network using IPv4 and the outer network is using IPv6. The 510 SBC receives an INVITE request with a session description from the 511 access network: 513 INVITE sip:callee@ipv6.domain.example.com SIP/2.0 514 Via: SIP/2.0/UDP 192.0.2.4 515 Contact: sip:caller@u1.example.com 517 v=0 518 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 519 c=IN IP4 192.0.2.4 520 m=audio 49230 RTP/AVP 96 521 a=rtpmap:96 L8/8000 523 Figure 8: Request Prior to Capabilities Match 525 Then the SBC performs a capability mismatch fixing function. In this 526 imagined situation the SBC inserts Record-Route and Via headers, and 527 rewrites the 'c' line from the sessions descriptor. Figure 9 shows 528 the request after the capability mismatch adjusment. 530 INVITE sip:callee@ipv6.domain.com SIP/2.0 531 Record-Route: 532 Via: SIP/2.0/UDP sip:[2001:620:8:801:201:2ff:fe94:8e10] 533 Via: SIP/2.0/UDP 192.0.2.4 534 Contact: sip:caller@u1.example.com 536 v=0 537 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 538 c=IN IP6 2001:620:8:801:201:2ff:fe94:8e10 539 m=audio 49230 RTP/AVP 96 540 a=rtpmap:96 L8/8000 542 Figure 9: Request After Capability Match 544 This message is then sent by the SBC to the onward IPv6 network. 546 3.4. NAT Traversal 548 3.4.1. General Information and Requirements 550 NAT traversal in this instance refers to the specific message 551 modifications required to assist a user-agent in maintaining SIP and 552 media connectivity when there is a NAT device located between the 553 user-agent and the proxy/registrar and, most likely, any other user- 554 agent. 556 An SBC performing a NAT (Network Address Translator) traversal 557 function for a user agent behind a NAT sits between the user agent 558 and the registrar of the domain. NATs are widely deployed in various 559 access networks today, so operators have a requirement to support it. 560 When the registrar receives a REGISTER request from the user agent 561 and responds with a 200 (OK) response, the SBC modifies such a 562 response decreasing the validity of the registration (i.e., the 563 registration expires sooner). This forces the user agent to send a 564 new REGISTER to refresh the registration sooner that it would have 565 done on receiving the original response from the registrar. The 566 REGISTER requests sent by the user agent refresh the binding of the 567 NAT before the binding expires. 569 Note that the SBC does not need to relay all the REGISTER requests 570 received from the user agent to the registrar. The SBC can generate 571 responses to REGISTER requests received before the registration is 572 about to expire at the registrar. Moreover, the SBC needs to 573 deregister the user agent if this fails to refresh its registration 574 in time, even if the registration at the registrar would still be 575 valid. 577 Operators implement this functionality in an SBC instead of in the 578 registrar for several reasons: (i) preventing packets from 579 unregistered users to prevent chances of DoS attack, (ii) 580 prioritization and/or re-routing of traffic (based on user or 581 service, like E911) as it enters the network, and (iii) performing a 582 load balancing function or reducing the load on other network 583 equipment. 585 Also other measures, such as acting as a media relay by modifying SDP 586 session descriptors (see Section 3.2), may be taken by SBC to ensure 587 media connectivity. 589 3.4.2. Architectural Issues 591 This approach to NAT traversal does not work when end-to-end 592 confidentiality or integrity-protection is used. The SBC would be 593 seen as a MitM modifying the messages between the user agent and the 594 registrar. 596 [[Comment.9: Is there something more specific to this function we can 597 put here? This is very generic and a general limitation of SBC 598 architectures.]][[Comment.10: If you want to add something, please 599 do. - Jani]] 601 3.4.3. Example 603 Consider the following example scenario: The SBC resides between the 604 UA and Registrar. Previously the UA has sent a REGISTER request to 605 Registrar, and the SBC receives the registration response shown in 606 Figure 10. 608 SIP/2.0 200 OK 609 From: Bob ;tag=a73kszlfl 610 To: Bob ;tag=34095828jh 611 CSeq: 1 REGISTER 612 Contact: ;expires=3600 614 Figure 10: Response Prior to NAT Maintenance Function 616 When performing the NAT traversal function, the SBC may re-write the 617 expiry time to coax the UA to re-register prior to the intermediating 618 NAT deciding to close the pinhole. Figure 11 shows a possible 619 modification of the response from Figure 10. 621 SIP/2.0 200 OK 622 From: Bob ;tag=a73kszlfl 623 To: Bob ;tag=34095828jh 624 CSeq: 1 REGISTER 625 Contact: ;expires=60 627 Figure 11: Manipulated Response for NAT Traversal 629 Naturally also other measures need to be taken in order to enable the 630 NAT traversal, but this example illustrates only one mechanism for 631 preserving the SIP related NAT bindings. 633 3.5. Access Control 635 3.5.1. General Information and Requirements 637 Network operators may wish to control what kind of signaling and 638 media traffic their network carries. There is strong motivation and 639 a requirement to do access control on the edge of an operator's 640 network. Access control can be based on, for example, IP addresses 641 or SIP identities. 643 This function can be implemented by protecting the inner network with 644 firewalls and configuring them so that they only accept SIP traffic 645 from the SBC. This way, all the SIP traffic entering the inner 646 network needs to be routed though the SBC, which only routes messages 647 from authorized parties or traffic that meets a specific policy that 648 is expressed in the SBC administratively. 650 Access control can be applied either only to the signaling, or to 651 both the signaling and media. If it is applied only to the 652 signaling, then the SBC might behave as a proxy server. If access 653 control is applied to both the signaling and media, then the SBC 654 behaves in a similar manner as explained in Section 3.2. A key part 655 of media-layer access control is that only media for authorized 656 sessions is allowed to pass through the SBC and/or associated media 657 relay devices. 659 In environments where there is limited bandwidth on the access links, 660 the SBC can compute the potential bandwidth usage by examining the 661 codecs present in SDP offers and answers. With this information, the 662 SBC can reject sessions before the available bandwidth is exhausted 663 to allow existing sessions to maintain acceptable quality of service. 664 Otherwise, the link could become over subscribed and all sessions 665 would experience a deterioration in quality of service. SBCs may 666 contact a policy server to determine whether sufficient bandwidth is 667 available on a per-session basis. 669 3.5.2. Architectural Issues 671 Since the SBC needs to handle all SIP messages, this function has 672 scalability implications. In addition, the SBC is a single point of 673 failure from an architectural point of view. Although, in practice, 674 many current SBCs have the capability to support redundant 675 configuration, which prevents the loss of calls and/or sessions in 676 the event of a failure on a single node. 678 [[Comment.11: I am tempted to remove this paragraph; this is a 679 general architectural problem that is not truly specific to SBCs. A 680 proxy configured into a SIP architecture that Record-Route'd requests 681 would ALSO be a single point of failure. Provisioning a network to 682 deal with the outage of a single element is just good design. 683 -Alan]][[Comment.12: I agree that this is not specific only to SBCs, 684 but is specific also to SBCs. I wouldn't like to remove this 685 paragraph. - Jani]] 687 If access control is performed only on behalf of signaling, then the 688 SBC is compatible with general SIP architectural principles, but if 689 it is performed for signaling and for media, then there are similar 690 problems as described in Section 3.2.2. 692 3.5.3. Example 694 Figure 12 shows a callflow where the SBC is providing both signaling 695 and media access control. 697 caller SBC callee 698 | | | 699 | Identify the caller | | 700 |<- - - - - - - - - - - >| | 701 | | | 702 | INVITE + SDP | | 703 |----------------------->| | 704 | [Modify the SDP] | 705 | | INVITE + modified SDP | 706 | |----------------------->| 707 | | | 708 | | 200 OK + SDP | 709 | |<-----------------------| 710 | [Modify the SDP] | 711 | | | 712 | 200 OK + modified SDP | | 713 |<-----------------------| | 714 | | | 715 | Media [Media inspection] Media | 716 |<======================>|<======================>| 717 | | | 719 Figure 12: Example Access Callflow 721 In this scenario, the SBC first identifies the caller, so it can 722 determine whether or not to give signaling access for the caller. 723 Some SBCs may rely on the proxy to authenticate the user-agent 724 placing the call. After authentication, the SBC modifies the session 725 descriptors in INVITE and 200 OK messages in a way that the media is 726 going to flow through SBC itself. When the media starts flowing, the 727 SBC can inspect whether the callee and caller use the codec(s) that 728 they had previously agreed on. 730 3.6. Protocol Repair 732 3.6.1. General Information and Requirements 734 SBC are also used to repair protocol messages generated by not-fully- 735 standard clients. Operators may wish to support protocol repair, if 736 they want to support as many client as possible. It is noteworthy, 737 that this function affects only the signaling component of SBC, and 738 that protocol repair function is not the same as protocol conversion. 740 3.6.2. Architectural Issues 742 In most cases, this function can be seen as being compatible with SIP 743 architectural principles, and it does not violate the end-to-end 744 model of SIP. The SBC repairing protocol messages behaves as a proxy 745 server that is liberal in what it accepts and strict in what it 746 sends. 748 3.6.3. Examples 750 The SBC can, for example, receive the an INVITE message from a not- 751 fully-standard client as illustrated in Figure 13. 753 INVITE sip:callee@sbchost.example.com 754 Via: SIP/2.0/UDP u1.example.com:5060;lr=1 755 From: Caller 756 To: Callee 757 Call-ID: 18293281@u1.example.com 758 CSeq: 1 INVITE 759 Contact: sip:caller@u1.example.com 761 Figure 13: Request from non-standard client 763 If the SBC does protocol repair, it can re-write the request line (in 764 this case the UAC did not put the target in the URI and instead put 765 the SBC hostname as the host portion). It could also remove excess 766 white spaces to make the SIP message more human readable. 768 Some other examples of "protocol repair" that have been implemented 769 in commercially available SBCs include: 771 o Changing Content-Disposition from "signal" to "session". This was 772 required for a user agent which sent an incorrect Content- 773 Disposition header. 774 o Addition of userinfo to a Contact URI when none was present. This 775 was required for a softswitch/proxy that would reject requests if 776 the Contact URI had no user part. 777 o Addition of a to-tag to provisional or error responses. 778 o Re-ordering of Contact header values in a REGISTER response. This 779 was required for a user agent that would take the expires value 780 from the first Contact header value without matching it against 781 its Contact value. 782 o Correction of SDP syntax where the user agent used "annexb=" in 783 the fmtp attribute instead of the proper "annexb:". 784 o Correction of signaling errors (convert BYE to CANCEL) for 785 termination of early sessions. 786 o Repair of header parameters in 'archaic' or incorrect formats. 787 Some older stacks assume that parameters are always of the form 788 NAME=VALUE. For those elements, it is necessary to convert 789 'lr=true' or 'lr=1' to 'lr' in order to interoperate with several 790 commercially available stacks and proxies. 792 3.7. Media Encryption 794 3.7.1. General Information and Requirements 796 SBCs are used to perform media encryption / decryption at the edge of 797 the network. This is the case when media encryption is used only on 798 the access network (outer network) side and the media is carried 799 unencrypted in the inner network. Operators may have an obligation 800 to provide the ability to do legal interception, while they still 801 want to give their customers the ability to encrypt media in the 802 access network. This leads to a situation where operators have a 803 requirement to perform media encryption function. 805 3.7.2. Architectural Issues 807 While performing a media encryption function, SBCs need to be able to 808 inject either themselves, or some other entity to the media path. 809 Due to this, the SBCs have the same architectural issues as explained 810 in Section 3.2. 812 3.7.3. Example 814 Figure 14 shows an example where the SBC is performing media 815 encryption related functions. 817 caller SBC#1 SBC#2 callee 818 | | | | 819 | INVITE + SDP | | | 820 |------------------->| | | 821 | [Modify the SDP] | | 822 | | | | 823 | | INVITE + mod. SDP | | 824 | |------------------->| | 825 | | [Modify the SDP] | 826 | | | | 827 | | | INVITE + mod. SDP | 828 | | |------------------->| 829 | | | | 830 | | | 200 OK + SDP | 831 | | |<-------------------| 832 | | [Modify the SDP] | 833 | | | | 834 | | 200 OK + mod. SDP | | 835 | |<-------------------| | 836 | [Modify the SDP] | | 837 | | | | 838 | 200 OK + mod. SDP | | | 839 |<-------------------| | | 840 | | | | 841 | Encrypted | Plain | Encrypted | 842 | media [enc./dec.] media [enc./dec.] media | 843 |<==================>|<- - - - - - - - ->|<==================>| 844 | | | | 846 Figure 14: Media Encryption Example 848 First the UAC sends an INVITE request , and the first SBC modifies 849 the session descriptor in a way that it injects itself to the media 850 path. The same happens in the second SBC. Then the UAS replies with 851 a 200 OK response, the SBCs inject themselves in the returning media 852 path. After signaling the media start flowing, and both SBCs are 853 performing media encryption and decryption. 855 4. Derived Requirements 857 Some of the functions listed in this document are more SIP-unfriendly 858 than others. This list requirements that are derived from the 859 functions that break the principles of SIP in one way or the other. 860 The derived requirements are: 862 Req-1: There should be a SIP-friendly way to hide network topology 863 information. Currently this is done e.g., by stripping and 864 replacing header fields, which is against the principles of 865 SIP. 866 Req-2: There should be a SIP-friendly way to direct media traffic 867 through intermediaries. Currently this is done e.g., by 868 modifying session descriptors, which is against the principles 869 of SIP. 870 Req-3: There should be a SIP-friendly way to fix capability 871 mismatches in SIP messages. Currently this is done by 872 modifying SIP messages, which violates e.g., end-to-end 873 security. 875 All the above-mentioned requirements are such that they do not have 876 an existing solution today. Thus, future work is needed in order to 877 develop solutions to these requirements. 879 5. Security Considerations 881 Many of the functions this document describes have important security 882 and privacy implications. If the IETF decides to develop standard 883 mechanisms to address those functions, security and privacy-related 884 aspects will need to be taken into consideration. 886 [[Comment.13: I wonder if it is worth classifying the specific type 887 of security problems and assembling them here. The remainder of this 888 document can then refer to the specific problem a given operational 889 activity has given today's typically implementation mechanisms. 890 [Alan]]][[Comment.14: My gut feeling is that it would require a lot 891 of work. If you want to do it, go ahead, but at least I don't have 892 the time to do it. - Jani]] 894 6. IANA Considerations 896 This document has no IANA considerations. 898 7. Acknowledgements 900 The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC 901 during the 61st IETF meeting, provided valuable input to this 902 document. Special thanks goes also to Sridhar Ramachandran, Gaurav 903 Kulshreshtha, and to Rakendu Devdhar. 905 8. References 906 8.1. Normative References 908 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 909 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 910 Session Initiation Protocol", RFC 3261, June 2002. 912 [2] Peterson, J., "A Privacy Mechanism for the Session Initiation 913 Protocol (SIP)", RFC 3323, November 2002. 915 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 916 Session Description Protocol (SDP)", RFC 3264, June 2002. 918 8.2. Informational References 920 [4] Handley, M. and V. Jacobson, "SDP: Session Description 921 Protocol", RFC 2327, April 1998. 923 Authors' Addresses 925 Jani Hautakorpi (editor) 926 Ericsson 927 Hirsalantie 11 928 Jorvas 02420 929 Finland 931 Email: Jani.Hautakorpi@ericsson.com 933 Gonzalo Camarillo 934 Ericsson 935 Hirsalantie 11 936 Jorvas 02420 937 Finland 939 Email: Gonzalo.Camarillo@ericsson.com 941 Robert F. Penfield 942 Acme Packet 943 71 Third Avenue 944 Burlington, MA 01803 945 US 947 Email: bpenfield@acmepacket.com 949 Alan Hawrylyshen 950 Ditech Networks Inc. 951 Suite 200, 1167 Kensington Cres NW 952 Calgary, Alberta T2N 1X7 953 Canada 955 Email: ahawrylyshen@ditechnetworks.com 957 Medhavi Bhatia 958 NexTone Communications 959 101 Orchard Ridge Drive 960 Gaithersburg, MD 20878 961 US 963 Email: mbhatia@nextone.com 965 Intellectual Property Statement 967 The IETF takes no position regarding the validity or scope of any 968 Intellectual Property Rights or other rights that might be claimed to 969 pertain to the implementation or use of the technology described in 970 this document or the extent to which any license under such rights 971 might or might not be available; nor does it represent that it has 972 made any independent effort to identify any such rights. Information 973 on the procedures with respect to rights in RFC documents can be 974 found in BCP 78 and BCP 79. 976 Copies of IPR disclosures made to the IETF Secretariat and any 977 assurances of licenses to be made available, or the result of an 978 attempt made to obtain a general license or permission for the use of 979 such proprietary rights by implementers or users of this 980 specification can be obtained from the IETF on-line IPR repository at 981 http://www.ietf.org/ipr. 983 The IETF invites any interested party to bring to its attention any 984 copyrights, patents or patent applications, or other proprietary 985 rights that may cover technology that may be required to implement 986 this standard. Please address the information to the IETF at 987 ietf-ipr@ietf.org. 989 Disclaimer of Validity 991 This document and the information contained herein are provided on an 992 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 993 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 994 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 995 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 996 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 997 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 999 Copyright Statement 1001 Copyright (C) The Internet Society (2006). This document is subject 1002 to the rights, licenses and restrictions contained in BCP 78, and 1003 except as set forth therein, the authors retain all their rights. 1005 Acknowledgment 1007 Funding for the RFC Editor function is currently provided by the 1008 Internet Society.