idnits 2.17.1 draft-ietf-mmusic-media-path-middleboxes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 812. 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 25 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 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 (January 17, 2008) is 5941 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4347' is defined on line 735, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-13 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-05 -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 8 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: July 20, 2008 Nokia Siemens Networks 6 January 17, 2008 8 Analysis of Middlebox Interactions for Signaling Protocol Communication 9 along the Media Path 10 draft-ietf-mmusic-media-path-middleboxes-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 20, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 Middleboxes are defined as any intermediary box performing functions 44 apart from normal, standard functions of an IP router on the data 45 path between a source host and destination host. Two such functions 46 are network address translation and firewalling. 48 When Application Layer Gateways, such as SIP entities, interact with 49 NATs and firewalls, as described in the MIDCOM architecture, then 50 problems may occur in the transport of media traffic when signaling 51 protocol interaction takes place along the media path, as it is the 52 case for recent key exchange proposals (such as DTLS-SRTP). This 53 document highlights problems that may arise. Unfortunately, it is 54 difficult for the end points to detect or predict problematic 55 behavior and to determine whether the media path is reliably 56 available for packet exchange. 58 This document aims to summarize the various sources and effects of 59 NAT and firewall control, the reasons that they exist, and possible 60 means of improving their behavior to allow protocols that rely upon 61 signaling along the media path to operate effectively. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 5 70 4.1.1. Single-Stage Commit . . . . . . . . . . . . . . . . . 5 71 4.1.2. Two-Stage Commit . . . . . . . . . . . . . . . . . . . 7 72 4.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 9 73 5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 10 75 5.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 13 76 6. Interactions between Media Path Signaling and Middlebox 77 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1. Firewalling . . . . . . . . . . . . . . . . . . . . . . . 14 79 6.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14 80 7. Preliminary Recommendations . . . . . . . . . . . . . . . . . 15 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 88 Intellectual Property and Copyright Statements . . . . . . . . . . 19 90 1. Introduction 92 According to by RFC 3234 [RFC3234] middleboxes are defined as any 93 intermediary box performing functions apart from normal, standard 94 functions of an IP router on the data path between a source host and 95 destination host. 97 In the context of SIP a SIP ALG may interact with a node along the 98 media path to control network address translation, firewalling, and 99 other functions. 101 With firewall control packet filters are installed based on the 102 SIP signaling interaction to implement a behavior of 'deny by 103 default' in order to reduce the risk of unwanted traffic. This 104 function is often referred to as 'gating'. Depending on the 105 timing of the packet filter installation and the content of the 106 packet filter signaling traffic along the media, such as DTLS-SRTP 107 or ICE, may be treated in an unexpected way. 109 In cases where the middlebox is involved in overcoming unmanaged 110 NAT traversal the case is similar. The key feature of this type 111 of NAT traversal is a desire to overcome the possible lack of 112 information about any [RFC4787] address and/or port mapping by a 113 possibly unknown NAT device (server reflexive address and 114 filtering properties). In particular, a NAT binding for an 115 endpoint may not exist yet for the address and port identified in 116 the endpoint's SDP. As such, a pilot packet sent by that endpoint 117 behind the NAT is required to create the necessary mappings in the 118 NAT for the media relay to deliver media destined for that 119 endpoint. Until that pilot packet is received no media packets 120 may be reliably forwarded to the endpoint by the relay. 122 This document presents a summary of these two techniques, discusses 123 their impact upon other protocols such as ICE and DTLS-SRTP, and 124 proposes a set of recommendations to mitigate the effects of gating 125 and latching on in-band negotiation mechanisms. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 We use the terms filter, policy action (or action), policy rule(s), 134 MIDCOM agent, and MIDCOM Policy Decision Point (PDP) as defined in 135 [RFC3303]. The MIDCOM agent is co-located with a SIP ALG that 136 comunicates with the firewall or the media relay. 138 3. Architecture 140 Figure 1 shows the architecture that is being considered in this 141 document with respect to firewall and NAT traversal using media 142 relaying. The timing and directionality with which media packets are 143 allowed to traverse a particular edge device is the subject of this 144 investigation. The MIDCOM agent thereby pushes policy rules to the 145 middlebox that allow or deny certain flows to bypass. Additionally, 146 in case of media relaying it is important for the MIDCOM agent to 147 adjust the signaling messages. 149 SIP +-----------------+ SIP 150 +-----+ Signaling | SIP ALG | Signaling +-----+ 151 | UAC |<----------->+-----------------+<----------->| UAS | 152 +-----+ | MIDCOM Agent | +-----+ 153 ^ +-----------------+ ^ 154 | ^ | 155 | Policy rule(s) | and NAT bindings | 156 | v | 157 | Media +-------------+ Media | 158 +----------------->| Middlebox |<-----------------+ 159 +-------------+ 161 Figure 1: Analysed Firewalling Architecture 163 The aspects of packet filtering are described in Section 4 whereas 164 NAT traversal is illustrated in Section 5. 166 4. Packet Filtering 168 Figure 1 highlights the interaction between the MIDCOM agent and the 169 middlebox. These two elements inspect call control signaling and 170 media path packets and determine when packets from a given source to 171 a given destination are allowed to flow between endpoints. It is 172 common for the gate controller to be the local outbound proxy for a 173 given SIP UA being gated. 175 The primary responsibility of the MIDCOM agent, which is co-located 176 with a SIP entity, is to examine the call control signaling to 177 determine the media addresses and ports used to define the media path 178 between the gated device and the endpoint(s) with which it is 179 corresponding. For SIP, this would correspond to the media addresses 180 described within SDP after at least one full offer/answer exchange. 182 This information is used to create one or more packet filters that 183 describe the expected media path(s) for the call. These packet 184 filters are combined with an algorithmic determination, typically 185 based on the state of the call, as to which direction(s) media 186 packets are allowed to flow between the endpoints, if at all. The 187 filter and the action that is being installed by the MIDCOM agent at 188 the middlebox may change during the lifetime of a SIP signaling 189 session, depending on the state of the call or on changes of the 190 address and port information of one (or even both) of the end points. 192 It is possible that the gate controller may not be able to establish 193 an exact address or port for one endpoint involved in the call in 194 which case it may wildcard the address and/or port for the source 195 and/or destination endpoint in the packet flow filter. In such a 196 case, the packet flow filter is considered to have matched against a 197 given media packet for the wildcarded field. 199 Note that it is possible to specify the filter using wildcards, for 200 example, if some end point address information is not known at a 201 given point in time. Additonally, the default firewalling policy is 202 subject to local configuration ('deny per default' vs. 'permit per 203 default'). For a given SIP signaling sessions the policy at the 204 MIDCOM agent might be very strict with respect to the packets that 205 are allowed to flow in a particular direction. For example, packets 206 may be allowed to flow in both directions, only in one direction for 207 a specific media stream. No particular behavior can be assumed. 209 When a media session is destroyed (end of call, deleted from the 210 session description, etc.), the MIDCOM agent removes policy rules 211 created for that media session at the middlebox. 213 4.1. Protocol Interaction 215 MIDCOM agents may employ a variety of models to determine when to 216 change the status of a particular policy rule. This is especially 217 true when a call is being established. For SIP, this would be when 218 an early dialog is established between endpoints. Although there is 219 the potential for a great deal of variability due to an intentional 220 lack of specification, typically, one of two models is used by the 221 MIDCOM agent to determine the state of a policy rule during call 222 setup: single-stage and two-stage commit. The term 'commit' here 223 refers to the point at which a policy rule is setup that allows media 224 traffic to flow. For example, this would be the point at which 225 packets for a media stream marked a=sendrecv in SDP was allowed to 226 flow bi-directionally by the middlebox. 228 4.1.1. Single-Stage Commit 230 Single stage commit is commonly used when the MIDCOM agent is most 231 involved only in firewalling. For SIP, MIDCOM agents use a single- 232 stage commit model typically install policy rules for the call when 233 the 200 OK to the INVITE is received in the case that the INVITE 234 contained an SDP offer, or when the ACK is received if the initial 235 offer was sent in the 200 OK itself. 237 This model is often used to prevent media from being sent end-to-end 238 prior to the call being established. 240 UAC Side MIDCOM UAS Side 241 UAC Middlebox Agent Middlebox UAS 242 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 243 | | | | | 244 | (1) INVITE + SDP Offer | | | 245 |---------------------------->| (2) INVITE + SDP Offer | 246 | c=IN IP4 47.0.0.1 |---------------------------->| 247 | m=audio 49170 RTP/AVP 0 | c=IN IP4 47.0.0.1 | 248 | a=sendrecv | m=audio 49170 RTP/AVP 0 | 249 | | | a=sendrecv | 250 | | | | | 251 | | | (3) 200 OK + SDP Answer | 252 | | |<----------------------------| 253 | | | c=IN IP4 47.0.0.2 | 254 | | | m=audio 36220 RTP/AVP 0 | 255 | | | a=sendrecv | | 256 | | | | | 257 | | (5) Policy | (4) Policy | | 258 | |<---------------|--------------->| | 259 | | Src: 47.0.0.2 | Src: 47.0.0.1 | | 260 | | port 36220 | port 49170 | | 261 | | Dst: 47.0.0.1 | Dst: 47.0.0.2 | | 262 | | port 49170 | port 36220 | | 263 | | sendrecv | sendrecv | | 264 | | action=permit | action=permit | | 265 | | | | | 266 | | | | RTP | 267 |<=========================================================>| 268 | | | | | 269 | (6) 200 OK + SDP Answer | | | 270 |<----------------------------| | | 271 | c=IN IP4 47.0.0.2 | | | 272 | m=audio 36220 RTP/AVP 0 | | | 273 | a=sendrecv | | | 274 | | | | | 275 | (7) ACK | (8) ACK | 276 |---------------------------->|---------------------------->| 277 | | | | | 278 Figure 2: Example Single-stage Commit with SIP and SDP 280 In the example above, policy is created in steps 4 and 5 to allow bi- 281 directional media flow based on the SDP exchanged in steps 1 and 3. 282 In this example, the MIDCOM agent installes the policies after the 283 200 OK to the INVITE arrives in step 3. With a firewalling policy of 284 'deny by default' media sent prior to steps 5 and 4 by the UAC or UAS 285 is discarded by the middleboxes. 287 Noted that early media that arrives before the 200 OK would require 288 special treatement since otherwise it would be dropped as well. 290 4.1.2. Two-Stage Commit 292 Two-stage commit is used when the MIDCOM agent also providers 293 functionality, such as Quality of Service signaling that may require 294 resources to reserved early on in the call establishment process 295 before it is known if the call will be answered. An example of this 296 would be where the MIDCOM agent is responsible for guaranteeing a 297 minimum level of bandwidth along the media path. In this case an 298 initial set of policies may be sent by the MIDCOM agent to the 299 middlebox even though they are put into a pending state but trigger a 300 resource reservation. Later, when the call is accepted, the gate 301 controller may update the state of the policies to active them. 303 UAC Side MIDCOM UAS Side 304 UAC Middlebox Agent Middlebox UAS 305 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 306 | | | | | 307 | (1) INVITE + SDP Offer | | | 308 |---------------------------->| (2) INVITE + SDP Offer | 309 | c=IN IP4 47.0.0.1 |---------------------------->| 310 | m=audio 49170 RTP/AVP 0 | c=IN IP4 47.0.0.1 | 311 | a=sendrecv | m=audio 49170 RTP/AVP 0 | 312 | | | a=sendrecv | 313 | | | | | 314 | | | (3) 180 + SDP Answer | 315 | (4) 180 + SDP Answer |<----------------------------| 316 |<----------------------------| c=IN IP4 47.0.0.2 | 317 | c=IN IP4 47.0.0.2 | m=audio 36220 RTP/AVP 0 | 318 | m=audio 36220 RTP/AVP 0 | a=sendrecv | 319 | a=sendrecv | | | 320 | | | | | 321 | | (5) Policy | (6) Policy | | 322 | |<---------------|--------------->| | 323 | | Src: 47.0.0.2 | Src: 47.0.0.1 | | 324 | | port 36220 | port 49170 | | 325 | | Dst: 47.0.0.1 | Dst: 47.0.0.2 | | 326 | | port 49170 | port 36220 | | 327 | | rule inactive | rule inactive | | 328 | | action=permit | action=permit | | 329 | | | | | 330 | | | (7) 200 OK | 331 | | |<----------------------------| 332 | | | | | 333 | | (9) UpdateGate | (8) UpdateGate | | 334 | |<---------------|--------------->| | 335 | | G: sendrecv | G: sendrecv | | 336 | | | | RTP | 337 |<=========================================================>| 338 | | | | | 339 | (10) 200 OK | | | 340 |<----------------------------| | | 341 | | | | | 342 | (11) ACK | (12) ACK | 343 |---------------------------->|---------------------------->| 344 | | | | | 346 Figure 3: Example Two-stage Commit with SIP and SDP 348 In the example above, policies are created in steps 5 and 6 based off 349 of the SDP sent in steps 1 and 3 in an initial inactive state (no 350 packets are allowed to flow) despite the SDP indicating the media 351 should be bi-directional. This interaction with the middlebox, 352 however, triggers a QoS reservation to take place. Later, when the 353 200 OK to the INVITE comes in step 7, the policies are updated in 354 steps 8 and 9 to indicate that packets should be allowed to flow bi- 355 directionally. Although functionally equivalent to the single-stage 356 commit example given earier in Figure 2, other operations at the gate 357 agent may have been performed simultaneously in steps 5 and 6 that 358 justifies the early explicit definition of the gates in an inactive 359 state. The full usage of PRACK here is not shown for purposes of 360 brevity. 362 4.2. Further Reading 364 Packet filtering based on the approach described in this document has 365 been described in a number of documents. Although the usage of this 366 architecture can also be found on the Internet their behavior is 367 largely specified only in documents that relate to IMS 368 standardization. The behavior of the devices deployed on the 369 Internet is therefore largely undocumented. Nevertheless, the 370 following documents give the reader a better idea of the 371 functionality and the signaling interaction. These documents may 372 also specify an additional behavior in relation to how packet 373 filtering is used when the MIDCOM agent is responsible for processing 374 SIP/SDP call control signaling and the middlebox is responsible for a 375 variety of activities beyond pure filtering. For example, it is 376 common for middleboxes to exempt RTCP flows from being blocked even 377 though the associated RTP flows are not allowed to flow in order to 378 support RTCP signaling while a call is on hold. These references are 379 given here for the reader to gather a better understanding of how 380 this is mechanism is used in various forums and is non-exhaustive: 382 1. 3GPP, "TS 23.203: Policy and charging control architecture" 383 [TS-23-203] 385 2. 3GPP, "TS 29.214: Policy and charging control over Rx reference 386 point" [TS-29-214] 388 3. ETSI TISPAN, "ES 282-003: Telecommunications and Internet 389 converged Services and Protocols for Advanced Networking 390 (TISPAN); Resource and Admission Control Sub-system (RACS); 391 Functional Architecture" [TISPAN-ES-282-003] 393 4. Cablelabs, "PacketCable 2.0: Quality of Service Specification 394 (PKT-SP-QOS-I01-070925)" [PKT-SP-QOS-I01-070925] 396 Note that different terms are used for the MIDCOM agent and the 397 middlebox. For example, in an IMS context the MIDCOM agent would be 398 part of the P-CSCF and PCRF elements or in TISPAN it would be part of 399 the P-CSCF, A-RACF and SPDF that are involved in controlling gating 400 operations. Many different elements perform the role of a middlebox: 401 GSM GGSN, CDMA PDSN, SAE serving gateway, TISPAN A-BGF/C-BGF/I-BGF, 402 PacketCable CMTS, etc. These functions may be present in the network 403 in a unified or decomposed architecture. 405 5. NAT Traversal 407 One NAT traversal technique that is being used is based on media 408 relay. As shown in Figure 1 the MIDCOM agent that is being co- 409 located with the SIP ALG functionality interacts with the middlebox 410 that is also a NAT in order to request and allocate NAT bindings. A 411 side effect of the interaction with a (double) NAT is that the media 412 traffic is forced to traverse a certain NAT in both directions (also 413 called media anchoring). 415 This architecture could be compared with a STUN relay 416 [I-D.ietf-behave-turn] that is being controlled by the MIDCOM agent 417 rather than the end point itself. The motivation why this technique 418 is being used in favor to other NAT traversal techniques is that 419 clients do not have to support anything beyond RFC 3261 [RFC3261] and 420 network administrators can control and apply local policy to the 421 relay binding process in a centralized manner. 423 5.1. Protocol Interaction 425 The MIDCOM agent's role is to inspect call control signaling and 426 update media address and port values based upon media relay binding 427 information allocated with the middlebox/media relay. For SIP, this 428 minimally involves updating the c= and m= lines in the SDP, although 429 some implementations may update other elements of the SDP for various 430 reasons. 432 Because the endpoints may not be able to gather a server reflexive 433 address for their media streams, the MIDCOM agent employs the 434 following algorithm to ensure that media can flow to the given 435 endpoint: 437 1. Give the corresponding endpoint an address and port on the 438 middlebox for them to send media to for the endpoint served by 439 the MIDCOM agent. 441 2. Give the served endpoint a different address and/or port on the 442 middlebox for it to send media to for the corresponding endpoint. 444 3. Use the address and port the corresponding endpoint supplies for 445 media streams as the destination for packets sent to the 446 middlebox by the served endpoint. 448 4. Use the address and port of the first packet received from the 449 served endpoint at the middlebox as the destination for packets 450 sent to the middlebox by the corresponding endpoint. 452 An example of this algorithm is shown in Figure 4 using SIP and SDP. 453 In this example the UAC is the endpoint served by the MIDCOM agent, 454 which is also acting as a local outbound proxy, and the UAS is the 455 corresponding endpoint. 457 Media Relay MIDCOM Agent and 458 UAC Middlebox Outbound Proxy UAS 459 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 460 | | | | 461 | (1) INVITE + SDP Offer | | 462 |---------------------------->| | 463 | c=IN IP4 10.0.0.1 | | 464 | m=audio 49170 RTP/AVP 0 | | 465 | a=sendrecv | | 466 | | | | 467 | | (2) Allocate | | 468 | |<------------- | | 469 | | | | 470 | | (3) Response | | 471 | |-------------->| | 472 | | In: 47.0.0.3 | (4) INVITE + SDP Offer | 473 | | 50000 |---------------------------->| 474 | | Out: 47.0.0.4 | c=IN IP4 47.0.0.3 | 475 | | 50002 | m=audio 50002 RTP/AVP 0 | 476 | | | a=sendrecv | 477 | | | | 478 | | | (5) 180 + SDP Answer | 479 | | (6) Update |<----------------------------| 480 | |<--------------| c=IN IP4 47.0.0.2 | 481 | | Peer: 47.0.0.2| m=audio 36220 RTP/AVP 0 | 482 | | 36220 | a=sendrecv | 483 | (7) 180 + SDP Answer | | 484 |<----------------------------| | 485 | c=IN IP4 47.0.0.4 | | 486 | m=audio 50002 RTP/AVP 0 | | 487 | a=sendrecv | | 488 | | | | 489 | (8) 200 OK | (8) 200 OK | 490 |<----------------------------|<----------------------------| 491 | | | | 492 | (9) ACK | (9) ACK | 493 |---------------------------->|---------------------------->| 494 | | | | 495 | | | (10) UAS-RTP | 496 | X<============================================| 497 | | | Source: 47.0.0.2:36220 | 498 | (11) UAC-RTP| | Dest: 47.0.0.3:50000 | 499 |============>| | | 500 | Source: 47.0.0.100:48650 | | 501 | Dest: 47.0.0.4:50002 | | 502 | | | (12) UAC-RTP | 503 | |============================================>| 504 | | | Source: 47.0.0.3:50000 | 505 | (13) UAS-RTP | Dest: 47.0.0.2:36220 | 506 |<============| | | 507 | Source: 47.0.0.4:50002 | | 508 | Dest: 47.0.0.100:48650 | | 509 | | | | 511 Figure 4: Call Flow with SIP + SDP 513 1. UAC sends INVITE to local outbound proxy, which is also a MIDCOM 514 agent, with an SDP offer. 516 2. The MIDCOM agent looks at the signaling and determines that a 517 NAT may be present (Via header address mismatch with observed 518 source address, etc.). It asks the middlebox to allocate a 519 media relay binding. 521 3. The middlebox responds with a media relay binding that consists 522 of an inbound address/port for media from the UAS, and an 523 outbound address/port for media from the UAC. 525 4. The MIDCOM agent updates the addresses in the SDP offer with the 526 inbound address/port information from the middlebox/media relay 527 binding response. 529 5. The UAS responds with a 180 containing an SDP answer. 531 6. The MIDCOM agent interacts with the middlebox to update the 532 destination address/port information from the SDP answer for 533 media to be sent to the UAS, and changes the addresses/ports in 534 the SDP answer to the UAC with the outbound address/port 535 information from the middlebox binding from step 3. Media can 536 now flow to the UAS from the UAC at the middlebox/media relay. 538 7. The UAC receives the SDP answer containing the media relay 539 outbound address/port information. 541 8. The UAS answers the INVITE with a 200 OK. 543 9. The UAC acknowledges with an ACK. 545 10. RTP for the UAS (which may have begun flowing prior to answer) 546 flows to the middlebox, but the middlebox has no reliable 547 address to relay the media to for the UAC yet. Media will 548 typically be dropped. 550 11. RTP arrives at the media relay on the inbound address/port from 551 the UAC. The middlebox observes the source address and port of 552 the arriving packet and completes the binding process. The 553 source address and port of the media from the UAC is now the 554 destination address/port for media arriving on the outbound port 555 of the middlebox/media relay from the UAS. 557 12. Media from the UAC is relayed to the UAS. 559 13. Media from the UAS is relayed to the UAC. It is up to local 560 policy at the media relay as to whether or not packets that had 561 arrived from the UAS for the UAC are queued or dropped prior to 562 the UAC's address/port information being updated in step 11. 564 5.2. Further Reading 566 Although the described NAT traversal approach is used by a number of 567 implementations to overcome incorrect address/port information in 568 call control signaling from an endpoint behind a NAT, only one 569 reference is known that describes the functionality in a standardized 570 manner. 572 1. ETSI TISPAN, "ES 282-003: Telecommunications and Internet 573 converged Services and Protocols for Advanced Networking 574 (TISPAN); Resource and Admission Control Sub-system (RACS); 575 Functional Architecture" [TISPAN-ES-282-003]. The TISPAN Ia 576 interface between the TISPAN BGF and SPDF is the relevant 577 specification. 579 6. Interactions between Media Path Signaling and Middlebox Behavior 581 This section points to the problems that occur when signaling 582 exchanges are performed along the media path when middleboxes are 583 present that behave in the way described in this document. 585 6.1. Firewalling 587 The description in Section 4 highlighted that the timing of the 588 policy rule installation by the MIDCOM agent towards the middlebox 589 has an impact on when and what media traffic is allowed to traverse. 591 Hence, the middlebox prevents the exchange of packets in the media 592 path until the session establishment signaling has reached a pre- 593 configured milestone where the MIDCOM agent signals to the middlebox 594 that packets are allowed to traverse in both directions. Prior to 595 this, packets may be allowed to flow uni-directionally to satisfy 596 certain service requirements or may be entirely blocked by the 597 middlebox. For SIP [RFC3261] the typically milestone that must be 598 reached is offer/answer exchange [RFC3264] accompanied by an 599 acknowledgement that the dialog has been accepted by the UAS (i.e., 600 200 OK to the INVITE). A concrete example of the impact can be found 601 with the case of key exchange along the media path, as it is provided 602 by DTLS-SRTP. Figure 2 of [I-D.fischl-sipping-media-dtls] shows that 603 the arrival of the SIP INVITE at the UAS triggers the DTLS handshake. 604 This message would be blocked by the middlebox, as described in 605 Section 4 since the MIDCOM agent has not yet installed policy rules. 606 The consequence is that the DTLS key exchange is delayed until the 607 policy rules are installed and that media traffic that is sent before 608 the DTLS exchange is completed may be dropped and the user 609 experiences clippping. 611 Unlike with the pilot packet used for NAT traversal, the bi- 612 directional media path is established via the signaling path, not via 613 packets sent along the media path. In some deployment models, RTCP 614 is always available bi-directionally regardless of the installed 615 policy rules. Obviously, this is not a property that can be 616 guaranteed to be true in the future. 618 6.2. NAT Traversal 620 The described NAT traversal interaction prevents asynchronous 621 exchange of packets in the media path until a pilot packet has been 622 received by the middlebox from the endpoint being served. It can be 623 employed for both the [RFC3264] offerer and/or answerer. Therefore, 624 in the worst case, both endpoints must generate a pilot packet 625 towards each other to ensure a bi-directional media path exists. Any 626 signaling on the media path that relies upon a uni-directional 627 handshake in the reverse direction may not complete until media in 628 the forward direction by the other endpoint. If signaling on the 629 media path is required to complete prior to media generation the 630 handshake may stall indefinitely. 632 7. Preliminary Recommendations 634 The following preliminary recommendations are suggested: 636 REC #1: It is recommended that any protocol handshake on the media 637 path ensure that a mechanism exists that causes both endpoints to 638 send at least one packet in the forward direction as part of, or 639 prior to, the handshake process. Retransmission of STUN 640 connectivity checks (see [I-D.ietf-behave-rfc3489bis]) as part of 641 ICE [I-D.ietf-mmusic-ice] is an example of such a mechanism that 642 satisfies this recommendation. 644 REC #2: It is recommended that middleboxes present on the media 645 path allow a nominal amount of traffic to be exchanged between 646 endpoints to enable completion of media path signaling prior to 647 the session being established. The amount of traffic necessary to 648 complete the signaling between endpoints is expected to be orders 649 of magnitude smaller than that of any sufficiently interesting 650 fraudulent traffic. 652 REC #3: It is recommended that failure to complete signaling on the 653 media path not automatically cause the session establishment to 654 fail unless explicitly specified by one or more endpoints. A 655 fallback scenario where signaling on the media path is retried 656 after the session has been established is recommended. 658 8. Security Considerations 660 This document talks about security related functionality and the 661 impact of one security mechanism, namely firewalling, to another one, 662 namely key management for media security. 664 9. IANA Considerations 666 This document does not require actions by IANA. 668 10. Acknowledgements 670 We would like to thank Steffen Fries, Dan Wing, Eric Rescorla, and 671 Francois Audet for their input to this document. Furthermore, we 672 would like to thank Jason Fischl, Guenther Horn, Thomas Belling, 673 Peter Schneider, Jari Arkko, Cullen Jennings for the discussion input 674 to this problem space. 676 We would also like to thank the participants of the IETF#70 MMUSIC 677 working group meeting for their feedback. 679 11. References 681 11.1. Normative References 683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 684 Requirement Levels", BCP 14, RFC 2119, March 1997. 686 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 687 A., Peterson, J., Sparks, R., Handley, M., and E. 688 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 689 June 2002. 691 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 692 with Session Description Protocol (SDP)", RFC 3264, 693 June 2002. 695 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 696 A. Rayhan, "Middlebox communication architecture and 697 framework", RFC 3303, August 2002. 699 11.2. Informative References 701 [I-D.fischl-sipping-media-dtls] 702 Fischl, J., "Datagram Transport Layer Security (DTLS) 703 Protocol for Protection of Media Traffic Established with 704 the Session Initiation Protocol", 705 draft-fischl-sipping-media-dtls-03 (work in progress), 706 July 2007. 708 [I-D.ietf-behave-rfc3489bis] 709 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 710 "Session Traversal Utilities for (NAT) (STUN)", 711 draft-ietf-behave-rfc3489bis-13 (work in progress), 712 November 2007. 714 [I-D.ietf-behave-turn] 715 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 716 "Traversal Using Relays around NAT (TURN): Relay 717 Extensions to Session Traversal Utilities for NAT 718 (STUN)", draft-ietf-behave-turn-05 (work in progress), 719 November 2007. 721 [I-D.ietf-mmusic-ice] 722 Rosenberg, J., "Interactive Connectivity Establishment 723 (ICE): A Protocol for Network Address Translator (NAT) 724 Traversal for Offer/Answer Protocols", 725 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 727 [PKT-SP-QOS-I01-070925] 728 CableLabs, "PacketCable 2.0: Quality of Service 729 Specification", September 2007, . 732 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 733 Issues", RFC 3234, February 2002. 735 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 736 Security", RFC 4347, April 2006. 738 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 739 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 740 RFC 4787, January 2007. 742 [TISPAN-ES-282-003] 743 ETSI, "Telecommunications and Internet converged Services 744 and Protocols for Advanced Networking (TISPAN); Resource 745 and Admission Control Sub-system (RACS); Functional 746 Architecture", June 2006, . 748 [TS-23-203] 749 3GPP, "Policy and charging control architecture", 750 September 2007, 751 . 753 [TS-29-214] 754 3GPP, "Policy and charging control over Rx reference 755 point", September 2007, 756 . 758 Authors' Addresses 760 Brian Stucker 762 Email: obsidian97@gmail.com 763 URI: http://www.linkedin.com/in/bstucker 764 Hannes Tschofenig 765 Nokia Siemens Networks 766 Linnoitustie 6 767 Espoo 02600 768 Finland 770 Phone: +358 (50) 4871445 771 Email: Hannes.Tschofenig@nsn.com 772 URI: http://www.tschofenig.com 774 Full Copyright Statement 776 Copyright (C) The IETF Trust (2008). 778 This document is subject to the rights, licenses and restrictions 779 contained in BCP 78, and except as set forth therein, the authors 780 retain all their rights. 782 This document and the information contained herein are provided on an 783 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 784 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 785 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 786 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Intellectual Property 792 The IETF takes no position regarding the validity or scope of any 793 Intellectual Property Rights or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; nor does it represent that it has 797 made any independent effort to identify any such rights. Information 798 on the procedures with respect to rights in RFC documents can be 799 found in BCP 78 and BCP 79. 801 Copies of IPR disclosures made to the IETF Secretariat and any 802 assurances of licenses to be made available, or the result of an 803 attempt made to obtain a general license or permission for the use of 804 such proprietary rights by implementers or users of this 805 specification can be obtained from the IETF on-line IPR repository at 806 http://www.ietf.org/ipr. 808 The IETF invites any interested party to bring to its attention any 809 copyrights, patents or patent applications, or other proprietary 810 rights that may cover technology that may be required to implement 811 this standard. Please address the information to the IETF at 812 ietf-ipr@ietf.org. 814 Acknowledgment 816 Funding for the RFC Editor function is provided by the IETF 817 Administrative Support Activity (IASA).