[secdir] SECDIR Review draft-ietf-dots-rfc8782-bis-05

[Donald Eastlake <[e-mail]>]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These reviews are primarily for the benefit of the Security ADs.
Document editors and WG chairs should treat these comments just
like any other last call comments.

The summary of the review is Ready with Issues.


Security:

I think the Security Considerations section is adequate in its
coverage but see below for some wording problems.

I did not review Sections 5 or 6.


Minor Issues / Nits:

General: I don't mean to be unduly harsh but I was put off by the
discursive and verbose style of this draft. On reading through, I get
the feeling that the same thing is often said more than once,
sometimes with different levels of detail, sometimes with different
terminology, sometimes in consecutive sentences and sometimes in
different parts of the draft; however, the numerous examples are
generally a good thing.

General/Global: All six occurrences of "as a reminder" should be
deleted from the draft. They just add useless words.

General: There are lots and lots of default/recommended configuration
values scattered around the draft. It might be useful to have a table
or list of them all, perhaps as an Operational Considerations section
or appendix.


Section 1: Draft says "The DOTS server may (not) be co-located with
the DOTS mitigator."  This appears to be a particularly confusing way
of saying "The DOTS server may or may not be co-located with the DOTS
mitigator." to which wording I would suggest changing.


Section 3:

Suggest wording change for clarity from
   DOTS clients and servers behave as CoAP endpoints.  By default, a
   DOTS client (or server) behaves as a CoAP client (or server).
   Nevertheless, a DOTS client (or server) behaves as a CoAP server (or
   client) for specific operations such as DOTS heartbeat operations
   (Section 4.7).
to
   DOTS clients and servers behave as CoAP endpoints.  By default, a
   DOTS client behaves as a CoAP client and a DOTS server behaves as
   CoAP server. However, for specific operations such as DOTS heartbeat
   operations (Section 4.7), a DOTS client or server may behave as
   the opposite type of CoAP endpoint.


In the text below from the draft, the parenthesis and wording just
seem to muddle things and create doubt as to the meaning:
   In deployments where multiple DOTS clients are enabled in a network
   (owned and operated by the same entity),
I think it would be clearer and easier to understand (assuming I
understood it correctly) as:
   In deployments where multiple DOTS clients are enabled in a network
   with the clients and network owned and operated by the same entity,

Should "must" be capitalized in the following draft text?
   Future DOTS extensions that request a CBOR value in the range
   "128-255" must support means similar to the aforementioned DOTS
   telemetry ones.


Section 4.4.1:

The following draft text uses "the trailing "=" " which implies that a
base 64 encoding ends with exactly one equal sign. But I believe there
can be zero, one, or two equal signs. I suggest the following:
OLD
         The truncated output is
         base64url encoded (Section 5 of [RFC4648]) with the trailing
         "=" removed from the encoding, and the resulting value used as
         the 'cuid'.
NEW
         The truncated output is
         base64url encoded (Section 5 of [RFC4648]) with any trailing
         equal signs ("=") removed from the encoding, and the
         resulting value used as the 'cuid'.


There is talk of greater/lesser mid values. Is that a ring arithmetic
comparison and if so should it reference [RFC182]?

Apparently pre-configured mitigation triggered by loss of the signal
channel are supposed to use mid's starting at zero but wrap around for
dynamic mitigation wraps to zero. Won't that cause conflicts?

On target-protocol, I suppose a reference to the IANA protocol
registry doesn't hurt but it seems to me that denial of service
traffic could use any protocol number, not necessarily one with a
specific definition. Maybe
OLD
      Values
      are taken from the IANA protocol registry [IANA-Proto].
NEW
      Values are integers in the range of 0 to 255. See [IANA-Proto]
      for common values.


Section 4.4.3: The section title and contents mis-use the word
"efficacy" standing by itself.  "efficacy" has a strong implication of
being how well something works, NOT how long it works unless there is
some additional word or words such as "period of effectiveness" or
"effective for a week".  As an example, "efficacy" for a vaccine is
how well it work to block the disease after the full course of
vaccination has been given. People use completely different words when
talking about how long a vaccine's protection lasts. In this particular
section, I recommend simply replacing all occurrences of "efficacy"
with "lifetime".

