Subject: Re: [tram] Fwd: New Version Notification for draft-williams-tram-ufrag-permission-00.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 15 Oct 2015 06:52:33 +0000

I meant with this change an attacker by just knowing the ufrag can now launch an attack on the TURN server and on the endpoint by  sending spoofed ICE requests with valid ufrag but invalid message-integrity, and can use any source IP address and possibly launch DDOS attack, TURN server will just forward those ICE requests to the endpoint.

-Tiru

From: Justin Uberti [mailto:[email-masked]]
Sent: Thursday, October 15, 2015 11:38 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Brandon Williams; [email-masked]
Subject: Re: [tram] Fwd: New Version Notification for draft-williams-tram-ufrag-permission-00.txt

DDOS of spoofed ICE requests can happen already against the host/srflx candidate, so unclear this is a real-world problem.

On Wed, Oct 14, 2015 at 7:39 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
To handle DDOS attack of spoofed ICE requests, did you consider the option of signaling the endpoint's short-term password to TURN server so as to block those ICE requests ?
draft-jennings-behave-rtcweb-firewall-01 and this draft are both discussing STUN inspection on firewalls and TURN servers but in different ways to solve different problems.

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brandon Williams
> Sent: Thursday, October 15, 2015 2:27 AM
> To: [email-masked]<mailto:[email-masked]>
> Subject: [tram] Fwd: New Version Notification for draft-williams-tram-ufrag-
> permission-00.txt
>
> I just posted the below referenced draft. It's focused on improving the speed
> of relayed ICE connectivity checks by defining a new type of permission that
> makes use of the offerer's ICE ufrag.
>
> We will appreciate your comments.
>
> Thanks,
> --Brandon
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-williams-tram-ufrag-permission-00.txt
> Date: Wed, 14 Oct 2015 13:49:35 -0700
> From: [email-masked]<mailto:[email-masked]>
> To: Brandon Williams <[email-masked]<mailto:[email-masked]>>, Brandon Williams
> <[email-masked]<mailto:[email-masked]>>, Justin Uberti <[email-masked]<mailto:[email-masked]>>,
> Justin Uberti <[email-masked]<mailto:[email-masked]>>
>
>
> A new version of I-D, draft-williams-tram-ufrag-permission-00.txt
> has been successfully submitted by Brandon Williams and posted to the IETF
> repository.
>
> Name:         draft-williams-tram-ufrag-permission
> Revision:     00
> Title:                Ufrag Permissions for Traversal Using Relays around NAT
> (TURN)
> Document date:        2015-10-14
> Group:                Individual Submission
> Pages:                9
> URL:
> https://www.ietf.org/internet-drafts/draft-williams-tram-ufrag-permission-
> 00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-williams-tram-ufrag-permission/
> Htmlized:
> https://tools.ietf.org/html/draft-williams-tram-ufrag-permission-00
>
>
> Abstract:
>     When using a TURN relay, ICE connectivity checks require an explicit
>     permission or channel binding to be established for each peer address
>     to be checked.  This requires the answerer to send its candidate
>     addresses to the offerer via the rendezvous server, which can impose
>     a latency penalty when the rendezvous server is centrally located.
>     This document defines a new type of TURN permission that will allow
>     any ICE connectivity check message that contains the offerer's ufrag
>     value to be accepted on a relay address for delivery over the
>     associated TURN tunnel.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> tram mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Thu, 15 Oct 2015 09:38:28 -0400

I don't see a significant difference in the attack profile for DDOS 
between this an standard address based permissions. In this case, I can 
mount a DDOS by knowing the ufrag. For address-based, I can mount a DDOS 
by knowing the address. The relatively minor difference is that reverse 
path filtering might limit an attacker's ability to spoof some 
addresses, but this is uncommon and unreliable enough that it's not 
really a meaningful improvement.

Since the relay and the client already have to deal with roughly the 
same DDOS risk, I don't see significant value in sharing the short-term 
password with the relay.

--Brandon

