idnits 2.17.00 (12 Aug 2021) /tmp/idnits2626/draft-ietf-mmusic-media-path-middleboxes-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 34 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 private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 8, 2010) is 4335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4347' is defined on line 868, but no explicit reference was found in the text == Outdated reference: draft-ietf-behave-rfc3489bis has been published as RFC 5389 == Outdated reference: draft-ietf-behave-turn has been published as RFC 5766 == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 == Outdated reference: draft-ietf-sip-dtls-srtp-framework has been published as RFC 5763 -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC B. Stucker 3 Internet-Draft 4 Intended status: Informational H. Tschofenig 5 Expires: January 9, 2011 Nokia Siemens Networks 6 July 8, 2010 8 Analysis of Middlebox Interactions for Signaling Protocol Communication 9 along the Media Path 10 draft-ietf-mmusic-media-path-middleboxes-03.txt 12 Abstract 14 Middleboxes are defined as any intermediary box performing functions 15 apart from normal, standard functions of an IP router on the data 16 path between a source host and destination host. Two such functions 17 are network address translation and firewalling. 19 When Application Layer Gateways, such as SIP entities, interact with 20 NATs and firewalls, as described in the MIDCOM architecture, then 21 problems may occur in the transport of media traffic when signaling 22 protocol interaction takes place along the media path, as it is the 23 case for recent key exchange proposals (such as DTLS-SRTP). This 24 document highlights problems that may arise. Unfortunately, it is 25 difficult for the end points to detect or predict problematic 26 behavior and to determine whether the media path is reliably 27 available for packet exchange. 29 This document aims to summarize the various sources and effects of 30 NAT and firewall control, the reasons that they exist, and possible 31 means of improving their behavior to allow protocols that rely upon 32 signaling along the media path to operate effectively. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 6 72 4.1.1. Single-Stage Commit . . . . . . . . . . . . . . . . . 6 73 4.1.2. Two-Stage Commit . . . . . . . . . . . . . . . . . . . 8 74 4.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 10 75 5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 12 77 5.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 15 78 6. Interactions between Media Path Signaling and Middlebox 79 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 6.1. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 16 81 6.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 17 82 7. Preliminary Recommendations . . . . . . . . . . . . . . . . . 18 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 According to by RFC 3234 [RFC3234] middleboxes are defined as any 94 intermediary box performing functions apart from normal, standard 95 functions of an IP router on the data path between a source host and 96 destination host. 98 In the context of SIP a SIP ALG may interact with a node along the 99 media path to control network address translation, firewalling, and 100 other functions. 102 With firewall control packet filters are installed based on the 103 SIP signaling interaction to implement a behavior of 'deny by 104 default' in order to reduce the risk of unwanted traffic. This 105 function is often referred to as 'gating'. Depending on the 106 timing of the packet filter installation and the content of the 107 packet filter signaling traffic along the media, such as DTLS-SRTP 108 or ICE, may be treated in an unexpected way. 110 In cases where the middlebox is involved in overcoming unmanaged 111 NAT traversal the case is similar. The key feature of this type 112 of NAT traversal is a desire to overcome the possible lack of 113 information about any [RFC4787] address and/or port mapping by a 114 possibly unknown NAT device (server reflexive address and 115 filtering properties). In particular, a NAT binding for an 116 endpoint may not exist yet for the address and port identified in 117 the endpoint's SDP. As such, a pilot packet sent by that endpoint 118 behind the NAT is required to create the necessary mappings in the 119 NAT for the media relay to deliver media destined for that 120 endpoint. Until that pilot packet is received no media packets 121 may be reliably forwarded to the endpoint by the relay. 123 This document presents a summary of these two techniques, discusses 124 their impact upon other protocols such as ICE and DTLS-SRTP, and 125 proposes a set of recommendations to mitigate the effects of gating 126 and latching on in-band negotiation mechanisms. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 We use the terms filter, policy action (or action), policy rule(s), 135 MIDCOM agent, and MIDCOM Policy Decision Point (PDP) as defined in 136 [RFC3303]. The MIDCOM agent is co-located with a SIP ALG that 137 communicates with the firewall or the media relay. 139 3. Architecture 141 Figure 1 shows the architecture that is being considered in this 142 document with respect to firewall and NAT traversal using media 143 relaying. The timing and directionality with which media packets are 144 allowed to traverse a particular edge device is the subject of this 145 investigation. The MIDCOM agent thereby pushes policy rules to the 146 middlebox that allow or deny certain flows to bypass. Additionally, 147 in case of media relaying it is important for the MIDCOM agent to 148 adjust the signaling messages. 150 SIP +-----------------+ SIP 151 +-----+ Signaling | SIP ALG | Signaling +-----+ 152 | UAC |<----------->+-----------------+<----------->| UAS | 153 +-----+ | MIDCOM Agent | +-----+ 154 ^ +-----------------+ ^ 155 | ^ | 156 | Policy rule(s) | and NAT bindings | 157 | v | 158 | Media +-------------+ Media | 159 +----------------->| Middlebox |<-----------------+ 160 +-------------+ 162 Figure 1: Analysed Firewalling Architecture 164 The aspects of packet filtering are described in Section 4 whereas 165 NAT traversal is illustrated in Section 5. 167 4. Packet Filtering 169 Figure 1 highlights the interaction between the MIDCOM agent and the 170 middlebox. These two elements inspect call control signaling and 171 media path packets and determine when packets from a given source to 172 a given destination are allowed to flow between endpoints. It is 173 common for the gate controller to be the local outbound proxy for a 174 given SIP UA being gated. 176 The primary responsibility of the MIDCOM agent, which is co-located 177 with a SIP entity, is to examine the call control signaling to 178 determine the media addresses and ports used to define the media path 179 between the gated device and the endpoint(s) with which it is 180 corresponding. For SIP, this would correspond to the media addresses 181 described within SDP after at least one full offer/answer exchange. 183 This information is used to create one or more packet filters that 184 describe the expected media path(s) for the call. These packet 185 filters are combined with an algorithmic determination, typically 186 based on the state of the call, as to which direction(s) media 187 packets are allowed to flow between the endpoints, if at all. The 188 filter and the action that is being installed by the MIDCOM agent at 189 the middlebox may change during the lifetime of a SIP signaling 190 session, depending on the state of the call or on changes of the 191 address and port information of one (or even both) of the end points. 193 It is possible that the gate controller may not be able to establish 194 an exact address or port for one endpoint involved in the call in 195 which case it may wildcard the address and/or port for the source 196 and/or destination endpoint in the packet flow filter. In such a 197 case, the packet flow filter is considered to have matched against a 198 given media packet for the wildcarded field. 200 Note that it is possible to specify the filter using wildcards, for 201 example, if some end point address information is not known at a 202 given point in time. Additionally, the default firewalling policy is 203 subject to local configuration ('deny per default' vs. 'permit per 204 default'). For a given SIP signaling sessions the policy at the 205 MIDCOM agent might be very strict with respect to the packets that 206 are allowed to flow in a particular direction. For example, packets 207 may be allowed to flow in both directions, only in one direction for 208 a specific media stream. No particular behavior can be assumed. 210 When a media session is destroyed (end of call, deleted from the 211 session description, etc.), the MIDCOM agent removes policy rules 212 created for that media session at the middlebox. 214 4.1. Protocol Interaction 216 MIDCOM agents may employ a variety of models to determine when to 217 change the status of a particular policy rule. This is especially 218 true when a call is being established. For SIP, this would be when 219 an early dialog is established between endpoints. Although there is 220 the potential for a great deal of variability due to an intentional 221 lack of specification, typically, one of two models is used by the 222 MIDCOM agent to determine the state of a policy rule during call 223 setup: single-stage and two-stage commit. The term 'commit' here 224 refers to the point at which a policy rule is setup that allows media 225 traffic to flow. For example, this would be the point at which 226 packets for a media stream marked a=sendrecv in SDP was allowed to 227 flow bi-directionally by the middlebox. 229 4.1.1. Single-Stage Commit 231 Single stage commit is commonly used when the MIDCOM agent is most 232 involved only in firewalling. For SIP, MIDCOM agents use a single- 233 stage commit model typically install policy rules for the call when 234 the 200 OK to the INVITE is received in the case that the INVITE 235 contained an SDP offer, or when the ACK is received if the initial 236 offer was sent in the 200 OK itself. 238 This model is often used to prevent media from being sent end-to-end 239 prior to the call being established. 241 UAC Side MIDCOM UAS Side 242 UAC Middlebox Agent Middlebox UAS 243 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 244 | | | | | 245 | (1) INVITE + SDP Offer | | | 246 |---------------------------->| (2) INVITE + SDP Offer | 247 | c=IN IP4 47.0.0.1 |---------------------------->| 248 | m=audio 49170 RTP/AVP 0 | c=IN IP4 47.0.0.1 | 249 | a=sendrecv | m=audio 49170 RTP/AVP 0 | 250 | | | a=sendrecv | 251 | | | | | 252 | | | (3) 200 OK + SDP Answer | 253 | | |<----------------------------| 254 | | | c=IN IP4 47.0.0.2 | 255 | | | m=audio 36220 RTP/AVP 0 | 256 | | | a=sendrecv | | 257 | | | | | 258 | | (5) Policy | (4) Policy | | 259 | |<---------------|--------------->| | 260 | | Src: 47.0.0.2 | Src: 47.0.0.1 | | 261 | | port 36220 | port 49170 | | 262 | | Dst: 47.0.0.1 | Dst: 47.0.0.2 | | 263 | | port 49170 | port 36220 | | 264 | | sendrecv | sendrecv | | 265 | | action=permit | action=permit | | 266 | | | | | 267 | | | | RTP | 268 |<=========================================================>| 269 | | | | | 270 | (6) 200 OK + SDP Answer | | | 271 |<----------------------------| | | 272 | c=IN IP4 47.0.0.2 | | | 273 | m=audio 36220 RTP/AVP 0 | | | 274 | a=sendrecv | | | 275 | | | | | 276 | (7) ACK | (8) ACK | 277 |---------------------------->|---------------------------->| 278 | | | | | 279 Figure 2: Example Single-stage Commit with SIP and SDP 281 In the example above, policy is created in steps 4 and 5 to allow bi- 282 directional media flow based on the SDP exchanged in steps 1 and 3. 283 In particular, the rules at the UAC side middlebox would indicate 284 that traffic exchanged between IP address 47.0.0.1 and port number 285 49170 and IP address 47.0.0.2 and port number 36220 is allowed in 286 both directions. 288 In this example, the MIDCOM agent installs the policies after the 200 289 OK to the INVITE arrives in step 3. With a firewalling policy of 290 'deny by default' media sent prior to steps 5 and 4 by the UAC or UAS 291 is discarded by the middleboxes. 293 Noted that early media that arrives before the 200 OK would require 294 special treatment since otherwise it would be dropped as well. 296 4.1.2. Two-Stage Commit 298 Two-stage commit is used when the MIDCOM agent also providers 299 functionality, such as Quality of Service signaling that may require 300 resources to reserved early on in the call establishment process 301 before it is known if the call will be answered. An example of this 302 would be where the MIDCOM agent is responsible for guaranteeing a 303 minimum level of bandwidth along the media path. In this case an 304 initial set of policies may be sent by the MIDCOM agent to the 305 middlebox even though they are put into a pending state but trigger a 306 resource reservation. Later, when the call is accepted, the gate 307 controller may update the state of the policies to active them. 309 UAC Side MIDCOM UAS Side 310 UAC Middlebox Agent Middlebox UAS 311 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 312 | | | | | 313 | (1) INVITE + SDP Offer | | | 314 |---------------------------->| (2) INVITE + SDP Offer | 315 | c=IN IP4 47.0.0.1 |---------------------------->| 316 | m=audio 49170 RTP/AVP 0 | c=IN IP4 47.0.0.1 | 317 | a=sendrecv | m=audio 49170 RTP/AVP 0 | 318 | | | a=sendrecv | 319 | | | | | 320 | | | (3) 180 + SDP Answer | 321 | (4) 180 + SDP Answer |<----------------------------| 322 |<----------------------------| c=IN IP4 47.0.0.2 | 323 | c=IN IP4 47.0.0.2 | m=audio 36220 RTP/AVP 0 | 324 | m=audio 36220 RTP/AVP 0 | a=sendrecv | 325 | a=sendrecv | | | 326 | | | | | 327 | | (5) Policy | (6) Policy | | 328 | |<---------------|--------------->| | 329 | | Src: 47.0.0.2 | Src: 47.0.0.1 | | 330 | | port 36220 | port 49170 | | 331 | | Dst: 47.0.0.1 | Dst: 47.0.0.2 | | 332 | | port 49170 | port 36220 | | 333 | | rule inactive | rule inactive | | 334 | | action=permit | action=permit | | 335 | | | | | 336 | | | (7) 200 OK | 337 | | |<----------------------------| 338 | | | | | 339 | | (9) UpdateGate | (8) UpdateGate | | 340 | |<---------------|--------------->| | 341 | | G: sendrecv | G: sendrecv | | 342 | | | | RTP | 343 |<=========================================================>| 344 | | | | | 345 | (10) 200 OK | | | 346 |<----------------------------| | | 347 | | | | | 348 | (11) ACK | (12) ACK | 349 |---------------------------->|---------------------------->| 350 | | | | | 352 Figure 3: Example Two-stage Commit with SIP and SDP 354 In the example above, policies are created in steps 5 and 6 based off 355 of the SDP sent in steps 1 and 3 in an initial inactive state (no 356 packets are allowed to flow) despite the SDP indicating the media 357 should be bi-directional. This interaction with the middlebox, 358 however, triggers a QoS reservation to take place. Later, when the 359 200 OK to the INVITE comes in step 7, the policies are updated in 360 steps 8 and 9 to indicate that packets should be allowed to flow bi- 361 directionally. Although functionally equivalent to the single-stage 362 commit example given earlier in Figure 2, other operations at the 363 gate agent may have been performed simultaneously in steps 5 and 6 364 that justifies the early explicit definition of the gates in an 365 inactive state. The full usage of PRACK here is not shown for 366 purposes of brevity. 368 4.2. Further Reading 370 Packet filtering based on the approach described in this document has 371 been described in a number of documents. Although the usage of this 372 architecture can also be found on the Internet their behavior is 373 largely specified only in documents that relate to IMS 374 standardization. The behavior of the devices deployed on the 375 Internet is therefore largely undocumented. Nevertheless, the 376 following documents give the reader a better idea of the 377 functionality and the signaling interaction. These documents may 378 also specify an additional behavior in relation to how packet 379 filtering is used when the MIDCOM agent is responsible for processing 380 SIP/SDP call control signaling and the middlebox is responsible for a 381 variety of activities beyond pure filtering. For example, it is 382 common for middleboxes to exempt RTCP flows from being blocked even 383 though the associated RTP flows are not allowed to flow in order to 384 support RTCP signaling while a call is on hold. These references are 385 given here for the reader to gather a better understanding of how 386 this is mechanism is used in various forums and is non-exhaustive: 388 1. 3GPP, "TS 23.203: Policy and charging control architecture" 389 [TS-23.203] 391 2. 3GPP, "TS 29.212: Policy and Charging Control over Gx reference 392 point" [TS-29.212] 394 3. 3GPP, "TS 29.213: Policy and Charging Control signalling flows 395 and QoS parameter mapping" [TS-29.213] 397 4. 3GPP, "TS 29.214: Policy and charging control over Rx reference 398 point" [TS-29.214] 400 5. ETSI TISPAN, "ES 282-003: Telecommunications and Internet 401 converged Services and Protocols for Advanced Networking 402 (TISPAN); Resource and Admission Control Sub-system (RACS); 403 Functional Architecture" [TISPAN-ES-282-003] 405 6. Cablelabs, "PacketCable 2.0: Quality of Service Specification 406 (PKT-SP-QOS-I01-070925)" [PKT-SP-QOS-I01-070925] 408 Note that different terms are used for the MIDCOM agent and the 409 middlebox. For example, in an IMS context the MIDCOM agent would be 410 part of the P-CSCF and PCRF elements or in TISPAN it would be part of 411 the P-CSCF, A-RACF and SPDF that are involved in controlling gating 412 operations. Many different elements perform the role of a middlebox: 413 GSM GGSN, CDMA PDSN, SAE serving gateway, TISPAN PCEF and A-BGF/ 414 C-BGF/I-BGF, PacketCable CMTS, etc. These functions may be present 415 in the network in a unified or decomposed architecture. 417 5. NAT Traversal 419 Two distinct types of NAT traversal can be supported by a MIDCOM 420 agent and the connected middlebox: 422 1. The MIDCOM agent and the attached middlebox act as a B2BUA at the 423 border of an operator's network to protect this network and to 424 perform the IP address and port conversion, which may be required 425 because private address spaces are used within the network, or 426 because IPv4 and IPv6 address realms are interfacing. For this 427 use case, the middlebox itself performs functions similar to a 428 NAT and is deployed instead of a NAT at a network border. 430 2. The MIDCOM agent and attached middlebox support the traversal of 431 a residential NAT (also termed costumer premise equipment), which 432 is typically located at the user's side of an access network, for 433 instance within a DSL router. The middlebox thereby acts as kind 434 of media relay. 436 Both functions can be combined by the same MIDCOM agent and connected 437 middlebox, for instance by a TISPAN C-BGF. 439 As shown in Figure 1 the MIDCOM agent that is being co- located with 440 the SIP ALG functionality interacts with the middlebox that is also a 441 NAT in order to request and allocate NAT bindings and then modifies 442 the SDP offer and answer within SIP to insert the IP addresses and 443 port allocated by the NAT as destination for the media in both 444 directions. A consequence of the interaction with a (double) NAT is 445 that the media traffic is forced to traverse a certain NAT in both 446 directions (also called media anchoring). The opening of pinholes 447 through the middlebox is only done on request of the MIDCOM agent, 448 and not triggered by the detection of outbound media flows. Such 449 middleboxes are for instance the TISPAN A-BGF/C-BGF/I-BGF and the 450 3GPP IMS Access Gateway. 452 The functionality and control of the middlebox becomes comparable to 453 a media gateway and TISPAN standardized the usage of the H.248 / 454 MEGACO protocol for the control of the middlebox by the midcom MIDCOM 455 agent. 457 This architecture could be compared with a STUN relay 458 [I-D.ietf-behave-turn] that is being controlled by the MIDCOM agent 459 rather than the end point itself. The motivation why this technique 460 is being used in favor to other NAT traversal techniques is that 461 clients do not have to support anything beyond RFC 3261 [RFC3261] and 462 network administrators can control and apply local policy to the 463 relay binding process in a centralized manner. 465 5.1. Protocol Interaction 467 The MIDCOM agent's role is to inspect call control signaling and 468 update media address and port values based upon media relay binding 469 information allocated with the middlebox/media relay. For SIP, this 470 minimally involves updating the c= and m= lines in the SDP, although 471 some implementations may also update other elements of the SDP for 472 various reasons. 474 Because the endpoints may not be able to gather a server reflexive 475 address for their media streams, the MIDCOM agent employs the 476 following algorithm to ensure that media can flow to the given 477 endpoint: 479 1. When receiving an initial SDP offer, the MIDCOM agent requests 480 authorization for the request arriving at the middlebox, 481 configures the middlebox to forward media between the offerer and 482 the destination address / port as received in the incoming SDP 483 offer, reserves a local IP address and port, and replaces the 484 destination address and port from the incoming offer with the IP 485 address / port used by the middlebox in the forwarded offer. 487 2. When receiving an initial SDP answer, the MIDCOM agent configures 488 the middlebox for the corresponding session to send media towards 489 the answerer towards the destination address and port as received 490 in the incoming SDP answer, request the middlebox to reserve a 491 local IP address / port, and exchange the destination address and 492 port from the incoming answer with that middlebox IP address and 493 port in the forwarded answer. 495 3. If the middlebox supports the traversal of residential NATs, it 496 applies a technique called "media latching": The destination IP 497 address of packets forwarded by the middlebox in the outbound 498 direction is derived from the source IP address of packets 499 received in the inbound direction. This overrides a destination 500 address possibly configured by the MIDCOM agent. 502 An example of this algorithm is shown in Figure 4 when using SIP and 503 SDP. In this example the UAC is the endpoint served by the MIDCOM 504 agent, which is also acting as a local outbound proxy, and the UAS is 505 the corresponding endpoint. We assume that the UAC is located behind 506 a residential NAT; this NAT is, however, not shown in Figure 4. 508 Media Relay MIDCOM Agent and 509 UAC Middlebox Outbound Proxy UAS 510 (UAC side) 511 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 512 | | | | 513 | (1) INVITE + SDP Offer | | 514 |---------------------------->| | 515 | c=IN IP4 10.0.0.1 | | 516 | m=audio 49170 RTP/AVP 0 | | 517 | a=sendrecv | | 518 | | | | 519 | | (2) Allocate | | 520 | |<------------- | | 521 | | | | 522 | | (3) Response | | 523 | |-------------->| | 524 | | In: 47.0.0.3 | (4) INVITE + SDP Offer | 525 | | 50000 |---------------------------->| 526 | | Out: 47.0.0.4 | c=IN IP4 47.0.0.3 | 527 | | 50002 | m=audio 50000 RTP/AVP 0 | 528 | | | a=sendrecv | 529 | | | | 530 | | | (5) 180 + SDP Answer | 531 | | (6) Update |<----------------------------| 532 | |<--------------| c=IN IP4 47.0.0.2 | 533 | | Peer: 47.0.0.2| m=audio 36220 RTP/AVP 0 | 534 | | 36220 | a=sendrecv | 535 | (7) 180 + SDP Answer | | 536 |<----------------------------| | 537 | c=IN IP4 47.0.0.4 | | 538 | m=audio 50002 RTP/AVP 0 | | 539 | a=sendrecv | | 540 | | | | 541 | (8) 200 OK | (8) 200 OK | 542 |<----------------------------|<----------------------------| 543 | | | | 544 | (9) ACK | (9) ACK | 545 |---------------------------->|---------------------------->| 546 | | | | 547 | | | (10) UAS-RTP | 548 | X<============================================| 549 | | | Source: 47.0.0.2:36220 | 550 | (11) UAC-RTP| | Dest: 47.0.0.3:50000 | 551 |============>| | | 552 | Source: 47.0.0.100:48650 | | 553 | Dest: 47.0.0.4:50002 | | 554 | | | (12) UAC-RTP | 555 | |============================================>| 556 | | | Source: 47.0.0.3:50000 | 557 | | | Dest: 47.0.0.2:36220 | 558 | | | | 559 | | | (13) UAS-RTP | 560 | |<============================================| 561 | | | Source: 47.0.0.2:36220 | 562 | (14) UAC-RTP| | Dest: 47.0.0.3:50000 | 563 |<============| | | 564 | Source: 47.0.0.4:50002 | | 565 | Dest: 47.0.0.100:48650 | | 566 | | | | 568 Figure 4: Call Flow with SIP + SDP 570 Step (1): UAC sends INVITE to local outbound proxy, which is also a 571 MIDCOM agent, with an SDP offer. 573 Step (2): The MIDCOM agent looks at the signaling and asks the 574 middlebox to allocate a media relay binding. At this point in 575 time the MIDCOM agent can only provide the IP address it finds 576 inside the offer, i.e., the IP address and port where the UAC is 577 expecting to receive traffic sent by the UAS. In this example the 578 IP address equals 10.0.0.1 and the port number is 49170. 580 Step (3): The middlebox responds with a media relay binding that 581 consists of an inbound address/port for media sent by the UAS, and 582 an outbound address/port for media sent by the UAC. The IP 583 address and port of the middlebox allocated for the inbound side 584 47.0.0.3:50000 and the address and port on the outbound side is 585 47.0.0.4:50002. 587 Step (4): The MIDCOM agent updates the addresses in the SDP offer 588 with the inbound address/port information from the middlebox/media 589 relay binding response, namely with 47.0.0.3:50000. 591 Step (5): The UAS responds with a 180 containing an SDP answer. 592 This answer indicates that traffic will be sent from the IP 593 address and port 47.0.0.2:36220. 595 Step (6): The MIDCOM agent interacts with the middlebox to update 596 the destination address/port information from the SDP answer for 597 media to be sent to the UAS, and changes the addresses/ports in 598 the SDP answer to the UAC with the outbound address/port 599 information from the middlebox binding from step 3. Media can now 600 flow to the UAS from the UAC at the middlebox/media relay, i.e., 601 in the outbound direction. 603 Step (7): The UAC receives the SDP answer containing the media relay 604 outbound address/port information, namely 47.0.0.4:50002. 606 Step (8): The UAS answers the INVITE with a 200 OK. 608 Step (9): The UAC acknowledges with an ACK. 610 Step (10): RTP for the UAS, which may have begun flowing prior to 611 answer, goes to the middlebox, but the middlebox has no reliable 612 address to relay the media to for the UAC yet. Media will 613 typically be dropped. 615 Step (11): RTP arrives at the media relay on the inbound address/ 616 port from the UAC. The middlebox observes the source address and 617 port of the arriving packet and completes the binding process. 618 The source address and port of the media from the UAC is now the 619 destination address/port for media arriving on the outbound port 620 of the middlebox/media relay from the UAS. 622 Step (12): Media originating from the UAC is relayed by the 623 middlebox to the UAS. 625 Step (13): Media from the UAS is sent towards the middlebox. 627 Step (14): The middlebox forwards the media traffic to the UAC. 629 5.2. Further Reading 631 In TS 23.228 the 3GPP standardized the usage of a SIP-ALG residing in 632 the P-CSCF to control an IMS Access Gateway, acting as middlebox at 633 the interface between the IMS and the access network (see Annex G), 634 and the usage of a SIP-ALG residing in the IBCF to control an TrGW as 635 a middlebox at the interface between the IMS and external networks or 636 other IMS networks (see Annex I). 638 Although the described residential NAT traversal approach is used by 639 a number of implementations to overcome incorrect address/port 640 information in call control signaling from an endpoint behind a NAT, 641 only one reference is known that describes the functionality in a 642 standardized manner. 644 1. ETSI TISPAN, "ES 282-003: Telecommunications and Internet 645 converged Services and Protocols for Advanced Networking 646 (TISPAN); Resource and Admission Control Sub-system (RACS); 647 Functional Architecture" [TISPAN-ES-282-003]. The TISPAN Ia 648 interface between the TISPAN BGF and SPDF is the relevant 649 specification. 651 6. Interactions between Media Path Signaling and Middlebox Behavior 653 This section points to the problems that occur when signaling 654 exchanges are performed along the media path when middleboxes are 655 present that behave in the way described in this document. 657 6.1. Packet Filtering 659 The description in Section 4 highlighted that the timing of the 660 policy rule installation by the MIDCOM agent towards the middlebox 661 has an impact on when and what media traffic is allowed to traverse. 663 The installation of policy rules is a prerequisite for related media 664 to flow. As those policy rules are derived from information from 665 both SDP offer and answer, they are typically installed at the 666 completion of the first offer-answer exchange. 668 Furthermore, the middlebox may prevent the exchange of packets in the 669 media path after this point by closing "gates" until the session 670 establishment signaling has reached a pre-configured milestone where 671 the MIDCOM agent signals to the middlebox that packets are allowed to 672 traverse in both directions. Prior to this, packets may be allowed 673 to flow uni-directionally to satisfy certain service requirements or 674 may be entirely blocked by the middlebox. For SIP [RFC3261] the 675 typically milestone that must be reached is offer/answer exchange 676 [RFC3264] accompanied by an acknowledgement that the dialog has been 677 accepted by the UAS (i.e., 200 OK to the INVITE). It depends on the 678 policy of an operator when to open gates. The policy may take into 679 account the requirements of special media types to have early 680 bidirectional media exchanges, e.g. if the usage of DTLS is indicated 681 in SDP. 683 A concrete example of the impact can be found with the case of key 684 exchange along the media path, as it is provided by DTLS-SRTP. 685 Figure 2 of [I-D.ietf-sip-dtls-srtp-framework] shows that the arrival 686 of the SIP INVITE at the UAS triggers the DTLS handshake. This 687 message would be blocked by the middlebox, as described in Section 4 688 since the MIDCOM agent has not yet installed policy rules. The 689 consequence is that the communication fails unless the UAS repeats 690 attempts for an DTLS handshake until connectivity is established in 691 both directions by the installation of policy rules and the presence 692 of opened gates. Due to extra time required for the DTLS exchange 693 the user may experience clipping. 695 According to 3GPP standards, gates for RTCP are always opened when 696 policy rules for related media are installed, even if related media 697 traffic is still blocked. Therefore, signalling embedded in RTCP is 698 likely to pass after the completion of the first offer-answer 699 exchange. Standardized policy rules only inspect source and 700 destination information of IP packets and the transport protocol 701 (e.g., UDP and TCP). Obviously, this is not a property that can be 702 guaranteed to be true in the future. 704 6.2. NAT Traversal 706 The described NAT traversal interaction prevents asynchronous 707 exchange of packets in the media path until a pilot packet has been 708 received by the middlebox from the endpoint being served. It can be 709 employed for both the [RFC3264] offerer and/or answerer. Therefore, 710 in the worst case, both endpoints must generate a pilot packet 711 towards each other to ensure a bi-directional media path exists. Any 712 signaling on the media path that relies upon a uni-directional 713 handshake in the reverse direction may not complete until media in 714 the forward direction by the other endpoint. If signaling on the 715 media path is required to complete prior to media generation the 716 handshake may stall indefinitely. 718 Middleboxes as described in Section 5 will not allow any media to 719 pass through without being configured to do so by the MIDCOM agent 720 when the first offer-answer exchange is completed. Without latching, 721 it may be technically feasible to pass media packets from answerer 722 towards the offerer after the offer has passed the MIDCOM agent, but 723 existing implementations hardly show that behavior. Furthermore, 724 such middleboxes may apply gating policies similar to the policies 725 discussed in Section 6.1 in addition. 727 The described latching technique for residential NAT traversal 728 interaction requires that a pilot packet has been received by the 729 middlebox from the endpoint being served before the middlebox is able 730 to send packets towards the endpoint. This latching technique can be 731 employed for both the RFC 3264 offerer and answerer. Therefore, in 732 the worst case, both endpoints must generate a pilot packet towards 733 each other to ensure that a bi-directional media path exists. If the 734 first packets to be exchanged in the media path are signalling 735 packets and a particular directionality of those packets is required, 736 communication may fail. To overcome these problems, empty packets 737 could be sent by the endpoint that has to receive rather than to send 738 the first signalling message. The offer is capable of sending the 739 pilot packet only when receiving the destination information within 740 the answer. Thus, before that point in time the offerer will also 741 not be able to receive any media packets or related signalling. 743 In a similar manner as outlined in Section 6.1, any in-path 744 signalling messages that are sent before the offer-answer exchange is 745 completed will be dropped. 747 7. Preliminary Recommendations 749 The following preliminary recommendations are suggested: 751 REC #1: It is recommended that any protocol handshake on the media 752 path ensure that a mechanism exists that causes both endpoints to 753 send at least one packet in the forward direction as part of, or 754 prior to, the handshake process. Retransmission of STUN 755 connectivity checks (see [I-D.ietf-behave-rfc3489bis]) as part of 756 ICE [I-D.ietf-mmusic-ice] is an example of such a mechanism that 757 satisfies this recommendation. Sending of no-op RTP packets (see 758 [I-D.ietf-avt-rtp-no-op]) is another example. 760 REC #2: It is recommended that middleboxes present on the media 761 path allow at least a nominal amount of traffic to be exchanged 762 between endpoints after the completion of the first offer-answer 763 exchange to enable the completion of media path signaling prior to 764 the session being established. Such policies may be restricted to 765 media types that use in-path signalling. The amount of traffic 766 necessary to complete the signaling between endpoints is expected 767 to be orders of magnitude smaller than that of any sufficiently 768 interesting fraudulent traffic. 770 REC #3: It is recommended that failure to complete signaling on the 771 media path not automatically cause the session establishment to 772 fail unless explicitly specified by one or more endpoints. A 773 fallback scenario where endpoints retry signaling on the media 774 path is recommended. Recommended points in time to retry 775 signalling on the media path are after the completion of the first 776 offer-answer exchange and again after the session has been 777 established. Additional retries with adequate pacing may be used 778 in addition. 780 REC #4: If signaling on the media path is required before media can 781 flow, the answer should send the SDP answer as soon as possible, 782 for example within a provisional SIP response, to allow the media 783 path signalling to bypass middleboxes and therefore to avoid 784 clipping. 786 8. Security Considerations 788 This document talks about security related functionality and the 789 impact of one security mechanism, namely firewalling, to another one, 790 namely key management for media security. 792 9. IANA Considerations 794 This document does not require actions by IANA. 796 10. Acknowledgements 798 We would like to thank Steffen Fries, Dan Wing, Eric Rescorla, and 799 Francois Audet for their input to this document. Furthermore, we 800 would like to thank Jason Fischl, Guenther Horn, Thomas Belling, 801 Peter Schneider, Jari Arkko, Cullen Jennings for the discussion input 802 to this problem space. 804 We would also like to thank the participants of the IETF#70 MMUSIC 805 working group meeting for their feedback. 807 Thomas Belling provided text proposals in April 2008. We are 808 thankful for his detailed suggestions. 810 11. References 812 11.1. Normative References 814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 815 Requirement Levels", BCP 14, RFC 2119, March 1997. 817 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 818 A., Peterson, J., Sparks, R., Handley, M., and E. 819 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 820 June 2002. 822 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 823 with Session Description Protocol (SDP)", RFC 3264, 824 June 2002. 826 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 827 A. Rayhan, "Middlebox communication architecture and 828 framework", RFC 3303, August 2002. 830 11.2. Informative References 832 [I-D.ietf-avt-rtp-no-op] 833 Andreasen, F., "A No-Op Payload Format for RTP", 834 draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. 836 [I-D.ietf-behave-rfc3489bis] 837 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 838 "Session Traversal Utilities for (NAT) (STUN)", 839 draft-ietf-behave-rfc3489bis-18 (work in progress), 840 July 2008. 842 [I-D.ietf-behave-turn] 843 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 844 Relays around NAT (TURN): Relay Extensions to Session 845 Traversal Utilities for NAT (STUN)", 846 draft-ietf-behave-turn-16 (work in progress), July 2009. 848 [I-D.ietf-mmusic-ice] 849 Rosenberg, J., "Interactive Connectivity Establishment 850 (ICE): A Protocol for Network Address Translator (NAT) 851 Traversal for Offer/Answer Protocols", 852 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 854 [I-D.ietf-sip-dtls-srtp-framework] 855 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 856 for Establishing an SRTP Security Context using DTLS", 857 draft-ietf-sip-dtls-srtp-framework-07 (work in progress), 858 March 2009. 860 [PKT-SP-QOS-I01-070925] 861 CableLabs, "PacketCable 2.0: Quality of Service 862 Specification", September 2007, . 865 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 866 Issues", RFC 3234, February 2002. 868 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 869 Security", RFC 4347, April 2006. 871 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 872 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 873 RFC 4787, January 2007. 875 [TISPAN-ES-282-003] 876 ETSI, "Telecommunications and Internet converged Services 877 and Protocols for Advanced Networking (TISPAN); Resource 878 and Admission Control Sub-system (RACS); Functional 879 Architecture", June 2006, . 881 [TS-23.203] 882 3GPP, "Policy and charging control architecture", 883 September 2007, 884 . 886 [TS-29.212] 887 3GPP, "Policy and Charging Control over Gx reference 888 point", June 2008, 889 . 891 [TS-29.213] 892 3GPP, "Policy and Charging Control signalling flows and 893 QoS parameter mapping", June 2008, 894 . 896 [TS-29.214] 897 3GPP, "Policy and charging control over Rx reference 898 point", June 2008, 899 . 901 Authors' Addresses 903 Brian Stucker 905 Email: obsidian97@gmail.com 906 URI: http://www.linkedin.com/in/bstucker 908 Hannes Tschofenig 909 Nokia Siemens Networks 910 Linnoitustie 6 911 Espoo 02600 912 Finland 914 Phone: +358 (50) 4871445 915 Email: Hannes.Tschofenig@gmx.net 916 URI: http://www.tschofenig.priv.at