Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-server-discovery-13: (with COMMENT)

[[e-mail]]

Hi Ben, 

An updated version is available at: https://tinyurl.com/dots-discovery-iesg 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk via Datatracker [mailto:[e-mail]]
> Envoyé : mardi 27 octobre 2020 03:07
> À : The IESG <[e-mail]>
> Cc : [e-mail]; dots-
> [e-mail]; [e-mail]; Valery Smyslov <[e-mail]>;
> [e-mail]
> Objet : Benjamin Kaduk's Yes on draft-ietf-dots-server-discovery-13:
> (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dots-server-discovery-13: Yes
> 
> 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 IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/
> 
> 
> 
> --------------------------------------------------------------------
> --
> COMMENT:
> --------------------------------------------------------------------
> --
> 
> Pulling in some follow-up from the directorate review comments...
> 
> Section 3
> 
>    o  Resolving a DOTS server domain name offered by an upstream
> transit
>       provider provisioned to a DOTS client into IP address(es)
> requires
>       the use of the appropriate DNS resolvers; otherwise, resolving
>       those names will fail.  The use of protocols such as DHCP does
>       allow associating provisioned DOTS server domain names with a
> list
>       of DNS servers to be used for name resolution.  Furthermore,
> DHCP
>       allows directly provisioning IP addresses therefore avoiding
> the
>       need for extra lookup delays.
> 
> I wonder if using "providing" rather than "provisioning" for at
> least the last instance would be more clear.

[Med] Works for me. 

> 
>    o  A resolution mechanism based on straightforward Naming
> Authority
>       Pointer (S-NAPTR) resource records in the Domain Name System
> (DNS)
>       (Section 6).
> 
> "Straightforward" needs to be capitalized here.

[Med] Fixed. Thanks. 

> 
> Section 4
> 
>    will support a local configuration.  More samples are discussed
> in
>    Section 3:
> 
> nit: s/:/./

[Med] OK.

> 
> Section 5
> 
>    The list of the IP addresses returned by DHCP servers is
> typically
>    used to feed the DOTS server selection procedure including when
> DOTS
>    agents are provided with primary and backup IP addresses of their
>    peer DOTS agents.  An example of DOTS server selection procedure
> is
>    specified in Section 4.3 of [RFC8782].
> 
> The referenced section in 8782 is about the "happy eyeballs", i.e.,
> picking between TCP/UDP and IPv4/IPv6 -- it doesn't really seem
> intended to cover the case where you have to pick betwen different
> actual nodes.

[Med] That text is about an example of address selection procedure (including between nodes: think about a dual stack host that receives both v4 and v6 config). It is useful as it refers (indirectly) to RFC6724 which allows for configuring a preference ... 

> 
> I'm also not sure how the "primary and backup" is intended to work,
> here.  Is the "provided with" referring to "by DHCP" or some out-of-
> band configuration?

[Med] ... I thought we had this already covered in the text, but it isn't. I added "The addresses are listed in the order of preference for use by the DOTS agent." so that a preference is signalled by the server to the a requesting DHCP client.

The primary will be listed first. 

> 
> Section 8.1
> 
>    configured name.  If the DOTS agent is instructed to trust
> subdomains
>    of the names in that list as well, a DOTS agent will also accept
> a
>    DHCP-discovered name if the left-most label of the discovered
> name is
>    matching a name in the pre-configured list.
> 
> If the agent is configured to trust subdomains of the configured
> list, then in the case where that configuration is relevant for the
> attack, the left-most label will be the (part of the) subdomain
> name, which is explicitly not matching the pre-configured list --
> the remaining bits are what match.
> 
[Med] Changed the wording as follows:

"If the DOTS agent is instructed to trust subdomains of the names in that list as well (e.g., "*.example.com"), a DOTS agent will accept a DHCP-discovered name that matches a name in the pre-configured list (e.g., "dots-1.example.com" or "dots-2.example.com")."


_________________________________________________________________________________________________________________________

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.