Re: [Dots] New Version Notification for draft-reddy-dots-signal-channel-08.txt

I think my point was missed.
See inline [DD]

________________________________________
From: Tirumaleswar Reddy (tireddy) [tireddy@cisco.com]
Sent: Wednesday, February 22, 2017 3:55 AM
To: Dave Dolson; dots@ietf.org
Subject: RE: New Version Notification for draft-reddy-dots-signal-channel-08.txt

> -----Original Message-----
> From: Dave Dolson [mailto:ddolson@sandvine.com]
> Sent: Wednesday, February 22, 2017 3:35 AM
> To: Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>; dots@ietf.org
> Subject: RE: New Version Notification for draft-reddy-dots-signal-channel-
> 08.txt
>
> On the topic of "Happy Eyeballs" (although I think this is a misnomer),

Why "Happy Eyeballs" is used by most browsers today https://tools.ietf.org/html/rfc6555 and MIF WG is also using "Happy Eyeballs" technique (see https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-11).
[DD] I said "misnomer" because although people look at browsers (with their eyeballs), dots protocol is not for human eyeballs. But I'm being pedantic :-)

> I believe
> the intent would be to use the same policy-id in each of the transports, to
> detect duplicates at the server, correct?

No. The use of "Happy Eyeballs" is test and pick a transport using which TLS or DTLS session can be established with the DOTS server (UDP has higher precedence than TCP).
Once the session is established on a specific transport, there is no need to send the mitigation request on both the transports.
[DD] Although the client desires only one request, if two sessions are initiated simultaneously, both *might* succeed. My point is that the server should be able to identify the duplicate -- and I think the "policy-id" field would be the mechanism to detect duplicates, correct?

> The document should say so. (Or if not, explain how duplicates are to be
> detected.)
>
>
> Also, has thought been given to preventing replay attacks?  E.g., maliciously
> asking for mitigation by replaying a captured mitigation request?

DTLS is capable of detecting replay attacks, see https://tools.ietf.org/html/rfc6347#section-3.3. I will update the draft to say Replay Detection using DTLS is mandatory for DOTS agents.

-Tiru

>
>
>
> -----Original Message-----
> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy
> (tireddy)
> Sent: Tuesday, February 21, 2017 4:31 AM
> To: dots@ietf.org
> Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-
> channel-08.txt
>
> This revision https://tools.ietf.org/html/draft-reddy-dots-signal-channel-08
> addresses comments from Ehud and Kaname.
>
> Major changes are:
>
> 1)DOTS mitigation request/response are marked as non-confirmable
> messages. Requests marked by the DOTS  client as Non-confirmable messages
> are sent at regular intervals until a response is received from the DOTS server
> (See Section 5.3 for more details).
>
> (Thanks to the feedback from Flemming, Andrew and Ehud).
>
> 2)Added support for vendor specific parameters.
>
> 3)Added new Mitigation status parameters: bytes_dropped, bps_dropped,
> pkts_dropped and pps_dropped.
>
> Comments and suggestions are welcome.
>
> -Tiru
>
>
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: Tuesday, February 21, 2017 2:28 PM
> > To: Prashanth Patil (praspati) <praspati@cisco.com>; Mohamed Boucadair
> > <mohamed.boucadair@orange.com>; Tirumaleswar Reddy (tireddy)
> > <tireddy@cisco.com>
> > Subject: New Version Notification for
> > draft-reddy-dots-signal-channel-08.txt
> >
> >
> > A new version of I-D, draft-reddy-dots-signal-channel-08.txt
> > has been successfully submitted by Tirumaleswar Reddy and posted to
> > the IETF repository.
> >
> > Name:               draft-reddy-dots-signal-channel
> > Revision:   08
> > Title:              Distributed Denial-of-Service Open Threat Signaling (DOTS)
> > Signal Channel
> > Document date:      2017-02-21
> > Group:              Individual Submission
> > Pages:              46
> > URL:            https://www.ietf.org/internet-drafts/draft-reddy-dots-signal-
> > channel-08.txt
> > Status:         https://datatracker.ietf.org/doc/draft-reddy-dots-signal-
> channel/
> > Htmlized:       https://tools.ietf.org/html/draft-reddy-dots-signal-channel-08
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-reddy-dots-signal-
> channel-
> > 08
> >
> > Abstract:
> >    This document specifies a mechanism that a DOTS client can use to
> >    signal that a network is under a Distributed Denial-of-Service (DDoS)
> >    attack to an upstream DOTS server so that appropriate mitigation
> >    actions are undertaken (including, blackhole, drop, rate-limit, or
> >    add to watch list) on the suspect traffic.  The document specifies
> >    the DOTS signal channel including Happy Eyeballs considerations.  The
> >    specification of the DOTS data channel is elaborated in a companion
> >    document.
> >
> >
> >
> >
> > 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.
> >
> > The IETF Secretariat
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots