Re: [CDNi] Éric Vyncke's Discuss on draft-ietf-cdni-uri-signing-22: (with DISCUSS)

[Andrew Ryan <[e-mail]>]

Éric,

   Please find some of my thoughts inline about this.

> -- Section 2.1.10 --
> About "Client IP (cdniip) claim", I really wonder whether this could be used in
> real life as some IPv4 Carrier-Grade NAT (CGN) have a large pool of "public"
> IPv4 addresses that could select different public IPv4 addresses if badly
> designed.

I have encountered customers in the CDN space who have requested and 
used client IP in their URL hashing.  Use cases ranged from internal 
development environments to HLS video streaming.  There are many reasons 
where client IP breaks down, but in some cases, it is also something 
clients have uses cases for.  If the largest reason for removing support 
for the client IP is because there are caveats in it's usage, it seems 
that allowing it and noting the caveats is the more flexible approach 
and may help with adoption of the spec, particularly for folks who are 
using it in their URL hashing workflow today.

> How will it work with dual-stack UAs where some connections could be
> over IPv4 and some over IPv6 ? Now to mention a dual-home (Wi-Fi & mobile data)
> UA ? Or what if the dCDN is between the UA and the CGN (assuming that the uCDN
> or CSP are upstream of the CGN) ?

Your examples here are some of the caveats to using client IP. The 
signing entity needs to be fully aware that client IP may not remain 
constant over the course of a client session or it may see an IP address 
when creating the hash that differs completely from the IP the client 
ultimately winds up hitting an endpoint with. These are situations that 
we can highlight to help the entity creating the hashes to make informed 
decisions about using client IP.

>
> Also, "If the received signed JWT contains a Client IP claim" uses singular
> rather than "one or several"

In some models I have seen the ability to use subnet masks or cidr 
ranges to allow a block of IPs, once again though it is up to the entity 
creating the hashes to decide which elements they want to include.  One 
model may work well for one entity and not for another.

Thank you very much
Andrew Ryan

On 11/15/2021 7:56 AM, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-cdni-uri-signing-22: 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-cdni-uri-signing/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document.
>
> Thank you for fixing all my previous COMMENTs in the -22 revision.
>
> I am afraid that I need to keep my DISCUSS about the cdniip even with the
> addition of a paragraph at the end of section 2.1.10... This paragraph
> ressembles to an application statement but it it really light. Why did the
> authors select not to use RFC 8174 normative language “NOT RECOMMENDED” ?
>
> The section 7 (security considerations) is still very light on the IP address
> sharing.
>
> -éric
>
> == DISCUSS ==
>
> -- Section 2.1.10 --
> About "Client IP (cdniip) claim", I really wonder whether this could be used in
> real life as some IPv4 Carrier-Grade NAT (CGN) have a large pool of "public"
> IPv4 addresses that could select different public IPv4 addresses if badly
> designed. How will it work with dual-stack UAs where some connections could be
> over IPv4 and some over IPv6 ? Now to mention a dual-home (Wi-Fi & mobile data)
> UA ? Or what if the dCDN is between the UA and the CGN (assuming that the uCDN
> or CSP are upstream of the CGN) ?
>
> Also, "If the received signed JWT contains a Client IP claim" uses singular
> rather than "one or several"
>
> I also noted that Section 7 (security considerations) puts some restrictions on
> the usefulness of cdniip.
>
> I would welcome some applicability statements on the use of cdniip.
>
>
>
>
>
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni