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

[Benjamin Kaduk <[e-mail]>]

Thanks, Med.

Please go ahead and upload a -14 if you get the chance; most of the IESG
will not start reviewing (for next week's telechat) until the end of this
week.

-Ben

On Tue, Oct 27, 2020 at 07:25:06AM +0000, [e-mail] wrote:
> 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.
>