Subject: [rtcweb] HTTP Fallback draft

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 7 Aug 2012 18:01:56 +0200

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Aug 2012 19:38:52 +0300

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?

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? 

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

Ciao
Hannes

On Aug 7, 2012, at 7:01 PM, Lorenzo Miniero wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 7 Aug 2012 19:12:26 +0200

Hi Hannes,

answering inline,

On Tue, 7 Aug 2012 19:38:52 +0300

> 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…

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

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Aug 2012 10:50:07 -0700

> in browsers and, as such, people will expect it to work wherever other

My take on this is that the actual work on developing the alternate
transport for RTP would have to occur elsewhere and, frankly, I think
it is a large enough task that it would likely require its own working
group (much as the RTP congestion control topic ended up as a BoF and
hopefully will become its own working group).  That doesn't mean that
the work couldn't be informed by the RTCWEB use cases, but I think it
would have to be done elsewhere.

I'd personally suggest starting with a discussion with the ADs on
whether a BoF on this topic would be something they might consider.
(Note, however, that I have not talked to Cullen about this and Magnus
is on vacation, so this is not a "Chairs' response"; just my own
thoughts).

regards,

Ted Hardie

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 7 Aug 2012 20:54:47 +0200

Hello Ted,

On Tue, 7 Aug 2012 10:50:07 -0700

> is on vacation, so this is not a "Chairs' response"; just my own

This makes sense. I'm a bit concerned about the additional time that may be needed by going through the process of forming a new WG (compared to just adding a milestone to an existing WG, that is), as the final result may end up being available much after the original WG completed its works, but I see your point.

I'll wait for more feedback about this and, if enough people seem interested about doing something like this, contacting the ADs and consider the next steps may be a good idea.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Aug 2012 21:34:09 +0200

Hi Lorenzo, sorry for opening another thread about this (I didn't
check my unread emails before reading the draft). Please see comments

>> 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…

Honestly I don't like the "all-over-http" vision. Admins filtering
traffic other than HTTP or HTTPS will also do their best efforts for
filtering specific traffic over HTTP, and IMHO making specifications
to run protocolos over HTTP legitimizes those hateful filtering
techniques.

> 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) th…

That's the problem (IMHO): if we make all to work over HTTP then some
day telcos providers will just offer HTTP (as "Internet") and we'll
need to study a new OSI model in which the lowest layer is called
"HTTP".

BTW: I sitll don't understand which is the advantage of using RTP over
HTTPS in comparison to TURN over TLS:443. Does is exist?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 7 Aug 2012 21:54:15 +0200

Hi Iñaki,

On Tue, 7 Aug 2012 21:34:09 +0200

> check my unread emails before reading the draft). Please see comments

No harm done, don't worry!

> to run protocolos over HTTP legitimizes those hateful filtering

I'm not a fan either, believe me :)

That said, as I said in another post I still think that, if RTCWEB/WebRTC is going to be deployed in browsers, they'll expect it to work in all the places where all other web applications do. Many proprietary protocols that do real-time communication implement tunneling somehow, or pretend to do so, which means something in line with that is needed for RTCWEB as well.

> need to study a new OSI model in which the lowest layer is called

Which is close enough to the hourglass draft Hannes mentioned in his post, I'm afraid. I can't but agree with you, but, again, if we have use cases and we want to have them working in as many topologies as possible, something must be done.

> HTTPS in comparison to TURN over TLS:443. Does is exist?

If we talk about a simple comparison, I'm sure TURN:TLS:443 performs much better than RTP over HTTPS, or at least, over the simple approach I documented in the draft at least (even though I tried to keep the overhead as little as possible). Comparing them is probably not fair, though, as they address two different scenarios: that's why HTTP would be just a fallback, and not something you'd use when you have alternatives.

