Re: [Add] AD review of draft-ietf-add-dnr-08

["Eric Vyncke (evyncke)" <[e-mail]>]

Med,

I just had a look at https://raw.githubusercontent.com/boucadair/draft-btw-add-home-network/master/draft-ietf-add-dnr.txt and this version seems to address all the point of my AD review.

Please go forward and upload it 😊 Then, I can start the IETF last call on this DNR but also DDR & SVCB

Thank you

-éric


From: "[e-mail]" <[e-mail]>
Date: Friday, 24 June 2022 at 11:22
To: Eric Vyncke <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: AD review of draft-ietf-add-dnr-08

Re-,

Please see inline.

Cheers,
Med

De : Eric Vyncke (evyncke) <[e-mail]>
Envoyé : vendredi 24 juin 2022 10:57
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]
Objet : Re: AD review of draft-ietf-add-dnr-08

Hello Med,

Thank you for your reply and for some actions of yours. Please see below for EV>

Regards

-éric


From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 23 June 2022 at 11:40
To: Eric Vyncke <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: AD review of draft-ietf-add-dnr-08

Hi Éric,

Thank you for the review.

Please see inline.

Cheers,
Med

De : Add <[e-mail]<mailto:[e-mail]>> De la part de Eric Vyncke (evyncke)
Envoyé : jeudi 23 juin 2022 09:06
À : [e-mail]<mailto:[e-mail]>
Objet : [Add] AD review of draft-ietf-add-dnr-08

# Éric Vyncke, INT AD, comments for draft-ietf-add-dnr-08
CC @evyncke

Thank you for the work put into this document.

As usual, as the responsible AD for the ADD WG, I have done an AD review before the IETF Last Call. Please find a MD-formatted review below. Before going further, I am requesting the authors to act/reply/comment on all the points below. The end goal is to ease the rest of the publication process.

Regards,

-éric

## COMMENT

### 6MAN review of the RA option

The document shepherd write-up is explicit about the DHC WG review but what about the 6MAN review of the RA options ? Suggest to be clear in the doc shepherd document about this point, even if only writing "6MAN WG was not consulted" (then I will make it clear for the IETF last call).

[Med] I confirm that we solicited 6man + reach out individuals to seek feedback on the RA part.

EV> This would be nice to add in the doc shepherd review. Anyway, I will keep this in my mind when starting the IETF last call.
EV> OTOH, I only see https://mailarchive.ietf.org/arch/msg/ipv6/qeSwxWBoPTOs0fzyaSBzUC2g-sc/ which was about a specific point of the DNR I-D and not about the full RA option.

### "DNS Server" could be ambiguous

The abstract, the introduction, and possibly other sections use "local DNS server" while I think that the authors' intent was rather "local recursive DNS server". If this is the case, then suggest changing the wording.

