Subject: [CDNi] URI Signing Client IP Claim Question

From: Phil Sorber <[email-masked]>
Date: Tue, 9 Nov 2021 15:39:17 -0700

This is one of three questions that I had after last call feedback. I'd
like to hear any opinions on the matter from the working group. I will be
pointing to this thread for explanation/justification about the changes or
lack thereof to the document. Thanks.

Do we want to remove the Client IP claim due to the issues it has with
things like dual stack, mptcp, switching from wifi to cell, etc, or does it
have value in niche use cases such as sharing links internally and thus we
should keep it but with proper discussion around it's uses?

---

From: Andrew Ryan <[email-masked]>
Date: Tue, 9 Nov 2021 18:43:11 -0500

Phil,

   In my past experience I have come across CDN customers who have use 
cases where including the client IP solves a need.  Without enumerating 
over all the potential uses cases for using client IP in the hash, if 
there are parties interested in using client IP in a hash, preventing 
them from doing so may gate the adoption of the specification.  
Providing a few examples of how the client IP may result in unexpected 
hash evaluation would probably serve as sufficient warning for it's 
usage.   Unless there is an undue burden on the specification for 
allowing client IP to be used, it probably makes more sense to keep 
client ip than to remove it.

Andrew Ryan

My opinion is that just because a particular claim has caveats, it 
shouldn't be excluded from support.

On 11/9/2021 5:39 PM, Phil Sorber wrote:
> This is one of three questions that I had after last call feedback. 
> I'd like to hear any opinions on the matter from the working group. I 
> will be pointing to this thread for explanation/justification about 
> the changes or lack thereof to the document. Thanks.
>
> things like dual stack, mptcp, switching from wifi to cell, etc, or 
> does it have value in niche use cases such as sharing links internally 
> and thus we should keep it but with proper discussion around it's uses?
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Chris Lemmons <[email-masked]>
Date: Wed, 10 Nov 2021 00:29:17 -0700

I agree with Andrew. The Client IP claim has considerable weaknesses,
but there is a strong desire for support for it industry-wide. I worry
that removing it would simply encourage even less privacy-protecting
implementations using non-standard claims. As a practical matter, I
think it's useful, subject to the many caveats already documented in
the draft.

I do think it could be made more useful by changing the claim from a
string type to an array type, where any IP address in the array
satisfies the claim. That would make the token potentially more useful
for small population and dual stack use. But it's rather late to be
making the change and there's no reason a more robust IP claim can't
be added via registration later if it proves sufficiently useful.

On Tue, Nov 9, 2021 at 4:43 PM Andrew Ryan <[email-masked]> wrote:
>
> Phil,
>
>   In my past experience I have come across CDN customers who have use cases where including the client IP solves a need.  Without enumerating over all the potential uses cases for using client IP in the hash, if there are parties interested in using client IP in a hash, preventing them from doing so may gate the adoption of the specification.  Providing a few examples of how the client IP may result in unexpected hash evaluation would probably serve as sufficient warning for it's usage.   Unless there is an undue burden on the specification for allowing client IP to be used, it probably makes more sense to keep client ip than to remove it.
>
> Andrew Ryan
>
> My opinion is that just because a particular claim has caveats, it shouldn't be excluded from support.
>
> This is one of three questions that I had after last call feedback. I'd like to hear any opinions on the matter from the working group. I will be pointing to this thread for explanation/justification about the changes or lack thereof to the document. Thanks.
>
> Do we want to remove the Client IP claim due to the issues it has with things like dual stack, mptcp, switching from wifi to cell, etc, or does it have value in niche use cases such as sharing links internally and thus we should keep it but with proper discussion around it's uses?
>

---

From: Kevin Ma <[email-masked]>
Date: Wed, 10 Nov 2021 12:40:54 -0500

Hi All,

  (As an individual) I agree with Andrew and Chris that the desire to use
this in private networks where IPs are well known and it is easy has been
much discussed (and is one of the reasons we included it in the first
place, along with the relatively broad support from proprietary solutions,
given all its known deficiencies).  To Chris's point about less privacy
protection, we at least require that the IP be encrypted, so there is
something to be said for keeping it wrt that.  We could add more
disclaimers if that would help, but I'd rather not deny the use case.

  I'm hesitant to make any big changes to the claims if we're close to
publishing.  If the array becomes a big deal for users, I think an
extension draft (as we are seeing from the SVA on metadata and
capabilities) is a good route; then we know that the request is backed by
actual usage.

thanx!

--  Kevin J. Ma

On Wed, Nov 10, 2021 at 2:30 AM Chris Lemmons <[email-masked]> wrote:

> over all the potential uses cases for using client IP in the hash, if there
> are parties interested in using client IP in a hash, preventing them from
> doing so may gate the adoption of the specification.  Providing a few
> examples of how the client IP may result in unexpected hash evaluation
> would probably serve as sufficient warning for it's usage.   Unless there
> is an undue burden on the specification for allowing client IP to be used,
> it probably makes more sense to keep client ip than to remove it.
> >
> > Andrew Ryan
> >