Section 4.4.3: Figure 16 seems to show a string value for
attack-status but Table 4 has only integer values?


Section 4.4.4: I suggest just removing the part of the sentence after
the "," in the following draft text because it just makes the sentence
longer and a little confusing:
   Once 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.


Section 4.5: Point a: The two sentences on Heartbeat interval are
parallel and slightly inconsistent. Suggest simply deleting the first
sentence.


Section 4.6: Suggested wording change to cut down on verbiage:
OLD
   If a DOTS server wants to redirect a DOTS client to an alternative
   DOTS server for a signal session, then the Response Code 5.03
   (Service Unavailable) will be returned in the response to the DOTS
   client.

   The DOTS server can return the error Response Code 5.03 in response
   to a request from the DOTS client or convey the error Response Code
   5.03 in a unidirectional notification response from the DOTS server.
NEW
   To redirect a DOTS client to an alternative DOTS server for a
   signal session, the server can return the Response Code 5.03
   (Service Unavailable) to the DOTS client or the server can return
   that Response Code in a notification response to the client.

Section 4.6: Suggest replacing "can" with "MAY" or "SHOULD" in the
following draft text:
   Requests issued by misbehaving DOTS clients that do not honor the TTL
   conveyed in the Max-Age Option or react to explicit redirect messages
   can be rejected by DOTS servers.


Section 7.3: Since the PMTU can change and could be lower that the
values suggested to be assumed in the first paragraph of Section 7.3,
it is essentially impossible to conform to the first sentence as
written. I suggest the following change:
OLD
   To avoid DOTS signal message fragmentation and the subsequent
   decreased probability of message delivery, DOTS agents MUST ensure
   that the DTLS record fits within a single datagram.
NEW
   To avoid DOTS signal message fragmentation and the subsequent
   decreased probability of message delivery, DOTS agents MUST NOT
   send datagrams exceeding the limits discussed in this Section.


Section 8: The following text says that a server only accepts messages
from a gateway, although this is immediately contradicted in the next
paragraph. I suggest the change indicated:
OLD
   a DOTS server only allows DOTS signal
   channel messages from an authorized DOTS gateway,
NEW
   only if a gateway is authorized does a DOTS server accept DOTS signal
   channel messages from it,


Section 8, Figure 30: Seems slightly misleading because it looks like
the link between the Guest and gateway is broken. But according to the
text, they did mutually authenticate. I would suggest moving the "X"
to indicate failure to just inside the DOTS gateway box where the link
from the client arrives at the gateway box.


Sections 10: If all references to [RFC8782] in a registry need to be
replaced with references to [this document], there is no need to list
all the occurrences in the registry. You can just tell IANA to do a
global replace.


Section 11:

I suggest the following change:
OLD
   For this attack vector
   to happen, the misbehaving client needs to pass the security
   validation checks by the DOTS server, and eventually the checks of a
   client-domain DOTS gateway.
NEW
   For this attack
   to succeed, the misbehaving client's messages need to pass the security
   validation checks by the DOTS server and, if they transit a DOTS
   gateway, the security checks of that gateway.

The way this sentence talks about moving around "mitigation efficacy"
reads very strangely to me. I suggest the following re-wording:
OLD
   A compromised DOTS client can collude with a DDoS attacker to send
   mitigation request for a target resource, get the mitigation efficacy
   from the DOTS server, and convey the mitigation efficacy to the DDoS
   attacker to possibly change the DDoS attack strategy.
NEW
   A compromised DOTS client can be commanded by a DDoS attacker to
   abuse mitigation requests for a target resource. This could use the
   "mitigation" abilities of the DOTS server for the benefit of the
   attacker possibly leading to a changed and more effective DDoS
   attack strategy.

Here is another "MUST" that I think should be reworded because you
cannot guarantee conformance to the MUST. For example, the server
could have run out of state memory.
OLD
   That is, only actions on IP
   resources that belong to the DOTS client's domain MUST be authorized
   by a DOTS server.
NEW
   A DOTS server MUST NOT authorize actions due to a DOTS client
   request unless those actions are limited to that client's IP
   resources.


Miscellaneous observation: It's too bad that there seems to be
absolutely no coordination between DOTS and BGP flowspec.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]