[CDNi] Erik Kline's Discuss on draft-ietf-cdni-uri-signing-21: (with DISCUSS)

[Erik Kline via Datatracker <[e-mail]>]

Erik Kline has entered the following ballot position for
draft-ietf-cdni-uri-signing-21: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Apologies for piling on, but I want to second Eric Vyncke's Discuss.  The
use of Client IP addresses is more problematic than one might suspect from
a reading of this document.

RFC 8305 Happy Eyeballs means for a dualstack client and a dualstack CSP or
CDN there are no guarantees that the address family will be the same.

Furthermore, a client using RFC 8981 (4941bis) IPv6 temporary addresses might
change source address (even with every request) so an exact match would not be
recommended.

To make matters even more complicated, a mobile client might make the CSP
request on Wi-Fi, walk out of range, and complete a subsequent CDN request
via its mobile provider network (or vice versa).  So, even using a fairly
short CIDR length for truncation may not work since the origin network can be
completely different between requests.

The latter behaviour can also be trigger by connection migration transports,
like MPTCP and (soon) QUIC.

I think one solution might include relaxing all the MUSTs in section 2.1.10.
Instead, perhaps some text that clarifies the presence of reliability issues
with Client IPs and recommends that CDNs be develop a more sophisticated
policy (or avoid using this altogether and prefer to use other claims).
Including the Client IP for logging purposes might be helpful, but being too
strict about verifying it can lead to client-visible failures.

Alternatively, UAs need to be augmented to know that when a cdniip is part
of the claim that it must try to keep the source IP address the same for
subsequent requests, recognizing, as section 7 does, that NAT can make this
impossible.  I'm not sure this is a workable option, though.