idnits 2.17.1 draft-ietf-mmusic-media-path-middleboxes-07.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 (May 30, 2013) is 3955 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4347' is defined on line 861, 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: December 01, 2013 Nokia Siemens Networks 6 G. Salgueiro 7 Cisco Systems 8 May 30, 2013 10 Analysis of Middlebox Interactions for Signaling 11 Protocol Communication along the Media Path 12 draft-ietf-mmusic-media-path-middleboxes-07.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 December 01, 2013. 53 Copyright Notice 55 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . 4 74 4.1. Protocol Interaction . . . . . . . . . . . . . . . . . . 5 75 4.1.1. Single-Stage Commit . . . . . . . . . . . . . . . . . 5 76 4.1.2. Two-Stage Commit . . . . . . . . . . . . . . . . . . 7 77 4.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 8 78 5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 9 79 5.1. Protocol Interaction . . . . . . . . . . . . . . . . . . 10 80 5.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 14 81 6. Interactions between Media Path Signaling and Middlebox 82 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 6.1. Packet Filtering . . . . . . . . . . . . . . . . . . . . 14 84 6.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 15 85 7. Preliminary Recommendations . . . . . . . . . . . . . . . . . 16 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 11.2. Informative References . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 pass through. 150 Additionally, in case of media relaying it is important for the 151 MIDCOM agent to 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 and 199 /or destination endpoint in the packet flow filter. In such a case, 200 the packet flow filter is considered to have matched against a given 201 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 | | | | | 283 Figure 2: Example Single-stage Commit with SIP and SDP 285 In the example above, policy is created in steps 4 and 5 to allow bi- 286 directional media flow based on the SDP exchanged in steps 1 and 3. 287 In particular, the rules at the UAC side middlebox would indicate 288 that traffic exchanged between IP address 47.0.0.1 and port number 289 49170 and IP address 47.0.0.2 and port number 36220 is allowed in 290 both directions. 292 In this example, the MIDCOM agent installs the policies after the 200 293 OK to the INVITE arrives in step 3. With a firewalling policy of 294 'deny by default' media sent prior to steps 5 and 4 by the UAC or UAS 295 is discarded by the middleboxes. 297 Noted that early media that arrives before the 200 OK would require 298 special treatment since otherwise it would be dropped as well. 300 4.1.2. Two-Stage Commit 302 Two-stage commit is used when the MIDCOM agent also providers 303 functionality, such as Quality of Service signaling that may require 304 resources to be reserved early on in the call establishment process 305 before it is known if the call will be answered. An example of this 306 would be where the MIDCOM agent is responsible for guaranteeing a 307 minimum level of bandwidth along the media path. In this case an 308 initial set of policies may be sent by the MIDCOM agent to the 309 middlebox even though they are put into a pending state but trigger a 310 resource reservation. Later, when the call is accepted, the gate 311 controller may update the state of the policies to active them. 313 UAC Side MIDCOM UAS Side 314 UAC Middlebox Agent Middlebox UAS 315 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 316 | | | | | 317 | (1) INVITE + SDP Offer | | | 318 |---------------------------->| (2) INVITE + SDP Offer | 319 | c=IN IP4 47.0.0.1 |---------------------------->| 320 | m=audio 49170 RTP/AVP 0 | c=IN IP4 47.0.0.1 | 321 | a=sendrecv | m=audio 49170 RTP/AVP 0 | 322 | | | a=sendrecv | 323 | | | | | 324 | | | (3) 180 + SDP Answer | 325 | (4) 180 + SDP Answer |<----------------------------| 326 |<----------------------------| c=IN IP4 47.0.0.2 | 327 | c=IN IP4 47.0.0.2 | m=audio 36220 RTP/AVP 0 | 328 | m=audio 36220 RTP/AVP 0 | a=sendrecv | 329 | a=sendrecv | | | 330 | | | | | 331 | | (5) Policy | (6) Policy | | 332 | |<---------------|--------------->| | 333 | | Src: 47.0.0.2 | Src: 47.0.0.1 | | 334 | | port 36220 | port 49170 | | 335 | | Dst: 47.0.0.1 | Dst: 47.0.0.2 | | 336 | | port 49170 | port 36220 | | 337 | | rule inactive | rule inactive | | 338 | | action=permit | action=permit | | 339 | | | | | 340 | | | (7) 200 OK | 341 | | |<----------------------------| 342 | | | | | 343 | | (9) UpdateGate | (8) UpdateGate | | 344 | |<---------------|--------------->| | 345 | | G: sendrecv | G: sendrecv | | 346 | | | | RTP | 347 |<=========================================================>| 348 | | | | | 349 | (10) 200 OK | | | 350 |<----------------------------| | | 351 | | | | | 352 | (11) ACK | (12) ACK | 353 |---------------------------->|---------------------------->| 354 | | | | | 356 Figure 3: Example Two-stage Commit with SIP and SDP 358 In the example above, policies are created in steps 5 and 6 based off 359 of the SDP sent in steps 1 and 3 in an initial inactive state (no 360 packets are allowed to flow) despite the SDP indicating the media 361 should be bi-directional. This interaction with the middlebox, 362 however, triggers a QoS reservation to take place. Later, when the 363 200 OK to the INVITE comes in step 7, the policies are updated in 364 steps 8 and 9 to indicate that packets should be allowed to flow bi- 365 directionally. Although functionally equivalent to the single-stage 366 commit example given earlier in Figure 2, other operations at the 367 gate agent may have been performed simultaneously in steps 5 and 6 368 that justifies the early explicit definition of the gates in an 369 inactive state. The full usage of PRACK here is not shown for 370 purposes of brevity. 372 4.2. Further Reading 374 Packet filtering based on the approach described in this document has 375 been described in a number of documents. Although the usage of this 376 architecture can also be found on the Internet their behavior is 377 largely specified only in documents that relate to IMS 378 standardization. The behavior of the devices deployed on the 379 Internet is therefore largely undocumented. Nevertheless, the 380 following documents give the reader a better idea of the 381 functionality and the signaling interaction. These documents may 382 also specify an additional behavior in relation to how packet 383 filtering is used when the MIDCOM agent is responsible for processing 384 SIP/SDP call control signaling and the middlebox is responsible for a 385 variety of activities beyond pure filtering. For example, it is 386 common for middleboxes to exempt RTCP flows from being blocked even 387 though the associated RTP flows are not allowed to flow in order to 388 support RTCP signaling while a call is on hold. These references are 389 given here for the reader to gather a better understanding of how 390 this is mechanism is used in various forums and is non-exhaustive: 392 1. 3GPP, "TS 23.203: Policy and charging control architecture" 393 [TS-23.203] 395 2. 3GPP, "TS 29.212: Policy and Charging Control over Gx reference 396 point" [TS-29.212] 398 3. 3GPP, "TS 29.213: Policy and Charging Control signaling flows and 399 QoS parameter mapping" [TS-29.213] 401 4. 3GPP, "TS 29.214: Policy and charging control over Rx reference 402 point" [TS-29.214] 404 5. ETSI TISPAN, "ES 282-003: Telecommunications and Internet 405 converged Services and Protocols for Advanced Networking 406 (TISPAN); Resource and Admission Control Sub-system (RACS); 407 Functional Architecture" [TISPAN-ES-282-003] 409 6. Cablelabs, "PacketCable 2.0: Quality of Service Specification 410 (PKT-SP-QOS-I01-070925)" [PKT-SP-QOS-I01-070925] 412 Note that different terms are used for the MIDCOM agent and the 413 middlebox. For example, in an IMS context the MIDCOM agent would be 414 part of the P-CSCF and PCRF elements or in TISPAN it would be part of 415 the P-CSCF, A-RACF and SPDF that are involved in controlling gating 416 operations. Many different elements perform the role of a middlebox: 417 GSM GGSN, CDMA PDSN, EPC PDN Gateway, TISPAN RCEF and C-BGF/I-BGF, 418 PacketCable CMTS, etc. These functions may be present in the network 419 in a unified or decomposed architecture. 421 5. NAT Traversal 423 Two distinct types of NAT traversal can be supported by a MIDCOM 424 agent and the connected middlebox: 426 1. The MIDCOM agent and the attached middlebox act as a B2BUA at the 427 border of an operator's network to protect this network and to 428 perform the IP address and port conversion, which may be required 429 because private address spaces are used within the network, or 430 because IPv4 and IPv6 address realms are interfacing. For this 431 use case, the middlebox itself performs functions similar to a 432 NAT and is deployed instead of a NAT at a network border. 434 2. The MIDCOM agent and attached middlebox support the traversal of 435 a residential NAT (also termed customer premise equipment), which 436 is typically located at the user's side of an access network, for 437 instance within a DSL router. The middlebox thereby acts as kind 438 of media relay. 440 Both functions can be combined by the same MIDCOM agent and connected 441 middlebox, for instance by a TISPAN C-BGF. 443 As shown in Figure 1 the MIDCOM agent that is being co-located with 444 the SIP ALG functionality interacts with the middlebox that is also a 445 NAT in order to request and allocate NAT bindings and then modifies 446 the SDP offer and answer within SIP to insert the IP addresses and 447 port allocated by the NAT as destination for the media in both 448 directions. A consequence of the interaction with a (double) NAT is 449 that the media traffic is forced to traverse a certain NAT in both 450 directions (also called media anchoring). The opening of pinholes 451 through the middlebox is only done on request of the MIDCOM agent, 452 and not triggered by the detection of outbound media flows. Such 453 middleboxes are for instance the TISPAN 3GPP Tr-GW/C-BGF/I-BGF and 454 the 3GPP IMS Access Gateway. 456 The functionality and control of the middlebox becomes comparable to 457 a media gateway and TISPAN standardized the usage of the H.248 / 458 MEGACO protocol for the control of the middlebox by the midcom MIDCOM 459 agent. 461 This architecture could be compared with a STUN relay [RFC5766] that 462 is being controlled by the MIDCOM agent rather than the end point 463 itself. The motivation why this technique is being used in favor to 464 other NAT traversal techniques is that clients do not have to support 465 anything beyond RFC 3261 [RFC3261] and network administrators can 466 control and apply local policy to the relay binding process in a 467 centralized manner. 469 5.1. Protocol Interaction 471 The MIDCOM agent's role is to inspect call control signaling and 472 update media address and port values based upon media relay binding 473 information allocated with the middlebox/media relay. For SIP, this 474 minimally involves updating the c= and m= lines in the SDP, although 475 some implementations may also update other elements of the SDP for 476 various reasons. 478 Because the endpoints may not be able to gather a server reflexive 479 address for their media streams, the MIDCOM agent employs the 480 following algorithm to ensure that media can flow to the given 481 endpoint: 483 1. When receiving an initial SDP offer, the MIDCOM agent requests 484 authorization for the request arriving at the middlebox, 485 configures the middlebox to forward media between the offerer and 486 the destination address / port as received in the incoming SDP 487 offer, reserves a local IP address and port, and replaces the 488 destination address and port from the incoming offer with the IP 489 address / port used by the middlebox in the forwarded offer. 491 2. When receiving an initial SDP answer, the MIDCOM agent configures 492 the middlebox for the corresponding session to send media towards 493 the answerer towards the destination address and port as received 494 in the incoming SDP answer, request the middlebox to reserve a 495 local IP address / port, and exchange the destination address and 496 port from the incoming answer with that middlebox IP address and 497 port in the forwarded answer. 499 3. If the middlebox supports the traversal of residential NATs, it 500 applies a technique called "media latching": The destination IP 501 address of packets forwarded by the middlebox in the outbound 502 direction is derived from the source IP address of packets 503 received in the inbound direction. This overrides a destination 504 address possibly configured by the MIDCOM agent. 506 An example of this algorithm is shown in Figure 4 when using SIP and 507 SDP. In this example the UAC is the endpoint served by the MIDCOM 508 agent, which is also acting as a local outbound proxy, and the UAS is 509 the corresponding endpoint. We assume that the UAC is located behind 510 a residential NAT; this NAT is, however, not shown in Figure 4. 512 Media Relay MIDCOM Agent and 513 UAC Middlebox Outbound Proxy UAS 514 (UAC side) 515 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 516 | | | | 517 | (1) INVITE + SDP Offer | | 518 |---------------------------->| | 519 | c=IN IP4 10.0.0.1 | | 520 | m=audio 49170 RTP/AVP 0 | | 521 | a=sendrecv | | 522 | | | | 523 | | (2) Allocate | | 524 | |<------------- | | 525 | | | | 526 | | (3) Response | | 527 | |-------------->| | 528 | | In: 47.0.0.3 | (4) INVITE + SDP Offer | 529 | | 50000 |---------------------------->| 530 | | Out: 47.0.0.4 | c=IN IP4 47.0.0.3 | 531 | | 50002 | m=audio 50000 RTP/AVP 0 | 532 | | | a=sendrecv | 533 | | | | 534 | | | (5) 180 + SDP Answer | 535 | | (6) Update |<----------------------------| 536 | |<--------------| c=IN IP4 47.0.0.2 | 537 | | Peer: 47.0.0.2| m=audio 36220 RTP/AVP 0 | 538 | | 36220 | a=sendrecv | 539 | (7) 180 + SDP Answer | | 540 |<----------------------------| | 541 | c=IN IP4 47.0.0.4 | | 542 | m=audio 50002 RTP/AVP 0 | | 543 | a=sendrecv | | 544 | | | | 545 | (8) 200 OK | (8) 200 OK | 546 |<----------------------------|<----------------------------| 547 | | | | 548 | (9) ACK | (9) ACK | 549 |---------------------------->|---------------------------->| 550 | | | | 551 | | | (10) UAS-RTP | 552 | X<============================================| 553 | | | Source: 47.0.0.2:36220 | 554 | (11) UAC-RTP| | Dest: 47.0.0.3:50000 | 555 |============>| | | 556 | Source: 47.0.0.100:48650 | | 557 | Dest: 47.0.0.4:50002 | | 558 | | | (12) UAC-RTP | 559 | |============================================>| 560 | | | Source: 47.0.0.3:50000 | 561 | | | Dest: 47.0.0.2:36220 | 562 | | | | 563 | | | (13) UAS-RTP | 564 | |<============================================| 565 | | | Source: 47.0.0.2:36220 | 566 | (14) UAC-RTP| | Dest: 47.0.0.3:50000 | 567 |<============| | | 568 | Source: 47.0.0.4:50002 | | 569 | Dest: 47.0.0.100:48650 | | 570 | | | | 572 Figure 4: Call Flow with SIP + SDP 574 Step (1): UAC sends INVITE to local outbound proxy, which is also a 575 MIDCOM agent, with an SDP offer. 577 Step (2): The MIDCOM agent looks at the signaling and asks the 578 middlebox to allocate a media relay binding. At this point in 579 time the MIDCOM agent can only provide the IP address it finds 580 inside the offer, i.e., the IP address and port where the UAC is 581 expecting to receive traffic sent by the UAS. In this example the 582 IP address equals 10.0.0.1 and the port number is 49170. 584 Step (3): The middlebox responds with a media relay binding that 585 consists of an inbound address/port for media sent by the UAS, and 586 an outbound address/port for media sent by the UAC. The IP 587 address and port of the middlebox allocated for the inbound side 588 47.0.0.3:50000 and the address and port on the outbound side is 589 47.0.0.4:50002. 591 Step (4): The MIDCOM agent updates the addresses in the SDP offer 592 with the inbound address/port information from the middlebox/media 593 relay binding response, namely with 47.0.0.3:50000. 595 Step (5): The UAS responds with a 180 containing an SDP answer. 596 This answer indicates that traffic will be sent from the IP 597 address and port 47.0.0.2:36220. 599 Step (6): The MIDCOM agent interacts with the middlebox to update 600 the destination address/port information from the SDP answer for 601 media to be sent to the UAS, and changes the addresses/ports in 602 the SDP answer to the UAC with the outbound address/port 603 information from the middlebox binding from step 3. Media can now 604 flow to the UAS from the UAC at the middlebox/media relay, i.e., 605 in the outbound direction. 607 Step (7): The UAC receives the SDP answer containing the media relay 608 outbound address/port information, namely 47.0.0.4:50002. 610 Step (8): The UAS answers the INVITE with a 200 OK. 612 Step (9): The UAC acknowledges with an ACK. 614 Step (10): RTP for the UAS, which may have begun flowing prior to 615 answer, goes to the middlebox, but the middlebox has no reliable 616 address to relay the media to for the UAC yet. Media will 617 typically be dropped. 619 Step (11): RTP arrives at the media relay on the inbound address/ 620 port from the UAC. The middlebox observes the source address and 621 port of the arriving packet and completes the binding process. 623 The source address and port of the media from the UAC is now the 624 destination address/port for media arriving on the outbound port 625 of the middlebox/media relay from the UAS. 627 Step (12): Media originating from the UAC is relayed by the 628 middlebox to the UAS. 630 Step (13): Media from the UAS is sent towards the middlebox. 632 Step (14): The middlebox forwards the media traffic to the UAC. 634 5.2. Further Reading 636 In TS 23.228 the 3GPP standardized the usage of a SIP-ALG residing in 637 the P-CSCF to control an IMS Access Gateway, acting as middlebox at 638 the interface between the IMS and the access network (see Annex G), 639 and the usage of a SIP-ALG residing in the IBCF to control an TrGW as 640 a middlebox at the interface between the IMS and external networks or 641 other IMS networks (see Annex I). 643 Although the described residential NAT traversal approach is used by 644 a number of implementations to overcome incorrect address/port 645 information in call control signaling from an endpoint behind a NAT, 646 only one reference is known that describes the functionality in a 647 standardized manner. 649 1. ETSI TISPAN, "ES 282-003: Telecommunications and Internet 650 converged Services and Protocols for Advanced Networking 651 (TISPAN); Resource and Admission Control Sub-system (RACS); 652 Functional Architecture" [TISPAN-ES-282-003]. The TISPAN Ia 653 interface between the TISPAN BGF and SPDF is the relevant 654 specification. 656 6. Interactions between Media Path Signaling and Middlebox Behavior 658 This section points to the problems that occur when signaling 659 exchanges are performed along the media path when middleboxes are 660 present that behave in the way described in this document. 662 6.1. Packet Filtering 664 The description in Section 4 highlighted that the timing of the 665 policy rule installation by the MIDCOM agent towards the middlebox 666 has an impact on when and what media traffic is allowed to traverse. 668 The installation of policy rules is a prerequisite for related media 669 to flow. As those policy rules are derived from information from 670 both SDP offer and answer, they are typically installed at the 671 completion of the first offer-answer exchange. 673 Furthermore, the middlebox may prevent the exchange of packets in the 674 media path after this point by closing "gates" until the session 675 establishment signaling has reached a pre-configured milestone where 676 the MIDCOM agent signals to the middlebox that packets are allowed to 677 traverse in both directions. Prior to this, packets may be allowed 678 to flow uni-directionally to satisfy certain service requirements or 679 may be entirely blocked by the middlebox. For SIP [RFC3261] the 680 typical milestone that must be reached is offer/answer exchange 681 [RFC3264] accompanied by an acknowledgement that the dialog has been 682 accepted by the UAS (i.e., 200 OK to the INVITE). It depends on the 683 policy of an operator when to open gates. The policy may take into 684 account the requirements of special media types to have early 685 bidirectional media exchanges, e.g. if the usage of DTLS is 686 indicated in SDP. 688 A concrete example of the impact can be found with the case of key 689 exchange along the media path, as it is provided by DTLS-SRTP. The 690 ladder diagram in Section 7.1 of [RFC5763] shows that the arrival of 691 the SIP INVITE at the UAS triggers the DTLS handshake. This message 692 would be blocked by the middlebox, as described in Section 4 since 693 the MIDCOM agent has not yet installed policy rules. The consequence 694 is that the communication fails unless the UAS repeats attempts for 695 an DTLS handshake until connectivity is established in both 696 directions by the installation of policy rules and the presence of 697 opened gates. Due to extra time required for the DTLS exchange the 698 user may experience clipping. 700 According to 3GPP standards, gates for RTCP are always opened when 701 policy rules for related media are installed, even if related media 702 traffic is still blocked. Therefore, signaling embedded in RTCP is 703 likely to pass after the completion of the first offer-answer 704 exchange. Standardized policy rules only inspect source and 705 destination information of IP packets and the transport protocol 706 (e.g., UDP and TCP). Obviously, this is not a property that can be 707 guaranteed to be true in the future. 709 6.2. NAT Traversal 711 The described NAT traversal interaction prevents asynchronous 712 exchange of packets in the media path until a pilot packet has been 713 received by the middlebox from the endpoint being served. It can be 714 employed for both the [RFC3264] offerer and/or answerer. Therefore, 715 in the worst case, both endpoints must generate a pilot packet 716 towards each other to ensure a bi-directional media path exists. Any 717 signaling on the media path that relies upon a uni-directional 718 handshake in the reverse direction may not complete until media in 719 the forward direction by the other endpoint. If signaling on the 720 media path is required to complete prior to media generation the 721 handshake may stall indefinitely. 723 Middleboxes as described in Section 5 will not allow any media to 724 pass through without being configured to do so by the MIDCOM agent 725 when the first offer-answer exchange is completed. Without latching, 726 it may be technically feasible to pass media packets from answerer 727 towards the offerer after the offer has passed the MIDCOM agent, but 728 existing implementations hardly show that behavior. Furthermore, 729 such middleboxes may apply gating policies similar to the policies 730 discussed in Section 6.1 in addition. 732 The described latching technique for residential NAT traversal 733 interaction requires that a pilot packet has been received by the 734 middlebox from the endpoint being served before the middlebox is able 735 to send packets towards the endpoint. This latching technique can be 736 employed for both the RFC 3264 offerer and answerer. Therefore, in 737 the worst case, both endpoints must generate a pilot packet towards 738 each other to ensure that a bi-directional media path exists. If the 739 first packets to be exchanged in the media path are signaling packets 740 and a particular directionality of those packets is required, 741 communication may fail. To overcome these problems, empty packets 742 could be sent by the endpoint that has to receive rather than to send 743 the first signaling message. The offer is capable of sending the 744 pilot packet only when receiving the destination information within 745 the answer. Thus, before that point in time the offerer will also 746 not be able to receive any media packets or related signaling. 748 In a similar manner as outlined in Section 6.1, any in-path signaling 749 messages that are sent before the offer-answer exchange is completed 750 will be dropped. 752 7. Preliminary Recommendations 754 The following preliminary recommendations are suggested: 756 REC #1: It is recommended that any protocol handshake on the media 757 path ensure that a mechanism exists that causes both endpoints to 758 send at least one packet in the forward direction as part of, or 759 prior to, the handshake process. Retransmission of STUN 760 connectivity checks (see [RFC5389]) as part of ICE [RFC5245] is an 761 example of such a mechanism that satisfies this recommendation. 762 Sending of no-op RTP packets (see [I-D.ietf-avt-rtp-no-op]) is 763 another example. 765 REC #2: It is recommended that middleboxes present on the media 766 path allow at least a nominal amount of traffic to be exchanged 767 between endpoints after the completion of the first offer-answer 768 exchange to enable the completion of media path signaling prior to 769 the session being established. Such policies may be restricted to 770 media types that use in-path signaling. The amount of traffic 771 necessary to complete the signaling between endpoints is expected 772 to be orders of magnitude smaller than that of any sufficiently 773 interesting fraudulent traffic. 775 REC #3: It is recommended that failure to complete signaling on the 776 media path not automatically cause the session establishment to 777 fail unless explicitly specified by one or more endpoints. A 778 fallback scenario where endpoints retry signaling on the media 779 path is recommended. Recommended points in time to retry 780 signaling on the media path are after the completion of the first 781 offer-answer exchange and again after the session has been 782 established. Additional retries with adequate pacing may be used 783 in addition. 785 REC #4: If signaling on the media path is required before media can 786 flow, the answerer should send the SDP answer as soon as possible, 787 for example within a provisional SIP response, to allow the media 788 path signaling to pass through middleboxes and therefore to avoid 789 clipping. 791 REC #5: It is recommended that middleboxes present on the media path 792 allow at least a nominal amount of traffic to be exchanged between 793 endpoints for at least one RTT after the middlebox receives a 794 message from the MIDCOM agent indicating the media session being 795 terminated. This will ensure that any transit signaling packets 796 on the media path exchanged during the session termination pass 797 through the middlebox. 799 8. Security Considerations 801 This document talks about security related functionality and the 802 impact of one security mechanism, namely firewalling, to another one, 803 namely key management for media security. 805 9. IANA Considerations 807 This document does not require actions by IANA. 809 10. Acknowledgements 811 We would like to thank Steffen Fries, Dan Wing, Eric Rescorla, and 812 Francois Audet for their input to this document. Furthermore, we 813 would like to thank Jason Fischl, Guenther Horn, Thomas Belling, 814 Peter Schneider, Jari Arkko, Cullen Jennings for the discussion input 815 to this problem space. 817 We would also like to thank the participants of the IETF#70 MMUSIC 818 working group meeting for their feedback. 820 Thomas Belling provided text proposals in April 2008. We are 821 thankful for his detailed suggestions. 823 This document has benefited from the discussion and review of the 824 MMUSIC working group, especially the detailed review and thoughtful 825 comments of Peter Musgrave and Muthu Arul Mozhi Perumal. 827 11. References 829 11.1. Normative References 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, March 1997. 834 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 835 A., Peterson, J., Sparks, R., Handley, M., and E. 836 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 837 June 2002. 839 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 840 with Session Description Protocol (SDP)", RFC 3264, June 841 2002. 843 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 844 A. Rayhan, "Middlebox communication architecture and 845 framework", RFC 3303, August 2002. 847 11.2. Informative References 849 [I-D.ietf-avt-rtp-no-op] 850 Andreasen, F., "A No-Op Payload Format for RTP", draft- 851 ietf-avt-rtp-no-op-04 (work in progress), May 2007. 853 [PKT-SP-QOS-I01-070925] 854 CableLabs, "PacketCable 2.0: Quality of Service 855 Specification", September 2007, . 858 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 859 Issues", RFC 3234, February 2002. 861 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 862 Security", RFC 4347, April 2006. 864 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 865 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 866 RFC 4787, January 2007. 868 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 869 (ICE): A Protocol for Network Address Translator (NAT) 870 Traversal for Offer/Answer Protocols", RFC 5245, April 871 2010. 873 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 874 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 875 October 2008. 877 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 878 for Establishing a Secure Real-time Transport Protocol 879 (SRTP) Security Context Using Datagram Transport Layer 880 Security (DTLS)", RFC 5763, May 2010. 882 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 883 Relays around NAT (TURN): Relay Extensions to Session 884 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 886 [TISPAN-ES-282-003] 887 ETSI, "Telecommunications and Internet converged Services 888 and Protocols for Advanced Networking (TISPAN); Resource 889 and Admission Control Sub-system (RACS); Functional 890 Architecture", June 2006, . 892 [TS-23.203] 893 3GPP, "Policy and charging control architecture", 894 September 2007, 895 . 897 [TS-29.212] 898 3GPP, "Policy and Charging Control over Gx reference 899 point", June 2008, 900 . 902 [TS-29.213] 903 3GPP, "Policy and Charging Control signaling flows and QoS 904 parameter mapping", June 2008, 905 . 907 [TS-29.214] 908 3GPP, "Policy and charging control over Rx reference 909 point", June 2008, 910 . 912 Authors' Addresses 914 Brian Stucker 915 Unaffiliated 917 Email: obsidian97@gmail.com 918 URI: http://www.linkedin.com/in/bstucker 920 Hannes Tschofenig 921 Nokia Siemens Networks 922 Linnoitustie 6 923 Espoo 02600 924 Finland 926 Phone: +358 (50) 4871445 927 Email: Hannes.Tschofenig@gmx.net 928 URI: http://www.tschofenig.priv.at 930 Gonzalo Salgueiro 931 Cisco Systems 932 7200-12 Kit Creek Road 933 Research Triangle Park, NC 27709 934 US 936 Email: gsalguei@cisco.com