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

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

I'd like to get a brief amount of agenda time to discuss changes we would need to some of the WebRTC WG drafts to make the ideas proposed in draft-jennings-behave-rtcweb-firewall- work and make people aware of this work. 

Would it be possible to get 10 minutes on the agenda ? 

Thanks, Cullen

---

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Jul 2015 09:17:09 -0700

On Tue, Jul 7, 2015 at 8:50 AM, Cullen Jennings <[email-masked]> wrote:

>
> I'd like to get a brief amount of agenda time to discuss changes we would
> need to some of the WebRTC WG drafts to make the ideas proposed in
> draft-jennings-behave-rtcweb-firewall- work and make people aware of this
> work.
>
​There is time on day 2, at this point, so it shouldn't be a problem.

Ted​

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Jul 2015 07:39:35 -0700

I have taken a brief look at this draft and I don't believe that the
proposed pinhole/inspection
algorithm provides the desired assurances of verifying consent:

1. If you open up an incoming/outgoing pinhole on outgoing packet, prior to
receiving an incoming STUN packet, then if the internal implementation
simply sends a new outgoing STUN packet every 5 seconds, then they
never need to rely on external consent.

2. If you just require *a* incoming STUN packet to be received in order to
extend the lifetime to 30 seconds, then an off-path attacker can forge
a STUN response that will cause the pinhole to be open for 30 seconds.
(Hence the need for the STUN transaction ID).

It seems to me that you should be instead requiring a complete STUN
transaction before allowing any non-STUN outgoing traffic. It would probably
be safe-ish to require it before allowing any incoming traffic as well,
though
that leaves the chance that you get a small amount of clipping with packet
drops or reordering.

WRT to the origin attribute, I have mixed feelings. I agree that your SNI
argument
is strong, but there is also a move to figure out how to encrypt SNI, so
every time
we extend that argument it makes that harder. OTOH, STUN origin will be
sent a lot less often than SNI, I imagine.

