Hi, Roman: -----邮件原件----- 发件人: Roman Danyliw via Datatracker [mailto:[email protected]] 发送时间: 2021年12月2日 6:42 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; Vijay Gurbani <[email protected]>; [email protected] 主题: Roman Danyliw's Discuss on draft-ietf-alto-cdni-request-routing-alto-17: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-cdni-request-routing-alto-17: Discuss 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The security consideration is silent on how to handle client (uCDN) authentication for this specific CDN use case. Hence, the default guidance from Section 15.13.2 of RFC7285 seems to apply -- that HTTP Digest Authentication or TLS client authentication could be used. [Qin Wu] RFC7285 section 8.3.5 recommends to use HTTP Digest Authentication and TLS Client Authentication for client authentication. So yes, section 15.3.2 of RFC7285 did apply. See quoted text below " For deployment scenarios where client authentication is desired to address risk type (2), ALTO requires that HTTP Digestion Authentication is supported to achieve ALTO client authentication to limit the number of parties with whom ALTO information is directly shared. TLS client authentication may also be supported. Depending on the use case and scenario, an ALTO server may apply other access control techniques to restrict access to its services. Access control can also help to prevent Denial-of-Service attacks by arbitrary hosts from the Internet. " If I understand the use case right, it seems like the uCDNs and dCDNs should know about each other, and there wouldn’t be an unreasonably large number of them to prevent credentials existing for peers. Is there a reason why there isn’t a normative guidance requiring some kind of peer authentication given this narrow use case? If not, why is ok given the significance of this ALTO data in FCI model. [Qin Wu] The normative guidance we provide is section 15 of RFC7285 which cover normative guidance for client authentication. Let us know if you have any suggested text. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Klaas Wierenga for the SECDIR review. ** Abstract. Typo? RFC 8008 defines precisely the semantics of FCI and provides guidelines on the FCI protocol, but the exact protocol is specified Shouldn’t this read, “but the exact protocol is _NOT_ specified”? [Qin Wu] Good catch and will ask author to fix. ** Section 8. For authenticity and integrity of ALTO information, an attacker may disguise itself as an ALTO server for a dCDN, and provide false capabilities and footprints to a uCDN using the CDNI Advertisement service. -- I don’t follow the intent of the first clause. Why is an _attacker_ concerned with the authenticity and integrity of the ALTO information? [Qin Wu] It tries to align with section 15.1 of RFC7285, if my understanding is correct. -- What role can TLS, an associated server certificate (for the dCDN) and configured knowledge of this certificate at the uCDN mitigate some of this risk? Shouldn’t the uCDNs only be communicating with a collection of known dCDNs with which it has some out-of-band negotiated arrangement? [Qin Wu] Yes, uCDNs will only communicate with dCDNs which he sign agreement with. But The attacker may be located between uCDNs and dCDNs as an man in middle attack. ** Section 8. For availability of ALTO services, an attacker may conduct service degradation attacks using services defined in this document to disable ALTO services of a network. Again, operating under the assumption that the dCDN (ALTO Server) would only be working with a known (prearranged) set of uCDNs and they would have authenticated somehow (per the DISCUSS), couldn’t repeated requested be rate limited and after attribution, filtered to minimize impact? [Qin Wu] Correct, if client authentication is in place, this security issue will be mitigated. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