On 10/15/2015 02:52 AM, Tirumaleswar Reddy (tireddy) wrote:
> I meant with this change an attacker by just knowing the ufrag can now
> launch an attack on the TURN server and on the endpoint by  sending
> spoofed ICE requests with valid ufrag but invalid message-integrity, and
> can use any source IP address and possibly launch DDOS attack, TURN
> server will just forward those ICE requests to the endpoint.
>
> -Tiru
>
> *From:*Justin Uberti [mailto:[email-masked]]
> *Sent:* Thursday, October 15, 2015 11:38 AM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Brandon Williams; [email-masked]
> *Subject:* Re: [tram] Fwd: New Version Notification for
> DDOS of spoofed ICE requests can happen already against the host/srflx
> candidate, so unclear this is a real-world problem.
>
> On Wed, Oct 14, 2015 at 7:39 PM, Tirumaleswar Reddy (tireddy)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> To handle DDOS attack of spoofed ICE requests, did you consider the
> option of signaling the endpoint's short-term password to TURN server so
> as to block those ICE requests ?
> draft-jennings-behave-rtcweb-firewall-01 and this draft are both
> discussing STUN inspection on firewalls and TURN servers but in
> different ways to solve different problems.
>
> -Tiru
>
>
>  > From: tram [mailto:[email-masked]
> <mailto:[email-masked]>] On Behalf Of Brandon Williams
>  > To: [email-masked] <mailto:[email-masked]>
>  > From: [email-masked] <mailto:[email-masked]>
>  > To: Brandon Williams <[email-masked]
> <mailto:[email-masked]>>, Brandon Williams
>  > <[email-masked] <mailto:[email-masked]>>,
> Justin Uberti <[email-masked] <mailto:[email-masked]>>,
>  > Justin Uberti <[email-masked] <mailto:[email-masked]>>
>  >
>  >
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dwilliams-2Dtram-2Dufrag-2Dpermission-2D&d=BQMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=bZyXc9ukjJ_QUjWupaG2ypne_ucgf7--UboitJcrs_Q&s=mlSpD0qNlcC4uIhWTAIPwCrTL2vKELBa1tiNytFJD5k&e=>
>  > 00.txt
>  > Status:
>  >
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwilliams-2Dtram-2Dufrag-2Dpermission_&d=BQMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=bZyXc9ukjJ_QUjWupaG2ypne_ucgf7--UboitJcrs_Q&s=uVF3cL4fmafmz2y-hCdit5rb6DNUtWzLSbRkKfp9Y6A&e=>
>  > Htmlized:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwilliams-2Dtram-2Dufrag-2Dpermission-2D00&d=BQMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=bZyXc9ukjJ_QUjWupaG2ypne_ucgf7--UboitJcrs_Q&s=bHBgOYW5JVSu372AlYCOhgPH2uWf4q2WLO51-HHWpwU&e=>
>  >
>  >
>  > Abstract:
>  > until the htmlized version and diff are available at tools.ietf.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=BQMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=bZyXc9ukjJ_QUjWupaG2ypne_ucgf7--UboitJcrs_Q&s=mGfmfaGDmisJX_ve6W-h_UsYBV8kRWIb_moQSXv1LyA&e=>.
>  >
>  > The IETF Secretariat
>  >
>  >
>  >
>  > [email-masked] <mailto:[email-masked]>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=BQMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=bZyXc9ukjJ_QUjWupaG2ypne_ucgf7--UboitJcrs_Q&s=BCDaXm84h8lOwaaK0UIn2XBghElu3h0oZp4iXligskc&e=>
>
> [email-masked] <mailto:[email-masked]>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=BQMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=bZyXc9ukjJ_QUjWupaG2ypne_ucgf7--UboitJcrs_Q&s=BCDaXm84h8lOwaaK0UIn2XBghElu3h0oZp4iXligskc&e=>
>

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 26 Oct 2015 02:51:35 +0000

Sent: Thursday, October 15, 2015 8:54 PM

My point was that this is already possible if the endpoint is not NATed or is behind a NAT with no filtering - the attacker can just send directly to the host/srflx candidate.

[TR] If the host is behind firewall then the attack is not possible. Attackers will probably have more incentive to attack TURN servers than hosts.

-Tiru

Even if the user is NATed, the attacker could forge the source address of the UDP packet to match an valid source.

On Wed, Oct 14, 2015 at 11:52 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
I meant with this change an attacker by just knowing the ufrag can now launch an attack on the TURN server and on the endpoint by  sending spoofed ICE requests with valid ufrag but invalid message-integrity, and can use any source IP address and possibly launch DDOS attack, TURN server will just forward those ICE requests to the endpoint.

-Tiru

From: Justin Uberti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 15, 2015 11:38 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Brandon Williams; [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] Fwd: New Version Notification for draft-williams-tram-ufrag-permission-00.txt

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 26 Oct 2015 03:02:01 +0000

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Thursday, October 15, 2015 7:08 PM
> To: Tirumaleswar Reddy (tireddy); Justin Uberti
> Cc: [email-masked]
> I don't see a significant difference in the attack profile for DDOS between this
> an standard address based permissions. In this case, I can mount a DDOS by
> knowing the ufrag. For address-based, I can mount a DDOS by knowing the
> address. The relatively minor difference is that reverse path filtering might
> limit an attacker's ability to spoof some addresses, but this is uncommon and
> unreliable enough that it's not really a meaningful improvement.

There are various other ways to detect IP address spoofing. For example possible techniques for source address validation are discussed in https://tools.ietf.org/html/rfc6959. 