Referring to the steps I described in my previous answer to Hannes, TURN:TLS:443 is probably the most useful option for scenarios 1 and 2, that is, where you can just pipe what you want on port 443 and be sure it will be ignored by the proxy. If the proxy checks what's going on, though, that may not be as easy. The proxy may be acting as a MITM for HTTPS, as Roman described, or just doing some traffic monitoring with anomaly detection or something like that: faking to be HTTPS is not going to work in that case, since the proxy may just see it's not HTTP at all, or may just understand it's not what it claims to be because it doesn't behave as it should; HTTP connections have a usually quite simple pattern (e.g., much more traffic going in one direction than the other and never at the same time), something that would be very different in a TURN connection instead.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 7 Aug 2012 21:23:50 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Lorenzo Miniero
> Sent: Wednesday, August 08, 2012 1:24 AM
> To: Iñaki Baz Castillo
> Cc: [email-masked]
> Subject: Re: [rtcweb] HTTP Fallback draft
> 
> Hi Iñaki,
> 
> 
> > >> 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).
> >
> That said, as I said in another post I still think that, if
> RTCWEB/WebRTC is going to be deployed in browsers, they'll expect it to
> work in all the places where all other web applications do. Many
> proprietary protocols that do real-time communication implement
> tunneling somehow, or pretend to do so, which means something in line
> with that is needed for RTCWEB as well.
> 
> 
> >
> >
> >
> >
> > > 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".
> >
> Which is close enough to the hourglass draft Hannes mentioned in his
> post, I'm afraid. I can't but agree with you, but, again, if we have
> use cases and we want to have them working in as many topologies as
> possible, something must be done.
> 
> 
> If we talk about a simple comparison, I'm sure TURN:TLS:443 performs
> much better than RTP over HTTPS, or at least, over the simple approach
> I documented in the draft at least (even though I tried to keep the
> overhead as little as possible). Comparing them is probably not fair,
> though, as they address two different scenarios: that's why HTTP would
> be just a fallback, and not something you'd use when you have
> alternatives.
> 
> Referring to the steps I described in my previous answer to Hannes,
> TURN:TLS:443 is probably the most useful option for scenarios 1 and 2,
> that is, where you can just pipe what you want on port 443 and be sure
> it will be ignored by the proxy. If the proxy checks what's going on,
> though, that may not be as easy. The proxy may be acting as a MITM for
> HTTPS, as Roman described, or just doing some traffic monitoring with
> anomaly detection or something like that: faking to be HTTPS is not
> going to work in that case, since the proxy may just see it's not HTTP
> at all, or may just understand it's not what it claims to be because it
> doesn't behave as it should; HTTP connections have a usually quite
> simple pattern (e.g., much more traffic going in one direction than the
> other and never at the same time), something that would be very
> different in a TURN connection instead.

Hi Lorenzo -

Enterprise Firewalls do have TLS Proxy that inspect TLS traffic. This is usually done to detect malware, content filtering, Data leakage Prevention, port misuse, Application visibility etc. So sending RTP traffic over HTTPS/HTTP can be detected and blocked if policy mandates it. 

--Tiru.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 07 Aug 2012 14:36:34 -0700

On 08/07/2012 12:54 PM, Lorenzo Miniero wrote:
> Hi Iñaki,
> 
> 
> On Tue, 7 Aug 2012 21:34:09 +0200 Iñaki Baz Castillo <[email-masked]>
> wrote:
> 
>> Hi Lorenzo, sorry for opening another thread about this (I didn't check
>> my unread emails before reading the draft). Please see comments inline:
>> 
> 
> 
>> filtering specific traffic over HTTP, and IMHO making specifications to
>> run protocolos over HTTP legitimizes those hateful filtering techniques.
>> 
> 
> 
> That said, as I said in another post I still think that, if RTCWEB/WebRTC
> is going to be deployed in browsers, they'll expect it to work in all the
> places where all other web applications do. Many proprietary protocols that
> do real-time communication implement tunneling somehow, or pretend to do
> so, which means something in line with that is needed for RTCWEB as well.
> 
> 
>> 
>> 
>> 
>> 
>>> 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
>> That's the problem (IMHO): if we make all to work over HTTP then some day
>> telcos providers will just offer HTTP (as "Internet") and we'll need to
>> study a new OSI model in which the lowest layer is called "HTTP".
>> 
> 
> 
> Which is close enough to the hourglass draft Hannes mentioned in his post,
> I'm afraid. I can't but agree with you, but, again, if we have use cases
> and we want to have them working in as many topologies as possible,
> something must be done.
> 
> 
> If we talk about a simple comparison, I'm sure TURN:TLS:443 performs much
> better than RTP over HTTPS, or at least, over the simple approach I
> documented in the draft at least (even though I tried to keep the overhead
> as little as possible). Comparing them is probably not fair, though, as
> they address two different scenarios: that's why HTTP would be just a
> fallback, and not something you'd use when you have alternatives.
> 
> TURN:TLS:443 is probably the most useful option for scenarios 1 and 2, that
> is, where you can just pipe what you want on port 443 and be sure it will
> be ignored by the proxy. If the proxy checks what's going on, though, that
> may not be as easy. The proxy may be acting as a MITM for HTTPS, as Roman
> described, or just doing some traffic monitoring with anomaly detection or
> something like that: faking to be HTTPS is not going to work in that case,
> since the proxy may just see it's not HTTP at all, or may just understand
> it's not what it claims to be because it doesn't behave as it should; HTTP
> connections have a usually quite simple pattern (e.g., much more traffic
> going in one direction than the other and never at the same time),
> something that would be very different in a TURN connection instead.
> 

