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