DDoS Open Threat Signaling (DOTS) Agent Discovery
Note: This ballot was opened for revision 13 and is now closed.
Benjamin Kaduk Yes
Comment (2020-10-26 for -13)
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. 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. Section 4 will support a local configuration. More samples are discussed in Section 3: nit: s/:/./ 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. 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? 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.
Deborah Brungard No Objection
Roman Danyliw No Objection
Comment (2020-11-02 for -14)
Figure 2. Editorial. Expand DMS somewhere in the surrounding text. Section 3. Editorial. Per “Dynamic means to discover DOTS servers in a deterministic manner are interesting from an operational standpoint”, this reads like a problem statement. Should it be restated as “dynamic discovery needs to be deterministic”? Section 4. Editorial. Recommend not using the colloquialism “whack-a-mole”. Section 4. Per “DOTS clients will prefer information received from the discovery methods in the order listed”, does that mean the order list of 1, 2, 3 in the text above? If so, perhaps make that clearer. Section 4. Editorial. s/The discovery method is reiterated/The discovery method is repeated/ Section 5. I don’t have a better IETF reference, but RFC6125 is 9 years old so if something newer could be found that would be great. Section 8.3. In the absence of DNSSEC, DoT or DoH could also provide a degree of path integrity protection.
Martin Duke No Objection
Comment (2020-10-30 for -14)
Sec 5 “... this document allows for configuring names to DOTS clients ...“ I think this means that the client receives server names, not that the clients have names themselves. But I’m not sure.
Erik Kline No Objection
Murray Kucherawy No Objection
Warren Kumari No Objection
Comment (2020-11-04 for -14)
I support Eric's discuss position. I'd like to thank Nagendra Nainar for the OpsDir review; it was very helpful in my ballotting
Barry Leiba No Objection
Comment (2020-10-28 for -14)
Overall discussion question (but not at blocking DISCUSS level): Does it make sense for DOTS clients to proactively discover appropriate DOTS servers *before* a DDoS attack hits, to avoid the issue of discovery being blocked by the attack that the client is trying to report? Should this document discuss that? Other comments, all minor: — Section 1 — This approach allows to reduce the impact of an attack and leads to more efficient defensive Nit: “allows to” isn’t proper English, as it lacks a subject: “allows <some entity> to”. I think the subject you want here is DOTS, so maybe this works?: NEW With this approach, DOTS can reduce the impact of an attack and lead to more efficient defensive END — Section 2 — The reader should be familiar with the terms defined in [RFC8811], [RFC3958], and [I-D.ietf-dots-signal-call-home]. I think this makes RFC 8811 and draft-ietf-dots-signal-call-home normative references, as they define require terminology. Certainly 8811 is normative in any case, as the architecture needs to be understood. — Section 3 — It is tempting to specify one single discovery mechanism for DOTS. Nevertheless, the analysis of the various use cases sketched in Nit: Ignore this if you’re happy with the text as it is, but I would remove the first sentence and just start this as “Analysis of the various use cases…”. Please expand “CPE” on first use — especially as it’s confusingly and contradictorily described as “Customer Premises Equipment” (provided by the operator) and “Customer Provided Equipment” (not provided by the operator), so we need to know which you mean. — Section 4 — These may be specified either as IP addresses or the DNS name of a DOTS server. The first half of the sentence is plural and the second singular. Should both be plural, “…either as IP addresses or DNS names of DOTS servers.” ? If it’s intentional that it can be multiple IP addresses but only one DNS name, it would be better to be more explicit about that. — Section 5 — and server while accommodating for the current best practices Nit: not “accommodating for”: just “accommodating”. — Section 5.1.1 — o dots-agent-name: A fully qualified domain name of the peer DOTS agent. This field is formatted as specified in Section 10 of [RFC8415]. As all Section 10 of 8415 does is send us to Section 3.1 of 1035, why not just point to the latter directly, rather than making the reader follow an extra reference? And it wouldn’t be bad to append to the “an example” sentence as follows: NEW An example of the dots-agent-name encoding is shown in Figure 4. This example conveys the FQDN "dots.example.com.”, and the resulting Option-length field is 18. END
Alvaro Retana No Objection
Martin Vigoureux No Objection
Éric Vyncke (was Discuss) No Objection
Comment (2020-11-05 for -14)
Thank you for the work put into this document. It is easy to read. Please find below a couple of blocking DISCUSS points and some non-blocking COMMENT points and some nits. In addition to my own points, please consider Zhen Caos' INT directorate review at: https://datatracker.ietf.org/doc/review-ietf-dots-server-discovery-11-intdir-lc-cao-2020-10-12/ I hope that this helps to improve the document, Regards, -éric == Previous DISCUSS -- solved by Med Boucadair and kept here for archiving purposes == -- Section 4 -- Trivial to fix: there is no "DHCP lease" for stateless DHCPv6... You should probably rather refer to the information-request refresh time option (section 21.23 of RFC 8415). -- Section 5.1.2 -- I fully second Zhen Cao's review: how will the IPv4-mapped IPv6 address(es) be used? They MUST not appear on the wire and there is a DHCPv4 option to convey the DOTS information. Is it when DHCPv6 is available, no DHCPv4, and only IPv4 connectivity to the DOTS server ? If so, then please clarify the text. == End of previous DISCUSS == Is DHCP really the way to go ? Even if it seems that there are use cases, relying on dynamic DHCP for such an important security protocol looks very strange to me (as the security AD has approved DHCP use, it is a mere non-blocking comment). Should DNSSEC be required for domain name resolution or is relying only on TLS server authentication enough ? The document gives a lot of IPv6 examples: thank you for this but it also mention multiple address families. Should Happy Eyeball be used when connected to the DOTS server? -- Section 4 -- While this section title is "Unified DOTS Discovery Procedure", I read 3 different mechanisms so apparently conflicting with the section title. Suggest to remove "unified" from the section title. Putting DHCP configuration under explicit configuration appears weird to me as DHCP is rather dynamic and on the same level as DNSD. May I suggest to move the sentence "DOTS clients will prefer information received from the discovery methods in the order listed" before the list? It is an important sentence IMHO. I wonder wheter the sentence "Expiry of a peer DOTS agent's certificate currently in use." is correct... Should it be "agent peer DOTS certificate" ? -- Sections 5.1.3 and 5.2.3-- The part of the sentence "as distinguished by the presence of multiple root labels" should be explained more as it is unclear. -- Section 6 -- Just to say that the use of S-NAPTR surprised me (no need to reply) == NITS == The id-nits tool indicates a non used reference to RFC 8783, so, please clean up the reference list ;-) -- Section 1 -- s/by multi-homed DOTS clients are out of scope/by multi-homed DOTS clients are out of this document scope/ ?
Magnus Westerlund No Objection
Comment (2020-11-05 for -14)
Shouldn't the security consideration section 8.2 ave some additional warnings about the ease of affecting the dns lookup when .local is used. This as mDNS more easily can be gamed?