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

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

> -----Original Message-----
> From: Dave Dolson [mailto:[e-mail]]
> Sent: Wednesday, February 22, 2017 9:54 PM
> To: Tirumaleswar Reddy (tireddy) <[e-mail]>; [e-mail]
> Subject: RE: New Version Notification for draft-reddy-dots-signal-channel-
> 08.txt
> 
> I think my point was missed.
> See inline [DD]
> 
> ________________________________________
> From: Tirumaleswar Reddy (tireddy) [[e-mail]]
> Sent: Wednesday, February 22, 2017 3:55 AM
> To: Dave Dolson; [e-mail]
> Subject: RE: New Version Notification for draft-reddy-dots-signal-channel-
> 08.txt
> 
> > -----Original Message-----
> > From: Dave Dolson [mailto:[e-mail]]
> > Sent: Wednesday, February 22, 2017 3:35 AM
> > To: Tirumaleswar Reddy (tireddy) <[e-mail]>; [e-mail]
> > 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 ?

Yes, you are correct. The DOTS client identity will be used to check if the client has transmitted the same policy-id 
over a different transport and also to detect duplicates in a DTLS session over UDP.

I will update the draft to clarify.

Cheers,
-Tiru

> 
> > 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:[e-mail]] On Behalf Of Tirumaleswar
> > Reddy
> > (tireddy)
> > Sent: Tuesday, February 21, 2017 4:31 AM
> > To: [e-mail]
> > 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: [e-mail] [mailto:[e-mail]]
> > > Sent: Tuesday, February 21, 2017 2:28 PM
> > > To: Prashanth Patil (praspati) <[e-mail]>; Mohamed
> > > Boucadair <[e-mail]>; Tirumaleswar Reddy
> > > (tireddy) <[e-mail]>
> > > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dots