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