I think that this problem should be looked from another point of view.  One of
the basic assumption of ICE is that a TURN address is always added with the
lowest priority to the gathered candidate addresses, because it guarantees
that ICE will always works.  Now we all now that this assumption is not true
in 100% of the cases, and this is the reason why years ago I added a TURN over
HTTP(S) transport in the product I was developing at the time and worked on an
I-D (never published).  So instead of seeing TURN over Websocket as a way to
work in difficult environments, we can just see it as a way to fulfill the
promise of ICE, which is to find a path in 100% of the cases, by adding TURN
over UDP then TURN over TCP/TLS, then TURN over Websockets as the lowest
priority in the gathered candidate addresses (that will probably require a
modification in RFC 5245, as it already recommends a priority of 0 for TURN
over UDP).

After Taipei I restarted working on this idea, but using Websocket this time.
 I gave up when I discovered that there was no Websocket dissector in
Wireshark, but now that this issue seems to be fixed, perhaps it is a good
idea to finish this work.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Aug 2012 18:51:39 -0700

> 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…

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

> 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) th…

[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?

---

From: Justin Uberti <[email-masked]>
Date: Tue, 7 Aug 2012 20:23:15 -0700

My perspective is that we can make a huge impact simply by codifying the
rules for doing basic things like TURN over 443 (with or without TLS), HTTP
CONNECT, etc. Running RTP over HTTP could help us get closer to 100%
coverage, but I think we start to enter the area of diminishing returns.

As such, I'd like to see us work towards a best practices document for
establishing sessions in these restricted environments; I think such a
document would be in scope for RTCWEB.

On Tue, Aug 7, 2012 at 11:54 AM, Lorenzo Miniero <[email-masked]>wrote:

> This makes sense. I'm a bit concerned about the additional time that may
> be needed by going through the process of forming a new WG (compared to
> just adding a milestone to an existing WG, that is), as the final result
> may end up being available much after the original WG completed its works,
> but I see your point.
>
> I'll wait for more feedback about this and, if enough people seem
> interested about doing something like this, contacting the ADs and consider
> the next steps may be a good idea.
>
> Lorenzo
>
>
> > regards,
> >
> > Ted Hardie
>
>
> --
> Lorenzo Miniero, COB
>
> Meetecho s.r.l.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 8 Aug 2012 06:18:27 +0000

> Behalf Of Bernard Aboba
> Sent: Wednesday, August 08, 2012 7:22 AM
> To: Lorenzo Miniero
> Cc: [email-masked]
> > 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.
> 
> 
> > 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;
> 
> > 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 

> 
> > 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] 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?

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 8 Aug 2012 12:03:18 +0200

Hi Bernard,

answering inline,

On Tue, 7 Aug 2012 18:51:39 -0700

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

You're right, actually I didn't fully describe the approach we presented in that paper. In that approach, infact, we did made use of TLS to encapsulate the traffic to tunnel (in the paper we tunneled everything we needed, not just RTP) on 443, with or without the CONNECT. So it was not a blind piping stuff on 443 or 80 (which may still work in a few cases, though), which means that other approaches like the TURN/TLS:443 could work fine there.

> [BA] Trying HTTP on port 443 isn't likely to work if the original non-TLS test on 443 failed. 

The CONNECT approach as we conceived it in the paper at the time actually sends an HTTP CONNECT on port 80 to request an encrypted connection towards a 443 destination. If the request is successfull, we have the same TLS stuff as in the direct approach. Or are you talking about something different?

