One document matched: draft-ietf-mmusic-media-path-middleboxes-00.txt
MMUSIC B. Stucker
Internet-Draft
Intended status: Informational H. Tschofenig
Expires: July 20, 2008 Nokia Siemens Networks
January 17, 2008
Analysis of Middlebox Interactions for Signaling Protocol Communication
along the Media Path
draft-ietf-mmusic-media-path-middleboxes-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
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.
When Application Layer Gateways, such as SIP entities, interact with
Stucker & Tschofenig Expires July 20, 2008 [Page 1]
Internet-Draft Middlebox Interactions January 2008
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.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 5
4.1.1. Single-Stage Commit . . . . . . . . . . . . . . . . . 5
4.1.2. Two-Stage Commit . . . . . . . . . . . . . . . . . . . 7
4.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 9
5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 10
5.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 13
6. Interactions between Media Path Signaling and Middlebox
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Firewalling . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14
7. Preliminary Recommendations . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Stucker & Tschofenig Expires July 20, 2008 [Page 2]
Internet-Draft Middlebox Interactions January 2008
1. Introduction
According to by RFC 3234 [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.
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.
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.
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 [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.
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.
2. Terminology
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 [RFC2119].
We use the terms filter, policy action (or action), policy rule(s),
MIDCOM agent, and MIDCOM Policy Decision Point (PDP) as defined in
[RFC3303]. The MIDCOM agent is co-located with a SIP ALG that
comunicates with the firewall or the media relay.
Stucker & Tschofenig Expires July 20, 2008 [Page 3]
Internet-Draft Middlebox Interactions January 2008
3. Architecture
Figure 1 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.
SIP +-----------------+ SIP
+-----+ Signaling | SIP ALG | Signaling +-----+
| UAC |<----------->+-----------------+<----------->| UAS |
+-----+ | MIDCOM Agent | +-----+
^ +-----------------+ ^
| ^ |
| Policy rule(s) | and NAT bindings |
| v |
| Media +-------------+ Media |
+----------------->| Middlebox |<-----------------+
+-------------+
Figure 1: Analysed Firewalling Architecture
The aspects of packet filtering are described in Section 4 whereas
NAT traversal is illustrated in Section 5.
4. Packet Filtering
Figure 1 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.
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.
This information is used to create one or more packet filters that
describe the expected media path(s) for the call. These packet
Stucker & Tschofenig Expires July 20, 2008 [Page 4]
Internet-Draft Middlebox Interactions January 2008
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.
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.
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.
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.
4.1. Protocol Interaction
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.
4.1.1. Single-Stage Commit
Single stage commit is commonly used when the MIDCOM agent is most
involved only in firewalling. For SIP, MIDCOM agents use a single-
Stucker & Tschofenig Expires July 20, 2008 [Page 5]
Internet-Draft Middlebox Interactions January 2008
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.
This model is often used to prevent media from being sent end-to-end
prior to the call being established.
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 |
|---------------------------->|---------------------------->|
| | | | |
Stucker & Tschofenig Expires July 20, 2008 [Page 6]
Internet-Draft Middlebox Interactions January 2008
Figure 2: Example Single-stage Commit with SIP and SDP
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.
Noted that early media that arrives before the 200 OK would require
special treatement since otherwise it would be dropped as well.
4.1.2. Two-Stage Commit
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.
Stucker & Tschofenig Expires July 20, 2008 [Page 7]
Internet-Draft Middlebox Interactions January 2008
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 |
|---------------------------->|---------------------------->|
| | | | |
Figure 3: Example Two-stage Commit with SIP and SDP
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
Stucker & Tschofenig Expires July 20, 2008 [Page 8]
Internet-Draft Middlebox Interactions January 2008
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 Figure 2, 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.
4.2. Further Reading
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:
1. 3GPP, "TS 23.203: Policy and charging control architecture"
[TS-23-203]
2. 3GPP, "TS 29.214: Policy and charging control over Rx reference
point" [TS-29-214]
3. 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" [TISPAN-ES-282-003]
4. Cablelabs, "PacketCable 2.0: Quality of Service Specification
(PKT-SP-QOS-I01-070925)" [PKT-SP-QOS-I01-070925]
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
Stucker & Tschofenig Expires July 20, 2008 [Page 9]
Internet-Draft Middlebox Interactions January 2008
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.
5. NAT Traversal
One NAT traversal technique that is being used is based on media
relay. As shown in Figure 1 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).
This architecture could be compared with a STUN relay
[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 [RFC3261] and
network administrators can control and apply local policy to the
relay binding process in a centralized manner.
5.1. Protocol Interaction
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.
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:
1. 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.
2. Give the served endpoint a different address and/or port on the
middlebox for it to send media to for the corresponding endpoint.
3. Use the address and port the corresponding endpoint supplies for
media streams as the destination for packets sent to the
Stucker & Tschofenig Expires July 20, 2008 [Page 10]
Internet-Draft Middlebox Interactions January 2008
middlebox by the served endpoint.
4. 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.
An example of this algorithm is shown in Figure 4 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.
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 |
Stucker & Tschofenig Expires July 20, 2008 [Page 11]
Internet-Draft Middlebox Interactions January 2008
|---------------------------->|---------------------------->|
| | | |
| | | (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 | |
| | | |
Figure 4: Call Flow with SIP + SDP
1. UAC sends INVITE to local outbound proxy, which is also a MIDCOM
agent, with an SDP offer.
2. 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.
3. 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.
4. The MIDCOM agent updates the addresses in the SDP offer with the
inbound address/port information from the middlebox/media relay
binding response.
5. The UAS responds with a 180 containing an SDP answer.
6. 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.
7. The UAC receives the SDP answer containing the media relay
outbound address/port information.
Stucker & Tschofenig Expires July 20, 2008 [Page 12]
Internet-Draft Middlebox Interactions January 2008
8. The UAS answers the INVITE with a 200 OK.
9. The UAC acknowledges with an ACK.
10. 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.
11. 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.
12. Media from the UAC is relayed to the UAS.
13. 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.
5.2. Further Reading
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.
1. 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" [TISPAN-ES-282-003]. The TISPAN Ia
interface between the TISPAN BGF and SPDF is the relevant
specification.
6. Interactions between Media Path Signaling and Middlebox Behavior
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.
Stucker & Tschofenig Expires July 20, 2008 [Page 13]
Internet-Draft Middlebox Interactions January 2008
6.1. Firewalling
The description in Section 4 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.
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 [RFC3261] the typically milestone that must be
reached is offer/answer exchange [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 [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
Section 4 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.
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.
6.2. NAT Traversal
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 [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.
Stucker & Tschofenig Expires July 20, 2008 [Page 14]
Internet-Draft Middlebox Interactions January 2008
7. Preliminary Recommendations
The following preliminary recommendations are suggested:
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 [I-D.ietf-behave-rfc3489bis]) as part of
ICE [I-D.ietf-mmusic-ice] is an example of such a mechanism that
satisfies this recommendation.
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.
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.
8. Security Considerations
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.
9. IANA Considerations
This document does not require actions by IANA.
10. Acknowledgements
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.
We would also like to thank the participants of the IETF#70 MMUSIC
Stucker & Tschofenig Expires July 20, 2008 [Page 15]
Internet-Draft Middlebox Interactions January 2008
working group meeting for their feedback.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
11.2. Informative References
[I-D.fischl-sipping-media-dtls]
Fischl, J., "Datagram Transport Layer Security (DTLS)
Protocol for Protection of Media Traffic Established with
the Session Initiation Protocol",
draft-fischl-sipping-media-dtls-03 (work in progress),
July 2007.
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-13 (work in progress),
November 2007.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Traversal Using Relays around NAT (TURN): Relay
Extensions to Session Traversal Utilities for NAT
(STUN)", draft-ietf-behave-turn-05 (work in progress),
November 2007.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Stucker & Tschofenig Expires July 20, 2008 [Page 16]
Internet-Draft Middlebox Interactions January 2008
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[PKT-SP-QOS-I01-070925]
CableLabs, "PacketCable 2.0: Quality of Service
Specification", September 2007, <http://www.cablelabs.com/
specifications/PKT-SP-QOS-I01-070925.pdf>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[TISPAN-ES-282-003]
ETSI, "Telecommunications and Internet converged Services
and Protocols for Advanced Networking (TISPAN); Resource
and Admission Control Sub-system (RACS); Functional
Architecture", June 2006, <http://webapp.etsi.org/>.
[TS-23-203]
3GPP, "Policy and charging control architecture",
September 2007,
<http://www.3gpp.org/ftp/Specs/html-info/23203.htm>.
[TS-29-214]
3GPP, "Policy and charging control over Rx reference
point", September 2007,
<http://www.3gpp.org/ftp/Specs/html-info/29214.htm>.
Authors' Addresses
Brian Stucker
Email: obsidian97@gmail.com
URI: http://www.linkedin.com/in/bstucker
Stucker & Tschofenig Expires July 20, 2008 [Page 17]
Internet-Draft Middlebox Interactions January 2008
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Stucker & Tschofenig Expires July 20, 2008 [Page 18]
Internet-Draft Middlebox Interactions January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Stucker & Tschofenig Expires July 20, 2008 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 02:50:46 |