Subject: [tram] Discuss ballot positions on draft-ietf-tram-turn-server-discovery

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 1 Sep 2016 07:41:17 -0500

Dear Authors,

I haven't seen responses to Discuss positions from Ben and from Suresh on
this draft, at least not yet (thank you for the quick responses to the
Discuss positions from Alexey, Kathleen, and Terry).

Ben's seems pretty clear, but I wanted to make sure Suresh's Discuss is
clear enough for you to work with. If you have a chance to let me know
something about that in the next couple of hours (pre-telechat), that would
be awesome.

The datatracker page with ballot positions is (as always) at
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ballot/
.

Thanks,

Spencer

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 1 Sep 2016 14:23:59 +0000

> -----Original Message-----
> From: Spencer Dawkins at IETF [mailto:[email-masked]]
> Sent: Thursday, September 1, 2016 6:11 PM
> To: Simon Perreault <[email-masked]>; draft-ietf-tram-turn-server-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Discuss ballot positions on draft-ietf-tram-turn-server-discovery
> 
> Dear Authors,
> 
> this draft, at least not yet (thank you for the quick responses to the Discuss
> positions from Alexey, Kathleen, and Terry).

I just now finished taking care of comments and discuss points on TURN Mobility :)

> 
> Ben's seems pretty clear, but I wanted to make sure Suresh's Discuss is clear
> enough for you to work with. If you have a chance to let me know something
> about that in the next couple of hours (pre-telechat), that would be awesome.

Suresh discuss looks clear to me. The points raised by Ben's and Kathleen needs to discussed in the WG. My initial thoughts:
a)We will have to discuss and update security considerations section that if STUN authentication is optional then the Enterprise/Access networks must use various mechanisms like subscriber-quota, permit requests to the TURN server only from specific IP addresses, Ingress Filtering etc.
b)This draft will have to update RFC5766.
c)Do we really want to make I-D.ietf-rtcweb-return normative (I prefer not) ?

-Tiru

---

From: Karl Stahl <[email-masked]>
Date: Sun, 4 Sep 2016 05:02:42 +0200

Tiru, to add to your stress :)

What happened to 
https://www.ietf.org/mail-archive/web/tram/current/msg02081.html (and an
earlier WG entry pointing out the same)?
The Anycast method does not work with RFC5766 TURN servers! That has not
been addressed at all.

A TURN server doesn’t react one way (answering 300 Try Alternate) when
addressed by an anycast address and another way (accepting the Allocate
request) when addressed by its unicast address, does it? 

I suggested this modification:

“When a client requires TURN services, it sends a STUN binding request to
the assigned anycast address.  The STUN server
responds with a 300 (Try Alternate) error as described in [RFC5389];  The
response contains a unicast address in the ALTERNATE-SERVER attribute, which
the client compares with the source address of the response and if the
addresses are the same, it is an indication to use the TURN server at that
address. 

For subsequent communication with the TURN server, the client uses that
responding server's unicast address.”

This proposed change has important advantages for security and usefulness
for draft-ietf-rtcweb-return-01 also.

See further [Karl] comments below.

/Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Tirumaleswar Reddy (tireddy)
Skickat: den 1 september 2016 16:24
Till: Spencer Dawkins at IETF; Simon Perreault;
[email-masked]; [email-masked];
[email-masked]
Ämne: Re: [tram] Discuss ballot positions on
draft-ietf-tram-turn-server-discovery

> this draft, at least not yet (thank you for the quick responses to the
Discuss
> positions from Alexey, Kathleen, and Terry).

I just now finished taking care of comments and discuss points on TURN
Mobility :)

> Ben's seems pretty clear, but I wanted to make sure Suresh's Discuss is
clear
> about that in the next couple of hours (pre-telechat), that would be
awesome.

Suresh discuss looks clear to me. The points raised by Ben's and Kathleen
needs to discussed in the WG. My initial thoughts:
a)We will have to discuss and update security considerations section that if
STUN authentication is optional then the Enterprise/Access networks must use
various mechanisms like subscriber-quota, permit requests to the TURN server
only from specific IP addresses, Ingress Filtering etc.
b)This draft will have to update RFC5766.

[Karl] The "autoconfiguration" of RFC 7478 (Web Real-Time Communication Use
Cases and Requirements) 2.3.5.1:
An enterprise that uses a WebRTC-based web application for
   communication desires to audit all WebRTC-based application sessions
   used from inside the company towards any external peer.  To be able
   to do this, they deploy a TURN server that straddles the boundary
   between the internal and the external network.
   The firewall will block all attempts to use STUN with an external
   destination unless they go to the enterprise auditing TURN server.
   In cases where employees are using WebRTC applications provided by an
   external service provider, they still want the traffic to stay inside
   their internal network and in addition not load the straddling TURN
   server; thus, they deploy a STUN server allowing the WebRTC client to
   determine its server reflexive address on the internal side.  Thus,
   enabling cases where peers are both on the internal side to connect
   without the traffic leaving the internal network.  It must be
   possible to configure the browsers used in the enterprise with
   network specific STUN and TURN servers.  This should be possible to
   achieve by autoconfiguration methods.  The WebRTC functionality will
   need to utilize both network specific STUN and TURN resources and
   STUN and TURN servers provisioned by the web application.

Does that not in itself provide sufficient "argument that the local/access
network is somehow equally protected." that Ben is looking for, so that
RFC5766 need not be updated (at least not for this use case)? 

And regarding Kathleen's discuss, isn't this use case "reason why TURN
server discovery should be restricted only to specific clients"?

c)Do we really want to make I-D.ietf-rtcweb-return normative (I prefer not)
?
[Karl] Why?

-Tiru

> The datatracker page with ballot positions is (as always) at
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ballo
t/
_______________________________________________
tram mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tram