Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt

[Erik Nygren <[e-mail]>]

I guess the question is whether it is worth having an Informational
covering this class of problem explicitly with a very clear "don't do
this!" focus?

In particular, there are two dimensions:

1) the classes of things people lock by IP address today (session cookies,
auth tokens, bearer tokens, etc)

2) the classes of multi-homing that cause problems here and how all of them
are increasing (happy eyeballs for dual-stack, privacy addressing,
multi-link multi-homing, load balanced proxies, load balanced NATs, ...)

With the summary that because of the increases in #2, it is strongly
advised not to do #1 anymore.

Questions sometimes come up on whether there are good technical solutions,
such as ways clients can force outbound connections across each link to
build up some sort of "association record" that glues the various IP
addresses together, but that is more of an apps-area topic, and also don't
work with some of the above.

       Erik



On Wed, Oct 29, 2014 at 5:16 PM, Eric Vyncke (evyncke) <[e-mail]>
wrote:

>  Erik, Bjoern and Simon,
>
>  Thanks for your review and comments.
>
>  The original intend was to document an issue faced by some content
> providers, but, Erik, you are right RFC 6883 section 8.2 clearly spells out
> the problem raised in my I-D, so, I guess my I-D is clearly useless and
> brings nothing.
>
>  ==> let's let him die by expiration ;-)
>
>  Else, I agree with Fred's, Jeroen's and others comment that the title
> was not well-chosen as it is not limited only to happy eyeball (the LSN
> case was also document in the I-D though)
>
>  -éric
>
>   From: Erik Nygren <[e-mail]>
> Date: mardi 28 octobre 2014 22:07
> To: Fred Baker <[e-mail]>
> Cc: IPv6 Operations <[e-mail]>
> Subject: Re: [v6ops] Fwd: I-D Action:
> draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt
>
>    On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker (fred) <[e-mail]>
> wrote:
>
>> I would be interested in folks’ view of this. Is this interesting?
>>
>
>  This is mentioned in section 8.2 of rfc6883 but keeps coming up over and
> over again
>  so may be worth calling out more clearly.  I'd title it in some way that
> didn't make it seem like
> a happy eyeball specific issue.
>
> It's not just a happy eyeballs issue.  It also happens with dual-stack
> environments where cookies or session or authentication tokens span origins
> where some servers are dual-stack and some are IPv4-only.   (For example,
> an auth granting service grants bearer tokens locked to the client IP
> address and then the client connects to some other service on a different
> hostname and passes along the tokens.  Even absent Happy Eyeballs these can
> be on different IP versions.)
>
> The large-scale NAT/CGN issue does make this not just an IPv6 issue.  At
> least some systems I've seen then check the IP in the cookie to make sure
> it's in the same /24 rather than the exact same IP, but that doesn't help
> in the dual-stack world.
>
>  Another issue beyond Happy Eyeballs is that privacy addressing bites you
> here as well for cookies that are used across different TCP connections
> spanning a privacy address rotation.
>
>  Having some more clear "don't do this" to point people to would be good,
> but I suspect we'll have many years of cleaning up applications doing this.
>
>