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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Brandon Williams [mailto:[e-mail]]
> Sent: Thursday, October 15, 2015 7:08 PM
> To: Tirumaleswar Reddy (tireddy); Justin Uberti
> Cc: [e-mail]
> Subject: Re: [tram] Fwd: New Version Notification for draft-williams-tram-
> ufrag-permission-00.txt
> 
> 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

> 
> --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:[e-mail]]
> > *Sent:* Thursday, October 15, 2015 11:38 AM
> > *To:* Tirumaleswar Reddy (tireddy)
> > *Cc:* Brandon Williams; [e-mail]
> > *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)
> > <[e-mail] <mailto:[e-mail]>> 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:[e-mail]
> > <mailto:[e-mail]>] On Behalf Of Brandon Williams  > Sent:
> > Thursday, October 15, 2015 2:27 AM  > To: [e-mail]
> > <mailto:[e-mail]>  > 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:
> > [e-mail] <mailto:[e-mail]>  > To:
> > Brandon Williams <[e-mail]
> > <mailto:[e-mail]>>, Brandon Williams  >
> > <[e-mail]
> <mailto:[e-mail]>>,
> > Justin Uberti <[e-mail] <mailto:[e-mail]>>,  >
> > Justin Uberti <[e-mail] <mailto:[e-mail]>>  >  >
> > > 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-permiss
> > ion-
> > <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://datatracker.ietf.org/doc/draft-williams-tram-ufrag-permission/
> > <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://tools.ietf.org/html/draft-williams-tram-ufrag-permission-00
> > <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:
> >  >     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
> > <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
> >  >
> >  >
> >  >
> >  > _______________________________________________
> >  > tram mailing list
> >  > [e-mail] <mailto:[e-mail]>  >
> > https://www.ietf.org/mailman/listinfo/tram
> > <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=>
> >
> > _______________________________________________
> > tram mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/tram
> > <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=>
> >
> 
> --
> Brandon Williams; Chief Architect
> Cloud Networking; Akamai Technologies Inc.