[Last-Call] Genart last call review of draft-ietf-dots-server-discovery-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux