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

["Mortensen, Andrew" <[e-mail]>]

Thanks, Dave. This is very helpful. My (extremely tardy) responses are inline. I’ve snipped most of the minor rephrasing suggestions. All comments are me speaking for myself, not necessarily for the other requirements draft editors.

I’ve opened issues on github for most of these comments.

On Nov 26, 2016, at 9:31 PM, Dave Dolson <[e-mail]<mailto:[e-mail]>> wrote:

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

I don’t want the document to restrict the definition of countermeasure, but I’m also not keen to enshrine specific types of countermeasure, either. I’ll revise to make it clearer.

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.

Speaking for myself, the “channel” distinction is meant to distinguish the unreliable, lightweight SOS messages to be used when under attack from the reliable messaging required to e.g. manage filters and resource aliases. The “signaling session” in the architecture document is active messaging between DOTS agents over 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?

It sounds like you’re really asking whether we should leave the definition of “filtering” up to the DOTS server/mitigator. I worry that leaving “filtering” loosely defined will lead to confusion further down the line. I think we need explicit actions: discard is very different from rate-limit.

As I see it, filtering is distinct from vendor extensions which might include countermeasure specifics. I don’t think DOTS is a general purpose interface for countermeasure configuration.

Similarly for “Blacklist”: is block the only valid action for black-listed addresses?

Yes, that’s the distinguishing characteristic of a blacklisted source. A whitelisted source is always allowed to pass. The DOTS client has full control over the black-/white-lists, though the scope is restricted by the DOTS server to prefixes/resources belonging to the DOTS client.

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?

I think (a) is correct, though ignoring a request without providing a reason when a service agreement is in place seems like a poor way to manage a service. In general a DOTS request for mitigation should result in mitigation, assuming business or service agreements are in place, but mitigating the attack might involve more than just a

In calling DOTS “advisory” I was trying to emphasize two points: the difficulty of maintaining reliable messaging under attack conditions (with the corollary that a DOTS server may not be able to help even if a request gets through); and the fact that DOTS is not a general purpose mitigation API.

Maybe I should clarify that further. I believe the DOTS *signal channel* is not a general purpose mitigation API. The DOTS data channel could evolve into that as a sort of DOTS control protocol, in which the impact of an attack on the communication layer between client and server is not a concern.

(My thinking is that a DOTS server may know better than the client based on a wider source of telemetry.)

Agreed. Once a mitigator begins filtering traffic bound for the domain of the DOTS client, the DOTS client’s view into the attack is skewed.


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

This has become more important since you suggested it, in light of the recent thread on telemetry. draft-reddy-dots-signal-channel is suggesting 500 bytes in the event the client can’t discern path MTU. I’m comfortable with text to the effect that clients SHOULD try to determine path MTU, and fall back to 500 bytes if it can’t be discovered.


In 2.2,
… snip ...
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?”

I meant this to be less restrictive than what you’ve described. There should be some way for the DOTS client to detect that its messages are being received/processed or lost, and the same is true for the DOTS server. That doesn’t have to mean an HTTP-like model. For example, in the protocol draft Nik Teague and I have put together, the signal channel is ongoing, periodic communication between client and server. The client does not need to send a separate message to ask about request status, since the DOTS server will send it in a few seconds anyway.

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

The full phrase is “MUST cease mitigation as quickly as possible”, by which I meant to express the importance of allowing the server to maintain the mitigation for a short period to reduce the impact of a DOTS client rapidly toggling mitigation. It sounds like the duration of that short period needs to be defined.

I think two things should be clear in the final text:

1) The DOTS client can cease to be the cause for a mitigation at any time by sending a mitigation termination request, but cannot consider a mitigation terminated until confirmation from the server. (Mitigation lifetime is there to handle the cases where the server’s confirmation is not delivered.)

2) Once a DOTS client tells a DOTS server to stop mitigating, the DOTS client is no longer responsible for the mitigation. The DOTS server/mitigator can continue mitigating arbitrarily, but after the mitigation termination grace period elapses and the client hasn’t renewed a request for mitigation, all responsibility for the mitigation is borne by the DOTS server domain.

OP-006. I would like to see all of specific scopes precisely defined as required or optional, but not as examples.

Yes, this is a good suggestion.

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?

It’s not DNS name filtering, but indicating which FQDNs need mitigation.


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.

This is a fair counterpoint. “Act for the overall good” is unfortunately not concrete enough for a requirement. Cases like two DOTS clients requesting mitigation for the same resources are easy to handle—the server just lets the losing client know mitigation is already in progress—but partially overlapping mitigation requests are harder to handle. Does the server notify each client that the actual mitigation scope is larger than originally requested?


2.5  - Data model requirements
I’m not sure what to make of this section. I think I just want to review the data model.

I’m comfortable just removing this section. With Flemming's draft apparently evolving more toward information model, do we need to discuss data model at all outside of the solutions drafts?

andrew