Subject: [tram] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ?

From: Cullen Jennings <[email-masked]>
Date: Tue, 7 Jul 2015 09:50:04 -0600

draft-jennings-behave-rtcweb-firewall-00 discussed how firewalls might handle WebRTC traffic. 

Would it be possible to get a short amount of agenda time in TRAM to talk about the changes this draft proposes to some TRAM drafts. Specifically the issue is when to use the STUN ORIGIN attribute. 

Thanks, Cullen

---

From: Simon Perreault <[email-masked]>
Date: Tue, 07 Jul 2015 12:05:50 -0400

> draft-jennings-behave-rtcweb-firewall-00 discussed how firewalls might handle WebRTC traffic. 

behave, the zombie WG that still gets -00 drafts! ;)

> Would it be possible to get a short amount of agenda time in TRAM to talk about the changes this draft proposes to some TRAM drafts. Specifically the issue is when to use the STUN ORIGIN attribute. 

Sure.

Note that ORIGIN has been stopped by the IESG brick wall and will
probably need to change significantly. We have scheduled a discussion on
that topic as our first order of business.

Simon

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 7 Jul 2015 21:42:56 -0600

> On Jul 7, 2015, at 10:05 AM, Simon Perreault <[email-masked]> wrote:
> 

Thanks - basically this draft is tired up the same issue so it may be that after that discussion, this draft turns into a very short discussion.

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 14 Jul 2015 00:32:06 +0200

This and next email was just posted on the RTCWEB list, but concerns TRAM
also:

I have read this draft and the latest draft-ietf-rtcweb-return-00 and
draft-ietf-tram-turn-server-discovery-03 drafts from the point of view of
finally getting a good and working solution to the old NAT/Firewall
traversal issue with real-time communication, here specifically WebRTC using
ICE.

I find all these drafts to be in the right direction and should be worked
trough to RFCs.

Regarding the comment on Section 6 (“The IETF is designing systems to send
interactive audio and video such that it looks like HTTPS and HTTP to the
proxies and firewalls “) and below:

> extremely unlikely that we would implement it.

I hope this means that the IETF should go no further in the direction of
“fooling real-time traffic” through firewalls, but rather make RFCs that can
allows good traversal of real-time traffic for users on networks that want
such traffic, and that we realize:

i) The network administrator wanting to block or make real-time traffic bad
and useless can always do that (exemplified in this behave draft, but maybe
the intent has to be clarified). And that taking further steps in the
direction of “fooling real-time traffic” through firewalls “has some risk of
impacting normal HTTP traffic, so there is a desire to provide guidance
around ways to do that in this draft.”  (quote from this behave draft)

ii) There may be legitimate reasons to e.g. allow surfing, but not voice on
a network. We cannot/should not rule against that, even if we all are for
net neutrality and against evil purposes for blocking e.g. voice and SIP
(which still sometimes seem to be the case). The network admin and the
firewall are in charge. If we want to use good real-time communication, we
have to use networks that wants to provide it – It should be a selling
feature for using the network access. Our efforts could possibly be advice
how evil blocking could be exposed/displayed so users can select other
network accesses for real-time communication.

I have lost track of where these repeatedly popping up suggestions to “fool
real-time traffic” through the most restrictive firewalls are, but the only
real solution is to make these firewalls less restrictive or to parallel
them, which is what the RETURN + TURN server DISCOVERY draft may achieve in
a good way.

I think there could be (maybe is) consensus around this, and as a comment to
this behave draft”:

- Yes, it guides how a firewall could be less restrictive, but still pretty
secure, and allow STUN-based traversal of  WebRTC real-time traffic through
the network default gateway.

However, that is not sufficient, it should in its “guidance to firewall
vendors” (which I believe the draft is), also point out the firewall
traversal clarified in the RETURN draft (From the introduction):

“This TURN server may be placed inside the network, with a

   firewall configuration allowing it to communicate with the public

   internet, or it may be operated by a third party outside the network,

   with a firewall configuration that allows hosts inside the network to

   communicate with it.  Use of the specified TURN server may be the

   only way for clients on the network to achieve a high quality WebRTC

   experience.  This scenario is required to be supported by the WebRTC

   requirements document [I-D.ietf-rtcweb-use-cases-and-requirements]

   Section 3.3.5.1.”

A firewall (designed to be secure AND to handle real-time communication
without having to be paralleled by an SBC or a TURN server) could very well
include such TURN server (or TURN Proxy or Border TURN server as it is
called in the RETURN draft).

Also, a network service provider offering such (sealed) TURN server (or TURN
Proxy or Border TURN server), typically has an enterprise firewall in front
of it: The firewall vendor should then be adviced to recommend his customers
to open a pinhole from the LAN to that TURN server (not to use an own
additional border TURN server requiring double RETURN or something like
that).

So, I suggest to add guidance about these things to this behave draft.

Having expressed this, I believe the sealed, configuration and
authentication concept of the RETURN draft, and possible the DISCOVERY draft
needs to be clarified/extended, which will follow in next email.

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Cullen Jennings
Skickat: den 8 juli 2015 05:43
Till: Simon Perreault
Kopia: [email-masked]
Ämne: Re: [tram] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ?

> On Jul 7, 2015, at 10:05 AM, Simon Perreault <
<mailto:[email-masked]> [email-masked]> wrote:

>> Would it be possible to get a short amount of agenda time in TRAM to talk
about the changes this draft proposes to some TRAM drafts. Specifically the
issue is when to use the STUN ORIGIN attribute. 

> probably need to change significantly. We have scheduled a discussion 

> on that topic as our first order of business.

> Simon

Thanks - basically this draft is tired up the same issue so it may be that
after that discussion, this draft turns into a very short discussion.

_______________________________________________

tram mailing list

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

 <https://www.ietf.org/mailman/listinfo/tram>
https://www.ietf.org/mailman/listinfo/tram