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

From: [email-masked]
Date: Thu, 10 Jan 2013 14:45:03 -0800

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)       : Brian Stucker
                          Hannes Tschofenig
                          Gonzalo Salgueiro
	Filename        : draft-ietf-mmusic-media-path-middleboxes-06.txt
	Pages           : 22
	Date            : 2013-01-10

Abstract:
   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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-media-path-middleboxes

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-media-path-middleboxes-06

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

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 10 Jan 2013 17:46:31 -0500

MMUSIC - 

I have simply updated the version of this draft to prevent expiration because recent discussions with the chairs have confirmed that we are ready now to progress this milestone. As part of that effort the chairs requested we clearly define the purpose, scope, and intended audience for the document. 

I came a bit late to the party but from my perspective this draft's purpose is to provide guidance and best practices on mitigating the issues middleboxes (particularly NATs and firewalls) can cause to end-to-end SIP/SDP-signaled media streams in different architectures.  The target audience is anyone (i.e. NAT/FW vendors, protocol designers, etc.) wanting such information ond that might benefit from the design tips to make their network/protocol/device more middlebox friendly.

I believe Flemming's recent comments (as an individual) masterfully summarized the scope, purpose and target audience for this document. Thus, I don't want to repeat (less eloquently) what I consider to be the right approach to this document.  For your convenience, here are those comments:

=====

A lot of the SIP and SDP work started out with a somewhat "purist" Internet view of the world, where things such as middleboxes were not considered. As other standards and industry organizations became interested in using SIP and SDP, different architectures were defined and some of those arcitectures did include the notion of middleboxes (e.g. 3GPP IMS and CableLabs PacketCable). From an IETF point of view, there was, at least initially, not a great deal of knowledge about these architectures and what the middleboxes defined by them were doing. Conversely, there was (is) also a concern that such middleboxes may break end-to-end transparency and hence there was a desire to try and alleviate that. 

To that effect, it was seen as useful to have a document that could
a) Explain what/how middleboxes might be operating in these architectures
b) Provide guidelines as to how such middleboxes could minimize (ideally avoid) impacting end-to-end transparency and/or how protocols could be used to try and alleviate any impact such middleboxes might have. 

The middleboxes draft is trying to address the above as it relates to the media path. The target audience is thus IETF participants that would like an overview of how these middleboxes may affect SIP/SDP-signaled media streams as well as what can be done to try and overcome that. Similarly, the document is targeted at people involved in these "other" architecture efforts, with a goal of making it clear how middleboxes may affect the operation of SIP/SDP-signaled media streams and hence provide some "design principles". This is not unlike some of the NAT work that was done in BEHAVE. 

It could be argued that these architectures have now been around for so long that producing the above document will not make any difference at this point. While I have some sympathy for this, I also think we have to recognize the importance of documenting what we know and to make that readily available for new people that will be working in this space. 

In other words, I still believe there is value in pursuing this document. As to whether it should be a BCP or Informational, I don't have any strong opinions. 

=====

As a group can we agree on this scope and that is worthwhile to finally complete this milestone?  Feedback welcome.

Cheers,

Gonzalo

On Jan 10, 2013, at 5:45 PM, [email-masked] wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Jan 2013 15:02:37 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gonzalo Salgueiro
> Sent: Thursday, January 10, 2013 2:47 PM
> To: mmusic
> Cc: [email-masked]
> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-media-path-
> middleboxes-06.txt
> 
> MMUSIC -
> 
> I have simply updated the version of this draft to prevent expiration
> because recent discussions with the chairs have confirmed that we are
> ready now to progress this milestone. As part of that effort the chairs
> requested we clearly define the purpose, scope, and intended audience
> for the document.
> 
> I came a bit late to the party but from my perspective this draft's
> purpose is to provide guidance and best practices on mitigating the
> issues middleboxes (particularly NATs and firewalls) can cause to end-
> to-end SIP/SDP-signaled media streams in different architectures.  The
> target audience is anyone (i.e. NAT/FW vendors, protocol designers,
> etc.) wanting such information ond that might benefit from the design
> tips to make their network/protocol/device more middlebox friendly.
> 
> I believe Flemming's recent comments (as an individual) masterfully
> summarized the scope, purpose and target audience for this document.
> Thus, I don't want to repeat (less eloquently) what I consider to be the
> right approach to this document.  For your convenience, here are those
> comments:
> 
> =====
> 
> A lot of the SIP and SDP work started out with a somewhat "purist"
> Internet view of the world, where things such as middleboxes were not
> considered. As other standards and industry organizations became
> interested in using SIP and SDP, different architectures were defined
> and some of those arcitectures did include the notion of middleboxes
> (e.g. 3GPP IMS and CableLabs PacketCable). From an IETF point of view,
> there was, at least initially, not a great deal of knowledge about these
> architectures and what the middleboxes defined by them were doing.
> Conversely, there was (is) also a concern that such middleboxes may
> break end-to-end transparency and hence there was a desire to try and
> alleviate that.
> 
> b) Provide guidelines as to how such middleboxes could minimize (ideally
> avoid) impacting end-to-end transparency and/or how protocols could be
> used to try and alleviate any impact such middleboxes might have.
> 
> The middleboxes draft is trying to address the above as it relates to
> the media path. The target audience is thus IETF participants that would
> like an overview of how these middleboxes may affect SIP/SDP-signaled
> media streams as well as what can be done to try and overcome that.
> Similarly, the document is targeted at people involved in these "other"
> architecture efforts, with a goal of making it clear how middleboxes may
> affect the operation of SIP/SDP-signaled media streams and hence provide
> some "design principles". This is not unlike some of the NAT work that
> was done in BEHAVE.
> 
> It could be argued that these architectures have now been around for so
> long that producing the above document will not make any difference at
> this point. While I have some sympathy for this, I also think we have to
> recognize the importance of documenting what we know and to make that
> readily available for new people that will be working in this space.
> 
> In other words, I still believe there is value in pursuing this
> document. As to whether it should be a BCP or Informational, I don't
> have any strong opinions.
> 
> =====
> 
> As a group can we agree on this scope and that is worthwhile to finally
> complete this milestone?  Feedback welcome.

I am glad this document was resurrected.  

Can the document say SBC instead of the awkward (and inaccurate) 
"SIP ALG combined with MIDCOM agent"?  Or is saying SBC impolitic.

-d

> > 	Title           : Analysis of Middlebox Interactions for Signaling
> Protocol Communication along the Media Path
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> 
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 25 Jan 2013 20:53:26 +0000

> "SIP ALG combined with MIDCOM agent"?  Or is saying SBC impolitic.

I don't think it can or should say "SBC" - because this doc does not describe what an SBC does.  At least not the first half (section 4), which is really about an inline ALG in the router/firewall. (ie, it's not the target/source of the IP addresses of the packets, doesn't change SIP/SDP, etc.)

Anyway, I read this latest draft, and it looks exactly like the older ones, so I don't see it fixing the issues with the older ones:
1) It claims to describe the impact on ICE, but doesn't
2) Doesn't describe the issues with forked or moved calls on early in-band media signaling (especially if you actually comply with recommendations #2+#4)
3) Uses terminology from ancient history (ie, RFC 3303) that no one else uses
4) Recommendation #5 is backwards I think - it should recommend protocols not to require/expect to exchange media-plane signaling after the session has been terminated. (in other words, since you can't rely on middleboxes being lenient, don't design a protocol to expect them to be so) 

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 25 Jan 2013 21:21:35 -0800

> Of Hadriel Kaplan
> Sent: Friday, January 25, 2013 12:53 PM
> To: mmusic
> > Can the document say SBC instead of the awkward (and inaccurate) "SIP
> > ALG combined with MIDCOM agent"?  Or is saying SBC impolitic.
> >
> 
> I don't think it can or should say "SBC" - because this doc does not
> describe what an SBC does.  At least not the first half (section 4),
> which is really about an inline ALG in the router/firewall. (ie, it's
> not the target/source of the IP addresses of the packets, doesn't change
> SIP/SDP, etc.)

Yes, you're right.  Thanks.

> Anyway, I read this latest draft, and it looks exactly like the older
> ones, so I don't see it fixing the issues with the older ones:
> 2) Doesn't describe the issues with forked or moved calls on early in-
> band media signaling (especially if you actually comply with
> recommendations #2+#4)

Which is where I got confused.  I thought it was trying to describe
what is sometimes called a 'decomposed SBC', where the B2BUA is 
controlling the media relaying function using a 
protocol-similar-to-MIDCOM.

I agree nobody uses "MIDCOM" or "MIDCOM architecture" to describe
how an ALG within a firewall or an ALG within a NAT (or NAPT) 
functions.

-d

> 4) Recommendation #5 is backwards I think - it should recommend
> protocols not to require/expect to exchange media-plane signaling after
> the session has been terminated. (in other words, since you can't rely
> on middleboxes being lenient, don't design a protocol to expect them to
> be so)
> 
> -hadriel
> 
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 28 Jan 2013 12:12:41 -0500

> 4) Recommendation #5 is backwards I think - it should recommend protocols not to require/expect to exchange media-plane signaling after the session has been terminated. (in other words, since you c…
Thanks for taking a look and providing your comments Hadriel. As per 
previous discussions, we wanted to first agree on the scope of the 
document and whether there was still value in pursuing such a document. 
As per Gonzalo's e-mail starting this thread, do you have any 
comments/concerns on that part (if so, please let the authors know what 
those are) ?

Once (/if) we get agreement on the scope, we can then get into detail 
around the technical aspects of the document as per your comments above.

Thanks

-- Flemming (MMUSIC co-chair)