Re: [Dots] AD review of draft-ietf-dots-requirements-15

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

Hi Ben. I’ve got a preliminary revision addressing your feedback up on GitHub:

Formatted text:
<https://raw.githubusercontent.com/amortensen/dots-requirements/mortensen_ad_feedback/draft-ietf-dots-requirements.txt>

Diff:
<https://github.com/amortensen/dots-requirements/commit/b58ca2609e79a9d230e94d4b174c82135f6f52be#diff-605866c1e67988414cce30d3d5d4d454>

The one thing I haven’t yet addressed is what to do with the black/whitelist terminology. It’s used *very* lightly in the requirements draft. I think we could quickly alter the text to use the term “filters” everywhere black/whitelist are used, e.g., DATA-004 becomes “Filter management”.

andrew



On Oct 16, 2018, at 1:49 PM, Benjamin Kaduk <[e-mail]<mailto:[e-mail]>> wrote:

[EXTERNAL EMAIL]

I had intended to cc the WG list on this; sorry I missed it at the time.
Andrew, do you expect to be able to prepare an update?

Thanks,

Ben

On Mon, Oct 08, 2018 at 09:56:01AM -0500, Benjamin Kaduk wrote:
Hi all,

Thanks for the fine document, and sorry for the processing delay -- the
timing interacted poorly with my travel schedule.

I just have some editorial notes that it would be nice to fix before we send
this out for broader review; I'll list them section-by-section.

Section 1.1

  A standardized method to coordinate a real-time response among
  involved operators will increase the speed and effectiveness of DDoS
  attack mitigation, and reduce the impact of these attacks.  This
  document describes the required characteristics of protocols that
  enable attack coordination and mitigation of DDoS attacks.

"protocols that enable attack coordination" can be read as if we are
generating DDoS attacks, which is probably not the intention.

Section 1.2

RFC 8174 has updated BCP 14 boilerplate; proactively changing to use it
will save lots of reviewers from pointing this out.

  Mitigator:  An entity, typically a network element, capable of
     performing mitigation of a detected or reported DDoS attack.  The
     means by which this entity performs these mitigations and how they
     are requested of it are out of scope.  The mitigator and DOTS
     server receiving a mitigation request are assumed to belong to the
     same administrative entity.

It may be best to avoid an unqualified "out of scope" and be clear about if
it's out of scope for this document, for the WG, etc.

  DOTS signal:  A concise authenticated status/control message
     transmitted over the signal channel between DOTS agents, used to
     indicate the client's need for mitigation, as well as to convey
     the status of any requested mitigation.

Is the message itself authenticated in addition to the authentication
provided by the signal channel?  It might be confusing to mention
authentication in both places if it's just the channel providing
authentication.

Also, I would suggest to s/as well as/or/, since (presumably) a single
message can do just one or the other.

  Data channel:  A bidirectional, mutually authentication communication
     channel between two DOTS agents used for infrequent but reliable
     bulk exchange of data not easily or appropriately communicated
     through the signal channel under attack conditions.

This definition left me wondering whether the data channel is supposed to
function during attack conditions (i.e., if the attack condition rendered
the signal channel unusable for this purpose, so the data channel was
created to still work under attack conditions).  The rest of the document
seems to clarify that the data channel is not expected to be useful during
attack conditions, so perhaps this could be clarified here.

  Blacklist:  A list of filters indicating sources from which traffic
     should be blocked, regardless of traffic content.

  Whitelist:  A list of filters indicating sources from which traffic
     should always be allowed, regardless of contradictory data gleaned
     in a detected attack.

I note without further comment that there was recently a long thread on
[e-mail]<mailto:[e-mail]> about potentially offensive terminology, which included both
of these words as examples.

Section 2

  The DOTS protocol must at a minimum make it possible for a DOTS
  client to request aid mounting a defense, coordinated by a DOTS
  server, against a suspected attack, signaling within or between
  domains as requested by local operators. [...]

This sentence has a lot of commas that breaks up the flow trying to read
it.  It could perhaps be split into two, as

% The DOTS protocol must at a minimum make it possible for a DOTS
% client to request aid mounting a defense against a suspected attack.
% This defense could be coordinated by a DOTS server and include signaling
% within or between domains as requested by local operators.

  [...]
  clients need to justify withdrawing help requests: the decision is
  local to the DOTS clients' domain.  Multi-homed DOTS clients must be
  able to select the appropriate DOTS server(s) to which a mitigation
  request is to be sent.  The method for selecting the appropriate DOTS
  server in a multi-homed environment is out of scope.

(same comment about "out of scope").

  DOTS protocol implementations face competing operational goals when
  maintaining this bidirectional communication stream.  On the one
  hand, DOTS must include protections ensuring message confidentiality,
  integrity and authenticity to keep the protocols from becoming
  additional vectors for the very attacks it is meant to help fight
  off.  [...]

It's probably worth including freshness/replay protection in this list.

