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

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 28 Oct 2014 14:29:59 +0000

I would be interested in folks’ view of this. Is this interesting?

Begin forwarded message:

> From: <[email-masked]>
> Subject: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt
> Date: October 27, 2014 at 12:55:22 PM PDT
> To: <[email-masked]>
> Reply-To: <[email-masked]>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : Happy Eyeballs Considerations for HTTP State Management Mechanisms
>        Author          : Eric Vyncke
> 	Filename        : draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt
> 	Pages           : 5
> 	Date            : 2014-10-27
> 
> Abstract:
>   HTTP servers usually save session states in their persistent storage
>   indexed by session cookies generated by the HTTP servers.  It is up
>   to the HTTP user-agent to send this session cookie on each HTTP
>   request.  Some HTTP servers check whether the cookie is associated
>   with the HTTP user-agent by the means of the user-agent IP address...
> 
>   If the Happy Eyeball mechanism is used to select between IPv6 and
>   IPv4, it may happen that while using the same HTTP server, some HTTP
>   requests are done over IPv6 and the others over IPv4, which leads to
>   two different sets of session states in the HTTP server.  This has
>   the consequence of inconsistencies at the HTTP server.
> 
>   The only purpose of this document is to document this issue.
> 
>   A similar problem arises with the use of non RFC 6888 compliant Large
>   Scale NAT (LSN) devices used to access an IPv4-only HTTP server.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-vyncke-v6ops-happy-eyeballs-cookie/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 28 Oct 2014 14:45:12 +0000

> I would be interested in folks’ view of this. Is this interesting?

Everything that makes crappy eyeballs more complicated and complex is a waste of time and trying to optimise for these kinds of client decisions on a server is a bad idea.

Everything that tries to track the user state by IP at upper layers should have gone away with the boom in 2001 as well.

For the sake of Section 5 I like this.

/bz

— 
Bjoern A. Zeeb             "Come on. Learn, goddamn it.", WarGames, 1983

---

From: Simon Perreault <[email-masked]>
Date: Tue, 28 Oct 2014 10:46:06 -0400

> I would be interested in folks’ view of this. Is this interesting?

Kind of.

There are a lot of web apps that tie session cookies to IP addresses. In my
day-to-day life the top offender is Bugzilla. You can still see the
infamous checkbox here:

https://bugzilla.mozilla.org/index.cgi?GoAheadAndLogIn=1

"[X] Restrict this session to this IP address (*using this option improves
security*)" (emphasis mine)

Many open source projects use Bugzilla. If this draft's only accomplishment
is making this checkbox disappear, then IMHO it will have been a huge
success. ;)

One improvement to the draft could be to justify why what it suggests
(i.e., not tying sessions to IP addresses) does not lower security. You
have to convince technical people to remove a feature that was up to now
advertised as "improving security". This can be a hard sell.

Simon

---

From: Tim Chown <[email-masked]>
Date: Tue, 28 Oct 2014 20:14:03 +0000

On 28 Oct 2014, at 14:46, Simon Perreault <[email-masked]> wrote:

> There are a lot of web apps that tie session cookies to IP addresses. In my day-to-day life the top offender is Bugzilla. You can still see the infamous checkbox here:
> 
> "[X] Restrict this session to this IP address (using this option improves security)" (emphasis mine)
> 
> Many open source projects use Bugzilla. If this draft's only accomplishment is making this checkbox disappear, then IMHO it will have been a huge success. ;)
> 
> One improvement to the draft could be to justify why what it suggests (i.e., not tying sessions to IP addresses) does not lower security. You have to convince technical people to remove a feature that was up to now advertised as "improving security". This can be a hard sell.

This would be a good outcome of this draft.

There can be not dissimilar issues between visits to the same site when the OS picks a different IP version per visit (as OSX is prone to do).

Tim

---

From: Erik Nygren <[email-masked]>
Date: Tue, 28 Oct 2014 17:07:18 -0400

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 28 Oct 2014 21:19:10 +0000

On Oct 28, 2014, at 2:07 PM, Erik Nygren <[email-masked]> wrote:

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

An important thing, in my mind, is that Happy Eyeballs isn’t fundamentally about IPv4 and IPv6, it’s about multihoming, which is to say that I have more than one address and more than one route, and it is conceivable that one or more of my addresses or routes doesn’t work. If I am multihomed in the sense of having multiple IPv4 paths, I can have the same problems, and I can have the same problems if I am IPv6-only but have multiple upstreams.

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 29 Oct 2014 21:16:07 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: mardi 28 octobre 2014 22:07
To: Fred Baker <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Operations <[email-masked]<mailto:[email-masked]>>
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) <[email-masked]<mailto:[email-masked]>> wrote:
I would be interested in folks’ view of this. Is this interesting?

---

From: Erik Nygren <[email-masked]>
Date: Wed, 29 Oct 2014 17:25:09 -0400

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) <[email-masked]>
wrote:

>  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.
>
>  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 <[email-masked]>
> To: Fred Baker <[email-masked]>
> Cc: IPv6 Operations <[email-masked]>
> Subject: Re: [v6ops] Fwd: I-D Action:
> draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt
>

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 29 Oct 2014 21:28:47 +0000

On 29 Oct 2014, at 21:25 , Erik Nygren <[email-masked]> wrote:

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

