Reviewer: Dale Worley Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dots-rfc8782-bis-05 Reviewer: Dale R. Worley Review Date: 2021-03-22 IETF LC End Date: 2021-03-22 IESG Telechat date: unknown Summary: This draft is on the right track but has open issues, described in the review. I've provided a long list of minor editorial issues, and a short list of technical issues. I suspect that the technical issues have been resolved in the practices of the community and that their apparent status as problems stems from not getting the wording properly aligned with practice. Major issues: The condition of two DOTS mitigation requests overlapping depends on addresses (and alternatives to them) but as defined in section 4.4.1, does NOT depend on port numbers. However, other parts of the text seem to presume that port numbers are involved in testing for overlapping. The correct choice needs to be established and the text made consistent. Does the requesting of a mitigation only withdraw overlapping mitigations that were requested using the same signal channel, or is the effect global? If a mitigation request with trigger-mitigation = false is activated by ending of a signal channel, does reestablishing the channel withdraw it? (Naively I thought it would, but that isn't stated.) If so, how are the former and the current signal channels correlated, given that cuid collisions can prevent them from using the same common identifiers? Indeed, the text does not make it clear how a mitigation that is triggered by the ending of a signal channel can be withdrawn, other than by the expiration of its timer. Minor issues: The 4.09 response is used to report cuid conflicts, but also various other conflicts. Given that cuid conflicts require specific processing, and can happen when other conflicts could also be reported, it seems to me that for cuid conflicts, you want that the response MUST include conflict-information. In section 4.4.1 there is a discussion of a configuration where a client communicates through two different gateways to one same server using a different certificate to communicate with each gateway. The text discusses a configuration where we want the two transaction streams to be treated as one by the client and server. It seems to me that this is an unusual situation which can only succeed if both the client and server have specific configuration for it. As a consequence, the situation doesn't need to be discussed in this document. Conversely, the default result of this topology is that the client and server treat both transactions streams separately (and perhaps neither of them is aware of the overall topology). It seems like this case should work correctly without any special considerations, and so does not need to be documented specifically, either. The overall framework for signal channel configuration is not clear. By default, I assume that the client sets the channel configuration, constrained by the limits on parameter values imposed by the server, and that these values apply to communication in both directions (when applicable). The text in 4.5 and 4.5.1 is consistent with this model. However text in 4.5.2 talks about "agents" changing configuration values, which implies it's possible for the server to set channel configuration. There is discussion in section 4.5.3 of a server sending "a validity time with a configuration it sends", which makes no sense if only the client can change the configuration -- the configuration won't change until the client changes it. Also "the update of the configuration data if a change occurs at the DOTS server side". The model needs to be established, and the text aligned with it. Nits/editorial comments: Global editorial issues: There is a lot of special terminology, and it would help if definitions were gathered in section 2. Additionally, this would help reveal where the text uses undefined synonyms of defined terms, several cases of which I have spotted. There are issues involving "Observe". One is at the start of section 4.4, where the text refers to "subscribe", but that is not the term used in CoAP, indeed CoAP deliberately avoids that term. Also, unless one is familiar with CoAP, one thinks GET has no side-effects, and thus cannot possibly establish a subscription. There are related issues in sections 4.4.2.1 and 4.4.2.2 that left me wondering for which GET requests Observe was mandatory and/or permitted and what values (0 and/or 1) were permitted. I think it would help to start 4.4.2.1 with an overview discussion of the permitted/required uses of Observe in DOTS GET requests. It would help to have adjectives for a mitigation request with trigger-mitigation = false, and for a mitigation request with trigger-mitigation = true. It seems that "deactivating" a mitigation request is used as an undefined synonym of "withdrawing" it, but (on my first two reads), I thought it meant "delete". At this point, I suspect that the words hide complexity which has not been made explicit: the client "requests" a mitigation with trigger-mitigation = false, but the loss of the channel "activates" it. Worse, "activation" causes the actions that are described as being caused by "requesting" a mitigation with trigger-mitigation = true. A description of the states, the transitions between them, and the verbs to describe them should be given, perhaps in section 2. Section 4.4.1 is 16 pages long and really should be cut into a number of subsections. Section 4.4.1 contains two parallel but different definitions/discussions of conflict-information. Not being in a position to print the document, I can't quite make out what is going on, but I suspect some reorganization of the section is in order to replace the two partial definitions with one complete one. (This might be connected with the entries in section 9 and/or section 10.3.) The two parallel definitions are partially excerpted below, and both have the problem that the contextual text says that the response will include "enough information for a DOTS client to recognize ...", but the definition of conflict-information states that it is optional: ----- The response includes enough information for a DOTS client to recognize the source of the conflict as described below in the 'conflict-information' subtree with only the relevant nodes listed: conflict-information: Indicates that a mitigation request is conflicting with another mitigation request. This optional attribute has the following structure: ----- For both 2.01 (Created) and 4.09 (Conflict) responses, the response includes enough information for a DOTS client to recognize the source of the conflict as described below: conflict-information: Indicates that a mitigation request is conflicting with another mitigation request(s) from other DOTS client(s). This optional attribute has the following structure: ----- Detailed editorial issues: (Note that some of these are summarized in a clearer way above.) 1. Introduction The example of Figure 1 is introduced by this paragraph: An example of a network diagram that illustrates a deployment of DOTS agents is shown in Figure 1. In this example, a DOTS server is operating on the access network. A DOTS client is located on the LAN (Local Area Network), while a DOTS gateway is embedded in the CPE (Customer Premises Equipment). But the example also includes a DOTS gateway, and would have been clearer to me if the statement introducing DOTS gateways was made before the start of the example rather than after it: The DOTS client can communicate directly with a DOTS server or indirectly via a DOTS gateway. 3. Design Overview support for asynchronous Non-confirmable messaging It might be worth noting here or in section 2 that "Non-confirmable" (and "Confirmable") are CoAP technical terms. Absent such mutual agreement, the DOTS signal channel MUST run over port number 4646 as defined in Section 10.1, for both UDP and TCP. It might be worth stating this port number is for both the client and the server to use (or that 4646 is just the listening port for servers). Also, the DOTS server may rely on the signal channel session loss to trigger mitigation for preconfigured mitigation requests (if any). This doesn't carry quite the right idea. What is really going on is that the DOTS client may configure mitigation requests that will be automatically acted upon by the server if the signal channel session is lost. This is a required facility of the server, but it may be relied upon by the client. DOTS signaling can happen with DTLS over UDP and TLS over TCP. s/can happen/can use/ or perhaps "can happen over". In deployments where multiple DOTS clients are enabled in a network (owned and operated by the same entity) ... I think you want something like "In deployments with multiple DOTS clients in a single network and administrative domain ...". o Port Control Protocol (PCP) [RFC6887] or Session Traversal Utilities for NAT (STUN) [RFC8489] may be used to retrieve the external addresses/prefixes and/or port numbers. Would be clearer if it is "may be used by the client to retrieve ...", as the preceding paragraph is about the translator and here we are talking about the client without explicitly mentioning it. 4.4. DOTS Mitigation Methods GET: DOTS clients may use the GET method to subscribe to DOTS server status messages or to retrieve the list of its mitigations maintained by a DOTS server (Section 4.4.2). Unless one is aware of the "Observe" option of CoAP, using GET to establish a subscription seems impossible, as it is a side-effect. The reader could be warned by wording like: GET: DOTS clients may use the GET method to retrieve the list of its mitigations maintained by a DOTS server (Section 4.4.2), or (using the CoAP Observe option [RFC7641]) to subscribe to DOTS server status messages. -- Mitigation requests MUST NOT be delayed because of checks on probing rate (Section 4.7 of [RFC7252]). How does this sentence connect with the preceding sentences of the paragraph? Also, what does "probing" refer to? I suspect you mean that mitigation requests can be Non-confirmable and would by default fall under the rules of the preceding sentences, but you don't want that. So the sentence could be clarified as "However, mitigation requests MUST NOT be delayed by these limitations." 4.4.1. Request Mitigation with the trailing "=" removed from the encoding Should be 'the trailing two "="', 'the trailing "="s', or similar, since the base64 encoding of a string of 16 bytes will always end in two "=". DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer to notify that the 'cuid' is already in use by another DOTS client. The error code 4.09 has other defined uses in the signal channel. Given the special and "global" action needed based on this error code, there must be an unambiguous way for the client to identify cuid collision. Unfortunately, there is no "session initiation handshake" message for which a 4.09 response would be unambiguous. It seems like the best choice is to look for conflict-information in the response, since it has a conflict-cause value "CUID Collision". But conflict-information is optional. I recommend making conflict-information mandatory in this situation. However, see my comments at the end of the section regarding the lack of clarity whether conflict-information is mandatory or optional. If the 'mid' value has reached 3/4 of (2^(32) - 1) (i.e., 3221225471) and no attack is detected, the DOTS client MUST reset 'mid' to 0 to handle 'mid' rollover. It sounds like, but does not say explicitly, that mid rollover automatically invalidates any active high-mid mitigation request, and thus, if the client wants to maintain any existing request, it must recreate them (necessarily with small mid values). This needs to be clarified. The default value of the parameter is 'true' (that is, the mitigation starts immediately). If 'trigger-mitigation' is not present in a request, this is equivalent to receiving a request with 'trigger-mitigation' set to 'true'. The second sentence is completely redundant, but I suspect that a practical need for it has been discovered. ... or the 'cuid' was generated from a rogue DOTS client. Probably s/from/by/. But it seems that there is a valid situation where duplicate cuids are plausible, when two DOTS clients are using the same certificate to peer with a server because that certificate is what the server administrator provided to peer with the server. I don't know if that is worth mentioning here, though. If a DOTS client is provisioned, for example, with distinct certificates as a function of the peer server-domain DOTS gateway, distinct 'cdid' values may be supplied by a server- domain DOTS gateway. The ultimate DOTS server MUST treat those 'cdid' values as equivalent. I'm having a hard time following this, probably because I am not familiar with the language used to describe these situations. I think it means If a DOTS client is provisioned, for example, with distinct certificates to use to peer with distinct server-domain DOTS gateways that peer to the same DOTS server, distinct 'cdid' values may be supplied by the gateways to the server. The ultimate DOTS server MUST treat those 'cdid' values as equivalent. The final normative statement is clear, but it isn't clear to me how the server can implement that, unless it is provisioned with the knowledge that the two certificates are used by the same client. More subtly, if the server must treat them as equivalent, dependencies between transactions in one transaction stream apply to the union of the transaction streams through the two servers. E.g. the rule that mid is nearly-monotonic and the consequences thereof. Handling this correctly requires that the client knows that transactions through the two gateways will be handled equivalently by one same server, and that seems to require that the client also be configured with particular knowledge. It seems to me that there are actually two cases (1) a "dumb" case where the client happens to access the same server through two gateways, but neither the client nor the server knows that. In that case, the signal channel protocol "just works" normally. (2) a "smart" case where both the client and serve must know that access through the two gateways is considered equivalent (but the gateways do not need to know). In that case, as long as both the client and server agree on this equivalence, the signal channel protocol also "just works". It's not clear that it is necessary to document here the "smart" case, as the needed adjustments are logically determined by the intended use case. If it is not needed, the quoted paragraph is probably best omitted, because trying to implement it generally would tend to cause the "dumb" case to fail. If the mitigation request contains the 'alias-name' and other parameters identifying the target resources (such as 'target-prefix', 'target-port-range', 'target- fqdn', or 'target-uri'), the DOTS server appends the parameter values in 'alias-name' with the corresponding parameter values in 'target- prefix', 'target-port-range', 'target-fqdn', or 'target-uri'. This sentence is not connected with any other processing -- what use is the concatenated value put to? Also, the processing described will NOT be done if alias-name is not present, suggesting that in some way it is optional. Also, the phrase "the parameter values in 'alias-name'" is undefined, as alias-name is an opaque string value. I suspect that some aspect of the processing has not been described. Perhaps the meaning is that an alias is always configured as a set of values for the other parameters, and that if a request contains both an alias name and other parameters, the effective request is formed by merging the two sets of parameter values. Though if that is meant, some provision must be made for the situation where the alias gives a value for a parameter that is contradicted by an explicit parameter in the request. If the DOTS server does not find the 'mid' parameter value conveyed in the PUT request in its configuration data [it may interpret it in a certain way] It's not clear what is going on here, as "mid=..." is a mandatory part of the Uri-Path, and any such request must be rejected. A DOTS server could reject mitigation requests when it is near capacity or needs to rate-limit a particular client, for example. This should be a separate paragraph, as it applies more broadly than the conditions of the first sentence of the paragraph. Also, it probably merits s/could/MAY/. Two mitigation requests from a DOTS client have overlapping scopes if there is a common IP address, IP prefix, FQDN, URI, or alias. Probably worth stating explicitly that a common port number is NOT a factor in determining overlapping scopes. If the DOTS server receives a mitigation request that overlaps with an active mitigation request, but both have distinct 'trigger- mitigation' types, the DOTS server SHOULD deactivate (absent explicit policy/configuration otherwise) the mitigation request with 'trigger- mitigation' set to 'false'. I'm pretty sure I don't know what this means. What does "deactivate" mean? The first time I read it, I thought it meant "delete", The second time, I suspected it meant the opposite action of "activate", which is what happens to a trigger-mitigation = false mitigation when the signal channel is lost. The third time, I was wondering why the reestablishment of the signal channel didn't automatically cause the trigger-mitigation = false mitigation to be deactivated. conflict-scope: Characterizes the exact conflict scope. It may include a list of IP addresses, a list of prefixes, a list of port numbers, a list of target protocols, a list of FQDNs, a list of URIs, a list of aliases, or references to conflicting ACLs (by an 'acl-name', typically [RFC8783]). Note this text includes a "list of port numbers", but port numbers are not a factor in conflicts. Also, is it really intended that this parameter is, effectively, only human-readable, since there is no particular way to specify what type of datum the value contains? 4.4.2. Retrieve Information Related to a Mitigation +-----------+----------------------------------------------------+ | 4 | Attack has exceeded the mitigation provider | | | capability. | +-----------+----------------------------------------------------+ "mitigation provider" is used in a few places but it appears that the intended term is "mitigator". +-----------+----------------------------------------------------+ | 6 | Attack mitigation is now terminated. | +-----------+----------------------------------------------------+ It seems like code 6 includes codes 5 and 7. Is this ambiguity intended? I suspect the text that is actually wanted is "DOTS client has withdrawn the mitigation request and the attack mitigation is now terminated." There is a parallel issue in section 10.6.2. 4.4.2.1. DOTS Servers Sending Mitigation Status DOTS implementations MUST use the Observe Option for both 'mitigate' and 'config' (Section 4.2). It's not clear what "MUST use the Observe Option" means. Does it mean that clients MUST use it in GET requests for 'mitigate' and 'config'? If so, is the client allowed to use "Observe: 1", despite that this section only discusses the "Observe: 0" case? Or does it just mean that servers must implement it, and thus respond correctly if a client sends it? 4.4.2.2. DOTS Clients Polling for Mitigation Status In such case, the DOTS client recalls the mitigation request by issuing a DELETE request for this mitigation request (Section 4.4.4). The term "recall" is used in a few places but it seems like the correct term is "withdraw" (section 4.4.4). 4.4.3. Efficacy Update from DOTS Clients In what way is an "efficacy update" different from an "update"? Can "efficacy" be removed without loss, or is it a term of art for updates to mitigation requests sent during attacks? It appears that an update is an "efficacy update" if and only if "attack-status" is present. This should be stated at the beginning of the section, as otherwise it's a mystery what distinguishes "efficacy updates". 4.4.4. Withdraw a Mitigation Once the request is validated, the DOTS server immediately acknowledges a DOTS client's request to withdraw the DOTS signal using 2.02 (Deleted) Response Code with no response payload. s/DOTS signal/DOTS mitigation request/ 4.5. DOTS Signal Channel Session Configuration d. Acceptable signal loss ratio: Maximum retransmissions, retransmission timeout value, and other message transmission parameters for Confirmable messages over the DOTS signal channel. What are the names of these parameters in the signal-config structure? As such, the transmission-related parameters ('missing-hb-allowed' and acceptable signal loss ratio) are negotiated only for DOTS over unreliable transports. It seems this could be said more clearly by listing the permitted fields: "only the 'heartbeat-interval' parameter [or whatever] is negotiated for DOTS over reliable transports". 4.5.1. Discover Configuration Parameters At least one of the attributes 'heartbeat-interval', 'missing-hb- allowed', 'probing-rate', 'max-retransmit', 'ack-timeout', and 'ack- random-factor' MUST be present in the PUT request. Note that 'heartbeat-interval', 'missing-hb-allowed', 'probing-rate', 'max- retransmit', 'ack-timeout', and 'ack-random-factor', if present, do not need to be provided for both 'mitigating-config', and 'idle- config' in a PUT request. Must both the mitigating and idle configuration sections be present in the PUT? Does the requirement "At least one..." apply to both sections together or each section alone? If e.g. missing-hb-allowed is present in one section but not the other, the wording gives a vague suggestion that the same value is implicitly provided for the other section. Is this true? The PUT request with a higher numeric 'sid' value overrides the DOTS signal channel session configuration data installed by a PUT request with a lower numeric 'sid' value. To avoid maintaining a long list of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be automatically deleted and no longer available at the DOTS server. Does this mean that the PUT with the higher sid installs what values it provides on top of the current configuration, or does it mean that the previous PUT's effect is entirely removed, that is, parameters not given in the higher-sid PUT take their default values? Note that the latter is resistant to problems from lost PUT requests but the former is not. o If the DOTS server finds the 'sid' parameter value conveyed in the PUT request in its configuration data and if the DOTS server has accepted the updated configuration parameters, 2.04 (Changed) MUST be returned in the response. Given the earlier statement "'sid' values MUST increase monotonically (when a new PUT is generated by a DOTS client to convey the configuration parameters for the signal channel).", if a server receives a PUT with the same sid as a previous PUT then the client is misbehaving and the server should send an error response. A DOTS client may issue a GET message with a 'sid' Uri-Path parameter to retrieve the negotiated configuration. Does this sid value matter, or is only its presence important? Also, you probably want to expand this to "a GET message for 'config' with a 'sid' Uri-Path parameter ...". 4.5.3. Configuration Freshness and Notifications The underlying processing is not made clear. Roughly, it seems that the idea is the server has the right to change the configuration unilaterally at any time, but if the client does a GET of the configuration, the server is required to commit that it won't change the configuration given in the response within Max-Age Option seconds. Or is this talking about a mechanism where the server can, at its initiative, tell the client how the client should behave? Which is completely different from section 4.5.2 where the client tells the server how to behave. 4.5.4. Delete DOTS Signal Channel Session Configuration Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request to set the configuration parameters to default values. Such a request does not include any 'sid'. I would take it as assumed that when the (D)TLS connection is established, that is, when the DOTS signal channel session is initiated, it has the default configuration parameters. Thus the DELETE described here is guaranteed to have no effect. But perhaps the intention is that the signal channel is conceptualized as persisting longer than the (D)TLS connection, and (perhaps) associated with the cuid/cdid value. If so, that should be stated clearly. 4.6. Redirected Signaling 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. What is "the response"? It seems that this is only sensible if the session is just being established, but there doesn't seem to be a specific session-initiation message. If you really mean that the server can redirect the session in response to any request, it would be helpful to state that directly. Also, you need to specify whether the connection to the alternate server is a new session (with independent state) or whether it is expected to be a continuation of the existing session (carrying the same state). 4.7. Heartbeat Mechanism For example, if a DOTS client receives a 2.04 response for its heartbeat messages but no server-initiated heartbeat messages, the DOTS client sets 'peer-hb-status' to 'false'. The DOTS server then will ... There is a lot of detail left out here, as there are messages and events involved that are not mentioned explicitly. I think what is meant is "For example, if a DOTS client receives a 2.04 response for its heartbeat messages but no server-initiated heartbeat messages, the DOTS client sets 'peer-hb-status' to 'false' in its next heartbeat message. Upon receiving that message, the DOTS server then will ..." It might be useful to explicitly state that the bodies of responses to heartbeat requests are empty. 6. YANG/JSON Mapping Parameters to CBOR It might help the implementors to tell whether this is the same as section 6 of RFC 8782 or not. 10.1. DOTS Signal Channel UDP and TCP Port Number IANA has assigned the port number 4646 (the ASCII decimal value for ".." (DOTS)) ... Ow! [END] -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
