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

[Phil Sorber <[e-mail]>]

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

On Wed, Feb 24, 2021 at 6:47 PM Erik Kline via Datatracker <[e-mail]>
wrote:

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

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.


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

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.


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

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.