Re: [Dots] Martin Duke's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)

[[e-mail]]

Hi Martin,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Martin Duke via Datatracker [mailto:[e-mail]]
> Envoyé : mercredi 2 juin 2021 00:40
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Martin Duke's No Objection on draft-ietf-dots-rfc8782-bis-
> 07: (with COMMENT)
> 
> Martin Duke has entered the following ballot position for
> draft-ietf-dots-rfc8782-bis-07: No Objection
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/
> 
> 
> 
> --------------------------------------------------------------------
> --
> COMMENT:
> --------------------------------------------------------------------
> --
> 
> Thank you for addressing Michael Tuexen's TSVART review.
> 
> As I did not review RFC8782, I'm taking this opportunity to review
> the entire document, rather than just the bis. I found numerous
> clarity issues:

[Med] It is always valuable to have fresh eyes to review. So, thanks! 

> 
> (4.4.1.1) How do DOTS servers detect a CUID collision? I believe
> Sec. 7 explains this is based on client authentication, but
> mentioning it here would be helpful.

[Med] We do already have the following at the end of 4.4.1.1:

   In both DOTS signal and data channel sessions, the DOTS client MUST
   authenticate itself to the DOTS server (Section 8).  The DOTS server
   MAY use the algorithm presented in Section 7 of [RFC7589] to derive
   the DOTS client identity or username from the client certificate.
   The DOTS client identity allows the DOTS server to accept mitigation
   requests with scopes that the DOTS client is authorized to manage.

Do you prefer if this text is mentioned earlier? 

> 
> In the "mid" definition: s/no attack is detected/no attack is
> underway

[Med] The OLD wording is more appropriate as an attack may be underway but not detected. 

> 
> In the "target_fqdn" definition. The text appears to assume a DNS
> resolution; is there a not a use case where the DOTS server would
> rely on e.g. SNI inspection and not defend an entire IP address that
> had multiple domains?

[Med] The resolution is needed for scope validation and conflict handling purposes. That's said, nothing prevents the mitigator to use the name to put in place application-specific countermeasures. We don't call out those as RFC8811 sets the scope as follows: 

   The scope of the DOTS specifications is the interfaces between the
   DOTS client and DOTS server.  The interfaces to the attack target and
   the mitigator are out of scope of DOTS.  Similarly, the operation of
   both the attack target and the mitigator is out of scope of DOTS.
   Thus, DOTS specifies neither how an attack target decides it is under
   DDoS attack nor does DOTS specify how a mitigator may actually
   mitigate such an attack.  

> 
> "lifetime" definition: The text says the DOTS server MAY reject
> unlimited lifetime, which implies that it MUST accept any finite
> lifetime.

[Med] No. This text is about the behavior when indefinite lifetime is requested. The full text is as follows:

      A lifetime of negative one (-1) indicates indefinite lifetime for
      the mitigation request.  The DOTS server MAY refuse an indefinite
      lifetime, for policy reasons; the granted lifetime value is
      returned in the response.  DOTS clients MUST be prepared to not be
      granted mitigations with indefinite lifetimes.

In all cases, it is the server who decides about the actual lifetime:

      The DOTS server MUST always indicate the actual lifetime in the
      response and the remaining lifetime in status messages sent to the
      DOTS client.

This is indicated also in the refresh request: 

   For a mitigation request to continue beyond the initial negotiated
                                                   ^^^^^^^^^^^^^^^^^^
   lifetime, the DOTS client has to refresh the current mitigation
   ^^^^^^^^ 
   request by sending a new PUT request.

 I presume you mean to say that DOTS servers are free to
> set a policy limit on the maximum allowable lifetime?

[Med] That's one implementation option. Other options would be:
* honor any finite lifetime but set a max only when indefinite lifetime is requested. 
* Use a max value for requested finite lifetimes and another max if indefinite lifetime is requested   

We don't include such details as these are implementation- and deployment-specific. 

> 
> (4.4.1.2) "cdid" definition: The example in Fig. 9 does not have a
> cdid that matches the cuid.

[Med] Which is OK.


 The text indicates that these might not
> match if a client-side gateway added the cdid,

[Med] The client-domain gateways do not insert the cdid. What we say is the following:

      The 'cdid' generated by a server-domain
      gateway is likely to be the same as the 'cuid' except the case
      in which the DOTS message was relayed by a client-domain DOTS
      gateway or the 'cuid' was generated by a rogue DOTS client.

Please note that the text talks about "relayed" not "inserted". If a request is relayed by a client-domain gateway, the cuid that will be presented by the client is != from the cdid that will be generated by the server-domain gateway. This is because the client certificate != the client-domain gateway certificate. 

 but then later says
