Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Extension of consistentAddress for IPv6

Description

With the increased usage of IPv6 we get more and more user reports from
users that frequently lose their Shibboleth sessions at SPs although the
inactivity between subsequent requests to the same SP is only a few
minutes. This then also often forces them to re-authenticate at the IdP
(after the default inactivity timeout of 30 min is over). Currently,
it's mostly Mac OS X 10.7 (Lion) users.

We found that the cause of this behavior has to to with the
consistentAddress check and the availability of IPv6 and IPv4.
If the client and the server both support the two protocols, then issues
like the one described above may occur with certain OS and browsers
because these send requests once with IPv4 and some time later with
IPv6. The algorithm used for the connection setup is nicknamed Happy
Eyeballs [1]. It is supposed to improve the connectivity/responsiveness
of IPv6 networks. The behavior of Mac OS X 10.7.x clients is a bit
different from the one used in Chrome and Firefox 10 that also use the
Happy Eyeballs algorithm. Mac OS does not prefer IPv6 but uses the
destination/protocol with the lowest round trip time. Depending on
routing and network load, this may be the IPv4 address at one time and a
few minutes later the IPv6 address.

Possible solutions against this Happy Eyeballs side effect with
consistentAddress="true" (default) are:

  • Disable IPv6 on client

  • Disable IPv6 on server

  • Disable consistentAddress (consistentAddress="false")

All of the above solutions have their limitations and drawbacks.
Another possible solution could be to extend the SP to auto-accept and store
one address for IPv4 and IPv6 each per session (identified by session cookie).
This may mitigate the issue described above.

One drawback here could be that this may degrade the security of
the extended consistentAddress feature as an attacker probably could
misuse it. So we are wondering what developers think of this?

Also to note: With IPv6 sometimes comes a privacy extension [2] that
will change the user's IPv6 regularly on some clients. Although this IP
change seems to be rather daily than hourly according to our IPv6
specialists, it still should be taken into account.

Environment

None

Activity

Show:

Scott Cantor December 10, 2012 at 7:13 PM

Closing with release.

Scott Cantor October 15, 2012 at 7:08 PM

http://svn.shibboleth.net/view/cpp-sp?rev=3788&view=rev

Generalizes the patch to other address families if needed.

Scott Cantor October 8, 2012 at 2:12 PM

Thanks. I'm going to wrap the address type detection code so it's extensible to other "families" but other than that it's basically done.

Former user October 8, 2012 at 8:32 AM

We did some quick tests with r3773, and it seems to work as expected: creating the session with IPv6 and then turning it off shows a "binding session... to new client address (130.59.x.y)" message in the log. The other way round (login via IPv4 first, then turn on IPv6) also worked fine.

Former user October 1, 2012 at 12:54 PM

To check for an IPv6 address in "client_addr", you could also feed it to inet_pton(AF_INET6, ...) and check for its return value - and if this fails, treat it as IPv4. inet_pton is POSIX stuff (cf. http://pubs.opengroup.org/onlinepubs/009695399/functions/inet_pton.html), so should be fairly portable.

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Original estimate

Components

Fix versions

Created April 27, 2012 at 7:11 AM
Updated December 10, 2012 at 7:13 PM
Resolved October 15, 2012 at 7:08 PM

Flag notifications