Re: [alto] Roman Danyliw's No Objection on draft-ietf-alto-cdni-request-routing-alto-18: (with COMMENT)

[Qin Wu <[e-mail]>]

Thanks Roman for clearing DISCUSS, @authors, please engage with Roman and address his additional comments. 

-Qin
-----邮件原件-----
发件人: Roman Danyliw via Datatracker [mailto:[e-mail]] 
发送时间: 2022年1月6日 5:31
收件人: The IESG <[e-mail]>
抄送: [e-mail]; [e-mail]; [e-mail]; Vijay Gurbani <[e-mail]>; [e-mail]
主题: Roman Danyliw's No Objection on draft-ietf-alto-cdni-request-routing-alto-18: (with COMMENT)

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?

-- 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?

** 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?