Subject: Re: [Dots] FW: New Version Notification for draft-reddy-dots-transport-02.txt

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 8 Mar 2016 15:33:23 +0000

Hi Tiru!

(Chair hat off ...)
Thanks for the updated draft.  I'm reply to the -02 thread as you addressed my feedback from -01.  A few comments:

** Page 2 - 3, Section 1.  Editorial.  I like the three bullets from [REPORT] because they make the problem concrete. I worry that in a few years those specific numbers (e.g., 100 Gbps) will appear dated.  While helpful, I don't think they are needed.

** Page 3, Section 1, Paragraph 3, "The proposed mechanism ...".  The text only discusses coordination "within the same network".  The DOTS use cases are broader than that to include coordination between different networks.

** Page 4, Section 3.  The second paragraph describes how the client talks to the relay that talks to the server that does the mitigation.  IMO, this text needs to be caveated that this is just one of many possible arrangements.  The requirements terminology tells us that clients can talk to servers directly; and that not all servers are mitigators.  Furthermore, in the description of the "DOTS client periodically queries the server ... check[s] the counter ...", is not found in the use case document.  For example, in Section 4.1.1 of the use-case document, step (f), it is the server that "regularly transmit[s] DOTS mitigation status messages".  Likewise, there is no reference to the counters.

** Page 5.  Section 4.  Editorial.  I have no issue with the discussion of RFC6555.  However, in terms of the flow of the text, I felt prematurely tossed into the conversation about IPv4 DTLS vs. IPv6 when I first read this section.  I didn't read that we're talking about DOTS signaling until page 6.  I would recommend providing more intro on the order of "DOTS signaling can happen with DTLS and TLS ..."

** Page 6, Bullet 5, "... client may want to probe the server to ensure it has maintained cryptographic state."  Is that a requirement that should be in the requirements draft?  I also didn't read about this probe in Section 5 or 6.

** Page 7, Section 5.1.  This introductory section would benefit for further description of what it means to request mitigate service.  The sub-section headers "{Convey, recall, retrieve} DOTS signal" confused me with their generic names.  In contrast, the filtering behavior described under 5.2.1 used more specific names "{Install, Remove, Retrieve} filtering rules".

** Page 8, Section 5.1.1, How does the DOTS server decline a mitigation request?  With which response code?

** Page 8, Section 5.1.1, What does a 200 response code mean?  Beyond "success", is it that the DOTS server has accepted the mitigation request and will try to mitigate the activity?  I'd clarify the language here.

** Page 8, Section 5.1.  With the caveat that this draft didn't explicitly state that it's mapping against draft-ietf-dots-use-cases-00, in cross walking the two drafts, I don't see certain protocol elements described by the use cases.  Specifically: 
-- Use Case Section 4.1.1, step (f): "... DOTS servers regularly transmit DOTS mitigation status updates"
-- Use Case Section 4.1.1, step (g): "... mitigators [DOTS clients] may optionally ... transmit DOTS mitigation efficacy updates to ... server"
-- Use Case Section 4.1.1, step (i): "... DOTS server transmit a DOTS mitigation status update to the ... mitigators [DOTS clients] to indicate that the DDOS attack has ceased"

Furthermore, the current use cases suggest that the DOTS server initiates or sends status back to the client under various circumstances.  As I read this draft, the communication appears to be client initiated.  Draft-moskowitz-dots-gre-00 also stated the needed for peer-to-peer communication.

In fairness, none of this use-case behavior is currently in the requirements draft against which you are mapping.

** Page 10, Section 5.2, I don't understand the title of this section, "REST"?

** Page 10, Section 5.2, Is the overview of the DOTS relay behavior described in this section also applicable to "Mitigation Service requests" too?  If so, I'd recommend generalizing some of this text and putting it earlier or later in the draft.

** Page 10, Section 5.2. Editorial.  This section notes that content is in JSON.  However, JSON examples have already been used to explain the protocol since Section 5.1.  Perhaps move the introduction to the format of the HTTP body earlier.

** Page 12, Section 5.2.1.1, "The relative order of two rules is determined by comparing their respective policy identifiers ... The rule with [a] lower numeric policy identifier values has higher precedent."  This guidance makes sense relative to this section.  However, recall earlier in Section 5.1.1, "policy-id ... [is] used as an opaque identifier by the server".  If the magnitude of policy-id is now being checked, the identifier isn't opaque.  While we're dealing with different message types, I'd recommend against defining an identically named field differently.

