Subject: Re: [Dots] Questions/Comments on draft-ietf-dots-requirements-04 content --

From: "Mortensen, Andrew" <[email-masked]>
Date: Wed, 7 Jun 2017 03:28:13 +0000

Thanks again, Russ. My comments are inline.

> On May 29, 2017, at 8:45 PM, Russ White <[email-masked]> wrote:
> 
> Y'all -- this email contains questions and comments about the technical content of the requirements draft.
> 
> 😊 /r
> 
> ==
> GEN-001
> 
> It seems like this might solved with a version number system that requires older version to ignore newer information; this might an option to support this requirement, but it is not obvious from the text if so.

Updated to add:

    DOTS protocols MUST use a version number system to distinguish
    protocol revisions. Implementations of older protocol versions
    SHOULD ignore information added to DOTS messages as part of
    newer protocol versions.

> ==
> GEN-002
> 
> There is nothing here about error correction or delivery assurance -- should there be? This might be covered someplace else, but I've not seen it yet.

I’m don’t think error correction is something we want to tackle here. (FEC seems to have been removed from the IETF QUIC protocol draft, as well.)

We do anticipate packet loss due to link congestion, and describe DOTS as an advisory protocol in this and the architecture drafts.

> ==
> GEN-004
> 
> Why not set Do Not Fragment? Is the concern for performance on boxes, or ... ??

Altered requirement to cover PMTU discovery and fallback.

> ==
> OP-001
> 
> I would prefer to say "connectionless," to leave the door open for QUIC -- unless there is an intent to write a separate draft for DOTS transport over QUIC.

Changed to read:

	While connectionless transports such as UDP etc.

> ==
> OP-004
> 
> To protect against route or DNS flapping caused by a client rapidly toggling mitigation...
> 
> It seems another option here might be some form of exponential backoff, which might be more effective than a five minute rule. It might be worth studying and/or allowing both options.

This does seem overly specific in the current text. I’m reading your suggestion to use exponential backoff of the mitigation active-but-terminating duration, and have altered the text to reflect that.

> ==
> OP-008
> 
> Okay -- but should the servers try to merge the conflicting requests, ignore both of them, or... ? Notfying is good, but there seems to want to be some other action here, as well. 
> 
> Another issue -- what if multiple servers send conflicting requests to a single mitigator? This seems to warrant the same sort of text, along with some idea of what action should be taken.
> 
> ==
> 3.1 seems to conflict with OP-001, above -- in one place, UDP is "MAY," in the other, it seems to be "MUST." Which is accurate? Again, it seems wise to allow for QUIC, as well.

Updated to read as follows:

    As part of a protocol expected to operate over links affected by DDoS attack
    traffic, the DOTS signal channel MUST NOT contribute significantly to link
    congestion. To meet the signal channel requirements above, DOTS signal
    channel implementations SHOULD support connectionless transports.
    However, some connectionless transports when deployed naively can be a
    source of network congestion, as discussed in [RFC5405]. Signal channel
    implementations using such connectionless transports, such as UDP,
    therefore MUST include a congestion control mechanism.

andrew