Re: [rtcweb] HTTP Fallback draft

[Lorenzo Miniero <[e-mail]>]

Hi Hannes,

answering inline,


On Tue, 7 Aug 2012 19:38:52 +0300
Hannes Tschofenig <[e-mail]> wrote:

> Hi Lorenzo, 
> 
> working on http://tools.ietf.org/html/draft-tschofenig-hourglass-00 (and Marc on draft-blanchet-iab-internetoverport443) I am wondering about the following aspect: 
> 
> 1) Do you have experience with network elements filtering RTP traffic? If so, in what networks did that happen?
> 


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.


> 2) In case you answered question #1 with 'yes' I would also like to understand why you believe that HTTP traffic will be allowed to traverse? Wouldn't you have to switch to HTTPS instead? 
> 


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); 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; 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.

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: there are cases where of course we might WANT the traversal to be controlled (as I said in the draft, it doesn't have to be sneaky, and could be made so that network administrators can control it) but that's a different issue. Probably far from being the optimal solution, but for extreme scenarios it may get things working whereas everything else might fail.


> Just to be clear, I don't have objections regarding your draft. I just would like to understand what motives people to run everything over HTTP (besides using HTTP features, which you don't really do). 
> 


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".

Thanks,
Lorenzo


> Ciao
> Hannes
> 
> On Aug 7, 2012, at 7:01 PM, Lorenzo Miniero wrote:
> 
> > Dear all,
> > 
> > during the meeting in Vancouver, there was some discussion about the
> > need we have for UDP-blocking firewall traversal in RTCWEB. HTTP
> > fallback was mentioned, and I remember it being a matter of discussion
> > at the latest interim meeting as well (at least looking at the minutes),
> > even though it hasn't apparently been addressed on the ML since.
> > Something in line with this was also discussed in Prague at the BOF,
> > when it was clearly quite too early to address.
> > 
> > Someone suggested that, rather than trying to address the issue right
> > away, it could be better to first try and summarize as a BCP draft what
> > people already do in that respect: it's quite obvious, in fact, that
> > this is already being done by many companies in their deployments, even
> > though probably in a non-standard way.
> > 
> > Since the subject interests me (during the abovementioned IETF in Prague
> > we brought a simple demo, which we used to informally showcase to a few
> > interested folks the basic prototype refrlecting our research in that
> > field) I chose to write a simple individual draft, instead, that rather
> > than doing the summary, basically documents the first steps we did with
> > our prototype. You can read the draft here:
> > 
> >   http://www.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt
> > 
> > Please beware that it is not at all meant to be a ready-to-be-used
> > solution to the problem, quite the opposite. I wrote the draft in a few
> > hours and it simply addresses what we started to do to try and address
> > the problem, and, as it will be obvious when reading the draft, it is
> > all but complete with respect to what such a solution is supposed to
> > make available: nevertheless, it tries to explain the basics of what may
> > be needed, even if much more is still missing. Its purpose is rather
> > trying to "throw a stone in the lake", as we like to say in Italy, in
> > order to draw attention on the problem and gather potential interest by
> > other people to work on it, whether or not such work would be based on
> > this draft. I placed a few Editors Notes across the text on some of the
> > most controversial issues, like how this should mix with ICE and
> > negotiation, how easy it should be to detect it and so on. Other even
> > more controversial ones, like how to address the impact of congestion
> > control on real-time streams, is not in the document as of yet, but it's
> > clear this will have to be taken care of eventually. Feedback and
> > suggestions are more than welcome!
> > 
> > That said, I guess there's a different question I should be asking to
> > the chairs: since there seems to be no related item in the milestones,
> > is such a work actually in line with what is the expected outcome of the
> > WG? Considering the draft basically addresses a new transport for RTP
> > and something that probably needs to be negotiated as well, I guess this
> > could be seen as belonging elsewhere (AVTCORE and/or MMUSIC?).
> > Nevertheless, my feeling is it belongs more here than somewhere else,
> > especially considering we're specifying a solution that will be deployed
> > in browsers and, as such, people will expect it to work wherever other
> > web applications do.
> > 
> > Thanks,
> > Lorenzo
> > 
> > -- 
> > Lorenzo Miniero, COB
> > 
> > Meetecho s.r.l.
> > Web Conferencing and Collaboration Tools
> > http://www.meetecho.com
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> 


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com