Subject: Re: [Dots] draft-ietf-dots-requirements-00 questions/comments

From: Andrew Mortensen <[email-masked]>
Date: Sun, 1 Nov 2015 12:36:09 -0500

Thanks for the comments, Roman! My responses are [AM] inline.

> On Oct 30, 2015, at 9:01 PM, Roman D. Danyliw <[email-masked]> wrote:
> 
> Hello Andrew, Robert and Tiru!
> 
> [Note: This note is written as an individual contributor.  Chair hat off.]
> 
> Thanks again for preparing this initial WG draft of the requirements.  In reviewing draft-ietf-dots-requirements-00, I had the following questions and comments.
> 
> ** Page 3: Section 1.1: Overview: "To achieve this aim, the protocol must permit DOTS clients ... to set the scope of the mitigation ...; and supply summarized attack information and additional hints the ...".
> 	
> OP-006 aligns with the "set the scope of the mitigation".  DATA-004 aligns with the "summarized attack information".  My question is whether "summarized attack information" should be restricted to only white and black lists (DATA-004).  Do we need other attack information ("attack telemetry”)?

[AM] At the previous meeting and in subsequent mail threads, Chris Morrow has made a very strong case for treating any attack telemetry from the DOTS client as advisory [1]: 

	"Wrong information is almost always a distraction and time-wasting event for the upstream mitigation provider.”

I’m definitely in this camp, which is why I specified “additional hints” rather than telemetry per se. I meant the “summarized attack information” to be broad enough to encompass existing vendor needs. In contrast to attack telemetry, which gives the mitigating entity the DOTS client’s (possibly wrong) view of the attack, black- and white-listing involves absolutes: the DOTS client should be able to indicate that it *always* wants certain prefixes blocked or conversely always permitted.

[1] See the following from Chris:
	<https://mailarchive.ietf.org/arch/msg/dots/ZEpnWiZta1mfabIhUe68Q_nPs3Q>
	<http://mailarchive.ietf.org/arch/msg/dots/wIPaaLfbb3Zfj40a7kxhRd36EY4>
	<https://mailarchive.ietf.org/arch/msg/dots/dn0RA2_V-M0tOWCrMZTdQlJi6CI>
	
> ** Page 3: Terminology: I'm not sure where the canonical terminology list should be.  I noticed that draft-ietf-dots-use-case-00 includes a definition for "DDoS", "attack target" and "Countermeasure" not present in this draft.  It also defines "attack telemetry" and "mitigation" differently.

[AM] As Roland said, we’ll work on reconciliation for the next revisions.

> ** Page 6: General Requirements: G-004 and G-005 appear to only apply to the signal channel.  Since there is a Data Channel Requirements section (Section 2.3), it seems like there should be corresponding Signal Channel requirements one as well.  With G-003, "signaling protocol" is used to scope the requirement.  Is that the same as "signal channel" or "DOTS signal" (i.e., signal+data channel)?

[AM] Good points. DOTS signal/heartbeat are meant to be distinct from the data channel. Will discuss re-organization with co-editors.

> ** Page 7: G-006: In order for DOTS ... despite advancements in cryptanalysis ...".  I'd recommend a broader statement.  Minimally, "... despite advancements in cryptanalysis and traffic analysis”.
> 
> ** Page 7: G-007: " ... such as including a timestamp or sequence number in every heartbeat and signal sent between DOTS agents."  I would recommend removing this last clause.  IMO, it is too specific and implementation oriented.  The requirement articulated in the first part of the sentence is clear enough.
> 
> ** Page 7: G-008: This requirement appears to only apply to the Data Channel.  IMO, it would fit better in Section 2.3, the section for data channel requirements.
> 
> ** Page 7: G-008: "As the resilience requirements for DOTS mandate small ...".  I propose this sentence read "As the resilience requirements for the DOTS signal channel mandates ..." to highlight that the signal and data channels have different requirements.

[AM] Above all marked for update.

> ** Page 9: DATA-002: How is this requirement different than G-006?  It has more specificity on why integrity and confidentiality are important for the data channel, but it still just repeats that encryption and authentication is required.

[AM] I think only (and only potentially) different in form. Marked for removal.

> ** Page 10: DATA-003: How is this authentication clause of this requirement different than OP-002? DATA-003 does add an authorization requirement not present in OP-002.

[AM] Would emphasizing the authorization requirement address your concern?

> ** In considering the ancillary used cases in draft-ietf-dots-use-cases-00, OP-006 would likely cover at least some of the Provisioning Use Case (Section 4.2.2).  I didn't see a requirement covering the Registration Use Case (Section 4.2.1).

[AM] Marked for addition.

Thanks!

andrew