Section 2.1

  GEN-001  Extensibility: Protocols and data models developed as part
     of DOTS MUST be extensible in order to keep DOTS adaptable to
     operational and proprietary DDoS defenses.  Future extensions MUST
     be backward compatible.  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.

No change specifically needed, but I'll note that using a version number
mostly precludes using individual per-feature tags to indicate feature
support.  It's okay for a WG to be making such a design choice at this
point in the process; I'm just pointing out that it is something of a
design choice.

  GEN-002  Resilience and Robustness: The signaling protocol MUST be
     designed to maximize the probability of signal delivery even under
     the severely constrained network conditions caused by particular
     attack traffic.  [...]

The word choice "particular" makes it sound as if there is a specific
attack that the author has in mind, leaving the reader wondering what
attack that is.  It may be better to just remove the word entirely or give
some description of what attack type(s) are relevant.

  GEN-003  Bulk Data Exchange: Infrequent bulk data exchange between
     DOTS agents can also significantly augment attack response
     coordination, permitting such tasks as population of black- or
     white-listed source addresses; address or prefix group aliasing;
     exchange of incident reports; and other hinting or configuration
     supplementing attack response.

     As the resilience requirements for the DOTS signal channel mandate
     small signal message size, a separate, secure data channel
     utilizing a reliable transport protocol MUST be used for bulk data
     exchange.

(This could potentially also clarify if it's expected to be useful during
attack conditions.)

  GEN-004  Mitigation Hinting: DOTS clients may have access to attack
     details which can be used to inform mitigation techniques.
     Example attack details might include locally collected
     fingerprints for an on-going attack, or anticipated or active
     attack focal points based on other threat intelligence.  DOTS
     clients MAY send mitigation hints derived from attack details to
     DOTS servers, in the full understanding that the DOTS server MAY
     ignore mitigation hints.  Mitigation hints MAY be transmitted
     across either signal or data channel.  [...]

My colleagues on the IESG tend to ask questions when there are multiple
options permitted but no discussion of why one might prefer one option or
the other.  (That is, they prefer a single mandatory option for reasons of
protocol simplicity.)

Section 2.2

  SIG-002  Sub-MTU Message Size: To avoid message fragmentation and the
     consequently decreased probability of message delivery over a
     congested link, signaling protocol message size MUST be kept under
     signaling Path Maximum Transmission Unit (PMTU), including the
     byte overhead of any encapsulation, transport headers, and
     transport- or message-level security.
     DOTS agents SHOULD attempt to learn the PMTU through mechanisms
     such as Path MTU Discovery [RFC1191] or Packetization Layer Path
     MTU Discovery [RFC4821].  If the PMTU cannot be discovered, DOTS
     agents SHOULD assume a PMTU of 1280 bytes.  If IPv4 support on
     legacy or otherwise unusual networks is a consideration and PMTU
nit: "the PMTU"
     is unknown, DOTS implementations MAY rely on a PMTU of 576 bytes,
     as discussed in [RFC0791] and [RFC1122].

  SIG-003  Bidirectionality: To support peer health detection, to
     maintain an active signal channel, and increase the probability of
nit: "to increase"
     signal delivery during an attack, the signal channel MUST be
     bidirectional, with client and server transmitting signals to each
     other at regular intervals, regardless of any client request for
     mitigation.  Unidirectional messages MUST be supported within the
     bidirectional signal channel to allow for unsolicited message
     delivery, enabling asynchronous notifications between DOTS agents.

This sentence about unidirectional messages left me a bit confused on first
read, I think just because of the way it was phrased.  It's basically just
saying that the signal channel is not necessarily request/reply pairs, but
can include oneshot notification messages that don't get an
application-level reply (but could still get a transport-level ack), right?
I don't have any specific text suggestions here, and it's probably okay to
leave it as-is.  (I have no particular reason to think that other people
get confused in the same ways that I do, after all.)

  SIG-005  Channel Redirection: In order to increase DOTS operational
     flexibility and scalability, DOTS servers SHOULD be able to
     redirect DOTS clients to another DOTS server at any time.  DOTS
     clients MUST NOT assume the redirection target DOTS server shares
     security state with the redirecting DOTS server.  DOTS clients are
     free to attempt abbreviated security negotiation methods supported
     by the protocol, such as DTLS session resumption, but MUST be
     prepared to negotiate new security state with the redirection
     target DOTS server.

When redirection occurs, is it always within the same "authentication
domain"?  There are perhaps additional complications about authenticating
the two servers and the redirection action if they are managed by different
entities or the client will be using different credentials with them.

  SIG-006  Mitigation Requests and Status: Authorized DOTS clients MUST
  [...]
     The initial active-but-terminating period is implementation- and
     deployment- specific, but SHOULD be sufficiently long to absorb
     latency incurred by route propagation.  If the client requests
     mitigation again before the initial active-but-terminating period

