draft-ietf-mmusic-media-path-middleboxes-00.txt   draft-ietf-mmusic-media-path-middleboxes-01.txt 
MMUSIC B. Stucker MMUSIC B. Stucker
Internet-Draft Internet-Draft
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: July 20, 2008 Nokia Siemens Networks Expires: January 15, 2009 Nokia Siemens Networks
January 17, 2008 July 14, 2008
Analysis of Middlebox Interactions for Signaling Protocol Communication Analysis of Middlebox Interactions for Signaling Protocol Communication
along the Media Path along the Media Path
draft-ietf-mmusic-media-path-middleboxes-00.txt draft-ietf-mmusic-media-path-middleboxes-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 20, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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 2, line 29 skipping to change at page 2, line 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . 4 4. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 5 4.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 5
4.1.1. Single-Stage Commit . . . . . . . . . . . . . . . . . 5 4.1.1. Single-Stage Commit . . . . . . . . . . . . . . . . . 5
4.1.2. Two-Stage Commit . . . . . . . . . . . . . . . . . . . 7 4.1.2. Two-Stage Commit . . . . . . . . . . . . . . . . . . . 7
4.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 9 4.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 9
5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10 5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 10 5.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 11
5.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 13 5.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 14
6. Interactions between Media Path Signaling and Middlebox 6. Interactions between Media Path Signaling and Middlebox
Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Firewalling . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 15
6.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14 6.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 16
7. Preliminary Recommendations . . . . . . . . . . . . . . . . . 15 7. Preliminary Recommendations . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 21
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 3, line 51 skipping to change at page 3, line 51
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
We use the terms filter, policy action (or action), policy rule(s), We use the terms filter, policy action (or action), policy rule(s),
MIDCOM agent, and MIDCOM Policy Decision Point (PDP) as defined in MIDCOM agent, and MIDCOM Policy Decision Point (PDP) as defined in
[RFC3303]. The MIDCOM agent is co-located with a SIP ALG that [RFC3303]. The MIDCOM agent is co-located with a SIP ALG that
comunicates 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 bypass. Additionally,
in case of media relaying it is important for the MIDCOM agent to in case of media relaying it is important for the MIDCOM agent to
skipping to change at page 5, line 21 skipping to change at page 5, line 21
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/or destination endpoint in the packet flow filter. In such a and/or destination endpoint in the packet flow filter. In such a
case, the packet flow filter is considered to have matched against a case, the packet flow filter is considered to have matched against a
given media packet for the wildcarded field. given 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. Additonally, 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 8 skipping to change at page 7, line 8
| 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 this example, the MIDCOM agent installes the policies after the In this example, the MIDCOM agent installs the policies after the 200
200 OK to the INVITE arrives in step 3. With a firewalling policy of 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 'deny by default' media sent prior to steps 5 and 4 by the UAC or UAS
is discarded by the middleboxes. is discarded by the middleboxes.
Noted that early media that arrives before the 200 OK would require Noted that early media that arrives before the 200 OK would require
special treatement since otherwise it would be dropped as well. special treatment since otherwise it would be dropped as well.
4.1.2. Two-Stage Commit 4.1.2. Two-Stage Commit
Two-stage commit is used when the MIDCOM agent also providers Two-stage commit is used when the MIDCOM agent also providers
functionality, such as Quality of Service signaling that may require functionality, such as Quality of Service signaling that may require
resources to reserved early on in the call establishment process resources to 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
skipping to change at page 9, line 9 skipping to change at page 9, line 9
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-
directionally. Although functionally equivalent to the single-stage directionally. Although functionally equivalent to the single-stage
commit example given earier in Figure 2, other operations at the gate commit example given earlier in Figure 2, other operations at the
agent may have been performed simultaneously in steps 5 and 6 that gate agent may have been performed simultaneously in steps 5 and 6
justifies the early explicit definition of the gates in an inactive that justifies the early explicit definition of the gates in an
state. The full usage of PRACK here is not shown for purposes of inactive state. The full usage of PRACK here is not shown for
brevity. purposes of brevity.
4.2. Further Reading 4.2. Further Reading
Packet filtering based on the approach described in this document has Packet filtering based on the approach described in this document has
been described in a number of documents. Although the usage of this been described in a number of documents. Although the usage of this
architecture can also be found on the Internet their behavior is architecture can also be found on the Internet their behavior is
largely specified only in documents that relate to IMS largely specified only in documents that relate to IMS
standardization. The behavior of the devices deployed on the standardization. The behavior of the devices deployed on the
Internet is therefore largely undocumented. Nevertheless, the Internet is therefore largely undocumented. Nevertheless, the
following documents give the reader a better idea of the following documents give the reader a better idea of the
skipping to change at page 9, line 36 skipping to change at page 9, line 36
filtering is used when the MIDCOM agent is responsible for processing filtering is used when the MIDCOM agent is responsible for processing
SIP/SDP call control signaling and the middlebox is responsible for a SIP/SDP call control signaling and the middlebox is responsible for a
variety of activities beyond pure filtering. For example, it is variety of activities beyond pure filtering. For example, it is
common for middleboxes to exempt RTCP flows from being blocked even common for middleboxes to exempt RTCP flows from being blocked even
though the associated RTP flows are not allowed to flow in order to 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 support RTCP signaling while a call is on hold. These references are
given here for the reader to gather a better understanding of how given here for the reader to gather a better understanding of how
this is mechanism is used in various forums and is non-exhaustive: this is mechanism is used in various forums and is non-exhaustive:
1. 3GPP, "TS 23.203: Policy and charging control architecture" 1. 3GPP, "TS 23.203: Policy and charging control architecture"
[TS-23-203] [TS-23.203]
2. 3GPP, "TS 29.214: Policy and charging control over Rx reference 2. 3GPP, "TS 29.212: Policy and Charging Control over Gx reference
point" [TS-29-214] point" [TS-29.212]
3. ETSI TISPAN, "ES 282-003: Telecommunications and Internet 3. 3GPP, "TS 29.213: Policy and Charging Control signalling flows
and QoS parameter mapping" [TS-29.213]
4. 3GPP, "TS 29.214: Policy and charging control over Rx reference
point" [TS-29.214]
5. ETSI TISPAN, "ES 282-003: Telecommunications and Internet
converged Services and Protocols for Advanced Networking converged Services and Protocols for Advanced Networking
(TISPAN); Resource and Admission Control Sub-system (RACS); (TISPAN); Resource and Admission Control Sub-system (RACS);
Functional Architecture" [TISPAN-ES-282-003] Functional Architecture" [TISPAN-ES-282-003]
6. Cablelabs, "PacketCable 2.0: Quality of Service Specification
4. 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 A-BGF/C-BGF/I-BGF, GSM GGSN, CDMA PDSN, SAE serving gateway, TISPAN PCEF and A-BGF/
PacketCable CMTS, etc. These functions may be present in the network C-BGF/I-BGF, PacketCable CMTS, etc. These functions may be present
in a unified or decomposed architecture. in the network in a unified or decomposed architecture.
5. NAT Traversal 5. NAT Traversal
One NAT traversal technique that is being used is based on media Two distinct types of NAT traversal can be supported by a MIDCOM
relay. As shown in Figure 1 the MIDCOM agent that is being co- agent and the connected middlebox:
located with the SIP ALG functionality interacts with the middlebox
that is also a NAT in order to request and allocate NAT bindings. A 1. The MIDCOM agent and the attached middlebox act as a B2BUA at the
side effect of the interaction with a (double) NAT is that the media border of an operator's network to protect this network and to
traffic is forced to traverse a certain NAT in both directions (also perform the IP address and port conversion, which may be required
called media anchoring). because private address spaces are used within the network, or
because IPv4 and IPv6 address realms are interfacing. For this
use case, the middlebox itself performs functions similar to a
NAT and is deployed instead of a NAT at a network border.
2. The MIDCOM agent and attached middlebox support the traversal of
a residential NAT (also termed costumer premise equipment), which
is typically located at the user's side of an access network, for
instance within a DSL router. The middlebox thereby acts as kind
of media relay.
Both functions can be combined by the same MIDCOM agent and connected
middlebox, for instance by a TISPAN C-BGF.
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 and then modifies
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
directions. A consequence 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). The opening of pinholes
through the middlebox is only done on request of the MIDCOM agent,
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
3GPP IMS Access Gateway.
The functionality and control of the middlebox becomes comparable to
a media gateway and TISPAN standardized the usage of the H.248 /
MEGACO protocol for the control of the middlebox by the midcom MIDCOM
agent.
This architecture could be compared with a STUN relay This architecture could be compared with a STUN relay
[I-D.ietf-behave-turn] that is being controlled by the MIDCOM agent [I-D.ietf-behave-turn] that is being controlled by the MIDCOM agent
rather than the end point itself. The motivation why this technique rather than the end point itself. The motivation why this technique
is being used in favor to other NAT traversal techniques is that is being used in favor to other NAT traversal techniques is that
clients do not have to support anything beyond RFC 3261 [RFC3261] and clients do not have to support anything beyond RFC 3261 [RFC3261] and
network administrators can control and apply local policy to the network administrators can control and apply local policy to the
relay binding process in a centralized manner. relay binding process in a centralized manner.
5.1. Protocol Interaction 5.1. Protocol Interaction
The MIDCOM agent's role is to inspect call control signaling and The MIDCOM agent's role is to inspect call control signaling and
update media address and port values based upon media relay binding update media address and port values based upon media relay binding
information allocated with the middlebox/media relay. For SIP, this information allocated with the middlebox/media relay. For SIP, this
minimally involves updating the c= and m= lines in the SDP, although minimally involves updating the c= and m= lines in the SDP, although
some implementations may update other elements of the SDP for various some implementations may also update other elements of the SDP for
reasons. various reasons.
Because the endpoints may not be able to gather a server reflexive Because the endpoints may not be able to gather a server reflexive
address for their media streams, the MIDCOM agent employs the address for their media streams, the MIDCOM agent employs the
following algorithm to ensure that media can flow to the given following algorithm to ensure that media can flow to the given
endpoint: endpoint:
1. Give the corresponding endpoint an address and port on the 1. When receiving an initial SDP offer, the MIDCOM agent requests
middlebox for them to send media to for the endpoint served by authorization for the request arriving at the middlebox,
the MIDCOM agent. configures the middlebox to forward media between the offerer and
the destination address / port as received in the incoming SDP
2. Give the served endpoint a different address and/or port on the offer, reserves a local IP address and port, and replaces the
middlebox for it to send media to for the corresponding endpoint. destination address and port from the incoming offer with the IP
address / port used by the middlebox in the forwarded offer.
3. Use the address and port the corresponding endpoint supplies for 2. When receiving an initial SDP answer, the MIDCOM agent configures
media streams as the destination for packets sent to the the middlebox for the corresponding session to send media towards
middlebox by the served endpoint. the answerer towards the destination address and port as received
in the incoming SDP answer, request the middlebox to reserve a
local IP address / port, and exchange the destination address and
port from the incoming answer with that middlebox IP address and
port in the forwarded answer.
4. Use the address and port of the first packet received from the 3. If the middlebox supports the traversal of residential NATs, it
served endpoint at the middlebox as the destination for packets applies a technique called "media latching": The destination IP
sent to the middlebox by the corresponding endpoint. address of packets forwarded by the middlebox in the outbound
direction is derived from the source IP address of packets
received in the inbound direction. This overrides a destination
address possibly configured by the MIDCOM agent.
An example of this algorithm is shown in Figure 4 using SIP and SDP. An example of this algorithm is shown in Figure 4 when using SIP and
In this example the UAC is the endpoint served by the MIDCOM agent, SDP. In this example the UAC is the endpoint served by the MIDCOM
which is also acting as a local outbound proxy, and the UAS is the agent, which is also acting as a local outbound proxy, and the UAS is
corresponding endpoint. the corresponding endpoint. We assume that the UAC is located behind
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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | | | | | | |
| (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 50002 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 | |
skipping to change at page 12, line 16 skipping to change at page 13, line 14
| | | (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 |
| (13) UAS-RTP | Dest: 47.0.0.2:36220 | | | | Dest: 47.0.0.2:36220 |
| | | |
| | | (13) UAS-RTP |
| |<============================================|
| | | Source: 47.0.0.2:36220 |
| (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
1. UAC sends INVITE to local outbound proxy, which is also a MIDCOM Step (1): UAC sends INVITE to local outbound proxy, which is also a
agent, with an SDP offer. MIDCOM agent, with an SDP offer.
2. The MIDCOM agent looks at the signaling and determines that a Step (2): The MIDCOM agent looks at the signaling and asks the
NAT may be present (Via header address mismatch with observed middlebox to allocate a media relay binding. At this point in
source address, etc.). It asks the middlebox to allocate a time the MIDCOM agent can only provide the IP address it finds
media relay binding. inside the offer, i.e., the IP address and port where the UAC is
expecting to receive traffic sent by the UAS. In this example the
IP address equals 10.0.0.1 and the port number is 49170.
3. The middlebox responds with a media relay binding that consists Step (3): The middlebox responds with a media relay binding that
of an inbound address/port for media from the UAS, and an consists of an inbound address/port for media sent by the UAS, and
outbound address/port for media from the UAC. an outbound address/port for media sent by the UAC. The IP
address and port of the middlebox allocated for the inbound side
47.0.0.3:50000 and the address and port on the outbound side is
47.0.0.4:50002.
4. The MIDCOM agent updates the addresses in the SDP offer with the Step (4): The MIDCOM agent updates the addresses in the SDP offer
inbound address/port information from the middlebox/media relay with the inbound address/port information from the middlebox/media
binding response. relay binding response, namely with 47.0.0.3:50000.
5. The UAS responds with a 180 containing an SDP answer. Step (5): The UAS responds with a 180 containing an SDP answer.
This answer indicates that traffic will be sent from the IP
address and port 47.0.0.2:36220.
6. The MIDCOM agent interacts with the middlebox to update the Step (6): The MIDCOM agent interacts with the middlebox to update
destination address/port information from the SDP answer for the destination address/port information from the SDP answer for
media to be sent to the UAS, and changes the addresses/ports in media to be sent to the UAS, and changes the addresses/ports in
the SDP answer to the UAC with the outbound address/port the SDP answer to the UAC with the outbound address/port
information from the middlebox binding from step 3. Media can information from the middlebox binding from step 3. Media can now
now flow to the UAS from the UAC at the middlebox/media relay. flow to the UAS from the UAC at the middlebox/media relay, i.e.,
in the outbound direction.
7. The UAC receives the SDP answer containing the media relay Step (7): The UAC receives the SDP answer containing the media relay
outbound address/port information. outbound address/port information, namely 47.0.0.4:50002.
8. The UAS answers the INVITE with a 200 OK. Step (8): The UAS answers the INVITE with a 200 OK.
9. The UAC acknowledges with an ACK. Step (9): The UAC acknowledges with an ACK.
10. RTP for the UAS (which may have begun flowing prior to answer) Step (10): RTP for the UAS, which may have begun flowing prior to
flows to the middlebox, but the middlebox has no reliable answer, goes to the middlebox, but the middlebox has no reliable
address to relay the media to for the UAC yet. Media will address to relay the media to for the UAC yet. Media will
typically be dropped. typically be dropped.
11. RTP arrives at the media relay on the inbound address/port from Step (11): RTP arrives at the media relay on the inbound address/
the UAC. The middlebox observes the source address and port of port from the UAC. The middlebox observes the source address and
the arriving packet and completes the binding process. The port of the arriving packet and completes the binding process.
source address and port of the media from the UAC is now the The source address and port of the media from the UAC is now the
destination address/port for media arriving on the outbound port destination address/port for media arriving on the outbound port
of the middlebox/media relay from the UAS. of the middlebox/media relay from the UAS.
12. Media from the UAC is relayed to the UAS. Step (12): Media originating from the UAC is relayed by the
middlebox to the UAS.
13. Media from the UAS is relayed to the UAC. It is up to local Step (13): Media from the UAS is sent towards the middlebox.
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 Step (14): The middlebox forwards the media traffic to the UAC.
the UAC's address/port information being updated in step 11.
5.2. Further Reading 5.2. Further Reading
Although the described NAT traversal approach is used by a number of In TS 23.228 the 3GPP standardized the usage of a SIP-ALG residing in
implementations to overcome incorrect address/port information in the P-CSCF to control an IMS Access Gateway, acting as middlebox at
call control signaling from an endpoint behind a NAT, only one the interface between the IMS and the access network (see Annex G),
reference is known that describes the functionality in a standardized and the usage of a SIP-ALG residing in the IBCF to control an TrGW as
manner. a middlebox at the interface between the IMS and external networks or
other IMS networks (see Annex I).
Although the described residential 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 1. ETSI TISPAN, "ES 282-003: Telecommunications and Internet
converged Services and Protocols for Advanced Networking converged Services and Protocols for Advanced Networking
(TISPAN); Resource and Admission Control Sub-system (RACS); (TISPAN); Resource and Admission Control Sub-system (RACS);
Functional Architecture" [TISPAN-ES-282-003]. The TISPAN Ia Functional Architecture" [TISPAN-ES-282-003]. The TISPAN Ia
interface between the TISPAN BGF and SPDF is the relevant interface between the TISPAN BGF and SPDF is the relevant
specification. specification.
6. Interactions between Media Path Signaling and Middlebox Behavior 6. Interactions between Media Path Signaling and Middlebox Behavior
This section points to the problems that occur when signaling This section points to the problems that occur when signaling
exchanges are performed along the media path when middleboxes are exchanges are performed along the media path when middleboxes are
present that behave in the way described in this document. present that behave in the way described in this document.
6.1. Firewalling 6.1. Packet Filtering
The description in Section 4 highlighted that the timing of the The description in Section 4 highlighted that the timing of the
policy rule installation by the MIDCOM agent towards the middlebox policy rule installation by the MIDCOM agent towards the middlebox
has an impact on when and what media traffic is allowed to traverse. has an impact on when and what media traffic is allowed to traverse.
Hence, the middlebox prevents the exchange of packets in the media The installation of policy rules is a prerequisite for related media
path until the session establishment signaling has reached a pre- to flow. As those policy rules are derived from information from
configured milestone where the MIDCOM agent signals to the middlebox both SDP offer and answer, they are typically installed at the
that packets are allowed to traverse in both directions. Prior to completion of the first offer-answer exchange.
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- Furthermore, the middlebox may prevent the exchange of packets in the
directional media path is established via the signaling path, not via media path after this point by closing "gates" until the session
packets sent along the media path. In some deployment models, RTCP establishment signaling has reached a pre-configured milestone where
is always available bi-directionally regardless of the installed the MIDCOM agent signals to the middlebox that packets are allowed to
policy rules. Obviously, this is not a property that can be 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). It depends on the
policy of an operator when to open gates. The policy may take into
account the requirements of special media types to have early
bidirectional media exchanges, e.g. if the usage of DTLS is indicated
in SDP.
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.ietf-sip-dtls-srtp-framework] 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 communication fails unless the UAS repeats
attempts for an DTLS handshake until connectivity is established in
both directions by the installation of policy rules and the presence
of opened gates. Due to extra time required for the DTLS exchange
the user may experience clipping.
According to 3GPP standards, gates for RTCP are always opened when
policy rules for related media are installed, even if related media
traffic is still blocked. Therefore, signalling embedded in RTCP is
likely to pass after the completion of the first offer-answer
exchange. Standardized policy rules only inspect source and
destination information of IP packets and the transport protocol
(e.g., UDP and TCP). Obviously, this is not a property that can be
guaranteed to be true in the future. guaranteed to be true in the future.
6.2. NAT Traversal 6.2. NAT Traversal
The described NAT traversal interaction prevents asynchronous The described NAT traversal interaction prevents asynchronous
exchange of packets in the media path until a pilot packet has been 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 received by the middlebox from the endpoint being served. It can be
employed for both the [RFC3264] offerer and/or answerer. Therefore, employed for both the [RFC3264] offerer and/or answerer. Therefore,
in the worst case, both endpoints must generate a pilot packet in the worst case, both endpoints must generate a pilot packet
towards each other to ensure a bi-directional media path exists. Any towards each other to ensure a bi-directional media path exists. Any
signaling on the media path that relies upon a uni-directional signaling on the media path that relies upon a uni-directional
handshake in the reverse direction may not complete until media in handshake in the reverse direction may not complete until media in
the forward direction by the other endpoint. If signaling on the the forward direction by the other endpoint. If signaling on the
media path is required to complete prior to media generation the media path is required to complete prior to media generation the
handshake may stall indefinitely. handshake may stall indefinitely.
Middleboxes as described in Section 5 will not allow any media to
pass through without being configured to do so by the MIDCOM agent
when the first offer-answer exchange is completed. Without latching,
it may be technically feasible to pass media packets from answerer
towards the offerer after the offer has passed the MIDCOM agent, but
existing implementations hardly show that behavior. Furthermore,
such middleboxes may apply gating policies similar to the policies
discussed in Section 6.1 in addition.
The described latching technique for residential NAT traversal
interaction requires that a pilot packet has been received by the
middlebox from the endpoint being served before the middlebox is able
to send packets towards the endpoint. This latching technique can be
employed for both the RFC 3264 offerer and answerer. Therefore, in
the worst case, both endpoints must generate a pilot packet towards
each other to ensure that a bi-directional media path exists. If the
first packets to be exchanged in the media path are signalling
packets and a particular directionality of those packets is required,
communication may fail. To overcome these problems, empty packets
could be sent by the endpoint that has to receive rather than to send
the first signalling message. The offer is capable of sending the
pilot packet only when receiving the destination information within
the answer. Thus, before that point in time the offerer will also
not be able to receive any media packets or related signalling.
In a similar manner as outlined in Section 6.1, any in-path
signalling messages that are sent before the offer-answer exchange is
completed will be dropped.
7. Preliminary Recommendations 7. Preliminary Recommendations
The following preliminary recommendations are suggested: The following preliminary recommendations are suggested:
REC #1: It is recommended that any protocol handshake on the media REC #1: It is recommended that any protocol handshake on the media
path ensure that a mechanism exists that causes both endpoints to path ensure that a mechanism exists that causes both endpoints to
send at least one packet in the forward direction as part of, or send at least one packet in the forward direction as part of, or
prior to, the handshake process. Retransmission of STUN prior to, the handshake process. Retransmission of STUN
connectivity checks (see [I-D.ietf-behave-rfc3489bis]) as part of 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 ICE [I-D.ietf-mmusic-ice] is an example of such a mechanism that
satisfies this recommendation. satisfies this recommendation. Sending of no-op RTP packets (see
[I-D.ietf-avt-rtp-no-op]) is another example.
REC #2: It is recommended that middleboxes present on the media REC #2: It is recommended that middleboxes present on the media
path allow a nominal amount of traffic to be exchanged between path allow at least a nominal amount of traffic to be exchanged
endpoints to enable completion of media path signaling prior to between endpoints after the completion of the first offer-answer
the session being established. The amount of traffic necessary to exchange to enable the completion of media path signaling prior to
complete the signaling between endpoints is expected to be orders the session being established. Such policies may be restricted to
of magnitude smaller than that of any sufficiently interesting media types that use in-path signalling. The amount of traffic
fraudulent 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 REC #3: It is recommended that failure to complete signaling on the
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 signaling on the media path is retried fallback scenario where endpoints retry signaling on the media
after the session has been established is recommended. path is recommended. Recommended points in time to retry
signalling on the media path are after the completion of the first
offer-answer exchange and again after the session has been
established. Additional retries with adequate pacing may be used
in addition.
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,
for example within a provisional SIP response, to allow the media
path signalling to bypass middleboxes and therefore to avoid
clipping.
8. Security Considerations 8. Security Considerations
This document talks about security related functionality and the This document talks about security related functionality and the
impact of one security mechanism, namely firewalling, to another one, impact of one security mechanism, namely firewalling, to another one,
namely key management for media security. namely key management for media security.
9. IANA Considerations 9. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
skipping to change at page 16, line 6 skipping to change at page 18, line 26
We would like to thank Steffen Fries, Dan Wing, Eric Rescorla, and We would like to thank Steffen Fries, Dan Wing, Eric Rescorla, and
Francois Audet for their input to this document. Furthermore, we Francois Audet for their input to this document. Furthermore, we
would like to thank Jason Fischl, Guenther Horn, Thomas Belling, would like to thank Jason Fischl, Guenther Horn, Thomas Belling,
Peter Schneider, Jari Arkko, Cullen Jennings for the discussion input Peter Schneider, Jari Arkko, Cullen Jennings for the discussion input
to this problem space. to this problem space.
We would also like to thank the participants of the IETF#70 MMUSIC We would also like to thank the participants of the IETF#70 MMUSIC
working group meeting for their feedback. working group meeting for their feedback.
Thomas Belling provided text proposals in April 2008. We are
thankful for his detailed suggestions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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,
skipping to change at page 16, line 28 skipping to change at page 19, line 7
[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 2002. June 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.fischl-sipping-media-dtls] [I-D.ietf-avt-rtp-no-op]
Fischl, J., "Datagram Transport Layer Security (DTLS) Andreasen, F., "A No-Op Payload Format for RTP",
Protocol for Protection of Media Traffic Established with draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
the Session Initiation Protocol",
draft-fischl-sipping-media-dtls-03 (work in progress),
July 2007.
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-13 (work in progress), draft-ietf-behave-rfc3489bis-16 (work in progress),
November 2007. July 2008.
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
"Traversal Using Relays around NAT (TURN): Relay Relays around NAT (TURN): Relay Extensions to Session
Extensions to Session Traversal Utilities for NAT Traversal Utilities for NAT (STUN)",
(STUN)", draft-ietf-behave-turn-05 (work in progress), draft-ietf-behave-turn-09 (work in progress), July 2008.
November 2007.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment 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", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sip-dtls-srtp-framework]
Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing an SRTP Security Context using DTLS",
draft-ietf-sip-dtls-srtp-framework-01 (work in progress),
February 2008.
[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.
skipping to change at page 17, line 28 skipping to change at page 20, line 7
[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.
[TISPAN-ES-282-003] [TISPAN-ES-282-003]
ETSI, "Telecommunications and Internet converged Services ETSI, "Telecommunications and Internet converged Services
and Protocols for Advanced Networking (TISPAN); Resource and Protocols for Advanced Networking (TISPAN); Resource
and Admission Control Sub-system (RACS); Functional and Admission Control Sub-system (RACS); Functional
Architecture", June 2006, <http://webapp.etsi.org/>. Architecture", June 2006, <http://webapp.etsi.org/>.
[TS-23-203] [TS-23.203]
3GPP, "Policy and charging control architecture", 3GPP, "Policy and charging control architecture",
September 2007, September 2007,
<http://www.3gpp.org/ftp/Specs/html-info/23203.htm>. <http://www.3gpp.org/ftp/Specs/html-info/23203.htm>.
[TS-29-214] [TS-29.212]
3GPP, "Policy and Charging Control over Gx reference
point", June 2008,
<http://www.3gpp.org/ftp/Specs/html-info/29212.htm>.
[TS-29.213]
3GPP, "Policy and Charging Control signalling flows and
QoS parameter mapping", June 2008,
<http://www.3gpp.org/ftp/Specs/html-info/29213.htm>.
[TS-29.214]
3GPP, "Policy and charging control over Rx reference 3GPP, "Policy and charging control over Rx reference
point", September 2007, point", June 2008,
<http://www.3gpp.org/ftp/Specs/html-info/29214.htm>. <http://www.3gpp.org/ftp/Specs/html-info/29214.htm>.
Authors' Addresses Authors' Addresses
Brian Stucker Brian Stucker
Email: obsidian97@gmail.com Email: obsidian97@gmail.com
URI: http://www.linkedin.com/in/bstucker URI: http://www.linkedin.com/in/bstucker
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.com URI: http://www.tschofenig.priv.at
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 19, line 44 skipping to change at line 946
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 57 change blocks. 
157 lines changed or deleted 290 lines changed or added

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