[Dots] AD Review of draft-ietf-dots-architecture-14

[Roman Danyliw <[e-mail]>]

Hello!

The following is my AD review of draft-ietf-dots-architecture-14:

** Section 1.2.  Per "In this architecture, DOTS clients and servers communicate using DOTS signaling ...", is this definition too narrow?  Per the guidance in Section 1.1.2 to use RFC8612 definitions, which says that "DOTS signal:  [is a] A status/control message transmitted over the authenticated signal channel ..." the text seems to ignoring the data channel.

** Section 1.2.  Along the same line, the next sentence, "As a result of signals from the DOTS client ...", seems to also present a very narrow example of what the signal channel might do (let alone the data channel).  I'm not sure how much this sentence adds to clarifying the scope as suggested by the section title.

** Section.  1.3 Per "The signal and data channels are loosely coupled, and may not terminate on the same DOTS server", it seems help to clarify the obvious that how these signals would be synchronized is out of scope.

** Section 2.  Figure 3.  Is this figure (i.e., the JSON example) normative?  This seems like a detail best left to the data channel spec (and omitted from this document).

** Section 2.  Per:
Note that while it is possible to exchange the above information
   before, during or after a DDoS attack, DOTS requires reliable
   delivery of this information and does not provide any special means
   for ensuring timely delivery of it during an attack.  In practice,
   this means that DOTS deployments should not rely on such information
   being exchanged during a DDoS attack.

It seems to me that there is guidance missing here.  If the first sentence says that this information can be exchanged before, during or after an attack, but don't count on it during the attack.  The second sentence reiterates the point that during an attack it will be unreliable, is a statement to the effect that necessary configuration must be made prior to the attack also needed?

** Section 2.1  Per "It is not until this point that the mitigation service is available for use.", this closing point about a mitigation service follows from the previous description.  However, I wanted to point out, the notion of a "mitigation service" being available after a fully configured DOTS client is not a construct previously used in the document or the terminology.  It's likely worth relating it to the previously defined terms like mitigator.

** Section 2.1.  To avoid confusion on terms (i.e., from HTTP), perhaps replace s/basic authorization/authorization/.

** Section 2.2.2.  Per "For a given DOTS client (administrative) domain, the DOTS server needs to be able to determine whether a given target  resource is in that domain.", what is a "target resource" isn't clear.  I think it is meant to be the resource that is the target of the attack (that the DOTS client is signaling about).  Also, the idea that DOTS clients have "domains" is a new concept here that needs clarification.

** Section 2.2.2. Per "The DOTS server enforces authorization of DOTS clients' signals for mitigation.", no objection.  Is there a complementary statement to make the data channel?

** Section 5.  Per "Any attacker with the ability to impersonate ...", this paragraph clearly describes in the impact of impersonation.  However, the suggested mitigations read like requirements.  Instead of trying to list them again, I would recommend explicitly citing the relevant requirements from Section 2.4 of the RFC8612 and noting that need for conformance to these security mechanisms.

** Section 5.  Per "Similarly, received data at rest SHOULD be stored with a satisfactory degree of security.", I would recommend explaining why the data should be secured. Perhaps:
OLD: 
Similarly, received data at rest SHOULD be
   stored with a satisfactory degree of security.

NEW (or something like it):
Similarly, as the received data may contain network topology, telemetry, threat, or preconfigured mitigation information which could be considered sensitive in certain environment, it SHOULD be protected at rest per required local policy.

** Section 5.  Per "As many mitigation systems employ diversion to scrub attack traffic, operators of DOTS agents SHOULD ensure DOTS sessions are resistant to Man-in-the-Middle (MitM) attacks.", I'm not following the link between the mitigation systems re-routing traffic with DOTS agents resisting MitM attack.  What actions should be agents be taking?

** Section 5.  Per:
   Any attack targeting the availability of DOTS servers may disrupt the
   ability of the system to receive and process DOTS signals resulting
   in failure to fulfill a mitigation request.  DOTS agents SHOULD be
   given adequate protections, again in accordance with best current
   practices for network and host security.

-- The first sentence talks about "DOTS servers".  The second talk about protecting "DOTS agents".  What's the role in the DOTS clients in this guidance?
-- Shouldn't the protections afforded to the DOTS agents be a mandatory (MUST)?

** Editorial Nits:
-- Section 1.  Editorial. s/for help defending/for help to defend/
-- Section 3.2.5.  Typo. s/deployements/deployments/