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

[[e-mail]]

Hi Erik,

Please see inline.

Cheers,
Med

De : Erik Kline [mailto:[e-mail]]
Envoyé : vendredi 4 juin 2021 02:46
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Erik Kline's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)


> [S4.4.1.1] [question]
>
> * For "lifetime" in the case where a "target-fqdn" was given, should
> the
>   resolution library's knowledge of the DNS RR TTL value(s) be
> factored in?
>
>   For example, what does lifetime=3600s mean for a hostname whose
> A/AAAA
>   RRs have only 5 minute lifetimes?  Is the DOTS server/enforcer
> expected
>   to continuously re-resolve every ${DNS_RR_TTL} and apply the
> policy for
>   up to the full 3600 seconds

[Med] Yeah. When possible, the client makes sure that the resolved addresses are valid during the mitigation lifetime. If a resolved address flushed out (e.g., DNS TTL expiry) while the mitigation is still active (pending lifetime!=0), the resolution library should be solicited.

As we don't impose any requirement on the name resolution library (and especially whether it exposes a validity timeout), I suggest the following change:

OLD:
      How a name is passed to an underlying name resolution library is
      implementation and deployment specific.  Nevertheless, once the
      name is resolved into one or multiple IP addresses, DOTS servers
      MUST apply the same validation checks as those for 'target-
      prefix'.

NEW:
      How a name is passed to an underlying name resolution library is
      implementation and deployment specific.  Nevertheless, once the
      name is resolved into one or multiple IP addresses, DOTS servers
      MUST apply the same validation checks as those for 'target-
      prefix'.  These validation checks are reiterated by the DOTS
      client each time a name is passed to the underlying name
      resolution library (e.g., upon expiry of DNS TTL).

Thanks for the explanation.  I *think* this text is good, except: isn't it the DOTS server reiterating the validation checks and not the DOTS client?
[Med] Yes, you are right. We have already fixed that in the published version: draft-ietf-dots-rfc8782-bis-08<https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-08>

Thank you.



_________________________________________________________________________________________________________________________

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.