[JIRA] Commented: (SSPCPP-447) Extension of consistentAddress for IPv6

[Kaspar Brand (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SSPCPP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14437#comment-14437 ] 

Kaspar Brand commented on SSPCPP-447:
-------------------------------------

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.

> Extension of consistentAddress for IPv6
> ---------------------------------------
>
>                 Key: SSPCPP-447
>                 URL: https://issues.shibboleth.net/jira/browse/SSPCPP-447
>             Project: Shibboleth SP - C++
>          Issue Type: Improvement
>          Components: Session Cache
>            Reporter: Lukas Haemmerle
>            Assignee: Scott Cantor
>             Fix For: 2.5.1
>
>   Original Estimate: 2 days
>          Time Spent: 1 day, 1 hour
>  Remaining Estimate: 7 hours
>
> 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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira