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

Ray Hunter <v6ops@globis.net> Wed, 11 February 2015 14:44 UTC

Return-Path: <v6ops@globis.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423761A8937 for <v6ops@ietfa.amsl.com>; Wed, 11 Feb 2015 06:44:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1KBF7ap6zEx for <v6ops@ietfa.amsl.com>; Wed, 11 Feb 2015 06:44:52 -0800 (PST)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 49FAE1A8935 for <v6ops@ietf.org>; Wed, 11 Feb 2015 06:44:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1F012871625; Wed, 11 Feb 2015 15:44:51 +0100 (CET)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uon8-264gF9n; Wed, 11 Feb 2015 15:44:51 +0100 (CET)
Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id E1894870069; Wed, 11 Feb 2015 15:44:50 +0100 (CET)
Message-ID: <54DB6AE1.4040504@globis.net>
Date: Wed, 11 Feb 2015 15:44:49 +0100
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: v6ops@ietf.org
References: <201502111247.t1BCl1Ek003460@irp-lnx1.cisco.com>
In-Reply-To: <201502111247.t1BCl1Ek003460@irp-lnx1.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/Bxctn30gxgKS6Q7IF1HmdwipLG8>
Cc: draft-vyncke-v6ops-happy-eyeballs-cookie@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-happy-eyeballs-cookie
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2015 14:44:59 -0000


fred@cisco.com wrote:
> 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