Subject: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie

From: [email-masked]
Date: Wed, 11 Feb 2015 04:47:01 -0800

A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it and comment.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 11 Feb 2015 15:44:49 +0100

> A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it and comment.

I have read this draft.

I'm quite frankly surprised that anyone would still attempt to link a 
source IP address and a session cookie at the server end. Use of NAT 
pools on IPv4-only firewalls have created identical operational problems 
for years.

Still, the mitigation advice is pretty sound: "don't do it"

Perhaps the draft could be even more generic: don't assume that an 
IPv4/IPv6 address can be used as a invariant key in a one-to-one mapping 
to an application-layer session table, especially where there isn't 
guaranteed underlying transport-layer-persistence.

This problem isn't happy eyeballs specific, nor HTTP specific.

-- 
Regards,
RayH

---

From: "Metzler, Dan J" <[email-masked]>
Date: Wed, 11 Feb 2015 16:31:51 +0000

A few comments on this

" 5.  Potential Mitgation"

 -  Obviously, correct the spelling of Mitigation.
 -  IMHO, I would remove the word "Potential".  (See below)

" 7.  Security Considerations"

 -  I would qualify the first phrase by rewording somewhat like as follows, (or remove the phrase altogether):
The association of the session cookie with the user-agent IP address has some security value as it can help prevent "session cookie stealing" in some limited situations...
 -  It should be understood that the desire to protect a cookie from cookie stealing often implies that a potential attacker has already gained access to the cookie, and is close enough in proximity to the transmission path(s), or endpoints, that any assumptions, about the attacker's address always being different, are no longer valid assumptions; even without a man-in-the-middle attack.  NAT, mobile devices, and server hosted client apps are all examples of situations where addresses can be shared and/or swapped between multiple users.  I would think that exchange of random keys at the beginning of session establishment, along with some type of validation algorithm, is a much better way to address this type of security consideration than using an address as the key.

- Dan

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, February 11, 2015 6:47 AM 
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie
> 
> A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-
> happy-eyeballs-cookie. Please take a look at it and comment.
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 12 Feb 2015 03:08:01 +0000 (UTC)

I think this is a good draft, and I agree with what it says, however I think perhaps it really belongs in the httpbis working group, as they're the HTTP experts?

The only other thought I've had is that it might be worth documenting that MPTCP shouldn't suffer from this problem as if an application cares about IP addresses, then only the first subflow's IP addresses are exposed to the application, even if a later subflow uses a different address family. There may be a little confusion in this area as MPTCP and HE might appear to be fairly similar at face value (and I think HE techniques applied to initial MPTCP subflow setup might improve the MPTCP establishment performance.).

Regards,
Mark.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 27 Feb 2015 13:21:39 +0000

Mark, Dan and Ray

Thanks a lot for your comments. BTW, this is kind of an 'old' draft
presented in Honolulu.

Brain Carpenter brought my attention to section 8.2 of RFC 6883 "IPv6
Guidance for Internet Content Providers" which summarizes the same issue
in one single paragraph. So, I am not sure whether this specific I-D
should continue? On one side, it is repetition but on the other it makes
this issue glaring and much more visible.

Anyway, I am updating it with your comments (and others) then upload it.

Regards and thanks

-éric

On 12/02/15 04:08, "Mark ZZZ Smith" <[email-masked]> wrote:

>I think this is a good draft, and I agree with what it says, however I
>think perhaps it really belongs in the httpbis working group, as they're
>the HTTP experts?
>
>The only other thought I've had is that it might be worth documenting
>that MPTCP shouldn't suffer from this problem as if an application cares
>about IP addresses, then only the first subflow's IP addresses are
>exposed to the application, even if a later subflow uses a different
>address family. There may be a little confusion in this area as MPTCP and
>HE might appear to be fairly similar at face value (and I think HE
>techniques applied to initial MPTCP subflow setup might improve the MPTCP
>establishment performance.).
>
>Regards,
>Mark.
>
>
>A new draft has been posted, at
>http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie.
>Please take a look at it and comment.
>