idnits 2.17.1 draft-ietf-sipping-sbc-funcs-06.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 1137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1155. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1161. 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 (June 16, 2008) is 5787 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4474 (ref. '3') (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '6') (Obsoleted by RFC 8866) == Outdated reference: A later version (-08) exists of draft-ietf-sip-ua-privacy-01 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-udp-guidelines-08 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 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: December 18, 2008 R. Penfield 6 Acme Packet 7 A. Hawrylyshen 8 Ditech Networks Inc. 9 M. Bhatia 10 3CLogic 11 June 16, 2008 13 Requirements from SIP (Session Initiation Protocol) Session Border 14 Control Deployments 15 draft-ietf-sipping-sbc-funcs-06.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 December 18, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document describes functions implemented in Session Initiation 49 Protocol (SIP) intermediaries known as Session Border Controllers 50 (SBCs). The goal of this document is to describe the commonly 51 provided functions of SBCs. A special focus is given to those 52 practices that are viewed to be in conflict with SIP architectural 53 principles. This document also explores the underlying requirements 54 of network operators that have led to the use of these functions and 55 practices in order to identify protocol requirements and determine 56 whether those requirements are satisfied by existing specifications 57 or additional standards work is required. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Background on SBCs . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Peering Scenario . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Access Scenario . . . . . . . . . . . . . . . . . . . . . 6 65 3. Functions of SBCs . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 8 67 3.1.1. General Information and Requirements . . . . . . . . . 8 68 3.1.2. Architectural Issues . . . . . . . . . . . . . . . . . 9 69 3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.2. Media Traffic Management . . . . . . . . . . . . . . . . . 10 71 3.2.1. General Information and Requirements . . . . . . . . . 10 72 3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 11 73 3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12 74 3.3. Fixing Capability Mismatches . . . . . . . . . . . . . . . 13 75 3.3.1. General Information and Requirements . . . . . . . . . 13 76 3.3.2. Architectural Issues . . . . . . . . . . . . . . . . . 14 77 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 14 78 3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 15 79 3.4.1. General Information and Requirements . . . . . . . . . 15 80 3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 16 81 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 16 82 3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 17 83 3.5.1. General Information and Requirements . . . . . . . . . 17 84 3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 18 85 3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 18 86 3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 19 87 3.6.1. General Information and Requirements . . . . . . . . . 19 88 3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 20 89 3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 20 90 3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 20 91 3.7.1. General Information and Requirements . . . . . . . . . 20 92 3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 21 93 3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 21 94 4. Derived Requirements for Future SIP Standardization Work . . . 22 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 100 8.2. Informational References . . . . . . . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 102 Intellectual Property and Copyright Statements . . . . . . . . . . 26 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 denial of 144 service prevention and detection); b) functionality not available in 145 the endpoints (NAT traversal, protocol interworking or repair); and 146 c) traffic management (media monitoring and QoS). Some of these 147 functions may also get integrated into other SIP elements (like pre- 148 paid platforms, 3GPP P-CSCF [5], 3GPP I-CSCF, etc). 150 SIP-based SBCs typically handle both signaling and media and can 151 implement behavior which is equivalent to a "privacy service" (as 152 described in[2]) performing both Header Privacy and Session Privacy). 153 SBCs often modify certain SIP headers and message bodies that proxies 154 are not allowed to modify. Consequently, they are, by definition, 155 B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs 156 varies depending on the functions they perform. For example, some 157 SBCs modify the session description carried in the message and insert 158 a Record-Route entry. Other SBCs replace the value of the Contact 159 header field with the SBCs address, and generate a new Call-ID and 160 new To and From tags. 162 +-----------------+ 163 | SBC | 164 [signaling] | +-----------+ | 165 <------------|->| signaling |<-|----------> 166 outer | +-----------+ | inner 167 network | | | network 168 | +-----------+ | 169 <------------|->| media |<-|----------> 170 [media] | +-----------+ | 171 +-----------------+ 173 Figure 1: SBC architecture 175 Figure 1 shows the logical architecture of an SBC, which includes a 176 signaling and a media component. In this document, the terms outer 177 and inner network are used for describing these two networks. An SBC 178 is logically associated to the inner network, and it typically 179 provides functions such as controlling and protecting access to the 180 inner network from the outer network. The SBC itself is configured 181 and managed by the organization operating the inner network. 183 In some scenarios SBCs operate with users' implicit consent and in 184 others they operate completely without users' consent. For example, 185 if an SBC is at the edge of an enterprise network performing topology 186 hiding (see Section 3.1), it is in the same administrative domain as 187 the enterprise users, and the users may choose to route through it. 188 If they choose to route through the SBC, then the SBC can be seen as 189 having an implicit consent from the users. Another example is a 190 scenario where a service provider has broken gateways and it deploys 191 an SBC in front of them for protocol repair (see Section 3.6) 192 reasons, then users may choose to configure the SBC as their gateway, 193 and so the SBC can be seen as having an implicit consent. 195 2.1. Peering Scenario 197 A typical peering scenario involves two network operators who 198 exchange traffic with each other. An example peering scenario is 199 illustrated in Figure 2. An originating gateway (GW) in operator A's 200 network sends an INVITE that is routed to the SBC in operator B's 201 network. Then the SBC forward it to the softswitch (SS). The 202 softswitch responds with a redirect (3xx) message back to the SBC 203 that points to the appropriate terminating gateway in operator B's 204 network. If operator B would not have an SBC, the redirect message 205 would go to the operator A's originating gateway. After receiving 206 the redirect message, the SBC sends the INVITE to the terminating 207 gateway. 209 Operator A . Operator B 210 . 211 . 2) INVITE 212 +-----+ . /--------------->+-----+ 213 |SS-A | . / 3) 3xx (redir.) |SS-B | 214 +-----+ . / /---------------+-----+ 215 . / / 216 +-----+ 1) INVITE +-----+--/ / +-----+ 217 |GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1| 218 +-----+ +-----+---------------------->+-----+ 219 . 220 +-----+ . +-----+ 221 |GW-A2| . |GW-B2| 222 +-----+ . +-----+ 224 Figure 2: Peering with SBC 226 From SBC's perspective the Operator A is the outer network, and 227 Operator B is the inner network. Operator B can use the SBC, for 228 example, to control access to its network, protect its gateways and 229 softswitches from unauthorized use and Denial of Service (DoS) 230 attacks, and monitor the signaling and media traffic. It also 231 simplifies network management by minimizing the number ACL (Access 232 Control List) entries in the gateways. The gateways do not need to 233 be exposed to the peer network, and they can restrict access (both 234 media and signaling) to the SBCs. The SBC helps ensure that only 235 media from sessions the SBC authorizes will reach the gateway. 237 2.2. Access Scenario 239 In an access scenario, presented in Figure 3, the SBC is placed at 240 the border between the access network (outer network) and the 241 operator's network (inner network) to control access to the 242 operator's network, protect its components (media servers, 243 application servers, gateways, etc.) from unauthorized use and DoS 244 attacks, and monitor the signaling and media traffic. Also, since 245 the SBC is call stateful, it may provide access control functions to 246 prevent over-subscription of the access links. Endpoints are 247 configured with the SBC as their outbound proxy address. The SBC 248 routes requests to one or more proxies in the operator network. 250 Access Network Operator Network 252 +-----+ 253 | UA1 |<---------\ 254 +-----+ \ 255 \ 256 +-----+ \------->+-----+ +-------+ 257 | UA2 |<-------------------->| SBC |<----->| proxy |<-- - 258 +-----+ /--->+-----+ +-------+ 259 / 260 +-----+ +-----+ / 261 | UA3 +---+ NAT |<---/ 262 +-----+ +-----+ 264 Figure 3: Access scenario with SBC 266 The SBC may be hosted in the access network (e.g,. this is common 267 when the access network is an enterprise network), or in the operator 268 network (e.g., this is common when the access network is a 269 residential or small business network). Despite where the SBC is 270 hosted, it is managed by the organization maintaining the operator 271 network. 273 Some endpoints may be behind enterprise or residential NATs. In 274 cases where the access network is a private network, the SBC is a NAT 275 for all traffic. It is noteworthy that SIP traffic may have to 276 traverse more that one NAT. The proxy usually does authentication 277 and/or authorization for registrations and outbound calls. The SBC 278 modifies the REGISTER request so that subsequent requests to the 279 registered address-of-record are routed to the SBC. This is done 280 either with a Path header, or by modifying the Contact to point at 281 the SBC. 283 The scenario presented in this section is a general one, and it 284 applies also to other similar settings. One example from a similar 285 setting is the one where an access network is the open internet, and 286 the operator network is the network of a SIP service provider. 288 3. Functions of SBCs 290 This section lists those functions that are used in SBC deployments 291 in current communication networks. Each subsection describes a 292 particular function or feature, the operators' requirements for 293 having it, explanation of any impact to the end-to-end SIP 294 architecture, and a concrete implementation example. Each section 295 also discusses potential concerns specific to that particular 296 implementation technique. Suggestions for alternative implementation 297 techniques that may be more architecturally compatible with SIP are 298 outside the scope of this document. 300 All the examples given in this section are simplified; only the 301 relevant header lines from SIP and SDP [6] messages are displayed. 303 3.1. Topology Hiding 305 3.1.1. General Information and Requirements 307 Topology hiding consists of limiting the amount of topology 308 information given to external parties. Operators have a requirement 309 for this functionality because they do not want the IP addresses of 310 their equipment (proxies, gateways, application servers, etc) to be 311 exposed to outside parties. This may be because they do not want to 312 expose their equipment to DoS attacks, they may use other carriers 313 for certain traffic and do not want their customers to be aware of it 314 or they may want to hide their internal network architecture from 315 competitors or partners. In some environments, the operator's 316 customers may wish to hide the addresses of their equipment or the 317 SIP messages may contain private, non-routable addresses. 319 The most common form of topology hiding is the application of header 320 privacy (see Section 5.1 of [2]), which involves stripping Via and 321 Record-Route headers, replacing the Contact header, and even changing 322 Call-IDs. However, in deployments which use IP addresses instead of 323 domain names in headers that cannot be removed (e.g. From and To 324 headers), the SBC may replace these IP addresses with its own IP 325 address or domain name. 327 For a reference, there are also other ways of hiding topology 328 information than inserting an intermediary, like an SBC, to the 329 signaling path. One of the ways is the User Agent (UA) driven 330 privacy mechanism [7], where the UA can facilitate the conceal of 331 topology information. 333 3.1.2. Architectural Issues 335 This functionality is based on a hop-by-hop trust model as opposed to 336 an end-to-end trust model. The messages are modified without 337 subscriber consent and could potentially modify or remove information 338 about the user's privacy, security requirements and higher layer 339 applications which are communicating end-to-end using SIP. Neither 340 user agent in an end-to-end call has any way to distinguish the SBC 341 actions from a Man-In-The-Middle (MitM) attack. 343 Topology hiding function does not work well with Authenticated 344 Identity Management [3] in scenarios where the SBC does not have any 345 kind of consent from the users. The Authenticated Identity 346 Management mechanism is based on a hash value that is calculated from 347 parts of From, To, Call-Id, CSeq, Date, and Contact header fields 348 plus from the whole message body. If the authentication service is 349 not provided by the SBC itself, the modification of the forementioned 350 header fields and the message body is in violation of [3]. Some 351 forms of topology hiding are in violation, because they are e.g., 352 replacing the Contact header of a SIP message. 354 3.1.3. Example 356 The current way of implementing topology hiding consists of having an 357 SBC act as a B2BUA (Back-to-Back User Agent) and remove all traces of 358 topology information (e.g., Via and Record-Route entries) from 359 outgoing messages. 361 Imagine the following example scenario: The SBC 362 (p4.domain.example.com) receives an INVITE request from the inner 363 network, which in this case is an operator network. The received SIP 364 message is shown in Figure 4. 366 INVITE sip:callee@u2.domain.example.com SIP/2.0 367 Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK48jq9w9174131.1 368 Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1 369 Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1 370 Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1 371 Contact: sip:caller@u1.example.com 372 Record-Route: 373 Record-Route: 374 Record-Route: 376 Figure 4: INVITE Request Prior to Topology Hiding 378 Then the SBC performs a topology hiding function. In this scenario, 379 the SBC removes and stores all existing Via and Record-Route headers, 380 and then inserts Via and Record-Route header fields with its own SIP 381 URI. After the topology hiding function, the message could appear as 382 shown in Figure 5. 384 INVITE sip:callee@u2.domain.example.com SIP/2.0 385 Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w1230129.1 386 Contact: sip:caller@u1.example.com 387 Record-Route: 389 Figure 5: INVITE Request After Topology Hiding 391 Like a regular proxy server that inserts a Record-Route entry, the 392 SBC handles every single message of a given SIP dialog. If the SBC 393 loses state (e.g., SBC restarts for some reason), it may not be able 394 to route messages properly (note: some SBCs preserve the state 395 information also on restart). For example, if the SBC removes "Via" 396 entries from a request and then restarts, thus losing state, the SBC 397 may not be able to route responses to that request; depending on the 398 information that was lost when the SBC restarted. 400 This is only one example of topology hiding. Besides topology hiding 401 (i.e., information related to network elements is beeing hidden), 402 SBCs may also do identity hiding (i.e., information related to 403 identity of subscribers in beeing hidden). While performing identity 404 hiding, SBCs may modify Contact header field values and other header 405 fields containing identity information. The header fields containing 406 identity information is listed in Section 4.1 of [2]. Since the 407 publication of [2], the following header fields containing identity 408 information have been defined: "P-Asserted-Identity", "Referred-By", 409 "Identity", and "Identity-Info". 411 3.2. Media Traffic Management 413 3.2.1. General Information and Requirements 415 Media traffic management is the function of controlling media 416 traffic. Network operators may require this functionality in order 417 to control the traffic being carried on their network on behalf of 418 their subscribers. Traffic management helps the creation of 419 different kinds of billing models (e.g., video telephony can be 420 priced differently to voice-only calls) and it also makes it possible 421 for operators to enforce the usage of selected codecs. 423 One of the use cases for media traffic management is the 424 implementation of intercept capabilities where required to support 425 audit or legal obligations. It is noteworthy that the legal 426 obligations mainly apply to operators providing voice services, and 427 those operators typically have infrastructure (e.g., SIP proxies 428 acting as B2BUAs) for providing intercept capabilities even without 429 SBCs. 431 Since the media path is independent of the signaling path, the media 432 may not traverse through the operator's network unless the SBC 433 modifies the session description. By modifying the session 434 description the SBC can force the media to be sent through a media 435 relay which may be co-located with the SBC. This kind of traffic 436 management can be done, for example, to ensure a certain QoS (Quality 437 of Service) level, or to ensure that subscribers are using only 438 allowed codecs. It is noteworthy that the SBCs do not have direct 439 ties to routing topology and they do not, for example, change 440 bandwidth reservations on Traffic Engineering (TE) tunnels. 442 Some operators do not want to manage the traffic, but only to monitor 443 it for collecting statistics and making sure that they are able to 444 meet any business service level agreements with their subscribers 445 and/or partners. The protocol techniques, from the SBC's viewpoint, 446 needed for monitoring media traffic are the same as for managing 447 media traffic. 449 SBCs on the media path are also capable of dealing with the "lost 450 BYE" issue if either endpoint dies in the middle of the session. The 451 SBC can detect that the media has stopped flowing and issue a BYE to 452 both sides to cleanup any state in other intermediate elements and 453 the endpoints. 455 One possible form of media traffic management is that SBCs terminate 456 media streams and SIP dialogs by generating BYE requests. This kind 457 of procedure can take place, for example, in a situation where the 458 subscriber runs out of credits. Media management is needed to ensure 459 that the subscriber cannot just ignore the BYE request generated by 460 the SBC and continue their media sessions. 462 3.2.2. Architectural Issues 464 Implementing traffic management in this manner requires the SBC to 465 access and modify the session descriptions (i.e., offers and answers) 466 exchanged between the user-agents. Consequently, this approach does 467 not work if user-agents encrypt or integrity-protect their message 468 bodies end-to-end. Again, messages are modified without subscriber 469 consent, and user-agents do not have any way to distinguish the SBC 470 actions from an attack by a MitM. Furthermore, this is in violation 471 of Authenticated Identity Management [3], see Section 3.1.2. 473 The insertion of a media relay can prevent "non-media" uses of media 474 path, for example media path key agreement. Sometimes this type of 475 prevention is intentional, but it is not always necessary. For 476 example, if an SBC is used just for enabling media monitoring, but 477 not for interception. 479 There are some possible issues related to the media relaying. If the 480 media relaying is not done in a correct manner, it may break 481 functions like Explicit Congestion Notification (ECN) and Path MTU 482 Discovery (PMTUD), for example. The media relays easily break such 483 IP and transport layer functionalities that rely on the correct 484 handling of the protocol fields. Some especially sensitive field 485 are, for example, ECN and Type of Service (TOS) fields, and Don't 486 Fragment (DF) bit. 488 Media traffic management function also hinders innovations. The 489 reason for the hinderance is that in many cases SBCs need to be able 490 to support new ways of communicating (e.g., extensions to the SDP 491 protocol) before new services can be taken into use, and that slows 492 down the adoption of innovations. 494 If an SBC directs many media streams through a central point in the 495 network, it is likely to cause a significant amount of additional 496 traffic to a path to that central point. This might create possible 497 bottleneck in the path. 499 In this application, the SBC may originate messages that the user may 500 not be able to authenticate as coming from the dialog peer or the SIP 501 Registrar/Proxy. 503 3.2.3. Example 505 Traffic management may be performed in the following way: The SBC 506 behaves as a B2BUA and inserts itself, or some other entity under the 507 operator's control, in the media path. In practice, the SBC modifies 508 the session descriptions carried in the SIP messages. As a result, 509 the SBC receives media from one user-agent and relays it to the other 510 user-agent and performs the identical operation with media traveling 511 in the reverse direction. 513 As mentioned in Section 3.2.1, codec restriction is a form of traffic 514 management. The SBC restricts the codec set negotiated in the offer/ 515 answer exchange [4] between the user-agents. After modifying the 516 session descriptions, the SBC can check whether or not the media 517 stream corresponds to what was negotiated in the offer/answer 518 exchange. If it differs, the SBC has the ability to terminate the 519 media stream or take other appropriate (configured) actions (e.g. 520 raise an alarm). 522 Consider the following example scenario: The SBC receives an INVITE 523 request from the outer network, which in this case is an access 524 network. The received SIP message contains the SDP session 525 descriptor shown in Figure 6. 527 v=0 528 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 529 c=IN IP4 192.0.2.4 530 m=audio 49230 RTP/AVP 96 98 531 a=rtpmap:96 L8/8000 532 a=rtpmap:98 L16/16000/2 534 Figure 6: Request Prior to Media Management 536 In this example, the SBC performs the media traffic management 537 function by rewriting the 'm' line, and removing one 'a' line 538 according to some (external) policy. Figure 7 shows the session 539 description after the traffic management function. 541 v=0 542 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 543 c=IN IP4 192.0.2.4 544 m=audio 49230 RTP/AVP 96 545 a=rtpmap:96 L8/8000 547 Figure 7: Request Body After Media Management 549 Media traffic management has a problem where the SBC needs to 550 understand the session description protocol and all extensions used 551 by the user-agents. This means that in order to use a new extension 552 (e.g., an extension to implement a new service) or a new session 553 description protocol, SBCs in the network may need to be upgraded in 554 conjunction with the endpoints. It is noteworthy that a similar 555 problem, but with header fields, applies to, for example, topology 556 hiding function, see Section 3.1. Certain extensions that do not 557 require active manipulation of the session descriptors to facilitate 558 traffic management will be able to be deployed without upgrading 559 existing SBCs, depending on the degree of transparency the SBC 560 implementation affords. In cases requiring an SBC modification to 561 support the new protocol features, the rate of service deployment may 562 be affected. 564 3.3. Fixing Capability Mismatches 566 3.3.1. General Information and Requirements 568 SBCs fixing capability mismatches enable communications between user- 569 agents with different capabilities or extensions. For example, an 570 SBC can enable a plain SIP [1] user agent to connect to a 3GPP 571 network, or enable a connection between user agents that support 572 different IP versions, different codecs, or that are in different 573 address realms. Operators have a requirement and a strong motivation 574 for performing capability mismatch fixing, so that they can provide 575 transparent communication across different domains. In some cases 576 different SIP extensions or methods to implement the same SIP 577 application (like monitoring session liveness, call history/diversion 578 etc) may also be interworked through the SBC. 580 3.3.2. Architectural Issues 582 SBCs that are fixing capability mismatches do it by insert a media 583 element to the media path using the procedures described in 584 Section 3.2. Therefore, these SBCs have the same concerns as SBCs 585 performing traffic management: the SBC may modify SIP messages 586 without consent from any of the user-agents. This may break end-to- 587 end security and application extensions negotiation. 589 The capability mismatch fixing is a fragile function in the long 590 term. The number of incompatibilities built into various network 591 elements is increasing the fragility and complexity over time. This 592 might lead to a situation where SBCs need to be able to handle a 593 large number of capability mismatches in parallel. 595 3.3.3. Example 597 Consider the following example scenario where the inner network is an 598 access network using IPv4 and the outer network is using IPv6. The 599 SBC receives an INVITE request with a session description from the 600 access network: 602 INVITE sip:callee@ipv6.domain.example.com SIP/2.0 603 Via: SIP/2.0/UDP 192.0.2.4 604 Contact: sip:caller@u1.example.com 606 v=0 607 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 608 c=IN IP4 192.0.2.4 609 m=audio 49230 RTP/AVP 96 610 a=rtpmap:96 L8/8000 612 Figure 8: Request Prior to Capabilities Match 614 Then the SBC performs a capability mismatch fixing function. In this 615 scenario the SBC inserts Record-Route and Via headers, and rewrites 616 the 'c' line from the sessions descriptor. Figure 9 shows the 617 request after the capability mismatch adjustment. 619 INVITE sip:callee@ipv6.domain.com SIP/2.0 620 Record-Route: 621 Via: SIP/2.0/UDP sip:[2001:DB8::801:201:2ff:fe94:8e10] 622 Via: SIP/2.0/UDP 192.0.2.4 623 Contact: sip:caller@u1.example.com 625 v=0 626 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 627 c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10 628 m=audio 49230 RTP/AVP 96 629 a=rtpmap:96 L8/8000 631 Figure 9: Request After Capability Match 633 This message is then sent by the SBC to the onward IPv6 network. 635 3.4. Maintaining SIP-related NAT Bindings 637 3.4.1. General Information and Requirements 639 NAT traversal in this instance refers to the specific message 640 modifications required to assist a user-agent in maintaining SIP and 641 media connectivity when there is a NAT device located between a user- 642 agent and a proxy/registrar and, possibly, any other user-agent. The 643 primary purpose of NAT traversal function is to keep up a control 644 connection to user-agents behind NATs. This can, for example, be 645 achieved by generating periodic network traffic that keeps bindings 646 in NATs alive. SBCs' NAT traversal function is required in scenarios 647 where the NAT is outside the SBC (i.e., not in cases where SBC itself 648 acts as a NAT). 650 An SBC performing a NAT (Network Address Translator) traversal 651 function for a user agent behind a NAT sits between the user-agent 652 and the registrar of the domain. NATs are widely deployed in various 653 access networks today, so operators have a requirement to support it. 654 When the registrar receives a REGISTER request from the user-agent 655 and responds with a 200 (OK) response, the SBC modifies such a 656 response decreasing the validity of the registration (i.e., the 657 registration expires sooner). This forces the user-agent to send a 658 new REGISTER to refresh the registration sooner that it would have 659 done on receiving the original response from the registrar. The 660 REGISTER requests sent by the user-agent refresh the binding of the 661 NAT before the binding expires. 663 Note that the SBC does not need to relay all the REGISTER requests 664 received from the user-agent to the registrar. The SBC can generate 665 responses to REGISTER requests received before the registration is 666 about to expire at the registrar. Moreover, the SBC needs to 667 deregister the user-agent if this fails to refresh its registration 668 in time, even if the registration at the registrar would still be 669 valid. 671 SBCs can also force traffic to go through a media relay for NAT 672 traversal purposes (more about media traffic management in 673 Section 3.2). A typical call has media streams to two directions. 674 Even though SBCs can force media streams from both directions to go 675 through a media relay, in some cases it is enough to relay only the 676 media from one direction (e.g., in a scenario where only the other 677 endpoint is behind a NAT). 679 3.4.2. Architectural Issues 681 This approach to NAT traversal does not work if end-to-end 682 confidentiality or integrity-protection mechanisms are used (e.g., 683 S/MIME). The SBC would be seen as a MitM modifying the messages 684 between the user-agent and the registrar. 686 There is also a problem related to the method how SBCs choose the 687 value for the validity of a registration period. This value should 688 be as high as possible, but it still needs to be low enough to 689 maintain the NAT binding. Some SBCs do not have any deterministic 690 method for choosing a suitable value. However, SBCs can just use a 691 sub-optimal, relatively small value which usually works. An example 692 from such value is 15 seconds (see [8]). 694 NAT Traversal for media using SBCs poses few issues as well. For 695 example an SBC normally guesses the recipient's public IP address on 696 one of the media streams relayed by the SBC by snooping on the source 697 IP address of another media stream relayed by the same SBC. This 698 causes security and interoperability issues since the SBC can end up 699 associating wrong destination IP addresses on media streams it is 700 relaying. For example, an attacker may snoop on the local IP address 701 and ports used by the SBC for media relaying the streams and send a 702 few packets from a malicious IP address to these destinations. In 703 most cases, this can cause media streams in the opposite directions 704 to divert traffic to the attacker resulting in a successful MitM or 705 DoS attack. A similar example of an interop issue is caused when an 706 endpoint behind a NAT attempts to switch the IP address of the media 707 streams by using a re-INVITE. If any media packets are re-ordered or 708 delayed in the network, they can cause the SBC to block the switch 709 from happening even if the re-INVITE successfully goes through. 711 3.4.3. Example 713 Consider the following example scenario: The SBC resides between the 714 UA and Registrar. Previously the UA has sent a REGISTER request to 715 Registrar, and the SBC receives the registration response shown in 716 Figure 10. 718 SIP/2.0 200 OK 719 From: Bob ;tag=a73kszlfl 720 To: Bob ;tag=34095828jh 721 CSeq: 1 REGISTER 722 Contact: ;expires=3600 724 Figure 10: Response Prior to NAT Maintenance Function 726 When performing the NAT traversal function, the SBC may re-write the 727 expiry time to coax the UA to re-register prior to the intermediating 728 NAT deciding to close the pinhole. Figure 11 shows a possible 729 modification of the response from Figure 10. 731 SIP/2.0 200 OK 732 From: Bob ;tag=a73kszlfl 733 To: Bob ;tag=34095828jh 734 CSeq: 1 REGISTER 735 Contact: ;expires=60 737 Figure 11: Manipulated Response for NAT Traversal 739 Naturally also other measures could be taken in order to enable the 740 NAT traversal (e.g., non-SIP keepalive messages), but this example 741 illustrates only one mechanism for preserving the SIP-related NAT 742 bindings. 744 3.5. Access Control 746 3.5.1. General Information and Requirements 748 Network operators may wish to control what kind of signaling and 749 media traffic their network carries. There is strong motivation and 750 a requirement to do access control on the edge of an operator's 751 network. Access control can be based on, for example, link-layer 752 identifiers, IP addresses or SIP identities. 754 This function can be implemented by protecting the inner network with 755 firewalls and configuring them so that they only accept SIP traffic 756 from the SBC. This way, all the SIP traffic entering the inner 757 network needs to be routed though the SBC, which only routes messages 758 from authorized parties or traffic that meets a specific policy that 759 is expressed in the SBC administratively. 761 Access control can be applied either only to the signaling, or to 762 both the signaling and media. If it is applied only to the 763 signaling, then the SBC might behave as a proxy server. If access 764 control is applied to both the signaling and media, then the SBC 765 behaves in a similar manner as explained in Section 3.2. A key part 766 of media-layer access control is that only media for authorized 767 sessions is allowed to pass through the SBC and/or associated media 768 relay devices. 770 Operators implement some functionalities, like NAT traversal for 771 example, in an SBC instead of other elements in the inner network for 772 several reasons: (i) preventing packets from unregistered users to 773 prevent chances of DoS attack, (ii) prioritization and/or re-routing 774 of traffic (based on user or service, like E911) as it enters the 775 network, and (iii) performing a load balancing function or reducing 776 the load on other network equipment. 778 In environments where there is limited bandwidth on the access links, 779 the SBC can compute the potential bandwidth usage by examining the 780 codecs present in SDP offers and answers. With this information, the 781 SBC can reject sessions before the available bandwidth is exhausted 782 to allow existing sessions to maintain acceptable quality of service. 783 Otherwise, the link could become over-subscribed and all sessions 784 would experience a deterioration in quality of service. SBCs may 785 contact a policy server to determine whether sufficient bandwidth is 786 available on a per-session basis. 788 3.5.2. Architectural Issues 790 Since the SBC needs to handle all SIP messages, this function has 791 scalability implications. In addition, the SBC is a single point of 792 failure from an architectural point of view. Although, in practice, 793 many current SBCs have the capability to support redundant 794 configuration, which prevents the loss of calls and/or sessions in 795 the event of a failure on a single node. 797 If access control is performed only on behalf of signaling, then the 798 SBC is compatible with general SIP architectural principles, but if 799 it is performed for signaling and for media, then there are similar 800 problems as described in Section 3.2.2. 802 3.5.3. Example 804 Figure 12 shows a callflow where the SBC is providing both signaling 805 and media access control (ACKs omitted for brevity). 807 caller SBC callee 808 | | | 809 | Identify the caller | | 810 |<- - - - - - - - - - - >| | 811 | | | 812 | INVITE + SDP | | 813 |----------------------->| | 814 | [Modify the SDP] | 815 | | INVITE + modified SDP | 816 | |----------------------->| 817 | | | 818 | | 200 OK + SDP | 819 | |<-----------------------| 820 | [Modify the SDP] | 821 | | | 822 | 200 OK + modified SDP | | 823 |<-----------------------| | 824 | | | 825 | Media [Media inspection] Media | 826 |<======================>|<======================>| 827 | | | 829 Figure 12: Example Access Callflow 831 In this scenario, the SBC first identifies the caller, so it can 832 determine whether or not to give signaling access for the caller. 833 This might be achieved using information gathered during 834 registration, or by other means. Some SBCs may rely on the proxy to 835 authenticate the user-agent placing the call. After identification, 836 the SBC modifies the session descriptors in INVITE and 200 OK 837 messages in a way so that the media is going to flow through the SBC 838 itself. When the media starts flowing, the SBC can inspect whether 839 the callee and caller use the codec(s) that they had previously 840 agreed on. 842 3.6. Protocol Repair 844 3.6.1. General Information and Requirements 846 SBCs are also used to repair protocol messages generated by not- 847 fully-standard compliant or badly implemented clients. Operators may 848 wish to support protocol repair, if they want to support as many 849 clients as possible. It is noteworthy, that this function affects 850 only the signaling component of an SBC, and that the protocol repair 851 function is not the same as protocol conversion (i.e., making 852 translation between two completely different protocols). 854 3.6.2. Architectural Issues 856 In most cases, this function can be seen as being compatible with SIP 857 architectural principles, and it does not violate the end-to-end 858 model of SIP. The SBC repairing protocol messages behaves as a proxy 859 server that is liberal in what it accepts and strict in what it 860 sends. However, the protocol repair might have problems with such 861 security mechanism that do cryptographical computations to the SIP 862 messages (e.g., hashing). 864 A similar problem related to increasing complexity, as explained in 865 Section 3.3.2, also affects protocol repair function. 867 3.6.3. Examples 869 The SBC can, for example, receive an INVITE message from a relatively 870 new SIP UA as illustrated in Figure 13. 872 INVITE sip:callee@sbchost.example.com 873 Via: SIP/2.0/UDP u1.example.com:5060;lr 874 From: Caller 875 To: Callee 876 Call-ID: 18293281@u1.example.com 877 CSeq: 1 INVITE 878 Contact: sip:caller@u1.example.com 880 Figure 13: Request from a relatively new client 882 If the SBC does protocol repair, it can re-write the 'lr' parameter 883 on the Via header field into the form 'lr=true', in order to support 884 some older, badly implemented SIP stacks. It could also remove 885 excess white spaces to make the SIP message more human readable. 887 3.7. Media Encryption 889 3.7.1. General Information and Requirements 891 SBCs are used to perform media encryption / decryption at the edge of 892 the network. This is the case when media encryption (e.g., Secure 893 Real-time Transport Protocol (SRTP)) is used only on the access 894 network (outer network) side and the media is carried unencrypted in 895 the inner network. Some operators may have an obligation to provide 896 the ability to do legal interception, while they still want to give 897 their customers the ability to encrypt media in the access network. 898 One possible way to do this is to perform media encryption function. 900 3.7.2. Architectural Issues 902 While performing a media encryption function, SBCs need to be able to 903 inject either themselves, or some other entity to the media path. It 904 must be noted that this kind of behavior is the same as a classical 905 MitM attack. Due to this, the SBCs have the same architectural 906 issues as explained in Section 3.2. 908 3.7.3. Example 910 Figure 14 shows an example where the SBC is performing media 911 encryption related functions (ACKs omitted for brevity). 913 caller SBC#1 SBC#2 callee 914 | | | | 915 | INVITE + SDP | | | 916 |------------------->| | | 917 | [Modify the SDP] | | 918 | | | | 919 | | INVITE + mod. SDP | | 920 | |------------------->| | 921 | | [Modify the SDP] | 922 | | | | 923 | | | INVITE + mod. SDP | 924 | | |------------------->| 925 | | | | 926 | | | 200 OK + SDP | 927 | | |<-------------------| 928 | | [Modify the SDP] | 929 | | | | 930 | | 200 OK + mod. SDP | | 931 | |<-------------------| | 932 | [Modify the SDP] | | 933 | | | | 934 | 200 OK + mod. SDP | | | 935 |<-------------------| | | 936 | | | | 937 | Encrypted | Plain | Encrypted | 938 | media [enc./dec.] media [enc./dec.] media | 939 |<==================>|<- - - - - - - - ->|<==================>| 940 | | | | 942 Figure 14: Media Encryption Example 944 First the UAC sends an INVITE request , and the first SBC modifies 945 the session descriptor in a way that it injects itself to the media 946 path. The same happens in the second SBC. Then the UAS replies with 947 a 200 OK response and the SBCs inject themselves in the returning 948 media path. After signaling the media starts flowing, and both SBCs 949 are performing media encryption and decryption. 951 4. Derived Requirements for Future SIP Standardization Work 953 Some of the functions listed in this document are more SIP-unfriendly 954 than others. This list of requirements is derived from the functions 955 that break the principles of SIP in one way or another. The derived 956 requirements are: 958 Req-1: There should be a SIP-friendly way to hide network topology 959 information. Currently this is done by stripping and 960 replacing header fields, which is against the principles of 961 SIP on behalf of some header fields (see Section 3.1). The 962 topology hiding is especially problematic in scenarios where 963 an SBC does not have users' consent. 964 Req-2: There should be a SIP-friendly way to direct media traffic 965 through intermediaries. Currently this is done by modifying 966 session descriptors, which is against the principles of SIP 967 (see Section 3.2, Section 3.4, Section 3.5, and Section 3.7). 968 This is especially problematic in scenarios where an SBC does 969 not have users' consent. 970 Req-3: There should be a SIP-friendly way to fix capability 971 mismatches in SIP messages. This requirement is harder to 972 fulfill on complex mismatch cases, like the 3GPP/SIP [1] 973 network mismatch. Currently this is done by modifying SIP 974 messages, which may violate end-to-end security (see 975 Section 3.3 and Section 3.6), on behalf of some header 976 fields. This is especially problematic in scenarios where an 977 SBC does not have users' consent. 979 Req-1 and Req-3 do not have an existing, standardized solution today. 980 There is ongoing work in the IETF for addressing Req-2, such as SIP 981 session policies, Traversal Using Relays around NAT (TURN), and 982 Interactive Connectivity Establishment (ICE). Nonetheless, future 983 work is needed in order to develop solutions to these requirements. 985 It is noteworthy that a subset of the functions of SBCs will remain 986 as non-standardized functions, because it is not reasonable, or 987 feasible to develop a standardized solutions to replace them. 988 Examples from this kind of functions are the ability to enforce the 989 usage of a specific codec and the protocol repair (see Section 3.6) 990 functionality. 992 5. Security Considerations 994 Many of the functions this document describes have important security 995 and privacy implications. One major security problem is that many 996 functions implemented by SBCs (e.g., topology hiding and media 997 traffic management) modify SIP messages and their bodies without the 998 user agents' consent. The result is that the user agents may 999 interpret the actions taken by an SBC as a MitM attack. SBCs modify 1000 SIP messages because it allows them to, for example, protect elements 1001 in the inner network from direct attacks. 1003 SBCs that place themselves (or another entity) on the media path can 1004 be used to eavesdrop on conversations. Since, often, user agents 1005 cannot distinguish between the actions of an attacker and those of an 1006 SBC, users cannot know whether they are being eavesdropped or an SBC 1007 on the path is performing some other function. SBCs place themselves 1008 on the media path because it allows them to, for example, perform 1009 legal interception. 1011 On a general level SBCs prevent the use of end-to-end authentication. 1012 This is because SBCs need to be able to perform actions that look 1013 like MitM attacks, and in order for user agents to communicate, they 1014 must allow those type of attacks. It other words, user agents can 1015 not use end-to-end security. This is especially harmful because also 1016 other network element, besides SBCs, are then able to do similar 1017 attacks. However, on some cases, user agents can establish encrypted 1018 media connections between each other. One example is a scenario 1019 where SBC is used for enabling media monitoring, but not for 1020 interception. 1022 An SBC is a single point of failure from the architectural point of 1023 view. This makes it an attractive target for DoS attacks. The fact 1024 that some functions of SBCs require those SBCs to maintain session- 1025 specific information makes the situation even worse. If the SBC 1026 crashes (or is brought down by an attacker), ongoing sessions 1027 experience undetermined behavior. 1029 If the IETF decides to develop standard mechanisms to address the 1030 requirements presented in Section 4, the security and privacy-related 1031 aspects of those mechanisms will, of course, need to be taken into 1032 consideration. 1034 6. IANA Considerations 1036 This document has no IANA considerations. 1038 7. Acknowledgements 1040 The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC 1041 during the 61st IETF meeting, provided valuable input to this 1042 document. Authors would also like to thank Sridhar Ramachandran, 1043 Gaurav Kulshreshtha, and Rakendu Devdhar. Reviewers Spencer Dawkins 1044 and Francois Audet also deserve special thanks. 1046 8. References 1048 8.1. Normative References 1050 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1051 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1052 Session Initiation Protocol", RFC 3261, June 2002. 1054 [2] Peterson, J., "A Privacy Mechanism for the Session Initiation 1055 Protocol (SIP)", RFC 3323, November 2002. 1057 [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1058 Identity Management in the Session Initiation Protocol (SIP)", 1059 RFC 4474, August 2006. 1061 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1062 Session Description Protocol (SDP)", RFC 3264, June 2002. 1064 8.2. Informational References 1066 [5] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 1067 5.15.0, June 2006. 1069 [6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1070 Description Protocol", RFC 4566, July 2006. 1072 [7] Munakata, M., Schubert, S., and T. Ohba, "UA-Driven Privacy 1073 Mechanism for SIP", draft-ietf-sip-ua-privacy-01 (work in 1074 progress), February 2008. 1076 [8] Eggert, L. and G. Fairhurst, "Guidelines for Application 1077 Designers on Using Unicast UDP", 1078 draft-ietf-tsvwg-udp-guidelines-08 (work in progress), 1079 June 2008. 1081 Authors' Addresses 1083 Jani Hautakorpi (editor) 1084 Ericsson 1085 Hirsalantie 11 1086 Jorvas 02420 1087 Finland 1089 Email: Jani.Hautakorpi@ericsson.com 1091 Gonzalo Camarillo 1092 Ericsson 1093 Hirsalantie 11 1094 Jorvas 02420 1095 Finland 1097 Email: Gonzalo.Camarillo@ericsson.com 1099 Robert F. Penfield 1100 Acme Packet 1101 71 Third Avenue 1102 Burlington, MA 01803 1103 US 1105 Email: bpenfield@acmepacket.com 1107 Alan Hawrylyshen 1108 Ditech Networks Inc. 1109 825 E Middlefield Rd 1110 Mountain View, CA 1111 US 1113 Email: alan.ietf@polyphase.ca 1115 Medhavi Bhatia 1116 3CLogic 1117 9700 Great Seneca Hwy. 1118 Rockville, MD 20850 1119 US 1121 Email: mbhatia@3clogic.com 1123 Full Copyright Statement 1125 Copyright (C) The IETF Trust (2008). 1127 This document is subject to the rights, licenses and restrictions 1128 contained in BCP 78, and except as set forth therein, the authors 1129 retain all their rights. 1131 This document and the information contained herein are provided on an 1132 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1133 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1134 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1135 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1136 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1137 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1139 Intellectual Property 1141 The IETF takes no position regarding the validity or scope of any 1142 Intellectual Property Rights or other rights that might be claimed to 1143 pertain to the implementation or use of the technology described in 1144 this document or the extent to which any license under such rights 1145 might or might not be available; nor does it represent that it has 1146 made any independent effort to identify any such rights. Information 1147 on the procedures with respect to rights in RFC documents can be 1148 found in BCP 78 and BCP 79. 1150 Copies of IPR disclosures made to the IETF Secretariat and any 1151 assurances of licenses to be made available, or the result of an 1152 attempt made to obtain a general license or permission for the use of 1153 such proprietary rights by implementers or users of this 1154 specification can be obtained from the IETF on-line IPR repository at 1155 http://www.ietf.org/ipr. 1157 The IETF invites any interested party to bring to its attention any 1158 copyrights, patents or patent applications, or other proprietary 1159 rights that may cover technology that may be required to implement 1160 this standard. Please address the information to the IETF at 1161 ietf-ipr@ietf.org. 1163 Acknowledgment 1165 Funding for the RFC Editor function is provided by the IETF 1166 Administrative Support Activity (IASA).