Re: [tram] Fwd: Re: [rtcweb] draft-schwartz-rtcweb-return

> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault
> Sent: Wednesday, April 08, 2015 5:39 PM
> To: tram@ietf.org
> Subject: [tram] Fwd: Re: [rtcweb] draft-schwartz-rtcweb-return
> 
> TRAMsters,
> 
> I'd like to see some discussion on how this impacts the server-discovery
> draft. This part in particular...
> 
> "endpoints MUST NOT implement a	configuration based on
> unauthenticated
> network multicast (e.g. mDNS)"
> 
> ...seems at odds with what was decided in Dallas (i.e., define mDNS
> discovery).
> 
> Thoughts?

Yes. After TURN server is discovered using mDNS, client must authenticate the TURN server to avoid some malicious host advertising that it offers TURN service. Further mDNS http://tools.ietf.org/html/rfc6762#section-21 also refers to using DNSSEC so that the client can ensure that the service is provided by a trusted participant and not a rouge participant.

-Tiru

> 
> I see having a coherent story for return and server-discovery as somewhat
> required...
> 
> Simon
> 
> -------- Message transféré --------
> Sujet : Re: [rtcweb] draft-schwartz-rtcweb-return Date : Wed, 8 Apr 2015
> 00:58:29 +0000 De : Cullen Jennings (fluffy) <fluffy@cisco.com> Pour :
> rtcweb@ietf.org <rtcweb@ietf.org>
> 
> 
> > On Mar 26, 2015, at 9:20 AM, Cullen Jennings <fluffy@cisco.com> wrote:
> >
> > I'd like to point out that the combination of ietf-tram-turn-server-discovery
> and draft-schwartz-rtcweb-return allow any network you are connected to
> more or less MITM your media and do things like rate limit it, generate
> analytics on who you are talking to, force your traffic through an
> intermediary that is in a  different legal jurisdiction and so on.
> 
> We discussed this after the meeting and came up with a  way to resolve this
> concern. Benjamin has added some text to the -06 to that specifically
> addresses this issue
> 
> http://www.ietf.org/rfcdiff?url1=draft-schwartz-rtcweb-return-05&url2=draft-
> schwartz-rtcweb-return-06
> 
> This completely deals with the issue I raised and with that change I support
> adopting this as a WG document.
> 
> After adoption, I think the WG should consider if any text is needed around
> the issue of TURN credentials. (If you run TURN with no credentials and an
> attacker can spoof the IP address in UDP packets, you can end up with the
> TURN servers in a nasty forwarding loop that allows an huge amplification
> factor for an attacker trying do DOS the turn servers - this is still possible
> with authentication but you know who to blame. When TURN was first done
> with was one of the reason TURN requires auth and STUN does not).
> However, I believe this issue can solved and should not block adopting the
> draft. )
> 
> Cullen
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram