HTTP State Management Mechanisms with Multiple Addresses User Agents
draft-vyncke-v6ops-happy-eyeballs-cookie-01

Document Type Expired Internet-Draft (individual)
Last updated 2015-09-06 (latest revision 2015-03-05)
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-vyncke-v6ops-happy-eyeballs-cookie-01.txt

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. Everything linking a state to an IP address (such as OAuth access code) to an IP address has the same issue. 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 in more details than in section 8.2 of RFC 6883 including security considerations and mitigations. A similar problem arises with the use of non RFC 6888 compliant Carrier-Grade NAT (CGN) devices used to access an IPv4-only HTTP server or HTTP user-agent using multi-homing.

Authors

√Čric Vyncke (evyncke@cisco.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)