Just to check my understanding: this new mitigation request serves only to
extend the current termination period, and so the client would have to make
yet another mitigation request after mitigation terminates?

     elapses, the DOTS server MAY exponentially increase the active-
     but-terminating period up to a maximum of 300 seconds (5 minutes).

"exponentially" requires specifying an exponent base -- is the period
doubling each request, increasing by a factor of 1.5, ...?

     After the active-but-terminating period elapses, the DOTS server
     MUST treat the mitigation as terminated, as the DOTS client is no
     longer responsible for the mitigation.


  SIG-008  Mitigation Scope: DOTS clients MUST indicate desired
     mitigation scope.  The scope type will vary depending on the
     resources requiring mitigation.  All DOTS agent implementations
     MUST support the following required scope types:

     *  IPv4 prefixes in CIDR notation [RFC4632]

I don't see why CIDR notation comes into play for the protocol itself; why
not just say "IPv4 prefixes" to match the "IPv6 prefixes" below?

     If there is additional information available narrowing the scope
     of any requested attack response, such as targeted port range,
     protocol, or service, DOTS clients SHOULD include that information
     in client mitigation requests.  DOTS clients MAY also include
     additional attack details.  DOTS servers MAY ignore such
     supplemental information when enabling countermeasures on the
     mitigator.

Is it implicit from this that the signal channel needs to provide some way
in which to convey this sort of structured data that makes the semantics
clear (as opposed to, say, implementation-defined)?

Section 2.3

  DATA-002  Data privacy and integrity: Transmissions over the data
     channel are likely to contain operationally or privacy-sensitive
     information or instructions from the remote DOTS agent.  Theft or
     modification of data channel transmissions could lead to
     information leaks or malicious transactions on behalf of the
     sending agent (see Section 4 below).  Consequently data sent over

It may be worth mentioning the risk of replay explicitly.

     the data channel MUST be encrypted and authenticated using current
     IETF best practices.  DOTS servers MUST enable means to prevent

Do we need to provide an extensible model or negotiation scheme for the
encryption/authentication algorithms, so that implementations can adapt as
best practices change?

     leaking operationally or privacy-sensitive data.  Although
     administrative entities participating in DOTS may detail what data
     may be revealed to third-party DOTS agents, such considerations
     are not in scope for this document.

  DATA-003  Resource Configuration: To help meet the general and signal
     channel requirements in Section 2.1 and Section 2.2, DOTS server
     implementations MUST provide an interface to configure resource
     identifiers, as described in SIG-007.  [...]

I think this is SIG-008, not SIG-007.

Section 2.4

  SEC-001  Peer Mutual Authentication: DOTS agents MUST authenticate
     each other before a DOTS signal or data channel is considered
     valid.  The method of authentication is not specified, but should
     follow current industry best practices with respect to any
     cryptographic mechanisms to authenticate the remote peer.

Authentication is great.  What model is used for making authorization
decisions?

  SEC-002  Message Confidentiality, Integrity and Authenticity: DOTS
  [...]
     In order for DOTS protocols to remain secure despite advancements
     in cryptanalysis and traffic analysis, DOTS agents MUST be able to
     negotiate the terms and mechanisms of protocol security, subject
     to the interoperability and signal message size requirements in
     Section 2.2.

I'd probably say "securely negotiate" just to avoid any questions.

  SEC-004  Authorization: DOTS servers MUST authorize all messages from
     DOTS clients which pertain to mitigation, configuration,
     filtering, or status.

Are there any message types left (that would not need authorization)?

Section 2.5

  DM-004  Mitigation Scope Representation: The data model MUST support
     representation of a requested mitigation's scope.  As mitigation
     scope may be represented in several different ways, per SIG-007
     above, the data model MUST be capable of flexible representation
     of mitigation scope.

Is "flexible" intended to encompass a generic extensibility to represent
new types of data and new semantics?

  DM-007  Acceptable Signal Loss Representation: The data model MUST be
     able to represent the DOTS agent's preference for acceptable
     signal loss when establishing a signal channel, as described in
     GEN-002.

Is this prefernce expressed as a threshold percentage of packet loss, a
timeout for keepalive messages, some other way, or we don't care?

Section 4

  Impersonation of either DOTS server or DOTS client could have

nit: "a DOTS server", "a DOTS client"

  Blocking communication between DOTS agents has the potential to
  disrupt the core function of DOTS, which is to request mitigation of
  active or expected DDoS attacks.  The DOTS signal channel is expected
  to operate over congested inbound links, and, as described in
  Section 2.2, the signal channel protocol must be designed for minimal
  data transfer to reduce the incidence of signal blocking.

"signal blocking" makes me think of an explicit firewall-like
functionality, whereas I think the threat here is more of an accidental
dropping of packets due to congestion and network elmeent overload.



Hopefully we can get a new rev out quickly and then I can request the IETF
Last Call!

Thanks to everyone for the good work that went into this document.

-Ben