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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 21 Feb 2017 09:31:10 +0000

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: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 21, 2017 2:28 PM
> To: Prashanth Patil (praspati) <[email-masked]>; Mohamed Boucadair
> <[email-masked]>; Tirumaleswar Reddy (tireddy)
> <[email-masked]>
> 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

---

From: Dave Dolson <[email-masked]>
Date: Tue, 21 Feb 2017 22:04:47 +0000

On the topic of "Happy Eyeballs" (although I think this is a misnomer),
I believe the intent would be to use the same policy-id in each of the transports, to detect duplicates at the server, 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?

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Tuesday, February 21, 2017 4:31 AM
To: [email-masked]
Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-channel-08.txt

Major changes are:

-Tiru

> until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Dots mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 22 Feb 2017 08:52:56 +0000

Hi Dave,
Please see my points inline:

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 Dave Dolson
发送时间: 2017年2月22日 6:05
收件人: Tirumaleswar Reddy (tireddy); [email-masked]
主题: Re: [Dots] New Version Notification for draft-reddy-dots-signal-channel-08.txt

On the topic of "Happy Eyeballs" (although I think this is a misnomer), I believe the intent would be to use the same policy-id in each of the transports, to detect duplicates at the server, correct?
The document should say so. (Or if not, explain how duplicates are to be detected.)
[Frank]: the main goal of "Happy Eyeballs" is to minimize the transport connection setup delay.

Also, has thought been given to preventing replay attacks?  E.g., maliciously asking for mitigation by replaying a captured mitigation request?
[Frank]: DOTS requirements draft mentioned this point already (SEC-003). I agrees some methods to avoid it should be described in the signal channel draft.

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Tuesday, February 21, 2017 4:31 AM
To: [email-masked]
Subject: Re: [Dots] New Version Notification for draft-reddy-dots-signal-channel-08.txt

Major changes are:

-Tiru

> has been successfully submitted by Tirumaleswar Reddy and posted to 
> the IETF repository.
> 
> 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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 22 Feb 2017 08:55:10 +0000

> From: Dave Dolson [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2017 3:35 AM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>; [email-masked]
> Subject: RE: New Version Notification for draft-reddy-dots-signal-channel-
> 08.txt
> 

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). 

> 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.

> 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

> 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).
>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 22 Feb 2017 16:23:53 +0000

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

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

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 :-)

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?

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 23 Feb 2017 02:14:17 +0000

> Sent: Wednesday, February 22, 2017 9:54 PM
> > Subject: RE: New Version Notification for
> > draft-reddy-dots-signal-channel- 08.txt
> >
> 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
> 
> >
> >
> >
> > From: Dots [mailto:[email-masked]] On Behalf Of Tirumaleswar
> > Reddy
> > (tireddy)
> > 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:
> >
> > 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).
> >
> > > To: Prashanth Patil (praspati) <[email-masked]>; Mohamed
> > > Boucadair <[email-masked]>; Tirumaleswar Reddy
> > > (tireddy) <[email-masked]>