Regards,
Roman

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Tirumaleswar
> Reddy (tireddy)
> Sent: Tuesday, February 09, 2016 11:17 PM
> To: [email-masked]
> Subject: [Dots] FW: New Version Notification for draft-reddy-dots-transport-
> 02.txt
> 
> Hi all,
> 
> This update to the draft includes the following changes.
> 
> * Proposes HappyEyeballs mechanism to convey DOTS signal
> * Addresses comments from the WG.
> * (D)TLS protocol profile to reduce delay to convey DOTS signal
> 
> Comments and suggestions are welcome.
> 
> -Tiru
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 10, 2016 9:28 AM
> To: Prashanth Patil (praspati); Dan Wing (dwing); Mike Geller (mgeller);
> Robert Moskowitz; Mohamed Boucadair; Tirumaleswar Reddy (tireddy)
> Subject: New Version Notification for draft-reddy-dots-transport-02.txt
> 
> 
> A new version of I-D, draft-reddy-dots-transport-02.txt has been successfully
> submitted by Tirumaleswar Reddy and posted to the IETF repository.
> 
> Name:		draft-reddy-dots-transport
> Revision:	02
> Title:		Co-operative DDoS Mitigation
> Document date:	2016-02-09
> Group:		Individual Submission
> Pages:		17
> URL:            https://www.ietf.org/internet-drafts/draft-reddy-dots-transport-
> 02.txt
> Status:         https://datatracker.ietf.org/doc/draft-reddy-dots-transport/
> Htmlized:       https://tools.ietf.org/html/draft-reddy-dots-transport-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-reddy-dots-transport-02
> 
> Abstract:
>    This document discusses mechanisms that a DOTS client can use, when
>    it detects a potential Distributed Denial-of-Service (DDoS) attack,
>    to signal that the DOTS client is under an attack or request an
>    upstream DOTS server to perform inbound filtering in its ingress
>    routers for traffic that the DOTS client wishes to drop.  The DOTS
>    server can then undertake appropriate actions (including, blackhole,
>    drop, rate-limit, or add to watch list) on the suspect traffic to the
>    DOTS client, thus reducing the effectiveness of the attack.
> 
> 
> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 11 Mar 2016 05:50:55 +0000

Hi Roman,

Thanks for the detailed review. Please see inline

> From: Roman D. Danyliw [mailto:[email-masked]]
> Sent: Tuesday, March 08, 2016 9:03 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> Subject: RE: [Dots] FW: New Version Notification for draft-reddy-dots-
> transport-02.txt
> 
> Hi Tiru!
> 
> (Chair hat off ...)
> ** Page 2 - 3, Section 1.  Editorial.  I like the three bullets from [REPORT]
> because they make the problem concrete. I worry that in a few years those
> specific numbers (e.g., 100 Gbps) will appear dated.  While helpful, I don't
> think they are needed.

Yes, removed text.

> 
> ** Page 3, Section 1, Paragraph 3, "The proposed mechanism ...".  The text
> only discusses coordination "within the same network".  The DOTS use cases
> are broader than that to include coordination between different networks.

Yes, updated text to clarify that the DOTS client and DOTS server may or may be located in the same administrative domain.

> 
> ** Page 4, Section 3.  The second paragraph describes how the client talks to
> the relay that talks to the server that does the mitigation.  IMO, this text
> needs to be caveated that this is just one of many possible arrangements.

Yup, updated draft.

> The requirements terminology tells us that clients can talk to servers directly;
> and that not all servers are mitigators.  

Added text to clarify that the DOTS client can directly talk to the server or via the DOTS relay.

> Furthermore, in the description of the
> "DOTS client periodically queries the server ... check[s] the counter ...", is not
> found in the use case document.  For example, in Section 4.1.1 of the use-
> case document, step (f), it is the server that "regularly transmit[s] DOTS
> mitigation status messages".  Likewise, there is no reference to the counters.

Section 4.1.1 of the use-case document is for DOTS signal, but the counters discussed in this section is for the data channel protocol
explained in the requirements draft https://tools.ietf.org/html/draft-ietf-dots-requirements-00#section-2.3. 
Step (f) needs more discussion, unsolicited response sent by the DOTS server indicating the mitigation status message could be lost and
DOTS client will not know if the server has sent the mitigation status. DOTS client can periodically query the DOTS server to learn the mitigation status and if no response is received then re-transmit the query.

> 
> ** Page 5.  Section 4.  Editorial.  I have no issue with the discussion of
> RFC6555.  However, in terms of the flow of the text, I felt prematurely tossed
> into the conversation about IPv4 DTLS vs. IPv6 when I first read this section.  I
> didn't read that we're talking about DOTS signaling until page 6.  I would
> recommend providing more intro on the order of "DOTS signaling can
> happen with DTLS and TLS ..."