I don't understand Section 6. Is this guidance to firewall vendors or to
browser
implementors. If the former, the firewall has no way of knowing what
"requests"
are if the connection use HTTPS (and if is uses HTTP, you have DPI-type
methods for
determining whether something is voice or video. If this is guidance to
browser
vendors, I consider it extremely unlikely that we would implement it.

Point #4 in your security considerations section seems like an entirely lost
cause, unless you assume that attackers are not really trying.

-Ekr

---

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

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

PS: I am separately posting this and the next email to the TRAM WG also, since they were also address about this draft and is responsible for the DISCOVERY draft

Från: rtcweb [mailto:[email-masked]] För Eric Rescorla
Skickat: den 8 juli 2015 16:40
Till: Cullen Jennings
Kopia: [email-masked]
Ämne: Re: [rtcweb] Agenda time for draft-jennings-behave-rtcweb-firewall-00 ?

I have taken a brief look at this draft and I don't believe that the proposed pinhole/inspection

be safe-ish to require it before allowing any incoming traffic as well, though

drops or reordering.

WRT to the origin attribute, I have mixed feelings. I agree that your SNI argument

is strong, but there is also a move to figure out how to encrypt SNI, so every time

 

I don't understand Section 6. Is this guidance to firewall vendors or to browser

implementors. If the former, the firewall has no way of knowing what "requests"

are if the connection use HTTPS (and if is uses HTTP, you have DPI-type methods for

determining whether something is voice or video. If this is guidance to browser

 

-Ekr

Thanks, Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 16 Jul 2015 13:51:36 -0600

Good points.I will update the draft but in the meantime there is a copy at 
http://fluffy.github.io/iceTrav/

The summary of the algorithm is roughly:

•The firewall looks for any outgoing STUN requests to STUN port (3478). When it finds one, it stores the 3 tuple of the source address port and protocol=UDP and for the next 30 seconds checks any packets from this 3 tuple to see if they are ICE connectivity checks. 

•When firewall sees an ICE connectivity check from the inside host (which is a STUN Binding Request containing the ice username), it stores that ice username value, and forwards the packet.  Thereafter, STUN Binding Requests and Binding Responses with matching 4-tuple (inside IP address, protocol=UDP, inside port, and matching ice username) are allowed in any direction (inside->outside and outside->inside).  For each 5-tuple, if a STUN Binding Request has a Success STUN Binding Response (with same transaction ID), in either direction, that 5-tuple is promoted to allow non-STUN traffic (DTLS, SRTP, and anything else).  

•Both promoted and non-promoted pinholes are closed after 30 seconds of not seeing a STUN Binding Request and Response transaction, in either direction.

•(Note to match the ice username external requests will need the halves on either side of “:” swapped)

(and thanks to  Dan Wing who came up with much of the above proposal ) 

more inline 

> On Jul 8, 2015, at 8:39 AM, Eric Rescorla <[email-masked]> wrote:
> 

Yah, don't want outside stuff to extended it. Intent was only inside stuff should extend. 

> that leaves the chance that you get a small amount of clipping with packet

Agree - have changed to that. 

> sent a lot less often than SNI, I imagine.

Sounds like this is going to get discussed in Tram. Unfortunately I think we have to choose between least evil on this topic. 

> vendors, I consider it extremely unlikely that we would implement it.

advice for firewall vendors for more or less all TLS connections that might be web traffic. It's horrific of course but since they are implementing things along these lines we might as well be specific on the algorithm so we understand the breakage. Or go deal with the root causes that theses sort of things (basically trying to hide WebRTC traffic inside HTTP) . I imagine this algorithm is not the best, it was just a rough place holder. Its needs a bit of tuning to interact with dash in a reasonable way.

---

From: Benjamin Schwartz <[email-masked]>
Date: Fri, 17 Jul 2015 11:40:07 -0700

Regarding the use of ORIGIN, the current text says

> Does adding the ORIGIN reduce user privacy? ... when the original TLS
connection for the HTTP was made, the Server Name Indication (SNI) in the
TLS of the HTTPS connection also revealed facebook.com, largely for the
same reasons - so that the firewall would be able to see which applications
are using the network.

I expect you're aware that this may not be true in TLS 1.3.

On Thu, Jul 16, 2015 at 12:51 PM, Cullen Jennings <[email-masked]> wrote:

> •The firewall looks for any outgoing STUN requests to STUN port (3478).
> When it finds one, it stores the 3 tuple of the source address port and
> protocol=UDP and for the next 30 seconds checks any packets from this 3
> tuple to see if they are ICE connectivity checks.
>
> •When firewall sees an ICE connectivity check from the inside host (which
> is a STUN Binding Request containing the ice username), it stores that ice
> username value, and forwards the packet.  Thereafter, STUN Binding Requests
> and Binding Responses with matching 4-tuple (inside IP address,
> protocol=UDP, inside port, and matching ice username) are allowed in any
> direction (inside->outside and outside->inside).  For each 5-tuple, if a
> STUN Binding Request has a Success STUN Binding Response (with same
> transaction ID), in either direction, that 5-tuple is promoted to allow
> non-STUN traffic (DTLS, SRTP, and anything else).
>
> •Both promoted and non-promoted pinholes are closed after 30 seconds of
> not seeing a STUN Binding Request and Response transaction, in either
> direction.
>
> Sounds like this is going to get discussed in Tram. Unfortunately I think
> we have to choose between least evil on this topic.
>
> >
> >
> advice for firewall vendors for more or less all TLS connections that
> might be web traffic. It's horrific of course but since they are
> implementing things along these lines we might as well be specific on the
> algorithm so we understand the breakage. Or go deal with the root causes
> that theses sort of things (basically trying to hide WebRTC traffic inside
> HTTP) . I imagine this algorithm is not the best, it was just a rough place
> holder. Its needs a bit of tuning to interact with dash in a reasonable way.
>
>
> >
> >