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

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 24 Feb 2021 17:46:59 -0800

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.

---

From: Phil Sorber <[email-masked]>
Date: Wed, 24 Feb 2021 23:06:22 -0700

Thank you for this thorough review. I have added my responses below.

> https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/

Yes, there are definitely caveats to using the Client IP for validation.
This is really just something that some CSPs want now, but hopefully they
will use something like this in a limited fashion. Perhaps there can be
value in using this with signed token renewal where the Client IP is only
validated on the first round trip. When combined with jti and a short JWT
lifetime, you can be reasonably assured that the chain would only be able
to continue for the correct user. If the IP had already changed by that
point, the client visible failure would be at the very beginning instead of
interrupting some long playing media.

> strict about verifying it can lead to client-visible failures.

I think additional guidance could be useful, but I don't think we can relax
the validation. Content owners really want to know how it will be validated
if they are including it in the first place. And as this is duplication of
a legacy feature, it really makes sense to have it behave as similarly as
possible. Principle of least surprise.

> impossible.  I'm not sure this is a workable option, though.

We wanted to make this essentially invisible to the UA by leveraging
existing behavior. I suspect that if we could relax that requirement, we'd
go a completely different route than anything discussed in this document.