Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-media-path-middleboxes-03.txt

From: [email-masked]
Date: Thu, 8 Jul 2010 00:15:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path
	Author(s)       : B. Stucker, H. Tschofenig
	Filename        : draft-ietf-mmusic-media-path-middleboxes-03.txt
	Pages           : 21
	Date            : 2010-07-08

Middleboxes are defined as any intermediary box performing functions
apart from normal, standard functions of an IP router on the data
path between a source host and destination host.  Two such functions
are network address translation and firewalling.

When Application Layer Gateways, such as SIP entities, interact with
NATs and firewalls, as described in the MIDCOM architecture, then
problems may occur in the transport of media traffic when signaling
protocol interaction takes place along the media path, as it is the
case for recent key exchange proposals (such as DTLS-SRTP).  This
document highlights problems that may arise.  Unfortunately, it is
difficult for the end points to detect or predict problematic
behavior and to determine whether the media path is reliably
available for packet exchange.

This document aims to summarize the various sources and effects of
NAT and firewall control, the reasons that they exist, and possible
means of improving their behavior to allow protocols that rely upon
signaling along the media path to operate effectively.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-path-middleboxes-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Jul 2010 22:31:43 +0200

Hi,

Some quick took-a-look-at-the-document-during-vacation comments:

Q1. I don't know whether it's done on purpose, but the document does not take SIP forking into consideration.

The document seems to assume, that once an offer-answer has taken place media traffic will always traverse the MIDCOM agent. However, in case of forking the MIDCOM agent may be instructed to pass media associated with a specific early dialog.

Q2. Even without forking, it can not always be ensured that bi-directional media will be passed during an early dialog (REC #4 seems to indicate that).

Q3. You seem to use both "media anchoring" and "media latching" terminology, eventhough I think you talk about the same thing?

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Thursday, July 08, 2010 10:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-media-path-middleboxes-03.txt

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 14 Jul 2010 17:21:06 +0200

Dear Christer,

thanks for your interest even during your vacation.

Q1:

The aim of this draft is to describe typical behaviour of middleboxes
and derive some recommendations.
It might well be that middleboxes that otherwise behave in a homogenous
fashion exhibit different behaviour when handling forked responses as
this field is relatively open in some standards (e.g. at Ix and Iq
interfaces in 3GPP, while PCC handling of forked responses is well
defined in 3GPP), and it might in such cases be problematic to agree or
proof what a typical behaviour of a middlebox is, even though the
behaviour you suggest is a plausible one.
Do you expect that there could be additional recommendations that can be
derived when digging deeper into this field?

Q2

Rec4 does not always help, but at least backward throughconnection at
SDP answer time is a frequent middlebox behaviour, and in those frequent
cases the recommendation helps.

Q3

Media anchoring and latching are in my understanding not the same thing.

See Clause 5

   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
       perform the IP address and port conversion, which may be required
       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.

In my understanding anchoring relates to 1 and latching to 2.
It might well be that 2 requires 1 in addition to work, but 1 can also
be done without 2 (e.g. at the 3GPP Ix interface).

I also believe the terminology in the draft keeps both apart:

See Clause 5 for anchoring:

   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 draft explains media latching in 5.1:

   3.  If the middlebox supports the traversal of residential NATs, it
       applies a technique called "media latching": The destination IP
       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.

Regards, Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Christer Holmberg
Sent: Tuesday, July 13, 2010 10:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MMUSIC] I-D
Action:draft-ietf-mmusic-media-path-middleboxes-03.txt

Hi,

Q1. I don't know whether it's done on purpose, but the document does not
take SIP forking into consideration.

The document seems to assume, that once an offer-answer has taken place
media traffic will always traverse the MIDCOM agent. However, in case of
forking the MIDCOM agent may be instructed to pass media associated with
a specific early dialog.

Q2. Even without forking, it can not always be ensured that
bi-directional media will be passed during an early dialog (REC #4 seems
to indicate that).

Q3. You seem to use both "media anchoring" and "media latching"
terminology, eventhough I think you talk about the same thing?

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of
[email-masked] [[email-masked]]
Sent: Thursday, July 08, 2010 10:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] I-D
Action:draft-ietf-mmusic-media-path-middleboxes-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Multiparty Multimedia Session Control
Working Group of the IETF.

        Title           : Analysis of Middlebox Interactions for
Signaling Protocol Communication along the Media Path
        Author(s)       : B. Stucker, H. Tschofenig
        Filename        :
draft-ietf-mmusic-media-path-middleboxes-03.txt
        Pages           : 21
        Date            : 2010-07-08

Middleboxes are defined as any intermediary box performing functions
apart from normal, standard functions of an IP router on the data path
between a source host and destination host.  Two such functions are
network address translation and firewalling.

When Application Layer Gateways, such as SIP entities, interact with
NATs and firewalls, as described in the MIDCOM architecture, then
problems may occur in the transport of media traffic when signaling
protocol interaction takes place along the media path, as it is the case
for recent key exchange proposals (such as DTLS-SRTP).  This document
highlights problems that may arise.  Unfortunately, it is difficult for
the end points to detect or predict problematic behavior and to
determine whether the media path is reliably available for packet
exchange.

This document aims to summarize the various sources and effects of NAT
and firewall control, the reasons that they exist, and possible means of
improving their behavior to allow protocols that rely upon signaling
along the media path to operate effectively.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-path-middleb
oxes-03.txt

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic