Re: [rtcweb] HTTP Fallback draft

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> [Tiru] Firewalls with TLS Proxy capability can detect such misuse and block. we have an alternate proposal to permit UDP flows across firewall
> http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-traversal-00
>

Is this thread  really about the ietf engineering a way to by-pass network policy set by network operators?

I do not believe that is acceptable.

CB
[Tiru] The above technique is not to by bass Enterprise Firewall policy, but have Firewall policy to permit nominated UDP flows only. For example Enterprise can permit calls to selected WebRTC servers that it trusts (let's say Dr.Good) and block others (like Dr. Evil). This draft is  solving the problem that in such cases permit call to be successful with WebRTC server Dr.Good and permit UDP flows for those calls without the need to have a ALG on Firewall.


From: Cameron Byrne [mailto:[e-mail]]
Sent: Wednesday, August 08, 2012 8:35 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [e-mail]; Lorenzo Miniero; Bernard Aboba
Subject: Re: [rtcweb] HTTP Fallback draft


On Aug 7, 2012 11:18 PM, "Tirumaleswar Reddy (tireddy)" <[e-mail]<mailto:[e-mail]>> wrote:
>
> > -----Original Message-----
> > From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On
> > Behalf Of Bernard Aboba
> > Sent: Wednesday, August 08, 2012 7:22 AM
> > To: Lorenzo Miniero
> > Cc: [e-mail]<mailto:[e-mail]>
> > Subject: Re: [rtcweb] HTTP Fallback draft
> >
> > > We indeed met such network elements in our experience, even though
> > most of the times it was just blind UDP filtering rather than RTP
> > filtering per se. It sometimes was just blind port filtering but the
> > effect was the same. This mostly happened within enterprises networks
> > where we tried, no matter how small or large.
> >
> >
> > [BA] this fits with my experience as well.
> >
> > > You're right. A couple of years ago we wrote a paper addressing the
> > potential approaches for tunneling attempts (if you're interested, I
> > can send you the link offline). In this paper we basically described,
> > as a diagram, which incremental steps could be carried out in order to
> > attempt a successful tunneling: 1) the first attempt is to just try
> > port 443, without encapulating anything (e.g., ssh using 443 instead of
> > 22);
> >
> > [BA] There are DPI boxes that will compare traffic against TLS and
> > catch this. So if it doesn't work you can't assume that 443 is blocked
> > by the firewall. Same with non-HTTP on port 80.
> >
> > > 2) in case that doesn't work, the second attempt is to use HTTP
> > CONNECT and then fall back to 1. for the connection that is
> > established;
> >
> > [BA] Trying HTTP on port 443 isn't likely to work if the original non-
> > TLS test on 443 failed.
> >
> > > 3) the third attempt (e.g., 443 is not available or the proxy acts as
> > a MITM) is to actually encapsulate in HTTP messages, whether you do
> > HTTP or HTTPS. In every case, the peer (either endpoint or server) must
> > be configured accordingly of course.
> >
> > [BA] If HTTP failed earlier, HTTP encapsulation also will probably
> > fail. It makes more sense to me to try TLS on 443.
>
> [Tiru] Firewalls with TLS Proxy capability can detect such misuse and block. we have an alternate proposal to permit UDP flows across firewall
> http://tools.ietf.org/html/draft-reddy-rtcweb-stun-auth-fw-traversal-00
>

Is this thread  really about the ietf engineering a way to by-pass network policy set by network operators?

I do not believe that is acceptable.

CB

> >
> > > What I describe in the draft is step 3, even though I guess some
> > words to suggest steps 1 and 2 (where you'd still need to encapsulate
> > RTP packets on top of a TCP-based protocol anyway) could be considered.
> > As long as it looks like valid HTTP and it behaves accordingly, I think
> > there's no reason why traversing should be impeded:
> >
> > [BA] DPI boxes aren't always up to date. For example don't expect them
> > to understand websockets.
> >
> > > I agree with you and I'm not really dying to do RTP over HTTP either,
> > but if some scenarios make it impossible for use cases to work (and
> > some firewall/NAT deployers are to blame here, probably) then a
> > fallback mechanism is something that can be nice to have, especially if
> > we're interested in something that "just works".
> >
> > [BA] If all the other avenues are tried first, then this would really
> > be a last resort. Any idea how frequently it should be expected to be
> > used?
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rtcweb