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

[[e-mail]]

Hi Éric, 

Thank for the comments. Much appreciated. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:[e-mail]]
> Envoyé : lundi 31 mai 2021 11:51
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Éric Vyncke's No Objection on draft-ietf-dots-rfc8782-bis-07:
> (with COMMENT)
> 
> Éric Vyncke 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 the work put into this document.
> 
> As I already reviewed the original RFC 8782, I have only review the
> diffs (thanks to RFCDIFF!).
> 
> Please find below some non-blocking COMMENT points (but replies would
> be appreciated).
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 3.1 --
> In "that follow the present specification", the use of "present" is
> ambiguous:
> does it mean current implementations of RFC 8782? or this
> specification (i.e., this I-D) ?

[Med] The full text is: 

   For both legacy and implementations that follow the present
   specification

"present spec" means "this document" while "legacy" refers to 8782. 

We can change it to the following if this would help: 

   For both legacy [RFC8482] and implementations that follow the present
   specification

> 
> -- Section 4.4.1.3 --
> I wonder why a port number can be used if the case of common/shared
> URI ? In "A list of port numbers may also be included if there is a
> common IP address, IP prefix, FQDN, URI, or alias."

[Med] This can be returned, for example, when a new request specifying an IP address + port overlaps with an existing request with a target-uri. 

> 
> -- Section 5.3 --
> I am not a YANG module expert but using a union for 'lifetime' just
> to allow a
> -1 value to signal infinity looks a little weird to me. Could the
> value 0x7fffffff be used for 'infinity' and keeping a uint32 ?

[Med] We considered several options at that time: 0, large number, or -1. We went for -1 as 0 can mean 'ends now' while 'large number' is still finite for "purists".  

The use of "union" is OK to make match the yang spec with the intended usage: a valid value can be "-1" or any uint32.

Please note that using a large number would impact the following CBOR mapping entry...

   | lifetime            | union        | 14   | 0 unsigned  | Number |
   |                     |              |      +-------------+--------+
   |                     |              |      | 1 negative  | Number |

... which would then break the constraint we set for the bis:

  "These
   modifications are made with the constraint to avoid changes to the
   mapping table defined in Table 5 of [RFC8782] (see also Section 6)."

> 
> In probing-rate.current-value, there is a default value of 5
> byte/second. Is it useful to recommend such a default value ?

[Med] This is to align the YANG module with this part in Section 4.5.2:

      |  Absent any explicit configuration or inability to
      |  dynamically adjust 'probing-rate' values (Section 4.8.1 of
      |  [RFC7252]), DOTS agents use 5 bytes/second as a default
      |  'probing-rate' value. 

> 
> More generically, I wonder whether measuring in octets/second is more
> suitable than in bits/second.

[Med] I think you are referring to "bps-dropped" attribute. It is actually in bytes per second as statement in Section 4.4.2: 

   bps-dropped:  The average number of dropped bytes per second for the
      mitigation request since the attack mitigation was triggered.

However when checking the YANG description, I guess that you were confused with the following:  

 "The average number of dropped bits per second for
                                ^^^^
  the mitigation request since the attack
  mitigation was triggered.  This should be over
  five-minute intervals (that is, measuring bytes
                         ^^^^^^^^^^^^^^^^^^^^^^^^
  into five-minute buckets and then averaging these
  buckets over the time since the mitigation was
  triggered).";

The text is updated as follows: 

NEW:
 "The average number of dropped bytes per second for
                                ^^^^^
  the mitigation request since the attack
  mitigation was triggered.  This should be over
  five-minute intervals (that is, measuring bytes
  into five-minute buckets and then averaging these
  buckets over the time since the mitigation was
  triggered).";

Thank you for catching this.

> 
> The 'alt-server' is now better typed as 'inet:domain-name'

[Med] This is to better reflect the description in the core text: 

   alt-server:  FQDN of an alternate DOTS server.
                ^^^^

 but I now
> wonder whether relying solely on DNS in a case of DoS is sensible.

[Med] The name can be supplied to any available name resolution library. For the particular case of DNS, we say the following:

   During a DDoS attack, the DNS server may be the target of another
   DDoS attack, the alternate DOTS server's IP addresses conveyed in the
   5.03 response help the DOTS client skip the DNS lookup of the
   alternate DOTS server, at the cost of trusting the first DOTS server
   to provide accurate information. 

As a side note, the name will also be used for authentication purposes. 

_________________________________________________________________________________________________________________________

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.