draft-ietf-mmusic-media-path-middleboxes-06.txt   draft-ietf-mmusic-media-path-middleboxes-07.txt 
MMUSIC B. Stucker MMUSIC B. Stucker
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: July 14, 2013 Nokia Siemens Networks Expires: December 01, 2013 Nokia Siemens Networks
G. Salgueiro G. Salgueiro
Cisco Systems Cisco Systems
January 10, 2013 May 30, 2013
Analysis of Middlebox Interactions for Signaling Analysis of Middlebox Interactions for Signaling
Protocol Communication along the Media Path Protocol Communication along the Media Path
draft-ietf-mmusic-media-path-middleboxes-06.txt draft-ietf-mmusic-media-path-middleboxes-07.txt
Abstract Abstract
Middleboxes are defined as any intermediary box performing functions Middleboxes are defined as any intermediary box performing functions
apart from normal, standard functions of an IP router on the data apart from normal, standard functions of an IP router on the data
path between a source host and destination host. Two such functions path between a source host and destination host. Two such functions
are network address translation and firewalling. are network address translation and firewalling.
When Application Layer Gateways, such as SIP entities, interact with When Application Layer Gateways, such as SIP entities, interact with
NATs and firewalls, as described in the MIDCOM architecture, then NATs and firewalls, as described in the MIDCOM architecture, then
skipping to change at page 1, line 37 skipping to change at page 1, line 37
document highlights problems that may arise. Unfortunately, it is document highlights problems that may arise. Unfortunately, it is
difficult for the end points to detect or predict problematic difficult for the end points to detect or predict problematic
behavior and to determine whether the media path is reliably behavior and to determine whether the media path is reliably
available for packet exchange. available for packet exchange.
This document aims to summarize the various sources and effects of This document aims to summarize the various sources and effects of
NAT and firewall control, the reasons that they exist, and possible NAT and firewall control, the reasons that they exist, and possible
means of improving their behavior to allow protocols that rely upon means of improving their behavior to allow protocols that rely upon
signaling along the media path to operate effectively. signaling along the media path to operate effectively.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 14, 2013. This Internet-Draft will expire on December 01, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . 5 4. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 6 4.1. Protocol Interaction . . . . . . . . . . . . . . . . . . 5
4.1.1. Single-Stage Commit . . . . . . . . . . . . . . . . . 6 4.1.1. Single-Stage Commit . . . . . . . . . . . . . . . . . 5
4.1.2. Two-Stage Commit . . . . . . . . . . . . . . . . . . . 8 4.1.2. Two-Stage Commit . . . . . . . . . . . . . . . . . . 7
4.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 10 4.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 8
5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 11 5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 12 5.1. Protocol Interaction . . . . . . . . . . . . . . . . . . 10
5.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 15 5.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 14
6. Interactions between Media Path Signaling and Middlebox 6. Interactions between Media Path Signaling and Middlebox
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 16 6.1. Packet Filtering . . . . . . . . . . . . . . . . . . . . 14
6.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 17 6.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 15
7. Preliminary Recommendations . . . . . . . . . . . . . . . . . 18 7. Preliminary Recommendations . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
According to by RFC 3234 [RFC3234] middleboxes are defined as any According to by RFC 3234 [RFC3234] middleboxes are defined as any
intermediary box performing functions apart from normal, standard intermediary box performing functions apart from normal, standard
functions of an IP router on the data path between a source host and functions of an IP router on the data path between a source host and
destination host. destination host.
In the context of SIP a SIP ALG may interact with a node along the In the context of SIP a SIP ALG may interact with a node along the
media path to control network address translation, firewalling, and media path to control network address translation, firewalling, and
skipping to change at page 5, line 12 skipping to change at page 4, line 12
[RFC3303]. The MIDCOM agent is co-located with a SIP ALG that [RFC3303]. The MIDCOM agent is co-located with a SIP ALG that
communicates with the firewall or the media relay. communicates with the firewall or the media relay.
3. Architecture 3. Architecture
Figure 1 shows the architecture that is being considered in this Figure 1 shows the architecture that is being considered in this
document with respect to firewall and NAT traversal using media document with respect to firewall and NAT traversal using media
relaying. The timing and directionality with which media packets are relaying. The timing and directionality with which media packets are
allowed to traverse a particular edge device is the subject of this allowed to traverse a particular edge device is the subject of this
investigation. The MIDCOM agent thereby pushes policy rules to the investigation. The MIDCOM agent thereby pushes policy rules to the
middlebox that allow or deny certain flows to bypass. Additionally, middlebox that allow or deny certain flows to pass through.
in case of media relaying it is important for the MIDCOM agent to Additionally, in case of media relaying it is important for the
adjust the signaling messages. MIDCOM agent to adjust the signaling messages.
SIP +-----------------+ SIP SIP +-----------------+ SIP
+-----+ Signaling | SIP ALG | Signaling +-----+ +-----+ Signaling | SIP ALG | Signaling +-----+
| UAC |<----------->+-----------------+<----------->| UAS | | UAC |<----------->+-----------------+<----------->| UAS |
+-----+ | MIDCOM Agent | +-----+ +-----+ | MIDCOM Agent | +-----+
^ +-----------------+ ^ ^ +-----------------+ ^
| ^ | | ^ |
| Policy rule(s) | and NAT bindings | | Policy rule(s) | and NAT bindings |
| v | | v |
| Media +-------------+ Media | | Media +-------------+ Media |
+----------------->| Middlebox |<-----------------+ +----------------->| Middlebox |<-----------------+
+-------------+ +-------------+
Figure 1: Analysed Firewalling Architecture Figure 1: Analysed Firewalling Architecture
The aspects of packet filtering are described in Section 4 whereas The aspects of packet filtering are described in Section 4 whereas
NAT traversal is illustrated in Section 5. NAT traversal is illustrated in Section 5.
4. Packet Filtering 4. Packet Filtering
Figure 1 highlights the interaction between the MIDCOM agent and the Figure 1 highlights the interaction between the MIDCOM agent and the
middlebox. These two elements inspect call control signaling and middlebox. These two elements inspect call control signaling and
skipping to change at page 6, line 14 skipping to change at page 5, line 12
filters are combined with an algorithmic determination, typically filters are combined with an algorithmic determination, typically
based on the state of the call, as to which direction(s) media 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 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 filter and the action that is being installed by the MIDCOM agent at
the middlebox may change during the lifetime of a SIP signaling the middlebox may change during the lifetime of a SIP signaling
session, depending on the state of the call or on changes of the 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. 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 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 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 which case it may wildcard the address and/or port for the source and
and/or destination endpoint in the packet flow filter. In such a /or destination endpoint in the packet flow filter. In such a case,
case, the packet flow filter is considered to have matched against a the packet flow filter is considered to have matched against a given
given media packet for the wildcarded field. media packet for the wildcarded field.
Note that it is possible to specify the filter using wildcards, for Note that it is possible to specify the filter using wildcards, for
example, if some end point address information is not known at a example, if some end point address information is not known at a
given point in time. Additionally, the default firewalling policy is given point in time. Additionally, the default firewalling policy is
subject to local configuration ('deny per default' vs. 'permit per subject to local configuration ('deny per default' vs. 'permit per
default'). For a given SIP signaling sessions the policy at the default'). For a given SIP signaling sessions the policy at the
MIDCOM agent might be very strict with respect to the packets that MIDCOM agent might be very strict with respect to the packets that
are allowed to flow in a particular direction. For example, packets are allowed to flow in a particular direction. For example, packets
may be allowed to flow in both directions, only in one direction for may be allowed to flow in both directions, only in one direction for
a specific media stream. No particular behavior can be assumed. a specific media stream. No particular behavior can be assumed.
When a media session is destroyed (end of call, deleted from the When a media session is destroyed (end of call, deleted from the
session description, etc.), the MIDCOM agent removes policy rules session description, etc.), the MIDCOM agent removes policy rules
created for that media session at the middlebox. created for that media session at the middlebox.
skipping to change at page 7, line 12 skipping to change at page 6, line 10
Single stage commit is commonly used when the MIDCOM agent is most Single stage commit is commonly used when the MIDCOM agent is most
involved only in firewalling. For SIP, MIDCOM agents use a single- involved only in firewalling. For SIP, MIDCOM agents use a single-
stage commit model typically install policy rules for the call when 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 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 contained an SDP offer, or when the ACK is received if the initial
offer was sent in the 200 OK itself. offer was sent in the 200 OK itself.
This model is often used to prevent media from being sent end-to-end This model is often used to prevent media from being sent end-to-end
prior to the call being established. prior to the call being established.
UAC Side MIDCOM UAS Side UAC Side MIDCOM UAS Side
UAC Middlebox Agent Middlebox UAS UAC Middlebox Agent Middlebox UAS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | | | | | | | |
| (1) INVITE + SDP Offer | | | | (1) INVITE + SDP Offer | | |
|---------------------------->| (2) INVITE + SDP Offer | |---------------------------->| (2) INVITE + SDP Offer |
| c=IN IP4 47.0.0.1 |---------------------------->| | c=IN IP4 47.0.0.1 |---------------------------->|
| m=audio 49170 RTP/AVP 0 | 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 | m=audio 49170 RTP/AVP 0 |
| | | a=sendrecv | | | | a=sendrecv |
| | | | | | | | | |
| | | (3) 200 OK + SDP Answer | | | | (3) 200 OK + 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 | (4) Policy | | | | (5) Policy | (4) Policy | |
| |<---------------|--------------->| | | |<---------------|--------------->| |
| | Src: 47.0.0.2 | Src: 47.0.0.1 | | | | Src: 47.0.0.2 | Src: 47.0.0.1 | |
| | port 36220 | port 49170 | | | | port 36220 | port 49170 | |
| | Dst: 47.0.0.1 | Dst: 47.0.0.2 | | | | Dst: 47.0.0.1 | Dst: 47.0.0.2 | |
| | port 49170 | port 36220 | | | | port 49170 | port 36220 | |
| | sendrecv | sendrecv | | | | sendrecv | sendrecv | |
| | action=permit | action=permit | | | | action=permit | action=permit | |
| | | | | | | | | |
| | | | RTP | | | | | RTP |
|<=========================================================>| |<=========================================================>|
| | | | | | | | | |
| (6) 200 OK + SDP Answer | | | | (6) 200 OK + 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 | | |
| | | | | | | | | |
| (7) ACK | (8) ACK | | (7) ACK | (8) ACK |
|---------------------------->|---------------------------->| |---------------------------->|---------------------------->|
| | | | | | | | | |
Figure 2: Example Single-stage Commit with SIP and SDP 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- 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. directional media flow based on the SDP exchanged in steps 1 and 3.
In particular, the rules at the UAC side middlebox would indicate In particular, the rules at the UAC side middlebox would indicate
that traffic exchanged between IP address 47.0.0.1 and port number that traffic exchanged between IP address 47.0.0.1 and port number
49170 and IP address 47.0.0.2 and port number 36220 is allowed in 49170 and IP address 47.0.0.2 and port number 36220 is allowed in
both directions. both directions.
In this example, the MIDCOM agent installs the policies after the 200 In this example, the MIDCOM agent installs the policies after the 200
skipping to change at page 9, line 5 skipping to change at page 7, line 33
functionality, such as Quality of Service signaling that may require functionality, such as Quality of Service signaling that may require
resources to be reserved early on in the call establishment process resources to be reserved early on in the call establishment process
before it is known if the call will be answered. An example of this 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 would be where the MIDCOM agent is responsible for guaranteeing a
minimum level of bandwidth along the media path. In this case an 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 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 middlebox even though they are put into a pending state but trigger a
resource reservation. Later, when the call is accepted, the gate resource reservation. Later, when the call is accepted, the gate
controller may update the state of the policies to active them. controller may update the state of the policies to active them.
UAC Side MIDCOM UAS Side UAC Side MIDCOM UAS Side
UAC Middlebox Agent Middlebox UAS UAC Middlebox Agent Middlebox UAS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | | | | | | | |
| (1) INVITE + SDP Offer | | | | (1) INVITE + SDP Offer | | |
|---------------------------->| (2) INVITE + SDP Offer | |---------------------------->| (2) INVITE + SDP Offer |
| c=IN IP4 47.0.0.1 |---------------------------->| | c=IN IP4 47.0.0.1 |---------------------------->|
| m=audio 49170 RTP/AVP 0 | 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 | m=audio 49170 RTP/AVP 0 |
| | | a=sendrecv | | | | a=sendrecv |
| | | | | | | | | |
| | | (3) 180 + SDP Answer | | | | (3) 180 + SDP Answer |
| (4) 180 + SDP Answer |<----------------------------| | (4) 180 + SDP Answer |<----------------------------|
|<----------------------------| c=IN IP4 47.0.0.2 | |<----------------------------| c=IN IP4 47.0.0.2 |
| c=IN IP4 47.0.0.2 | m=audio 36220 RTP/AVP 0 | | c=IN IP4 47.0.0.2 | m=audio 36220 RTP/AVP 0 |
| m=audio 36220 RTP/AVP 0 | a=sendrecv | | m=audio 36220 RTP/AVP 0 | a=sendrecv |
| a=sendrecv | | | | a=sendrecv | | |
| | | | | | | | | |
| | (5) Policy | (6) Policy | | | | (5) Policy | (6) Policy | |
| |<---------------|--------------->| | | |<---------------|--------------->| |
| | Src: 47.0.0.2 | Src: 47.0.0.1 | | | | Src: 47.0.0.2 | Src: 47.0.0.1 | |
| | port 36220 | port 49170 | | | | port 36220 | port 49170 | |
| | Dst: 47.0.0.1 | Dst: 47.0.0.2 | | | | Dst: 47.0.0.1 | Dst: 47.0.0.2 | |
| | port 49170 | port 36220 | | | | port 49170 | port 36220 | |
| | rule inactive | rule inactive | | | | rule inactive | rule inactive | |
| | action=permit | action=permit | | | | action=permit | action=permit | |
| | | | | | | | | |
| | | (7) 200 OK | | | | (7) 200 OK |
| | |<----------------------------| | | |<----------------------------|
| | | | | | | | | |
| | (9) UpdateGate | (8) UpdateGate | | | | (9) UpdateGate | (8) UpdateGate | |
| |<---------------|--------------->| | | |<---------------|--------------->| |
| | G: sendrecv | G: sendrecv | | | | G: sendrecv | G: sendrecv | |
| | | | RTP | | | | | RTP |
|<=========================================================>| |<=========================================================>|
| | | | | | | | | |
| (10) 200 OK | | | | (10) 200 OK | | |
|<----------------------------| | | |<----------------------------| | |
| | | | | | | | | |
| (11) ACK | (12) ACK | | (11) ACK | (12) ACK |
|---------------------------->|---------------------------->| |---------------------------->|---------------------------->|
| | | | | | | | | |
Figure 3: Example Two-stage Commit with SIP and SDP Figure 3: Example Two-stage Commit with SIP and SDP
In the example above, policies are created in steps 5 and 6 based off 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 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 packets are allowed to flow) despite the SDP indicating the media
should be bi-directional. This interaction with the middlebox, should be bi-directional. This interaction with the middlebox,
however, triggers a QoS reservation to take place. Later, when the 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 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- steps 8 and 9 to indicate that packets should be allowed to flow bi-
skipping to change at page 11, line 13 skipping to change at page 9, line 40
Functional Architecture" [TISPAN-ES-282-003] Functional Architecture" [TISPAN-ES-282-003]
6. Cablelabs, "PacketCable 2.0: Quality of Service Specification 6. Cablelabs, "PacketCable 2.0: Quality of Service Specification
(PKT-SP-QOS-I01-070925)" [PKT-SP-QOS-I01-070925] (PKT-SP-QOS-I01-070925)" [PKT-SP-QOS-I01-070925]
Note that different terms are used for the MIDCOM agent and the Note that different terms are used for the MIDCOM agent and the
middlebox. For example, in an IMS context the MIDCOM agent would be 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 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 the P-CSCF, A-RACF and SPDF that are involved in controlling gating
operations. Many different elements perform the role of a middlebox: operations. Many different elements perform the role of a middlebox:
GSM GGSN, CDMA PDSN, SAE serving gateway, TISPAN PCEF and A-BGF/ GSM GGSN, CDMA PDSN, EPC PDN Gateway, TISPAN RCEF and C-BGF/I-BGF,
C-BGF/I-BGF, PacketCable CMTS, etc. These functions may be present PacketCable CMTS, etc. These functions may be present in the network
in the network in a unified or decomposed architecture. in a unified or decomposed architecture.
5. NAT Traversal 5. NAT Traversal
Two distinct types of NAT traversal can be supported by a MIDCOM Two distinct types of NAT traversal can be supported by a MIDCOM
agent and the connected middlebox: agent and the connected middlebox:
1. The MIDCOM agent and the attached middlebox act as a B2BUA at the 1. The MIDCOM agent and the attached middlebox act as a B2BUA at the
border of an operator's network to protect this network and to border of an operator's network to protect this network and to
perform the IP address and port conversion, which may be required perform the IP address and port conversion, which may be required
because private address spaces are used within the network, or because private address spaces are used within the network, or
skipping to change at page 11, line 49 skipping to change at page 10, line 28
As shown in Figure 1 the MIDCOM agent that is being co-located with 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 the SIP ALG functionality interacts with the middlebox that is also a
NAT in order to request and allocate NAT bindings and then modifies NAT in order to request and allocate NAT bindings and then modifies
the SDP offer and answer within SIP to insert the IP addresses and the SDP offer and answer within SIP to insert the IP addresses and
port allocated by the NAT as destination for the media in both port allocated by the NAT as destination for the media in both
directions. A consequence of the interaction with a (double) NAT is directions. A consequence of the interaction with a (double) NAT is
that the media traffic is forced to traverse a certain NAT in both that the media traffic is forced to traverse a certain NAT in both
directions (also called media anchoring). The opening of pinholes directions (also called media anchoring). The opening of pinholes
through the middlebox is only done on request of the MIDCOM agent, through the middlebox is only done on request of the MIDCOM agent,
and not triggered by the detection of outbound media flows. Such and not triggered by the detection of outbound media flows. Such
middleboxes are for instance the TISPAN A-BGF/C-BGF/I-BGF and the middleboxes are for instance the TISPAN 3GPP Tr-GW/C-BGF/I-BGF and
3GPP IMS Access Gateway. the 3GPP IMS Access Gateway.
The functionality and control of the middlebox becomes comparable to The functionality and control of the middlebox becomes comparable to
a media gateway and TISPAN standardized the usage of the H.248 / a media gateway and TISPAN standardized the usage of the H.248 /
MEGACO protocol for the control of the middlebox by the midcom MIDCOM MEGACO protocol for the control of the middlebox by the midcom MIDCOM
agent. agent.
This architecture could be compared with a STUN relay [RFC5766] that This architecture could be compared with a STUN relay [RFC5766] that
is being controlled by the MIDCOM agent rather than the end point is being controlled by the MIDCOM agent rather than the end point
itself. The motivation why this technique is being used in favor to itself. The motivation why this technique is being used in favor to
other NAT traversal techniques is that clients do not have to support other NAT traversal techniques is that clients do not have to support
skipping to change at page 13, line 12 skipping to change at page 11, line 39
direction is derived from the source IP address of packets direction is derived from the source IP address of packets
received in the inbound direction. This overrides a destination received in the inbound direction. This overrides a destination
address possibly configured by the MIDCOM agent. address possibly configured by the MIDCOM agent.
An example of this algorithm is shown in Figure 4 when using SIP and An example of this algorithm is shown in Figure 4 when using SIP and
SDP. In this example the UAC is the endpoint served by the MIDCOM 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 agent, which is also acting as a local outbound proxy, and the UAS is
the corresponding endpoint. We assume that the UAC is located behind the corresponding endpoint. We assume that the UAC is located behind
a residential NAT; this NAT is, however, not shown in Figure 4. a residential NAT; this NAT is, however, not shown in Figure 4.
Media Relay MIDCOM Agent and Media Relay MIDCOM Agent and
UAC Middlebox Outbound Proxy UAS UAC Middlebox Outbound Proxy UAS
(UAC side) (UAC side)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | | | | | |
| (1) INVITE + SDP Offer | | | (1) INVITE + SDP Offer | |
|---------------------------->| | |---------------------------->| |
| c=IN IP4 10.0.0.1 | | | c=IN IP4 10.0.0.1 | |
| m=audio 49170 RTP/AVP 0 | | | m=audio 49170 RTP/AVP 0 | |
| a=sendrecv | | | a=sendrecv | |
| | | | | | | |
| | (2) Allocate | | | | (2) Allocate | |
| |<------------- | | | |<------------- | |
| | | | | | | |
| | (3) Response | | | | (3) Response | |
| |-------------->| | | |-------------->| |
| | In: 47.0.0.3 | (4) INVITE + SDP Offer | | | In: 47.0.0.3 | (4) INVITE + SDP Offer |
| | 50000 |---------------------------->| | | 50000 |---------------------------->|
| | Out: 47.0.0.4 | c=IN IP4 47.0.0.3 | | | Out: 47.0.0.4 | c=IN IP4 47.0.0.3 |
| | 50002 | m=audio 50000 RTP/AVP 0 | | | 50002 | m=audio 50000 RTP/AVP 0 |
| | | a=sendrecv | | | | a=sendrecv |
| | | | | | | |
| | | (5) 180 + SDP Answer | | | | (5) 180 + SDP Answer |
| | (6) Update |<----------------------------| | | (6) Update |<----------------------------|
| |<--------------| c=IN IP4 47.0.0.2 | | |<--------------| c=IN IP4 47.0.0.2 |
| | Peer: 47.0.0.2| m=audio 36220 RTP/AVP 0 | | | Peer: 47.0.0.2| m=audio 36220 RTP/AVP 0 |
| | 36220 | a=sendrecv | | | 36220 | a=sendrecv |
| (7) 180 + SDP Answer | | | (7) 180 + SDP Answer | |
|<----------------------------| | |<----------------------------| |
| c=IN IP4 47.0.0.4 | | | c=IN IP4 47.0.0.4 | |
| m=audio 50002 RTP/AVP 0 | | | m=audio 50002 RTP/AVP 0 | |
| a=sendrecv | | | a=sendrecv | |
| | | | | | | |
| (8) 200 OK | (8) 200 OK | | (8) 200 OK | (8) 200 OK |
|<----------------------------|<----------------------------| |<----------------------------|<----------------------------|
| | | | | | | |
| (9) ACK | (9) ACK | | (9) ACK | (9) ACK |
|---------------------------->|---------------------------->| |---------------------------->|---------------------------->|
| | | | | | | |
| | | (10) UAS-RTP | | | | (10) UAS-RTP |
| X<============================================| | X<============================================|
| | | Source: 47.0.0.2:36220 | | | | Source: 47.0.0.2:36220 |
| (11) UAC-RTP| | Dest: 47.0.0.3:50000 | | (11) UAC-RTP| | Dest: 47.0.0.3:50000 |
|============>| | | |============>| | |
| Source: 47.0.0.100:48650 | | | Source: 47.0.0.100:48650 | |
| Dest: 47.0.0.4:50002 | | | Dest: 47.0.0.4:50002 | |
| | | (12) UAC-RTP | | | | (12) UAC-RTP |
| |============================================>| | |============================================>|
| | | Source: 47.0.0.3:50000 | | | | Source: 47.0.0.3:50000 |
| | | Dest: 47.0.0.2:36220 | | | | Dest: 47.0.0.2:36220 |
| | | | | | | |
| | | (13) UAS-RTP | | | | (13) UAS-RTP |
| |<============================================| | |<============================================|
| | | Source: 47.0.0.2:36220 | | | | Source: 47.0.0.2:36220 |
| (14) UAC-RTP| | Dest: 47.0.0.3:50000 | | (14) UAC-RTP| | Dest: 47.0.0.3:50000 |
|<============| | | |<============| | |
| Source: 47.0.0.4:50002 | | | Source: 47.0.0.4:50002 | |
| Dest: 47.0.0.100:48650 | | | Dest: 47.0.0.100:48650 | |
| | | | | | | |
Figure 4: Call Flow with SIP + SDP Figure 4: Call Flow with SIP + SDP
Step (1): UAC sends INVITE to local outbound proxy, which is also a Step (1): UAC sends INVITE to local outbound proxy, which is also a
MIDCOM agent, with an SDP offer. MIDCOM agent, with an SDP offer.
Step (2): The MIDCOM agent looks at the signaling and asks the Step (2): The MIDCOM agent looks at the signaling and asks the
middlebox to allocate a media relay binding. At this point in middlebox to allocate a media relay binding. At this point in
time the MIDCOM agent can only provide the IP address it finds time the MIDCOM agent can only provide the IP address it finds
inside the offer, i.e., the IP address and port where the UAC is inside the offer, i.e., the IP address and port where the UAC is
skipping to change at page 16, line 41 skipping to change at page 15, line 22
establishment signaling has reached a pre-configured milestone where establishment signaling has reached a pre-configured milestone where
the MIDCOM agent signals to the middlebox that packets are allowed to the MIDCOM agent signals to the middlebox that packets are allowed to
traverse in both directions. Prior to this, packets may be allowed traverse in both directions. Prior to this, packets may be allowed
to flow uni-directionally to satisfy certain service requirements or to flow uni-directionally to satisfy certain service requirements or
may be entirely blocked by the middlebox. For SIP [RFC3261] the may be entirely blocked by the middlebox. For SIP [RFC3261] the
typical milestone that must be reached is offer/answer exchange typical milestone that must be reached is offer/answer exchange
[RFC3264] accompanied by an acknowledgement that the dialog has been [RFC3264] accompanied by an acknowledgement that the dialog has been
accepted by the UAS (i.e., 200 OK to the INVITE). It depends on the accepted by the UAS (i.e., 200 OK to the INVITE). It depends on the
policy of an operator when to open gates. The policy may take into policy of an operator when to open gates. The policy may take into
account the requirements of special media types to have early account the requirements of special media types to have early
bidirectional media exchanges, e.g. if the usage of DTLS is indicated bidirectional media exchanges, e.g. if the usage of DTLS is
in SDP. indicated in SDP.
A concrete example of the impact can be found with the case of key 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. The exchange along the media path, as it is provided by DTLS-SRTP. The
ladder diagram in Section 7.1 of [RFC5763] shows that the arrival of ladder diagram in Section 7.1 of [RFC5763] shows that the arrival of
the SIP INVITE at the UAS triggers the DTLS handshake. This message the SIP INVITE at the UAS triggers the DTLS handshake. This message
would be blocked by the middlebox, as described in Section 4 since would be blocked by the middlebox, as described in Section 4 since
the MIDCOM agent has not yet installed policy rules. The consequence the MIDCOM agent has not yet installed policy rules. The consequence
is that the communication fails unless the UAS repeats attempts for is that the communication fails unless the UAS repeats attempts for
an DTLS handshake until connectivity is established in both an DTLS handshake until connectivity is established in both
directions by the installation of policy rules and the presence of directions by the installation of policy rules and the presence of
skipping to change at page 18, line 46 skipping to change at page 17, line 26
media path not automatically cause the session establishment to media path not automatically cause the session establishment to
fail unless explicitly specified by one or more endpoints. A fail unless explicitly specified by one or more endpoints. A
fallback scenario where endpoints retry signaling on the media fallback scenario where endpoints retry signaling on the media
path is recommended. Recommended points in time to retry path is recommended. Recommended points in time to retry
signaling on the media path are after the completion of the first signaling on the media path are after the completion of the first
offer-answer exchange and again after the session has been offer-answer exchange and again after the session has been
established. Additional retries with adequate pacing may be used established. Additional retries with adequate pacing may be used
in addition. in addition.
REC #4: If signaling on the media path is required before media can REC #4: If signaling on the media path is required before media can
flow, the answer should send the SDP answer as soon as possible, flow, the answerer should send the SDP answer as soon as possible,
for example within a provisional SIP response, to allow the media for example within a provisional SIP response, to allow the media
path signaling to bypass middleboxes and therefore to avoid path signaling to pass through middleboxes and therefore to avoid
clipping. clipping.
REC #5: It is recommended that middleboxes present on the media path REC #5: It is recommended that middleboxes present on the media path
allow at least a nominal amount of traffic to be exchanged between allow at least a nominal amount of traffic to be exchanged between
endpoints for at least one RTT after the middlebox receives a endpoints for at least one RTT after the middlebox receives a
message from the MIDCOM agent indicating the media session being message from the MIDCOM agent indicating the media session being
terminated. This will ensure that any transit signaling packets terminated. This will ensure that any transit signaling packets
on the media path exchanged during the session termination pass on the media path exchanged during the session termination pass
through the middlebox. through the middlebox.
skipping to change at page 20, line 9 skipping to change at page 18, line 31
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264, June
June 2002. 2002.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
A. Rayhan, "Middlebox communication architecture and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002. framework", RFC 3303, August 2002.
11.2. Informative References 11.2. Informative References
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", Andreasen, F., "A No-Op Payload Format for RTP", draft-
draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[PKT-SP-QOS-I01-070925] [PKT-SP-QOS-I01-070925]
CableLabs, "PacketCable 2.0: Quality of Service CableLabs, "PacketCable 2.0: Quality of Service
Specification", September 2007, <http://www.cablelabs.com/ Specification", September 2007, <http://www.cablelabs.com/
specifications/PKT-SP-QOS-I01-070925.pdf>. specifications/PKT-SP-QOS-I01-070925.pdf>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002. Issues", RFC 3234, February 2002.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245, April
April 2010. 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, May 2010.
 End of changes. 22 change blocks. 
200 lines changed or deleted 201 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/