< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/