One document matched: draft-ietf-mmusic-media-path-middleboxes-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3234.xml">
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY I-D.ietf-mmusic-ice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice.xml">
<!ENTITY I-D.ietf-behave-turn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-turn.xml">
<!ENTITY I-D.ietf-behave-rfc3489bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-rfc3489bis.xml">
<!ENTITY RFC4347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347.xml">
<!ENTITY RFC3303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3303.xml">
<!ENTITY I-D.fischl-sipping-media-dtls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fischl-sipping-media-dtls.xml">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-mmusic-media-path-middleboxes-00.txt" ipr="full3978">
<front>
<title abbrev="Middlebox Interactions">Analysis of Middlebox Interactions for Signaling Protocol
Communication along the Media Path</title>
<author fullname="Brian Stucker" initials="B." surname="Stucker">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>obsidian97@gmail.com</email>
<uri>http://www.linkedin.com/in/bstucker</uri>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<date year="2008"/>
<area>RAI</area>
<workgroup>MMUSIC</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Middleboxes are defined as any intermediary box performing functions apart from normal,
standard functions of an IP router on the data path between a source host and destination
host. Two such functions are network address translation and firewalling.</t>
<t>When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as
described in the MIDCOM architecture, then problems may occur in the transport of media
traffic when signaling protocol interaction takes place along the media path, as it is the
case for recent key exchange proposals (such as DTLS-SRTP). This document highlights
problems that may arise. Unfortunately, it is difficult for the end points to detect or
predict problematic behavior and to determine whether the media path is reliably available
for packet exchange. </t>
<t>This document aims to summarize the various sources and effects of NAT and firewall
control, the reasons that they exist, and possible means of improving their behavior to
allow protocols that rely upon signaling along the media path to operate effectively.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>According to by RFC 3234 <xref target="RFC3234"/> middleboxes are defined as any
intermediary box performing functions apart from normal, standard functions of an IP router
on the data path between a source host and destination host.</t>
<t>In the context of SIP a SIP ALG may interact with a node along the media path to control
network address translation, firewalling, and other functions. </t>
<t>
<list style="empty">
<t> With firewall control packet filters are installed based on the SIP signaling
interaction to implement a behavior of 'deny by default' in order to reduce the risk of
unwanted traffic. This function is often referred to as 'gating'. Depending on the
timing of the packet filter installation and the content of the packet filter signaling
traffic along the media, such as DTLS-SRTP or ICE, may be treated in an unexpected way. </t>
<t>In cases where the middlebox is involved in overcoming unmanaged NAT traversal the case
is similar. The key feature of this type of NAT traversal is a desire to overcome the
possible lack of information about any <xref target="RFC4787"/> address and/or port
mapping by a possibly unknown NAT device (server reflexive address and filtering
properties). In particular, a NAT binding for an endpoint may not exist yet for the
address and port identified in the endpoint's SDP. As such, a pilot packet sent by that
endpoint behind the NAT is required to create the necessary mappings in the NAT for the
media relay to deliver media destined for that endpoint. Until that pilot packet is
received no media packets may be reliably forwarded to the endpoint by the relay. </t>
</list>
</t>
<t> This document presents a summary of these two techniques, discusses their impact upon
other protocols such as ICE and DTLS-SRTP, and proposes a set of recommendations to mitigate
the effects of gating and latching on in-band negotiation mechanisms. </t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"/>.</t>
<t>We use the terms filter, policy action (or action), policy rule(s), MIDCOM agent, and
MIDCOM Policy Decision Point (PDP) as defined in <xref target="RFC3303"/>. The MIDCOM agent
is co-located with a SIP ALG that comunicates with the firewall or the media relay.</t>
</section>
<section anchor="gating" title="Architecture">
<t><xref target="architecture"/> shows the architecture that is being considered in this
document with respect to firewall and NAT traversal using media relaying. The timing and
directionality with which media packets are allowed to traverse a particular edge device is
the subject of this investigation. The MIDCOM agent thereby pushes policy rules to the
middlebox that allow or deny certain flows to bypass. Additionally, in case of media
relaying it is important for the MIDCOM agent to adjust the signaling messages.</t>
<t>
<figure anchor="architecture" title="Analysed Firewalling Architecture">
<artwork align="center"><![CDATA[
SIP +-----------------+ SIP
+-----+ Signaling | SIP ALG | Signaling +-----+
| UAC |<----------->+-----------------+<----------->| UAS |
+-----+ | MIDCOM Agent | +-----+
^ +-----------------+ ^
| ^ |
| Policy rule(s) | and NAT bindings |
| v |
| Media +-------------+ Media |
+----------------->| Middlebox |<-----------------+
+-------------+
]]></artwork>
</figure>
</t>
<t>The aspects of packet filtering are described in <xref target="packet-filter"/> whereas NAT
traversal is illustrated in <xref target="nat-traversal"/>.</t>
</section>
<section anchor="packet-filter" title="Packet Filtering">
<t><xref target="architecture"/> highlights the interaction between the MIDCOM agent and the
middlebox. These two elements inspect call control signaling and media path packets and
determine when packets from a given source to a given destination are allowed to flow
between endpoints. It is common for the gate controller to be the local outbound proxy for a
given SIP UA being gated. </t>
<t>The primary responsibility of the MIDCOM agent, which is co-located with a SIP entity, is
to examine the call control signaling to determine the media addresses and ports used to
define the media path between the gated device and the endpoint(s) with which it is
corresponding. For SIP, this would correspond to the media addresses described within SDP
after at least one full offer/answer exchange. </t>
<t>This information is used to create one or more packet filters that describe the expected
media path(s) for the call. These packet filters are combined with an algorithmic
determination, typically based on the state of the call, as to which direction(s) media
packets are allowed to flow between the endpoints, if at all. The filter and the action that
is being installed by the MIDCOM agent at the middlebox may change during the lifetime of a
SIP signaling session, depending on the state of the call or on changes of the address and
port information of one (or even both) of the end points.</t>
<t>It is possible that the gate controller may not be able to establish an exact address or
port for one endpoint involved in the call in which case it may wildcard the address and/or
port for the source and/or destination endpoint in the packet flow filter. In such a case,
the packet flow filter is considered to have matched against a given media packet for the
wildcarded field. </t>
<t>Note that it is possible to specify the filter using wildcards, for example, if some end
point address information is not known at a given point in time. Additonally, the default
firewalling policy is subject to local configuration ('deny per default' vs. 'permit per
default'). For a given SIP signaling sessions the policy at the MIDCOM agent might be very
strict with respect to the packets that are allowed to flow in a particular direction. For
example, packets may be allowed to flow in both directions, only in one direction for a
specific media stream. No particular behavior can be assumed. </t>
<t>When a media session is destroyed (end of call, deleted from the session description,
etc.), the MIDCOM agent removes policy rules created for that media session at the
middlebox.</t>
<section title="Protocol Interaction">
<t>MIDCOM agents may employ a variety of models to determine when to change the status of a
particular policy rule. This is especially true when a call is being established. For SIP,
this would be when an early dialog is established between endpoints. Although there is the
potential for a great deal of variability due to an intentional lack of specification,
typically, one of two models is used by the MIDCOM agent to determine the state of a
policy rule during call setup: single-stage and two-stage commit. The term 'commit' here
refers to the point at which a policy rule is setup that allows media traffic to flow. For
example, this would be the point at which packets for a media stream marked a=sendrecv in
SDP was allowed to flow bi-directionally by the middlebox.</t>
<section title="Single-Stage Commit">
<t>Single stage commit is commonly used when the MIDCOM agent is most involved only in
firewalling. For SIP, MIDCOM agents use a single-stage commit model typically install
policy rules for the call when the 200 OK to the INVITE is received in the case that the
INVITE contained an SDP offer, or when the ACK is received if the initial offer was sent
in the 200 OK itself.</t>
<t>This model is often used to prevent media from being sent end-to-end prior to the call
being established.</t>
<t>
<figure anchor="single-stage-commit"
title="Example Single-stage Commit with SIP and SDP">
<artwork align="center"><![CDATA[
UAC Side MIDCOM UAS Side
UAC Middlebox Agent Middlebox UAS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | | |
| (1) INVITE + SDP Offer | | |
|---------------------------->| (2) INVITE + SDP Offer |
| c=IN IP4 47.0.0.1 |---------------------------->|
| m=audio 49170 RTP/AVP 0 | c=IN IP4 47.0.0.1 |
| a=sendrecv | m=audio 49170 RTP/AVP 0 |
| | | a=sendrecv |
| | | | |
| | | (3) 200 OK + SDP Answer |
| | |<----------------------------|
| | | c=IN IP4 47.0.0.2 |
| | | m=audio 36220 RTP/AVP 0 |
| | | a=sendrecv | |
| | | | |
| | (5) Policy | (4) Policy | |
| |<---------------|--------------->| |
| | Src: 47.0.0.2 | Src: 47.0.0.1 | |
| | port 36220 | port 49170 | |
| | Dst: 47.0.0.1 | Dst: 47.0.0.2 | |
| | port 49170 | port 36220 | |
| | sendrecv | sendrecv | |
| | action=permit | action=permit | |
| | | | |
| | | | RTP |
|<=========================================================>|
| | | | |
| (6) 200 OK + SDP Answer | | |
|<----------------------------| | |
| c=IN IP4 47.0.0.2 | | |
| m=audio 36220 RTP/AVP 0 | | |
| a=sendrecv | | |
| | | | |
| (7) ACK | (8) ACK |
|---------------------------->|---------------------------->|
| | | | |
]]></artwork>
</figure>
</t>
<t>In the example above, policy is created in steps 4 and 5 to allow bi-directional media
flow based on the SDP exchanged in steps 1 and 3. In this example, the MIDCOM agent
installes the policies after the 200 OK to the INVITE arrives in step 3. With a
firewalling policy of 'deny by default' media sent prior to steps 5 and 4 by the UAC or
UAS is discarded by the middleboxes. </t>
<t>Noted that early media that arrives before the 200 OK would require special treatement
since otherwise it would be dropped as well. </t>
</section>
<section title="Two-Stage Commit">
<t>Two-stage commit is used when the MIDCOM agent also providers functionality, such as
Quality of Service signaling that may require resources to reserved early on in the call
establishment process before it is known if the call will be answered. An example of
this would be where the MIDCOM agent is responsible for guaranteeing a minimum level of
bandwidth along the media path. In this case an initial set of policies may be sent by
the MIDCOM agent to the middlebox even though they are put into a pending state but
trigger a resource reservation. Later, when the call is accepted, the gate controller
may update the state of the policies to active them.</t>
<t>
<figure anchor="two-stage-commit" title="Example Two-stage Commit with SIP and SDP">
<artwork align="center"><![CDATA[
UAC Side MIDCOM UAS Side
UAC Middlebox Agent Middlebox UAS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | | |
| (1) INVITE + SDP Offer | | |
|---------------------------->| (2) INVITE + SDP Offer |
| c=IN IP4 47.0.0.1 |---------------------------->|
| m=audio 49170 RTP/AVP 0 | c=IN IP4 47.0.0.1 |
| a=sendrecv | m=audio 49170 RTP/AVP 0 |
| | | a=sendrecv |
| | | | |
| | | (3) 180 + SDP Answer |
| (4) 180 + SDP Answer |<----------------------------|
|<----------------------------| c=IN IP4 47.0.0.2 |
| c=IN IP4 47.0.0.2 | m=audio 36220 RTP/AVP 0 |
| m=audio 36220 RTP/AVP 0 | a=sendrecv |
| a=sendrecv | | |
| | | | |
| | (5) Policy | (6) Policy | |
| |<---------------|--------------->| |
| | Src: 47.0.0.2 | Src: 47.0.0.1 | |
| | port 36220 | port 49170 | |
| | Dst: 47.0.0.1 | Dst: 47.0.0.2 | |
| | port 49170 | port 36220 | |
| | rule inactive | rule inactive | |
| | action=permit | action=permit | |
| | | | |
| | | (7) 200 OK |
| | |<----------------------------|
| | | | |
| | (9) UpdateGate | (8) UpdateGate | |
| |<---------------|--------------->| |
| | G: sendrecv | G: sendrecv | |
| | | | RTP |
|<=========================================================>|
| | | | |
| (10) 200 OK | | |
|<----------------------------| | |
| | | | |
| (11) ACK | (12) ACK |
|---------------------------->|---------------------------->|
| | | | |
]]></artwork>
</figure>
</t>
<t>In the example above, policies are created in steps 5 and 6 based off of the SDP sent
in steps 1 and 3 in an initial inactive state (no packets are allowed to flow) despite
the SDP indicating the media should be bi-directional. This interaction with the
middlebox, however, triggers a QoS reservation to take place. Later, when the 200 OK to
the INVITE comes in step 7, the policies are updated in steps 8 and 9 to indicate that
packets should be allowed to flow bi-directionally. Although functionally equivalent to
the single-stage commit example given earier in <xref target="single-stage-commit"/>,
other operations at the gate agent may have been performed simultaneously in steps 5 and
6 that justifies the early explicit definition of the gates in an inactive state. The
full usage of PRACK here is not shown for purposes of brevity.</t>
</section>
</section>
<section title="Further Reading">
<t>Packet filtering based on the approach described in this document has been described in a
number of documents. Although the usage of this architecture can also be found on the
Internet their behavior is largely specified only in documents that relate to IMS
standardization. The behavior of the devices deployed on the Internet is therefore largely
undocumented. Nevertheless, the following documents give the reader a better idea of the
functionality and the signaling interaction. These documents may also specify an
additional behavior in relation to how packet filtering is used when the MIDCOM agent is
responsible for processing SIP/SDP call control signaling and the middlebox is responsible
for a variety of activities beyond pure filtering. For example, it is common for
middleboxes to exempt RTCP flows from being blocked even though the associated RTP flows
are not allowed to flow in order to support RTCP signaling while a call is on hold. These
references are given here for the reader to gather a better understanding of how this is
mechanism is used in various forums and is non-exhaustive:</t>
<t>
<list style="numbers">
<t>
<xref target="TS-23-203">3GPP, "TS 23.203: Policy and charging control
architecture"</xref>
</t>
<t>
<xref target="TS-29-214">3GPP, "TS 29.214: Policy and charging control over Rx
reference point"</xref>
</t>
<t>
<xref target="TISPAN-ES-282-003">ETSI TISPAN, "ES 282-003: Telecommunications and
Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource
and Admission Control Sub-system (RACS); Functional Architecture"</xref>
</t>
<t>
<xref target="PKT-SP-QOS-I01-070925">Cablelabs, "PacketCable 2.0: Quality of Service
Specification (PKT-SP-QOS-I01-070925)"</xref>
</t>
</list>
</t>
<t>Note that different terms are used for the MIDCOM agent and the middlebox. For example,
in an IMS context the MIDCOM agent would be part of the P-CSCF and PCRF elements or in
TISPAN it would be part of the P-CSCF, A-RACF and SPDF that are involved in controlling
gating operations. Many different elements perform the role of a middlebox: GSM GGSN, CDMA
PDSN, SAE serving gateway, TISPAN A-BGF/C-BGF/I-BGF, PacketCable CMTS, etc. These
functions may be present in the network in a unified or decomposed architecture.</t>
</section>
</section>
<!-- ================================================================================ -->
<section anchor="nat-traversal" title="NAT Traversal">
<t>One NAT traversal technique that is being used is based on media relay. As shown in <xref
target="architecture"/> the MIDCOM agent that is being co-located with the SIP ALG
functionality interacts with the middlebox that is also a NAT in order to request and
allocate NAT bindings. A side effect of the interaction with a (double) NAT is that the
media traffic is forced to traverse a certain NAT in both directions (also called media
anchoring). </t>
<t>This architecture could be compared with a STUN relay <xref target="I-D.ietf-behave-turn"/>
that is being controlled by the MIDCOM agent rather than the end point itself. The
motivation why this technique is being used in favor to other NAT traversal techniques is
that clients do not have to support anything beyond RFC 3261 <xref target="RFC3261"/> and
network administrators can control and apply local policy to the relay binding process in a
centralized manner. </t>
<section title="Protocol Interaction">
<t>The MIDCOM agent's role is to inspect call control signaling and update media address and
port values based upon media relay binding information allocated with the middlebox/media
relay. For SIP, this minimally involves updating the c= and m= lines in the SDP, although
some implementations may update other elements of the SDP for various reasons. </t>
<t>Because the endpoints may not be able to gather a server reflexive address for their
media streams, the MIDCOM agent employs the following algorithm to ensure that media can
flow to the given endpoint:</t>
<t>
<list style="numbers">
<t>Give the corresponding endpoint an address and port on the middlebox for them to send
media to for the endpoint served by the MIDCOM agent.</t>
<t>Give the served endpoint a different address and/or port on the middlebox for it to
send media to for the corresponding endpoint.</t>
<t>Use the address and port the corresponding endpoint supplies for media streams as the
destination for packets sent to the middlebox by the served endpoint.</t>
<t>Use the address and port of the first packet received from the served endpoint at the
middlebox as the destination for packets sent to the middlebox by the corresponding
endpoint.</t>
</list>
</t>
<t>An example of this algorithm is shown in <xref target="latching_callflow"/> using SIP and
SDP. In this example the UAC is the endpoint served by the MIDCOM agent, which is also
acting as a local outbound proxy, and the UAS is the corresponding endpoint.</t>
<t>
<figure anchor="latching_callflow" title="Call Flow with SIP + SDP">
<artwork align="center"><![CDATA[
Media Relay MIDCOM Agent and
UAC Middlebox Outbound Proxy UAS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | |
| (1) INVITE + SDP Offer | |
|---------------------------->| |
| c=IN IP4 10.0.0.1 | |
| m=audio 49170 RTP/AVP 0 | |
| a=sendrecv | |
| | | |
| | (2) Allocate | |
| |<------------- | |
| | | |
| | (3) Response | |
| |-------------->| |
| | In: 47.0.0.3 | (4) INVITE + SDP Offer |
| | 50000 |---------------------------->|
| | Out: 47.0.0.4 | c=IN IP4 47.0.0.3 |
| | 50002 | m=audio 50002 RTP/AVP 0 |
| | | a=sendrecv |
| | | |
| | | (5) 180 + SDP Answer |
| | (6) Update |<----------------------------|
| |<--------------| c=IN IP4 47.0.0.2 |
| | Peer: 47.0.0.2| m=audio 36220 RTP/AVP 0 |
| | 36220 | a=sendrecv |
| (7) 180 + SDP Answer | |
|<----------------------------| |
| c=IN IP4 47.0.0.4 | |
| m=audio 50002 RTP/AVP 0 | |
| a=sendrecv | |
| | | |
| (8) 200 OK | (8) 200 OK |
|<----------------------------|<----------------------------|
| | | |
| (9) ACK | (9) ACK |
|---------------------------->|---------------------------->|
| | | |
| | | (10) UAS-RTP |
| X<============================================|
| | | Source: 47.0.0.2:36220 |
| (11) UAC-RTP| | Dest: 47.0.0.3:50000 |
|============>| | |
| Source: 47.0.0.100:48650 | |
| Dest: 47.0.0.4:50002 | |
| | | (12) UAC-RTP |
| |============================================>|
| | | Source: 47.0.0.3:50000 |
| (13) UAS-RTP | Dest: 47.0.0.2:36220 |
|<============| | |
| Source: 47.0.0.4:50002 | |
| Dest: 47.0.0.100:48650 | |
| | | |
]]></artwork>
</figure>
</t>
<t>
<list style="numbers">
<t>UAC sends INVITE to local outbound proxy, which is also a MIDCOM agent, with an SDP
offer.</t>
<t>The MIDCOM agent looks at the signaling and determines that a NAT may be present (Via
header address mismatch with observed source address, etc.). It asks the middlebox to
allocate a media relay binding.</t>
<t>The middlebox responds with a media relay binding that consists of an inbound
address/port for media from the UAS, and an outbound address/port for media from the
UAC.</t>
<t>The MIDCOM agent updates the addresses in the SDP offer with the inbound address/port
information from the middlebox/media relay binding response.</t>
<t>The UAS responds with a 180 containing an SDP answer.</t>
<t>The MIDCOM agent interacts with the middlebox to update the destination address/port
information from the SDP answer for media to be sent to the UAS, and changes the
addresses/ports in the SDP answer to the UAC with the outbound address/port
information from the middlebox binding from step 3. Media can now flow to the UAS from
the UAC at the middlebox/media relay.</t>
<t>The UAC receives the SDP answer containing the media relay outbound address/port
information.</t>
<t>The UAS answers the INVITE with a 200 OK.</t>
<t>The UAC acknowledges with an ACK.</t>
<t>RTP for the UAS (which may have begun flowing prior to answer) flows to the
middlebox, but the middlebox has no reliable address to relay the media to for the UAC
yet. Media will typically be dropped.</t>
<t>RTP arrives at the media relay on the inbound address/port from the UAC. The
middlebox observes the source address and port of the arriving packet and completes
the binding process. The source address and port of the media from the UAC is now the
destination address/port for media arriving on the outbound port of the
middlebox/media relay from the UAS.</t>
<t>Media from the UAC is relayed to the UAS.</t>
<t>Media from the UAS is relayed to the UAC. It is up to local policy at the media relay
as to whether or not packets that had arrived from the UAS for the UAC are queued or
dropped prior to the UAC's address/port information being updated in step 11.</t>
</list>
</t>
</section>
<section title="Further Reading">
<t>Although the described NAT traversal approach is used by a number of implementations to
overcome incorrect address/port information in call control signaling from an endpoint
behind a NAT, only one reference is known that describes the functionality in a
standardized manner.</t>
<t>
<list style="numbers">
<t>
<xref target="TISPAN-ES-282-003">ETSI TISPAN, "ES 282-003: Telecommunications and
Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource
and Admission Control Sub-system (RACS); Functional Architecture"</xref>. The TISPAN
Ia interface between the TISPAN BGF and SPDF is the relevant specification.</t>
</list>
</t>
</section>
</section>
<!-- ================================================================================ -->
<section title="Interactions between Media Path Signaling and Middlebox Behavior">
<t>This section points to the problems that occur when signaling exchanges are performed along
the media path when middleboxes are present that behave in the way described in this
document. </t>
<section title="Firewalling">
<t>The description in <xref target="packet-filter"/> highlighted that the timing of the
policy rule installation by the MIDCOM agent towards the middlebox has an impact on when
and what media traffic is allowed to traverse.</t>
<t> Hence, the middlebox prevents the exchange of packets in the media path until the
session establishment signaling has reached a pre-configured milestone where the MIDCOM
agent signals to the middlebox that packets are allowed to traverse in both directions.
Prior to this, packets may be allowed to flow uni-directionally to satisfy certain service
requirements or may be entirely blocked by the middlebox. For SIP <xref target="RFC3261"/>
the typically milestone that must be reached is offer/answer exchange <xref
target="RFC3264"/> accompanied by an acknowledgement that the dialog has been accepted
by the UAS (i.e., 200 OK to the INVITE). A concrete example of the impact can be found
with the case of key exchange along the media path, as it is provided by DTLS-SRTP. Figure
2 of <xref target="I-D.fischl-sipping-media-dtls"/> shows that the arrival of the SIP
INVITE at the UAS triggers the DTLS handshake. This message would be blocked by the
middlebox, as described in <xref target="packet-filter"/> since the MIDCOM agent has not
yet installed policy rules. The consequence is that the DTLS key exchange is delayed until
the policy rules are installed and that media traffic that is sent before the DTLS
exchange is completed may be dropped and the user experiences clippping.</t>
<t> Unlike with the pilot packet used for NAT traversal, the bi-directional media path is
established via the signaling path, not via packets sent along the media path. In some
deployment models, RTCP is always available bi-directionally regardless of the installed
policy rules. Obviously, this is not a property that can be guaranteed to be true in the
future.</t>
</section>
<section title="NAT Traversal">
<t>The described NAT traversal interaction prevents asynchronous exchange of packets in the
media path until a pilot packet has been received by the middlebox from the endpoint being
served. It can be employed for both the <xref target="RFC3264"/> offerer and/or answerer.
Therefore, in the worst case, both endpoints must generate a pilot packet towards each
other to ensure a bi-directional media path exists. Any signaling on the media path that
relies upon a uni-directional handshake in the reverse direction may not complete until
media in the forward direction by the other endpoint. If signaling on the media path is
required to complete prior to media generation the handshake may stall indefinitely.</t>
</section>
</section>
<section title="Preliminary Recommendations">
<t>The following preliminary recommendations are suggested:</t>
<t>
<list style="hanging">
<t hangText="REC #1: ">It is recommended that any protocol handshake on the media path
ensure that a mechanism exists that causes both endpoints to send at least one packet in
the forward direction as part of, or prior to, the handshake process. Retransmission of
STUN connectivity checks (see <xref target="I-D.ietf-behave-rfc3489bis"/>) as part of
ICE <xref target="I-D.ietf-mmusic-ice"/> is an example of such a mechanism that
satisfies this recommendation.</t>
<t hangText="REC #2: ">It is recommended that middleboxes present on the media path allow
a nominal amount of traffic to be exchanged between endpoints to enable completion of
media path signaling prior to the session being established. The amount of traffic
necessary to complete the signaling between endpoints is expected to be orders of
magnitude smaller than that of any sufficiently interesting fraudulent traffic.</t>
<t hangText="REC #3: ">It is recommended that failure to complete signaling on the media
path not automatically cause the session establishment to fail unless explicitly
specified by one or more endpoints. A fallback scenario where signaling on the media
path is retried after the session has been established is recommended.</t>
</list>
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>This document talks about security related functionality and the impact of one security
mechanism, namely firewalling, to another one, namely key management for media security.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require actions by IANA.</t>
</section>
<section anchor="acks" title="Acknowledgements">
<t>We would like to thank Steffen Fries, Dan Wing, Eric Rescorla, and Francois Audet for their
input to this document. Furthermore, we would like to thank Jason Fischl, Guenther Horn,
Thomas Belling, Peter Schneider, Jari Arkko, Cullen Jennings for the discussion input to
this problem space.</t>
<t>We would also like to thank the participants of the IETF#70 MMUSIC working group meeting
for their feedback.</t>
</section>
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC3261; &RFC3264;
&RFC3303; </references>
<references title="Informative References"> &RFC3234; &RFC4787; &RFC4347;
&I-D.ietf-mmusic-ice; &I-D.ietf-behave-turn; &I-D.ietf-behave-rfc3489bis;
&I-D.fischl-sipping-media-dtls; <reference anchor="TS-29-214"
target="http://www.3gpp.org/ftp/Specs/html-info/29214.htm">
<front>
<title>Policy and charging control over Rx reference point</title>
<author fullname="3GPP">
<organization>3GPP</organization>
</author>
<date day="25" month="September" year="2007"/>
</front>
</reference>
<reference anchor="TS-23-203" target="http://www.3gpp.org/ftp/Specs/html-info/23203.htm">
<front>
<title>Policy and charging control architecture</title>
<author fullname="3GPP">
<organization>3GPP</organization>
</author>
<date day="26" month="September" year="2007"/>
</front>
</reference>
<reference anchor="TISPAN-ES-282-003" target="http://webapp.etsi.org/">
<front>
<title> Telecommunications and Internet converged Services and Protocols for Advanced
Networking (TISPAN); Resource and Admission Control Sub-system (RACS); Functional
Architecture</title>
<author fullname="ETSI">
<organization>ETSI</organization>
</author>
<date day="20" month="June" year="2006"/>
</front>
</reference>
<reference anchor="PKT-SP-QOS-I01-070925"
target="http://www.cablelabs.com/specifications/PKT-SP-QOS-I01-070925.pdf">
<front>
<title>PacketCable 2.0: Quality of Service Specification</title>
<author fullname="CableLabs">
<organization>CableLabs</organization>
</author>
<date day="25" month="September" year="2007"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:42:24 |