Re: [Dots] Genart last call review of draft-ietf-dots-server-discovery-12

[[e-mail]]

Hi Peter, 

Thank you for the review. 

An updated version with changes to address you review can be seen at: https://github.com/boucadair/draft-ietf-dots-discovery/blob/master/draft-ietf-dots-server-discovery-12.txt 

A diff is also available here: https://tinyurl.com/dots-discovery-peter 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Peter Yee via Datatracker [mailto:[e-mail]]
> Envoyé : lundi 19 octobre 2020 06:48
> À : [e-mail]
> Cc : [e-mail]; [e-mail];
> [e-mail]
> Objet : Genart last call review of draft-ietf-dots-server-discovery-
> 12
> 
> Reviewer: Peter Yee
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-dots-server-discovery-12
> Reviewer: Peter Yee
> Review Date: 2020-10-18
> IETF LC End Date: 2020-10-12
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document specifies several methods by which a DOTS
> agent may be discovered dynamically. The document has a few nits. It
> also places what may be an unreasonable burden on the need to obtain
> authentication credentials during an attack. [Ready with Issues]
> 
> Major issues: None
> 
> Minor issues:
> 
> Page 4, section 1, last paragraph: the assumption that a DOTS agent
> can obtain an authentication credential in the midst of an attack in
> order to authenticate to another DOTS agent (server) in order to
> obtain services seems odd.

[Med] There is no such assumption in the draft. That text is about what is required to pre-provisioned so that a discovered server can be used. Add "pre-" to that text to avoid confusion. 

 There are already provisions in this
> document to allow servers to be specified by IP address in order to
> reduce the need to hit the DNS for a name resolution. But it's
> considered reasonable to attempt a more complex protocol in order to
> obtain a credential that may well be server-specific?

[Med] The mechanisms used to provision the credentials are not the ones used to discover the reachability information (think about SIP and the like). We are following a similar model for DOTS and hence the current scope for discovery in the document.  

 I think more
> discussion should be given here, particularly to possible
> mitigations. One suggestion might be to perform DOTS service
> discovery periodically (while not under
> attack)

[Med] As indicated in Section 4, the discovery will be executed when "attach(ing) to a new network" (covers the bootstrapping case) and then reiterated upon expiry of a validity timer. Other triggers to reiterate the procedure is

 and obtain the credentials needed to access each discovered
> service.
> While the set of services that are discovered during an attack may
> not exactly match those discovered prior to the attack, the idea is
> that the need for obtaining credentials during an attack could be
> obviated for services that have not changed during the intervening
> period. Further considerations could include rediscovering services
> and obtaining new credentials as old ones expire.

[Med] As called in Section 4, rediscovery will be doesn't upon credentials expiry. 

> 
> Page 6, section 4, 1st paragraph, last sentence: I'd consider
> dropping this sentence. It presumes that operators do not know how
> to segregate their hosts between different configuration regimes
> (manual/static vs. dynamic). Operators might prefer to maintain
> different DOTS services for hosts on their networks and to configure
> them with a mix of methods.

[Med] This is exactly what this text is about. Anyway, reworded the text.  

 This is similar to networks with both
> fixed IP addresses and DHCP services. Operators are expected to deal
> with configuration correctly and prevent clashes.
> 
> Page 7, 1st paragraph after the number list, last sentence: I'd say
> "suitable"
> might be more suitable (sorry) than "proper". It's not that a
> device's DNS configuration may not be proper, but that it can't be
> modified for DOTS purposes. The device may perform all other DNS
> lookup functions for its primary purpose without issue and still not
> be able to use DNS for DOTS discovery purposes.

[Med] OK.

> 
> Page 11, section 5.1.3, 4th paragraph, 2nd sentence: neither RFC
> 8415 (section
> 10) or the sub-referenced RFC 1035 (section 3.1) gives information
> on "validating" a domain name. What is meant by the term
> "validating"?

[Med] The validation is about making sure that he encoding follows the one in 1035 and that no compression form is used.

> 
> Page 11, section 5.1.3, 6th paragraph: add a discussion of what
> happens if all addresses end up being discarded. It doesn't have to
> be terribly involved, but the case should be addressed. Do reference
> identifiers (as when both OPTIONS_V6_DOT_RI and
> OPTIONS_V6_DOTS_ADDRESS are present) then need to be treated as
> names to be resolved?
> 

[Med] Rearranged the text so that one about validating addresses is discussed first. The discussion will then be whether valid addresses are obtained or not. 

> Page 13, section 5.2.3, 4th paragraph, 2nd sentence: same comment as
> given for 5.1.3/4/2.
> 
> Page 13, section 5.2.3, 6th paragraph: same comment as given for
> 5.1.3/6.
> 

[Med] Idem as above.

> Nits/editorial comments:

[Med] Fixed all those. Thank you, Peter. 

> 
> Page 3, section 1, 1st paragraph, 3rd sentence: change "appraoch" to
> "approach". Change "allows" to "helps".
> 
> Page 5, section 3, 2nd bullet item, 1st sentence: change "to
> associate" to "associating".
> 
> Page 5, section 3, 2nd bullet item, 2nd sentence: change "to
> directly provision" to "directly provisioning". Consider swapping
> "avoiding" and "therefore".
> 
> Page 6, 2nd bullet item: change "straightforward" to
> "Straightforward".
> 
> Page 6, section 4, 2nd paragraph last sentence: change "samples" to
> "examples".
> Change the colon to a period.
> 
> Page 6, list item 1, first bullet item, 1st paragraph, 1st sentence:
> delete the comma after "A DOTS client".
> 
> Page 6, last partial sentence: delete the "'s" (apostrophe s).
> 
> Page 8, section 5, 3rd paragraph: change "to also supply" to "also
> supplying".
> 
> Page 8, section 5, 7th paragraph: change "to terminate" to
> "terminating".
> 
> Page 11, section 5.1.3, 3rd paragraph, 1st sentence: insert "the"
> before "reference identifier".
> 
> Page 11, section 5.1.3, 3rd paragraph, 2nd sentence: insert "an"
> before "underlying resolution library".
> 
> Page 13, section 5.2.3, 3rd paragraph, 1st sentence: insert "the"
> before "reference identifier".
> 
> Page 15, Figure 8 title: delete "Sample".
> 
> Page 18, section 8.1, 2nd paragraph, 4th sentence: change "pe-
> configured" to "pre-configured".
> 
> Page 18, section 8.1, 2nd paragraph, 5th sentence: insert "a" before
> "list".
> Change "DHCP discovered" to "DHCP-discovered".
> 
> Page 18, section 8.1, 2nd paragraph, last sentence: change "DHCP
> discovered" to "DHCP-discovered".
> 
> 


_________________________________________________________________________________________________________________________

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.