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

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 02 Jun 2021 23:09:02 -0700

Erik Kline 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:
----------------------------------------------------------------------

[S3] [comment]

* I don't know if it's really necessary to dredge up RFC 6296, but I
  understand the desire for completeness.

[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, or is the DNS RR TTL ignored once the
  resolution has been confirmed to have succeeded or failed?

---

From: <[email-masked]>
Date: Thu, 3 Jun 2021 08:16:51 +0000

Hi Erik, 

Thanks for the review.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Erik Kline via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 3 juin 2021 08:09
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Erik Kline's No Objection on draft-ietf-dots-rfc8782-bis-07:
> (with COMMENT)
> 
> 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.)
> 
> 

[Med] You got the intent about the completeness. The key point is that we are not recommending it, but just cite as one example where things may be broken. 

>   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).

, or is the DNS RR TTL ignored once the
>   resolution has been confirmed to have succeeded or failed?

_________________________________________________________________________________________________________________________

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.

---

From: Erik Kline <[email-masked]>
Date: Thu, 3 Jun 2021 17:45:39 -0700

> [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:

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?

---

From: <[email-masked]>
Date: Fri, 4 Jun 2021 07:21:02 +0000

Hi Erik,

Please see inline.

Cheers,
Med

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

OLD:

NEW:

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.