Subject: [alto] Roman Danyliw's Discuss on draft-ietf-alto-cdni-request-routing-alto-17: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 01 Dec 2021 14:42:16 -0800

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.

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.

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

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