I would phrase that differently as “I want predictable, deterministic behaviour and not magic”.

—

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Oct 2014 17:38:13 -0400

> I would phrase that differently as “I want predictable, deterministic behaviour and not magic”.

Then you want POTS, not a global packet-switched network.

:)

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 30 Oct 2014 00:04:26 +0000

> Then you want POTS, not a global packet-switched network.

Go to the detnet BOF...

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 30 Oct 2014 12:16:28 +0000

> Then you want POTS, not a global packet-switched network.

Damn that thing still works after so many decades and is so reliable indeed;  now SIP is taking over.

I was more thinking in terms of applications (or more general end-node behaviour), but I wouldn’t mind more simple, deterministic protocol behaviour either;  less can be more;  feature-itis is a disease of its own.  And, personally I guess, if we had more working (deployed) code before we’d have RFCs published on specifications, we’d have a lot less OPs (or ooops) things to write down and deal with and a lot less crap and a lot less drafts making it to RFCs;-)

/bz

—

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Oct 2014 09:21:46 -0400

On Thu, Oct 30, 2014 at 8:16 AM, Bjoern A. Zeeb <
[email-masked]> wrote:

> I was more thinking in terms of applications (or more general end-node
> behaviour), but I wouldn’t mind more simple, deterministic protocol
> behaviour either;  less can be more;  feature-itis is a disease of its
> own.  And, personally I guess, if we had more working (deployed) code
> before we’d have RFCs published on specifications, we’d have a lot less OPs
> (or ooops) things to write down and deal with and a lot less crap and a lot
> less drafts making it to RFCs;-)

Come on Bjoern, you're too young for change resistance syndrome! ;)

We need more and more to think of source IP addresses as ephemeral things.
Just like you don't care which ephemeral source port gets picked by the OS
when you call connect(), you shouldn't care about which source address is
picked when calling connect_by_name() or whatever other HE-like API out
there.

Simon

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 30 Oct 2014 14:31:48 +0100

On 2014-10-30 14:21, Simon Perreault wrote:
[..]
> you shouldn't care about which source
> address is picked when calling connect_by_name() or whatever other
> HE-like API out there.

While in the general case you should not care, it would be really useful
if there is a knob that makes it deterministic, so that you are not
swapping between source/dest pairs all the time.

Sometimes you actually want to debug the problem, to fix the issue
instead of the world breaking behind your back.

On OSX that means SSHing into another box (eg Linux) which does not muck
around with randomness based on the position of the moon.

Well, latency + throughput, *apparently*, nobody really knows the
parameters they use for picking what the destination will be or how th
results of getaddrinfo() get sorted.

Greets,
 Jeroen

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 30 Oct 2014 21:26:32 -0700

>________________________________
> From: Fred Baker (fred) <[email-masked]>
>To: Erik Nygren <[email-masked]> 
>Sent: Wednesday, 29 October 2014, 8:19

I'd think Multipath TCP could also cause these issues, as the MPTCP subflows are not limited to the IP protocol that application 'thinks' it is talking. Even MPTCP subflows of the same IP version to the same destination across session might end up with this issue if the subflows come up in different order.

>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 31 Oct 2014 13:21:05 +0000

Mark,

My understanding of MTCP is that the application layer always sees the
same (the first one I guess) IP address and does not see all the different
ones involves in the sub flows.

-éric

On 31/10/14 05:26, "Mark ZZZ Smith" <[email-masked]> wrote:

>>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.)
>
>I'd think Multipath TCP could also cause these issues, as the MPTCP
>subflows are not limited to the IP protocol that application 'thinks' it
>is talking. Even MPTCP subflows of the same IP version to the same
>destination across session might end up with this issue if the subflows
>come up in different order.
>
>
>>
>>
>>
>>An important thing, in my mind, is that Happy Eyeballs isn’t
>>fundamentally about IPv4 and IPv6, it’s about multihoming, which is to
>>say that I have more than one address and more than one route, and it is
>>conceivable that one or more of my addresses or routes doesn’t work. If
>>I am multihomed in the sense of having multiple IPv4 paths, I can have
>>the same problems, and I can have the same problems if I am IPv6-only
>>but have multiple upstreams.
>>
>>
>>
>>
>>
>>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.
>>>
>>
>>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 31 Oct 2014 13:23:56 +0000

From: Simon Perreault <[email-masked]<mailto:[email-masked]>>
We need more and more to think of source IP addresses as ephemeral things. Just like you don't care which ephemeral source port gets picked by the OS when you call connect(), you shouldn't care about which source address is picked when calling connect_by_name() or whatever other HE-like API out there.

Ephemeral and probably less and less meaningful

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Fri, 31 Oct 2014 15:06:37 +0100

> Ephemeral and probably less and less meaningful

It loses its meaning of an "identity", and keeps the one as a full
(IPv6) or partial (IPv4+NAT) "current locator in the network".

--a

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 Oct 2014 08:33:25 -0700

> On Oct 31, 2014, at 6:23 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> 
> 
> From: Simon Perreault <[email-masked] <mailto:[email-masked]>>

That’s all well and good, except when source address selection goes horribly wrong, you’re in a world of hurt if the API doesn’t provide a mechanism for override.

Owen