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

[Benjamin Schwartz <[e-mail]>]

If the TURN server's identity is discovered over mDNS, then how can the
client authenticate the TURN server, except to prove that it's the same one
advertised over mDNS?  Assuming mDNS is trivial to forge on a broadcast
network, this does not seem like sufficient protection.  Maybe you are
saying that the TURN server's "real identity" is configured by some other
mechanism, and only its address is distributed by mDNS?

I'm not familiar with the interaction between mDNS and DNSSEC, or how this
would help to identify trusted servers.  This seems like another case in
which a trusted pre-configuration mechanism is still required.

On Wed, Apr 8, 2015 at 8:40 AM, Tirumaleswar Reddy (tireddy) <
[e-mail]> wrote:

> > -----Original Message-----
> > From: tram [mailto:[e-mail]] On Behalf Of Simon Perreault
> > Sent: Wednesday, April 08, 2015 5:39 PM
> > To: [e-mail]
> > 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) <[e-mail]> Pour :
> > [e-mail] <[e-mail]>
> >
> >
> > > On Mar 26, 2015, at 9:20 AM, Cullen Jennings <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > tram mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>