> 
> Since the relay and the client already have to deal with roughly the same
> DDOS risk, I don't see significant value in sharing the short-term password
> with the relay.

DDOS mitigation now has to also deal with a possible L7 attack and would be good to be discussed in detail in the draft.
 
-Tiru

> > spoofed ICE requests with valid ufrag but invalid message-integrity,
> > and can use any source IP address and possibly launch DDOS attack,
> > TURN server will just forward those ICE requests to the endpoint.
> >
> > -Tiru
> >
> > option of signaling the endpoint's short-term password to TURN server
> > so as to block those ICE requests ?
> > <mailto:[email-masked]>] On Behalf Of Brandon Williams  > Sent:
> > Thursday, October 15, 2015 2:27 AM  > To: [email-masked]
> > <mailto:[email-masked]>  > Subject: [tram] Fwd: New Version
> > Notification for
> >  > I just posted the below referenced draft. It's focused on improving
> > the speed  > of relayed ICE connectivity checks by defining a new type
> > of permission that  > makes use of the offerer's ICE ufrag.
> >  >
> >  > -------- Forwarded Message --------  > Subject: New Version
> > Notification for  > draft-williams-tram-ufrag-permission-00.txt
> >  > Date: Wed, 14 Oct 2015 13:49:35 -0700  > From:
> > [email-masked] <mailto:[email-masked]>  > To:
> > Brandon Williams <[email-masked]
> > <mailto:[email-masked]>>, Brandon Williams  >
> > Justin Uberti <[email-masked] <mailto:[email-masked]>>,  >
> > Justin Uberti <[email-masked] <mailto:[email-masked]>>  >  >
> >  > has been successfully submitted by Brandon Williams and posted to
> > the IETF  > repository.
> >  >
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_int
> > ernet-2Ddrafts_draft-2Dwilliams-2Dtram-2Dufrag-2Dpermission-
> 2D&d=BQMGa
> > Q&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> NSnsgwbBVUJa4mZfmEIB
> > Xg&m=bZyXc9ukjJ_QUjWupaG2ypne_ucgf7--
> UboitJcrs_Q&s=mlSpD0qNlcC4uIhWTAI
> > PwCrTL2vKELBa1tiNytFJD5k&e=>
> >  > 00.txt
> >  > Status:
> >  >
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
> > .org_doc_draft-2Dwilliams-2Dtram-2Dufrag-
> 2Dpermission_&d=BQMGaQ&c=96Zb
> > ZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> NSnsgwbBVUJa4mZfmEIBXg&m=bZy
> > Xc9ukjJ_QUjWupaG2ypne_ucgf7--UboitJcrs_Q&s=uVF3cL4fmafmz2y-
> hCdit5rb6DN
> > UtWzLSbRkKfp9Y6A&e=>
> >  > Htmlized:
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_h
> > tml_draft-2Dwilliams-2Dtram-2Dufrag-2Dpermission-
> 2D00&d=BQMGaQ&c=96ZbZ
> > ZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> NSnsgwbBVUJa4mZfmEIBXg&m=bZyX
> > c9ukjJ_QUjWupaG2ypne_ucgf7--
> UboitJcrs_Q&s=bHBgOYW5JVSu372AlYCOhgPH2uWf
> > 4q2WLO51-HHWpwU&e=>
> >  >
> >  >
> >  > Abstract:
> >  > Please note that it may take a couple of minutes from the time of
> > submission  > until the htmlized version and diff are available at
> > tools.ietf.org
> > <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__tools.ietf.org&d=BQMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> nnRGWmcGKRIuadq6-
> NSnsgwbBVUJa4mZfmEIBXg&m=bZyXc9ukjJ_QUjWupaG2ypne_ucgf7--
> UboitJcrs_Q&s=mGfmfaGDmisJX_ve6W-h_UsYBV8kRWIb_moQSXv1LyA&e=>.
> >  >
> >  > The IETF Secretariat
> >  >
> >  >
> >  >
> >  > [email-masked] <mailto:[email-masked]>  >
> > <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mai
> > lman_listinfo_tram&d=BQMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> nnRGWmcGKRI
> > uadq6-
> NSnsgwbBVUJa4mZfmEIBXg&m=bZyXc9ukjJ_QUjWupaG2ypne_ucgf7--UboitJc
> > rs_Q&s=BCDaXm84h8lOwaaK0UIn2XBghElu3h0oZp4iXligskc&e=>
> >
> > <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mai
> > lman_listinfo_tram&d=BQMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> nnRGWmcGKRI
> > uadq6-
> NSnsgwbBVUJa4mZfmEIBXg&m=bZyXc9ukjJ_QUjWupaG2ypne_ucgf7--UboitJc
> > rs_Q&s=BCDaXm84h8lOwaaK0UIn2XBghElu3h0oZp4iXligskc&e=>
> >
> 
> --