draft-ietf-mmusic-media-path-middleboxes-03.txt   draft-ietf-mmusic-media-path-middleboxes-04.txt 
MMUSIC B. Stucker MMUSIC B. Stucker
Internet-Draft Internet-Draft Unaffiliated
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: January 9, 2011 Nokia Siemens Networks Expires: August 2, 2012 Nokia Siemens Networks
July 8, 2010 G. Salgueiro
Cisco Systems
January 30, 2012
Analysis of Middlebox Interactions for Signaling Protocol Communication Analysis of Middlebox Interactions for Signaling
along the Media Path Protocol Communication along the Media Path
draft-ietf-mmusic-media-path-middleboxes-03.txt draft-ietf-mmusic-media-path-middleboxes-04.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 2, line 4 skipping to change at page 2, line 5
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 January 9, 2011.
This Internet-Draft will expire on August 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 8, line 25 skipping to change at page 8, line 25
'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 treatment 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 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
skipping to change at page 10, line 41 skipping to change at page 10, line 41
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.212: Policy and Charging Control over Gx reference 2. 3GPP, "TS 29.212: Policy and Charging Control over Gx reference
point" [TS-29.212] point" [TS-29.212]
3. 3GPP, "TS 29.213: Policy and Charging Control signalling flows 3. 3GPP, "TS 29.213: Policy and Charging Control signaling flows and
and QoS parameter mapping" [TS-29.213] QoS parameter mapping" [TS-29.213]
4. 3GPP, "TS 29.214: Policy and charging control over Rx reference 4. 3GPP, "TS 29.214: Policy and charging control over Rx reference
point" [TS-29.214] point" [TS-29.214]
5. ETSI TISPAN, "ES 282-003: Telecommunications and Internet 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 6. Cablelabs, "PacketCable 2.0: Quality of Service Specification
skipping to change at page 11, line 31 skipping to change at page 11, line 31
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
because IPv4 and IPv6 address realms are interfacing. For this because IPv4 and IPv6 address realms are interfacing. For this
use case, the middlebox itself performs functions similar to a use case, the middlebox itself performs functions similar to a
NAT and is deployed instead of a NAT at a network border. NAT and is deployed instead of a NAT at a network border.
2. The MIDCOM agent and attached middlebox support the traversal of 2. The MIDCOM agent and attached middlebox support the traversal of
a residential NAT (also termed costumer premise equipment), which a residential NAT (also termed customer premise equipment), which
is typically located at the user's side of an access network, for is typically located at the user's side of an access network, for
instance within a DSL router. The middlebox thereby acts as kind instance within a DSL router. The middlebox thereby acts as kind
of media relay. of media relay.
Both functions can be combined by the same MIDCOM agent and connected Both functions can be combined by the same MIDCOM agent and connected
middlebox, for instance by a TISPAN C-BGF. middlebox, for instance by a TISPAN C-BGF.
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 A-BGF/C-BGF/I-BGF and the
3GPP IMS Access Gateway. 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 This architecture could be compared with a STUN relay [RFC5766] that
[I-D.ietf-behave-turn] that is being controlled by the MIDCOM agent is being controlled by the MIDCOM agent rather than the end point
rather than the end point itself. The motivation why this technique itself. The motivation why this technique is being used in favor to
is being used in favor to other NAT traversal techniques is that other NAT traversal techniques is that clients do not have to support
clients do not have to support anything beyond RFC 3261 [RFC3261] and anything beyond RFC 3261 [RFC3261] and network administrators can
network administrators can control and apply local policy to the control and apply local policy to the relay binding process in a
relay binding process in a centralized manner. 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 also update other elements of the SDP for some implementations may also update other elements of the SDP for
various reasons. various reasons.
skipping to change at page 16, line 36 skipping to change at page 16, line 36
both SDP offer and answer, they are typically installed at the both SDP offer and answer, they are typically installed at the
completion of the first offer-answer exchange. completion of the first offer-answer exchange.
Furthermore, the middlebox may prevent the exchange of packets in the Furthermore, the middlebox may prevent the exchange of packets in the
media path after this point by closing "gates" until the session media path after this point by closing "gates" until the session
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
typically 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 indicated
in SDP. 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. exchange along the media path, as it is provided by DTLS-SRTP. The
Figure 2 of [I-D.ietf-sip-dtls-srtp-framework] shows that the arrival ladder diagram in Section 7.1 of [RFC5763] shows that the arrival of
of the SIP INVITE at the UAS triggers the DTLS handshake. This the SIP INVITE at the UAS triggers the DTLS handshake. This message
message would be blocked by the middlebox, as described in Section 4 would be blocked by the middlebox, as described in Section 4 since
since the MIDCOM agent has not yet installed policy rules. The the MIDCOM agent has not yet installed policy rules. The consequence
consequence is that the communication fails unless the UAS repeats is that the communication fails unless the UAS repeats attempts for
attempts for an DTLS handshake until connectivity is established in an DTLS handshake until connectivity is established in both
both directions by the installation of policy rules and the presence directions by the installation of policy rules and the presence of
of opened gates. Due to extra time required for the DTLS exchange opened gates. Due to extra time required for the DTLS exchange the
the user may experience clipping. user may experience clipping.
According to 3GPP standards, gates for RTCP are always opened when According to 3GPP standards, gates for RTCP are always opened when
policy rules for related media are installed, even if related media policy rules for related media are installed, even if related media
traffic is still blocked. Therefore, signalling embedded in RTCP is traffic is still blocked. Therefore, signaling embedded in RTCP is
likely to pass after the completion of the first offer-answer likely to pass after the completion of the first offer-answer
exchange. Standardized policy rules only inspect source and exchange. Standardized policy rules only inspect source and
destination information of IP packets and the transport protocol destination information of IP packets and the transport protocol
(e.g., UDP and TCP). Obviously, this is not a property that can be (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
skipping to change at page 17, line 47 skipping to change at page 17, line 47
such middleboxes may apply gating policies similar to the policies such middleboxes may apply gating policies similar to the policies
discussed in Section 6.1 in addition. discussed in Section 6.1 in addition.
The described latching technique for residential NAT traversal The described latching technique for residential NAT traversal
interaction requires that a pilot packet has been received by the interaction requires that a pilot packet has been received by the
middlebox from the endpoint being served before the middlebox is able middlebox from the endpoint being served before the middlebox is able
to send packets towards the endpoint. This latching technique can be to send packets towards the endpoint. This latching technique can be
employed for both the RFC 3264 offerer and answerer. Therefore, in employed for both the RFC 3264 offerer and answerer. Therefore, in
the worst case, both endpoints must generate a pilot packet towards the worst case, both endpoints must generate a pilot packet towards
each other to ensure that a bi-directional media path exists. If the each other to ensure that a bi-directional media path exists. If the
first packets to be exchanged in the media path are signalling first packets to be exchanged in the media path are signaling packets
packets and a particular directionality of those packets is required, and a particular directionality of those packets is required,
communication may fail. To overcome these problems, empty packets communication may fail. To overcome these problems, empty packets
could be sent by the endpoint that has to receive rather than to send 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 the first signaling message. The offer is capable of sending the
pilot packet only when receiving the destination information within pilot packet only when receiving the destination information within
the answer. Thus, before that point in time the offerer will also the answer. Thus, before that point in time the offerer will also
not be able to receive any media packets or related signalling. not be able to receive any media packets or related signaling.
In a similar manner as outlined in Section 6.1, any in-path In a similar manner as outlined in Section 6.1, any in-path signaling
signalling messages that are sent before the offer-answer exchange is messages that are sent before the offer-answer exchange is completed
completed will be dropped. 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 [RFC5389]) as part of ICE [RFC5245] is an
ICE [I-D.ietf-mmusic-ice] is an example of such a mechanism that example of such a mechanism that satisfies this recommendation.
satisfies this recommendation. Sending of no-op RTP packets (see Sending of no-op RTP packets (see [I-D.ietf-avt-rtp-no-op]) is
[I-D.ietf-avt-rtp-no-op]) is another example. 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 at least a nominal amount of traffic to be exchanged path allow at least a nominal amount of traffic to be exchanged
between endpoints after the completion of the first offer-answer between endpoints after the completion of the first offer-answer
exchange to enable the completion of media path signaling prior to exchange to enable the completion of media path signaling prior to
the session being established. Such policies may be restricted to the session being established. Such policies may be restricted to
media types that use in-path signalling. The amount of traffic media types that use in-path signaling. The amount of traffic
necessary to complete the signaling between endpoints is expected necessary to complete the signaling between endpoints is expected
to be orders of magnitude smaller than that of any sufficiently to be orders of magnitude smaller than that of any sufficiently
interesting fraudulent traffic. 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 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
signalling 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 answer 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 signalling to bypass middleboxes and therefore to avoid path signaling to bypass middleboxes and therefore to avoid
clipping. clipping.
REC #5: It is recommended that middleboxes present on the media path
allow at least a nominal amount of traffic to be exchanged between
endpoints for at least one RTT after the middlebox receives a
message from the MIDCOM agent indicating the media session being
terminated. This will ensure that any transit signaling packets
on the media path exchanged during the session termination pass
through the middlebox.
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 19, line 29 skipping to change at page 19, line 37
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 Thomas Belling provided text proposals in April 2008. We are
thankful for his detailed suggestions. thankful for his detailed suggestions.
This document has benefited from the discussion and review of the
MMUSIC working group, especially the detailed review and thoughtful
comments of Peter Musgrave and Muthu Arul Mozhi Perumal.
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 20, line 11 skipping to change at page 20, line 22
[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-ietf-avt-rtp-no-op-04 (work in progress), May 2007. draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-18 (work in progress),
July 2008.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-16 (work in progress), July 2009.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
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-07 (work in progress),
March 2009.
[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
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[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.212] [TS-29.212]
3GPP, "Policy and Charging Control over Gx reference 3GPP, "Policy and Charging Control over Gx reference
point", June 2008, point", June 2008,
<http://www.3gpp.org/ftp/Specs/html-info/29212.htm>. <http://www.3gpp.org/ftp/Specs/html-info/29212.htm>.
[TS-29.213] [TS-29.213]
3GPP, "Policy and Charging Control signalling flows and 3GPP, "Policy and Charging Control signaling flows and QoS
QoS parameter mapping", June 2008, parameter mapping", June 2008,
<http://www.3gpp.org/ftp/Specs/html-info/29213.htm>. <http://www.3gpp.org/ftp/Specs/html-info/29213.htm>.
[TS-29.214] [TS-29.214]
3GPP, "Policy and charging control over Rx reference 3GPP, "Policy and charging control over Rx reference
point", June 2008, 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
Unaffiliated
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@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Gonzalo Salgueiro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
Email: gsalguei@cisco.com
 End of changes. 29 change blocks. 
73 lines changed or deleted 82 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/