< draft-ietf-mmusic-media-path-middleboxes-02.txt		draft-ietf-mmusic-media-path-middleboxes-03.txt >
	MMUSIC B. Stucker		MMUSIC B. Stucker
	Internet-Draft		Internet-Draft
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: September 10, 2009 Nokia Siemens Networks		Expires: January 9, 2011 Nokia Siemens Networks
	March 9, 2009		July 8, 2010
	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-02.txt		draft-ietf-mmusic-media-path-middleboxes-03.txt
	Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 10, 2009.
	Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.
	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 3, line 5 ¶		skipping to change at page 1, line 35 ¶
	document highlights problems that may arise. Unfortunately, it is		document highlights problems that may arise. Unfortunately, it is
	difficult for the end points to detect or predict problematic		difficult for the end points to detect or predict problematic
	behavior and to determine whether the media path is reliably		behavior and to determine whether the media path is reliably
	available for packet exchange.		available for packet exchange.
	This document aims to summarize the various sources and effects of		This document aims to summarize the various sources and effects of
	NAT and firewall control, the reasons that they exist, and possible		NAT and firewall control, the reasons that they exist, and possible
	means of improving their behavior to allow protocols that rely upon		means of improving their behavior to allow protocols that rely upon
	signaling along the media path to operate effectively.		signaling along the media path to operate effectively.
			Status of this Memo
			This Internet-Draft is submitted in full conformance with the
			provisions of BCP 78 and BCP 79.
			Internet-Drafts are working documents of the Internet Engineering
			Task Force (IETF). Note that other groups may also distribute
			working documents as Internet-Drafts. The list of current Internet-
			Drafts is at http://datatracker.ietf.org/drafts/current/.
			Internet-Drafts are draft documents valid for a maximum of six months
			and may be updated, replaced, or obsoleted by other documents at any
			time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
			This Internet-Draft will expire on January 9, 2011.
			Copyright Notice
			Copyright (c) 2010 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . 5		4. Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 6		4.1. Protocol Interaction . . . . . . . . . . . . . . . . . . . 6
	4.1.1. Single-Stage Commit . . . . . . . . . . . . . . . . . 6		4.1.1. Single-Stage Commit . . . . . . . . . . . . . . . . . 6
	4.1.2. Two-Stage Commit . . . . . . . . . . . . . . . . . . . 8		4.1.2. Two-Stage Commit . . . . . . . . . . . . . . . . . . . 8
	4.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 10		4.2. Further Reading . . . . . . . . . . . . . . . . . . . . . 10
	skipping to change at page 8, line 8 ¶		skipping to change at page 8, 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 particular, the rules at the UAC side middlebox would indicate
			that traffic exchanged between IP address 47.0.0.1 and port number
			49170 and IP address 47.0.0.2 and port number 36220 is allowed in
			both directions.
	In this example, the MIDCOM agent installs the policies after the 200		In this example, the MIDCOM agent installs the policies after the 200
	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 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
	skipping to change at page 20, line 21 ¶		skipping to change at page 20, line 21 ¶
	[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-18 (work in progress),		draft-ietf-behave-rfc3489bis-18 (work in progress),
	July 2008.		July 2008.
	[I-D.ietf-behave-turn]		[I-D.ietf-behave-turn]
	Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using		Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
	Relays around NAT (TURN): Relay Extensions to Session		Relays around NAT (TURN): Relay Extensions to Session
	Traversal Utilities for NAT (STUN)",		Traversal Utilities for NAT (STUN)",
	draft-ietf-behave-turn-13 (work in progress),		draft-ietf-behave-turn-16 (work in progress), July 2009.
	February 2009.
	[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]		[I-D.ietf-sip-dtls-srtp-framework]
	Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing an SRTP Security Context using DTLS",		for Establishing an SRTP Security Context using DTLS",
	draft-ietf-sip-dtls-srtp-framework-06 (work in progress),		draft-ietf-sip-dtls-srtp-framework-07 (work in progress),
	February 2009.		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
End of changes. 7 change blocks.
	42 lines changed or deleted		43 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/