> that "only the first on-path server-domain DOTS gateway can  insert
> a 'cdid' value." After reading this a few times, I think what you
> are saying is (a) clients MUST NOT add cdid;
> (b) client-side gateways SHOULD add them;

[Med] Actually no because such information is not trusted: 

      DOTS servers MUST ignore 'cdid' attributes that are directly
      supplied by source DOTS clients or client-domain DOTS gateways.

 (c) the first server-side
> gateway MUST strip them and then add their own; and (d) subsequent
> server side gateways MUST NOT change the cdid. Is this correct?
> Either way, it could be expressed less confusingly.

[Med] I'm not sure a modification is needed because I suspect the confusion came from interpreting "relayed" as "inserted".

Please let us know if any enhancement is needed. Will be more than happy to consider it. Thanks.   

> 
> (4.4.1.3) Fig. 11: Where does the second cuid come from? Is this
> generated by the server on behalf of the client? If so, I recommend
> s/a new request with a new 'cuid'/a new request with a new, server-
> provided 'cuid'

[Med] The new cuid is generated by the client as per the following in Section 4.4.1.1: 

      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.  Upon receipt of that error code, a new 'cuid'
      MUST be generated by the DOTS peer (e.g., using [RFC4122]).

> 
> When extending the lifetime, does the new lifetime field measure
> from the initial trigger or from the moment of extension?

[Med] The latter. FWIW, the description of "lifetime" includes the following: 

      Upon the expiry of this lifetime, and if the
      request is not refreshed, the mitigation request is removed.  The
      request can be refreshed by sending the same request again.

That is, the lifetime will be decremented till it reaches 0 (i.e., expire). That’s why we have: 

   For a mitigation request to continue beyond the initial negotiated
                                        ^^^^^^
   lifetime, the DOTS client has to refresh the current mitigation
   request by sending a new PUT request.  This PUT request MUST use the
   same 'mid' value, and it MUST repeat all the other parameters as sent
   in the original mitigation request apart from a possible change to
   the 'lifetime' parameter value.  In such a case, the DOTS server MAY
   update the mitigation request, and a 2.04 (Changed) response is

"possible change" is used here to cover the case where the client decides to use adjust the lifetime as a function of the mitigation operations (e.g., use long lifetime).

 If the
> former, a change in the lifetime value is mandatory, not
> "potential." If the latter, how does the server distinguish this
> from a duplicate request?

[Med] This is done at the CoAP level (Message ID, in particular). FWIW, this is reminded in the document:

   As a reminder, the Message ID
   (Section 3 of [RFC7252]) is changed each time a new CoAP request is
   sent, and the Token (Section 5.3.1 of [RFC7252]) is randomized in
   each CoAP request.

> 
> (4.4.2) Fig. 14 uses a string to represent the status instead of one
> of the values in Table 3.

[Med] That figure is correct because:

(1) Section 4.4 says the following: 

   JSON encoding of YANG modeled data [RFC7951] is used to illustrate
   the various methods defined in the following subsections.  Also, the
   examples use the Labels defined in Sections 10.6.2, 10.6.3, 10.6.4,
   and 10.6.5.

(2) enum values are mapped to string (JSON). 

   +---------------------+--------------+------+-------------+--------+
   | Parameter Name      | YANG Type    | CBOR | CBOR Major  | JSON   |
   |                     |              | Key  | Type &      | Type   |
   |                     |              |      | Information |        |
   +=====================+==============+======+=============+========+
   | status              | enumeration  | 16   | 0 unsigned  | String |


> 
> (4.4.3) Same with Fig. 16 and Table 4.

[Med] Idem as previous one. 

> 
> (4.4.2.1) If updates are non-confirmable, how does the client know
> if it's gotten out of sync on state updates?

[Med] The client can follow 4.4.2.2:

   The DOTS client can send the GET request at frequent intervals
   without the Observe Option to retrieve the configuration data of the
   mitigation request and non-configuration data (i.e., the attack
   status).  DOTS clients MAY be configured with a policy indicating the
   frequency of polling DOTS servers to get the mitigation status.

> 
> (4.5.1) What is the unit of probing rate?

[Med] bytes/second. This is indicated, e.g., in the YANG module: 

       leaf current-value {
         type uint16;
         units "byte/second";
         default "5";
         description
           "Current probing-rate value.";
       }

I updated 4.5.1 to mention it there as well. Thanks.

> 
> (8) s/should/SHOULD, s/must/MUST throughout.
> 

[Med] We don't use the normative language here as this is redundant with what is in Section 7.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.