Roman: I have asked Jensen to produce a version to address your remaining comments, would you like to confirm to him about some of his additional clarification points? Thanks!
-Qin 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Jensen Zhang 发送时间: 2022年1月18日 22:00 收件人: Roman Danyliw <r...@cert.org> 抄送: alto-chairs <alto-cha...@ietf.org>; The IESG <i...@ietf.org>; draft-ietf-alto-cdni-request-routing-a...@ietf.org; IETF ALTO <alto@ietf.org> 主题: Re: [alto] Roman Danyliw's No Objection on draft-ietf-alto-cdni-request-routing-alto-18: (with COMMENT) Hi Roman, Many thanks for your comments. See our answers inline. Please let us know if they address your concerns. On Thu, Jan 6, 2022 at 5:31 AM Roman Danyliw via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-alto-cdni-request-routing-alto-18: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Klaas Wierenga for the SECDIR review. Thanks for addressing my DISCUSS point ** 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? This bullet describes the same risk scenario as the one in Sec 15.1 of RFC7285. -- 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? Yes, the uCDNs should only communicate with known dCDNs. But an attacker can start a man-in-the-middle attack. About how to configure TLS, does the second last bullet of this section make it clear? ** 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? Yes, considering the limited number of authenticated uCDNs, this security issue may not be that risky. This bullet just aligns with Sec 15.5 of RFC7285. Do you strongly think we should remove this one? Thanks, Jensen _______________________________________________ alto mailing list alto@ietf.org<mailto:alto@ietf.org> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