[Med] We are using the generic term “DNS server” on purpose as the options can also be used to discover forwarders. The subtleties between the various modes are covered in RFC8499. That’s why we have: “This document makes use of the terms defined in [RFC8499<https://datatracker.ietf.org/doc/html/rfc8499>].“

EV> I appreciate that forwarders are in scope. But RFC 8499 does not define « DNS server » so this reference does not help.
EV> Therefore, I strongly suggest using a wording such as « DNS server (i.e., recursive resolver or forwarder) » in the abstract and add some text in the introduction stating that « DNS server » covers both recursive resolver and forwarder.

[Med] As you can see in the diff (https://tinyurl.com/latest-dnr-changes), I went with Dave’s proposal.

### Section 3.1 flow

```
   In order to allow for PKIX-based authentication between a DNS client
   and an encrypted DNS server,
```
While the above text is correct, the reader has only the explanation later. Suggest to change the flow to ease the reader's task.

[Med] Can you please indicate the change you have in mind? Thanks.


### Section 3.1 ADN

"ADN" is not expanded at first use.

[Med] This was already expanded in the introduction.

EV> good point, I failed to spot it ;-)

### Section 3.1 Global IPv4 address

```
   This IP address can be a
   private IPv4 address, a link-local address, a Unique Local IPv6
   unicast Address (ULA), or a Global Unicast Address (GUA).
```
What about global IPv4 address ? The wording seems to indicate an exhaustive list while it is not. What about anycast ?

[Med] The text you quoted was in reference to a specific example: “For example, a router embedding a recursive server or a forwarder has to include one single IP address pointing to one of its LAN-facing interfaces”. For such a case, the LAN-facing address is typically a private IPv4 address. The case of public (which includes anycast) is covered by this text in Section 5.1:

==

Both private and

      public IPv4 addresses can be included in this field.
==

EV> I still find it slightly confusing though. Could you rephrase into “E.g., This IP address can be a ...”
[Med] ACK. As the previous sentence starts also with “For example”, I went with this wording in the candidate version: “Typically, this IP address can be a..”

### Section 3.1 round-robin

```
   If multiple IP addresses are to be returned in an Encrypted DNS
   option, these addresses are ordered in the preference for use by the
   client.
```
Should there be a recommendation somewhere for a round-robin to spread the load ?

[Med] We don’t include such aspects as that is more about selection than discovery.


### Section 3.1 RECOMMENDED vs. MUST vs. SHOULD

```
   At least the following service
   parameters are RECOMMENDED to be supported by a DNR implementation:
```
While "dohpath" is obviously applicable only to DoH, should the normative language be more than "RECOMMENDED", a "MUST" or "SHOULD" seems at the right level for "alpn" and "port" at least.

[Med] As you know, RECOMMENDED is equivalent to SHOULD. That’s said, we can’t use MUST for all the parameters because, for example, the support of ECH is not justified for the typical home case.

EV> what annoys me is that some parameters (alpn) are MUST and not only RECOMMENDED/SHOULD
[Med] We can split this into two sets: one with MUST and another with recommended. See the suggested text in the diff.

Later in `returning an ADN only can be considered` suggest using a 'MAY'

[Med] This is about configuration/use, not implementation support.

Beware that these changes are important and will need to be run again through the WG during the IETF Last Call.

### Section 4.1 reference to dnsop-svcb ?

```
      Service Parameters (SvcParams) (variable length):  Specifies a set of
      service parameters that are encoded following the rules in
      Section 2.1 of [I-D.ietf-dnsop-svcb-https].  Service parameters
```
is it section 2.1 (zone file) or section 2.2 (wire format)?

[Med] I confirm: 2.1. Particularly, this part:

==

  SvcParams are a

   whitespace-separated list, with each SvcParam consisting of a

   SvcParamKey=SvcParamValue pair or a standalone SvcParamKey.
==

EV> I still have doubts, but I will trust the authors on this one

### Section 5.1 example

To be consistent with section 4.1, please also use a figure similar to figure 2 rather than the existing figure 5.

[Med] Added a new sentence to refer to the example in Figure 2 and removed figure 5.


### Section 5.1 address length

```
   Addr Length:  Indicates the length of included IPv4 addresses in
      octets.  It MUST be a multiple of 4 for ServiceMode.
```
Unsure what "for ServiceMode" has to do here... Should it be removed ?

[Med] Because in the ServiceMode, an IP address must be returned. We don’t have that constraint for the ADN-only mode (as no address is returned).

EV> ack, thanks

### Section 6.1 address length

```
   Addr Length:  Indicates the length of included IPv6 addresses in
      octets.  It MUST be a multiple of 16 for ServiceMode.
```
Unsure what "for ServiceMode" has to do here... Should it be removed ?
[Med] Idem as above.

### Section 6.2

What happens when multiple RAs are received ? Either from different routers or from the same router ?

[Med] That’s covered by this text:

==

In addition, the host

   follows the procedure described in Section 5.3.1 of [RFC8106]<https://datatracker.ietf.org/doc/html/rfc8106#section-5.3.1> with

   the formatting requirements in Section 6.1<https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr#section-6.1> substituted for the length

   validation.
==


Section 5.3.1 of 8106 says the following:

==

   In the case where the DNS information of RDNSS and DNSSL can be

   obtained from multiple sources, such as RAs and DHCP, the IPv6 host

   SHOULD keep some DNS options from all sources.
==

EV> except that RFC 8106 only applies to the RDNSS RA option and not to the DNR RA options. So, it is required, IMHO, to repeat the text.
[Med] The intent here is to leverage on the RFC8106 procedure for processing the encrypted DNS options rather than repeating it. I edited the text to make this clear (please see the diff). Hope this is better.

### Section 7.4 PSK

"pre-shared key", may I assume it is the WPA PSK ? Please be specific.

[Med] OK, updated the text to clarify this. Thanks.


### Section 7.4 station-to-station

If not mistaken (but I am far from being a IEEE 802.11 expert), the AP can be configured to prevent all station-to-station conversations, which will stop many of the above attacks. If confirmed, then suggest to mention it.

[Med] Will double check. Thanks.


### Section 8.3

"DNS Encrypted DNS Option" or "Encrypted DNS Option" ?

[Med] Fixed. Thanks.


_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.