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

From: Erik Kline <[email-masked]>
Date: Sun, 18 Jul 2021 15:41:59 -0700

Phil,

Thanks for your reply.

I think, if CDNs really want a foot-gun, that perhaps it would suffice to
add some guidance to the operator(s) that they MUST keep the IP address
family support uniform among all the services the UA might attempt to
contact.

For example, if the CSP is dual-stacked then the cdniip might be an IPv6
address and in order to be reasonably effective all xCDNs that might
process the claim MUST also be dual-stacked.

If there were text to this effect that might be as good as we can expect,
although I note that it severely raises the level of effort required to
deploy IPv6 -- which is regrettable (and should perhaps also be noted).

Thanks,
-ek

On Wed, Feb 24, 2021 at 10:06 PM Phil Sorber <[email-masked]> wrote:

> 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 <
> [email-masked]> 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.
>