Added intro.

> 
> ** Page 6, Bullet 5, "... client may want to probe the server to ensure it has
> maintained cryptographic state."  Is that a requirement that should be in the
> requirements draft?  I also didn't read about this probe in Section 5 or 6.

Probes can be sent using DTLS heartbeat and hence not discussed in Section 5 and 6. 
Yes, It is already explained in the requirement draft (OP-003).

> 
> ** Page 7, Section 5.1.  This introductory section would benefit for further
> description of what it means to request mitigate service.  The sub-section
> headers "{Convey, recall, retrieve} DOTS signal" confused me with their
> generic names.  In contrast, the filtering behavior described under 5.2.1 used
> more specific names "{Install, Remove, Retrieve} filtering rules".

Added the following lines to this section: 
POST request is used to convey the DOTS signal from a DOTS client to a DOTS server over the signal channel, possibly traversing a DOTS relay, indicating the DOTS client's need for mitigation, as well as the scope of any requested mitigation. DELETE request is used by the DOTS client to withdraw the request for mitigation from the DOTS server. GET request is used by the DOTS client to retrieve the DOTS signal(s) it had conveyed to the DOTS server.

> 
> ** Page 8, Section 5.1.1, How does the DOTS server decline a mitigation
> request?  With which response code ?

5xx will be the error code returned, updated draft.

> 
> ** Page 8, Section 5.1.1, What does a 200 response code mean?  Beyond
> "success", is it that the DOTS server has accepted the mitigation request and
> will try to mitigate the activity?  I'd clarify the language here.

Yes, clarified the language.
NEW:
Response code 200 (OK) will be returned in the response if the DOTS server has accepted the mitigation request and will try to mitigate the attack.

> 
> ** Page 8, Section 5.1.  With the caveat that this draft didn't explicitly state
> that it's mapping against draft-ietf-dots-use-cases-00, in cross walking the
> two drafts, I don't see certain protocol elements described by the use cases.
> Specifically:
> -- Use Case Section 4.1.1, step (g): "... mitigators [DOTS clients] may
> optionally ... transmit DOTS mitigation efficacy updates to ... server"
> -- Use Case Section 4.1.1, step (i): "... DOTS server transmit a DOTS mitigation
> status update to the ... mitigators [DOTS clients] to indicate that the DDOS
> attack has ceased"
> 
> Furthermore, the current use cases suggest that the DOTS server initiates or
> sends status back to the client under various circumstances.  As I read this
> draft, the communication appears to be client initiated.  

Yes, we plan to update the draft to explain how the client can periodically query and learn the mitigation status from the DOTS server.

> Draft-moskowitz-
> dots-gre-00 also stated the needed for peer-to-peer communication.
> 

I don't think Section 4.1.1, step (g) is discussed in the requirement draft, will discuss with my co-authors and update the requirements draft. Requirement (OP-005) covers Section 4.1.1, step (f) and step (i).

> ** Page 10, Section 5.2, I don't understand the title of this section, "REST"?

Changed title to " Protocol for Data Channel"

> 
> ** Page 10, Section 5.2, Is the overview of the DOTS relay behavior described
> in this section also applicable to "Mitigation Service requests" too? 

Yes.

>  If so, I'd
> recommend generalizing some of this text and putting it earlier or later in the
> draft.

Done.

> 
> ** Page 10, Section 5.2. Editorial.  This section notes that content is in JSON.
> However, JSON examples have already been used to explain the protocol
> since Section 5.1.  Perhaps move the introduction to the format of the HTTP
> body earlier.

Fixed.

> 
> ** Page 12, Section 5.2.1.1, "The relative order of two rules is determined by
> comparing their respective policy identifiers ... The rule with [a] lower
> numeric policy identifier values has higher precedent."  This guidance makes
> sense relative to this section.  However, recall earlier in Section 5.1.1, "policy-
> id ... [is] used as an opaque identifier by the server".  If the magnitude of
> policy-id is now being checked, the identifier isn't opaque.  While we're
> dealing with different message types, I'd recommend against defining an
> identically named field differently.

Fixed.

-Tiru

> > Subject: [Dots] FW: New Version Notification for
> > draft-reddy-dots-transport- 02.txt
> >
> > Hi all,
> >
> > To: Prashanth Patil (praspati); Dan Wing (dwing); Mike Geller
> > (mgeller); Robert Moskowitz; Mohamed Boucadair; Tirumaleswar Reddy
> > (tireddy)
> > A new version of I-D, draft-reddy-dots-transport-02.txt 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
> >