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. 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? 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) 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. 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. 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. 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"? 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? 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. Nits/editorial comments: 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". -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
