Question re session hijacking in dual stack environments w/MacOS

Hey all, as we've slowly deployed IPv6 to our end users, it has begun to
cause some issues for those on Mac's specifically. Apple apparently has
an algorithm at some point in the network stack to decide whether IPv4
or IPv6 is, perhaps, 'better' or 'faster' at any given point in time
during an ongoing session. This allows a computer talking to a dual
stack remote website to flip flop between v4 and v6 as activity is
conducted.

Websites that require some type of authentication that is handled via
session cookies have been booting our users out randomly with "your ip
address has changed" type message. This occurs when their Mac decides
to switch between protocols because the site views it as a session
hijacking attempt when Joe User with session ID xyz switches from
192.0.2.10 to 2001:db8::1:1:a or vice versa.

Has anyone run into this? Our users on other platforms don't seem to
have this issue; linux and MS desktops seem to just use v6 if it's
available and v4 if not.

Thanks,

David

Info about Apple and their unique IPv6 selection process

https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html

This sounds like a really poor practice on the part of the website operators. Users on wireless devices may be switching networks throughout the same session (wifi/LTE), or there could be a cluster of proxies, or short DHCP leases, or tor circuit changes, or privacy extensions, etc. This is almost as bad as using GeoIP databases to authenticate.

-Laszlo

I have been tracking down an issue for months where SSH'ing to some
devices (which picks IPv6 by default) from my Mac while in the office
drops the connection, forcing me to reconnect. It's random; sometimes it
happens a lot, sometimes, rarely, other times not at all.

I've sort of suspected OS X to be the issue (10.10.5) here. The
workaround has been to SSH strictly on IPv4 which is always stable. So
it seems to be an issue when the session is carried over IPv6.

This only affects OS X. SSH'ing from FreeBSD, for example, on IPv6 is
stable. To be honest, I've been a little busy to look deeper into this,
but it definitely has something to do with what you describe, I imagine.

Mark.

I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX
generates a new random IPv6 address, applies it to the interface, and then
drops the old IPv6 addresses as they stale out. Sessions in use or not.

sudo sysctl -w net.inet6.ip6.use_tempaddr=0

sudo sh -c 'echo net.inet6.ip6.use_tempaddr=0 >> /etc/sysctl.conf'

I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX
generates a new random IPv6 address, applies it to the interface, and then
drops the old IPv6 addresses as they stale out. Sessions in use or not.

Isn't the OS supposed to wait for the last user of the old address to close
their socket before dropping it?

> I suspect this is OSX implementing IPv6 Privacy Extensions. Where OSX
> generates a new random IPv6 address, applies it to the interface, and then
> drops the old IPv6 addresses as they stale out. Sessions in use or not.

Isn't the OS supposed to wait for the last user of the old address to close
their socket before dropping it?

Bowser talks to server with temp address 1. Sockets close. New
temp address generated. User click submit. New temp address used.

It is stupid web site design to assume that addresses will be stable
even within a session.

In my experience, no, it doesn't. Ie. the main reason I disable it is
because my ssh sessions hung after some period of time, so ssh had
sockets open, but yet the IPv6 addresses kept rotating out.
Disabling it definately made the ssh sessions stable on OSX.

Apple codes to the masses. Average web browser user or mail client
won't care, that is all they test against. Not people that leave ssh
sessions open for days to weeks at a time.

>
> > I suspect this is OSX implementing IPv6 Privacy Extensions. Where
> > OSX generates a new random IPv6 address, applies it to the
> > interface, and then drops the old IPv6 addresses as they stale
> > out. Sessions in use or not.
>
> Isn't the OS supposed to wait for the last user of the old address
> to close their socket before dropping it?

In my experience, no, it doesn't. Ie. the main reason I disable it is
because my ssh sessions hung after some period of time, so ssh had
sockets open, but yet the IPv6 addresses kept rotating out.
Disabling it definately made the ssh sessions stable on OSX.

Apple codes to the masses. Average web browser user or mail client
won't care, that is all they test against. Not people that leave ssh
sessions open for days to weeks at a time.

Since no one else has mentioned it yet, mosh is another solution to
this for ssh:
https://mosh.mit.edu/

I doubt it given the variable frequency he describes.

If it were OSX timing out addresses, he’d see a session drop every day or two
rather than frequently sometimes.

Owen

Interesting. Thanks, Doug.

I just upgraded to El Capitan, so I'll see if there are any changes in
that when I'm back in the office, and then look at your suggestion if
not. Thanks.

Mark.

No… It just waits for the valid lifetime to expire.

Privacy addresses don’t refresh their preferred lifetime and start counting the valid lifetime from preferred expiration IIRC.

Owen