> [BA] DPI boxes aren't always up to date. For example don't expect them to understand websockets.

That's true, and that's why in the draft I proposed a more "basic" approach: that is, relying on a simpler behaviour for HTTP, chunked or not GET and POST messages, in order to look as much as possible as normal HTTP. Probably not very efficient, but more likely to be accepted by intermediaries.

> [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? 

The ideal scenario would be "never" :)

Unfortunately, there are still cases where such an approach may be needed. I'm not sure how often this could happen, though, as it probably depends on how many deployments that enforce such limitations are out there: I'm not sure it's just prisons or military as Roman said, as you just need to properly set up a proxy like Squid to do something like that cheaply, so there could be more.

Thanks,
Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 8 Aug 2012 12:08:42 +0200

Hi Justin,

On Tue, 7 Aug 2012 20:23:15 -0700

> document would be in scope for RTCWEB.

You're right, according to the feedback gathered on the draft so far this looks like a reasonable way to move on. I'm not sure a pure BCP would be enough, though, considering that too many documented different approaches, no matter how effective each, could eventually lead to a few interoperability issues (some browsers/relays may end up implementing some and not others). Maybe something in line with a BCP that at least mandates a certain sequence of or logic in attempts?

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 8 Aug 2012 08:05:28 -0700

On Aug 7, 2012 11:18 PM, "Tirumaleswar Reddy (tireddy)" <[email-masked]>
wrote:
> [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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 8 Aug 2012 17:10:16 +0200

> I do not believe that is acceptable.

Not exactly. Imagine the classic example of hotels providing free WiFi
(but just for HTTP and HTTPS). They do allow their clients to visit
web pages and, therefore, I could expect that they would also allow
any kind of communication that takes place within the web page.

WebRTC introduces UDP, RTP, ICE and more stuf into the WWW world.
These protocols could be blocked in some scenarios (hotel WiFi) but
that does not necessarily mean that the network admins want to block
WebRTC (since it occurs "within" the WWW they already allow).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 8 Aug 2012 15:21:09 +0000

> 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?

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:[email-masked]]
Sent: Wednesday, August 08, 2012 8:35 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]; Lorenzo Miniero; Bernard Aboba
Subject: Re: [rtcweb] HTTP Fallback draft

On Aug 7, 2012 11:18 PM, "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>> wrote:
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> > Behalf Of Bernard Aboba
> > Cc: [email-masked]<mailto:[email-masked]>

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

CB

> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 Aug 2012 17:28:50 +0200

Forking thread....

> network policy set by network operators?
It's about getting stuff done in the presence of rules that hinder the 
"simple way".
Those rules may be set that way deliberately, by ignorance, because of 
implementation limitations, or in error; there's no way to know.

> I do not believe that is acceptable.
We've already done TURN, including TURN over TLS.

Old quote: "This is not about starting down the slippery slope; this is 
about how far we slide into the muck at the bottom".

---

From: Justin Uberti <[email-masked]>
Date: Wed, 8 Aug 2012 12:02:15 -0700

That makes sense to me. The overall point I was driving at was that we
wouldn't have to invent new protocols, we could just propose the
sequence/logic that you describe, perhaps accompanied by real-world data
that explains the approach.

On Wed, Aug 8, 2012 at 3:08 AM, Lorenzo Miniero <[email-masked]>wrote:

> You're right, according to the feedback gathered on the draft so far this
> looks like a reasonable way to move on. I'm not sure a pure BCP would be
> enough, though, considering that too many documented different approaches,
> no matter how effective each, could eventually lead to a few
> interoperability issues (some browsers/relays may end up implementing some
> and not others). Maybe something in line with a BCP that at least mandates
> a certain sequence of or logic in attempts?
>
> Lorenzo
>
>
> >
> > On Tue, Aug 7, 2012 at 11:54 AM, Lorenzo Miniero <[email-masked]
> >wrote:
> >
> > > Hello Ted,
> > >
> > >
> > > > On Tue, Aug 7, 2012 at 9:01 AM, Lorenzo Miniero <
> [email-masked]>
> > > wrote:
> > > > > is such a work actually in line with what is the expected outcome
> of
> > > the