Subject: [Dots] feedback on draft-ietf-dots-requirements

From: Dave Dolson <[email-masked]>
Date: Sun, 27 Nov 2016 02:31:46 +0000

Here are my comments from in-depth reading of the dots requirement draft.

1.1
I had trouble parsing "Once staggering attack traffic volume is now the norm" until I realized it should be hyphenated "Once-staggering"

1.2
To the list in "DDoS attack targets", can we add "network links" ? E.g., the target might not be a specific end-point, rather an entire organization's connection to the internet.

For definition of "DDoS attack telemetry", should the word "measurements" should be used?  "Collected measurements and behavioral characteristics..."

For "countermeasure", this sounds like only packet filtering. Is that accurate and complete? Could tar-pit or routing changes be included in countermeasures?

Is "signal channel" intended to be the same thing as the "session" mentioned in the architecture? I think so, and terminology should be made consistent between the docs. If not, I don't understand the difference between channel and session.

Should "Data channel" also be bidirectional an mutually-authenticated, like the signal channel?

Should "Filter" be limited to the two actions of rate-limiting or discarding?  Is filter really intended to include action, or just the match criteria?
Similarly for "Blacklist": is block the only valid action for black-listed addresses?

2.
The second paragraph says "DOTS is an advisory protocol." I thought this might mean that (a) a client's request for aid may be ignored and (b) mitigation may be done prior to request or after withdrawal. Would that idea be accurate?  (My thinking is that a DOTS server may know better than the client based on a wider source of telemetry.)

In 2.1,
- to GEN-002, I suggest adding that DOTS should be carried in a transport not susceptible to head-of-line blocking.

- is GEN-003 intended to be a statement about the transport protocol being bidirectional? E.g., on the same UDP connection. If so, please say so; otherwise it is probably OK.

- in GEN-004, consider picking a specific MTU size, like 500 bytes, because otherwise there is no way to judge if the protocol meets requirements.

In 2.2,
- in OP-002, we mandate session health monitoring, but we haven't so far mandated having a session, or what constitutes a session. So I think we need an OP-002a that mandates a session and how it shall be defined and maintained.
- In OP-003, can we choose whether security state is shared or whether a new state is negotiated after connection? Otherwise the client is left guessing, it seems.
Also, I don't know what is meant exactly by fate-shared security state. Please replace with a more precise description. (It sounds like if one fails the other should fail, but I can't believe you intended that.)

OP-004: This requirement has several ideas in it, which I think should be broken into multiple requirements:

(a)    The idea that messages be acknowledged with a status code.

-          But it is unclear whether the status must be delivered immediately, or reported later. I expect there could be an immediate "I hear your request", which doesn't necessarily mean anything can be done. There should be a way for the client to later ask, "how are you doing with that request?"

(b)   Whether the server MUST do as it is told.

-          On this point, I think the "MUST cease mitigation activity" is wrong, since the server may have other evidence or other clients requesting the mitigation. This is acknowledged by the "may continue mitigating" later in the paragraph. So at minimum the MUST is too strong.

OP-005. Instead of wording this as a requirement on the client, can we reword it as a requirement on the server?  E.g., "A DOTS server MUST be capable of accepting a mitigation lifetime, after which a mitigation request is removed if not refreshed."  This server perspective should be applied to all of the paragraphs.

OP-006. I would like to see all of specific scopes precisely defined as required or optional, but not as examples.
Let's argue about which scopes are mandatory or optional  (or extendable) at this requirements phase.
Also, I'm not clear on what DNS name filtering means: is this for filtering DNS packets, or for looking up the name and filtering the corresponding addresses?

OP-008. I hope there isn't going to be an argument about this, but... I believe it is not a client error to ask for a mitigation that conflicts with another client (how could it even know?). Rather, it is up to the server to weigh the various requests and act for the overall good. As paragraph 2 of section 2 says, "DOTS is an advisory protocol".
I don't even think an overlapping prefix range is an error; rather both clients have identified the same attack.

OP-009. I believe the idea is that the client may be behind a NAT, not the server? If the server might be behind a NAT, there will need to be a way to poke a hole in the NAT, either with uPnP or other means. Please make this clear.

Are there encryption or integrity requirements for the signal channel?

DATA-001. Could one phrase this as, DOTS must be sent over a transport with reliable in-order delivery?

DATA-004. In the last paragraph there is a hint that different clients own different address ranges. This idea needs to be better defined. It isn't clear to me that a DOTS client necessarily "owns" the addresses that it noticed requires mitigating. E.g., a relay doesn't own the addresses it is passing along mitigation requests about. Also, an organization might have different clients that can request mitigation for the same ranges, so we don't want mutually exclusive ownership.

In section 2.4, Security,

-          Authentication is described, but neither authorization nor auditing are mentioned. Regarding authorization, can different clients have different privileges/capabilities? Revocation of authorization is required too.  And auditing of requests seems like a good idea.

SEC-003  Does it need to prevent message replay, or merely make replay useless? E.g., replaying idempotent operations is OK.

2.5
I'm not sure what to make of this section. I think I just want to review the data model.

3.1 This sentence is unnecessary: "The form of that congestion control is implementation specific."

3.2 Why does the data channel require in-order message delivery? I think we need to know what the messages are before making that decision. Keep in mind that HTTP does not provide that.

David Dolson
Senior Software Architect
Sandvine