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 +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com