Hi Roman, A new version that echoes the replies already provided in this thread is available:
URL: https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-21.txt Status: https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-21 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cdni-request-routing-alto-21.txt Please let us know if they address your concerns. Best regards, Jensen On Tue, Jan 18, 2022 at 10:00 PM Jensen Zhang <jingxuan.n.zh...@gmail.com> wrote: > 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> 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 >> https://www.ietf.org/mailman/listinfo/alto >> >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
