Subject: Re: [rtcweb] draft-schwartz-rtcweb-return

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 8 Apr 2015 00:58:29 +0000

> On Mar 26, 2015, at 9:20 AM, Cullen Jennings <[email-masked]> 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

---

From: Justin Uberti <[email-masked]>
Date: Mon, 13 Apr 2015 19:21:47 -0700

I think this is a sensible change and we should adopt the revised document.

On Tue, Apr 7, 2015 at 5:58 PM, Cullen Jennings (fluffy) <[email-masked]>
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
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 16 Apr 2015 17:41:00 +0000

+1 I also think this looks like a sensible revision and would like to see this adopted sooner rather than later.

Andy

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Justin
> Uberti
> Sent: 14 April 2015 03:22
> To: Cullen Jennings (fluffy)
> Cc: [email-masked]
> Subject: Re: [rtcweb] draft-schwartz-rtcweb-return
> 
> On Tue, Apr 7, 2015 at 5:58 PM, Cullen Jennings (fluffy)
> <[email-masked]> 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.
> 
> this concern. Benjamin has added some text to the -06 to that
> specifically addresses this issue
> 
> 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
> 
> 
> 
>