Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Fri, 31 October 2014 13:21 UTC

Return-Path: <evyncke@cisco.com>
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 85AF21A8868 for <v6ops@ietfa.amsl.com>; Fri, 31 Oct 2014 06:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 C7eg8KO9IebG for <v6ops@ietfa.amsl.com>; Fri, 31 Oct 2014 06:21:07 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800DA1A8967 for <v6ops@ietf.org>; Fri, 31 Oct 2014 06:21:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4586; q=dns/txt; s=iport; t=1414761666; x=1415971266; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zw1hmDJ9KJgVUxCBmGUZsTjqw129WJCkHu7yScpvUK4=; b=RBB3R7Rk4fpA0SKbJCQLyzxyzbZhxFdl8lz0fMwrwVXprwP0p4k+Xyok bNQrKn//V9LPz3CJ95bXtAiIUCxWLAA8mw4XdjK41AVCUqEp3T+zFl/Un f8nzhhM+8a9601s3fYVhkT1Oq8gFkgl2u+NhGw3GQBp+XFzDiBMbVBqsB 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4FAEuMU1StJV2b/2dsb2JhbABUCIJrI1RYBIMCyhYKh00CHHsWAQEBAQF9hAIBAQEEAQEBIBE6CxACAQgRBAEBAQICJgICAiULFQgIAgQBDQWILAMSAQy1A5RwAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBLY0pgWICIxgbB4J3gVQFhRkFjHeHEIJIgguPW4Ztg3hsgQZCgQMBAQE
X-IronPort-AV: E=Sophos;i="5.07,294,1413244800"; d="scan'208";a="368188333"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 31 Oct 2014 13:21:05 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9VDL5mJ001432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 13:21:05 GMT
Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 08:21:05 -0500
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>, "Fred Baker (fred)" <fred@cisco.com>, Erik Nygren <erik+ietf@nygren.org>
Thread-Topic: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt
Thread-Index: AQHP9MNQKJIumVyT6ES71v1qwzlW3ZxKlhWA
Date: Fri, 31 Oct 2014 13:21:05 +0000
Message-ID: <D0794B14.30ED3%evyncke@cisco.com>
References: <20141027195522.23487.548.idtracker@ietfa.amsl.com> <5A5248BF-9E86-4B90-B344-C2DE1A3A8B56@cisco.com> <CAKC-DJhMf72D4wUcSL1_t_mSBLHotNm2KPE4v8OW94wfpHMN5w@mail.gmail.com> <71D94EF2-2740-4BC8-BA1D-40A667A9BD8E@cisco.com> <1414729592.66054.YahooMailNeo@web162204.mail.bf1.yahoo.com>
In-Reply-To: <1414729592.66054.YahooMailNeo@web162204.mail.bf1.yahoo.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [10.55.185.73]
Content-Type: text/plain; charset="utf-8"
Content-ID: <DB39EBBD9D30814795C146C6F94CBC1C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TlvVSKCeSPc-QkL6GUlRj2bQiX0
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt
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: Fri, 31 Oct 2014 13:21:09 -0000

Mark,

My understanding of MTCP is that the application layer always sees the
same (the first one I guess) IP address and does not see all the different
ones involves in the sub flows.

-éric

On 31/10/14 05:26, "Mark ZZZ Smith" <markzzzsmith@yahoo.com.au> wrote:

>
>
>
>
>
>>________________________________
>> From: Fred Baker (fred) <fred@cisco.com>
>>To: Erik Nygren <erik+ietf@nygren.org>
>>Cc: IPv6 Operations <v6ops@ietf.org>
>>Sent: Wednesday, 29 October 2014, 8:19
>>Subject: Re: [v6ops] Fwd: I-D Action:
>>draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt
>> 
>>
>>
>>
>>
>>On Oct 28, 2014, at 2:07 PM, Erik Nygren <erik+ietf@nygren.org> wrote:
>>
>>On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker (fred) <fred@cisco.com>
>>wrote:
>>
>>I would be interested in folks’ view of this. Is this interesting?
>>>
>>
>>
>>This is mentioned in section 8.2 of rfc6883 but keeps coming up over and
>>over again
>>
>>so may be worth calling out more clearly.  I'd title it in some way that
>>didn't make it seem like
>>a happy eyeball specific issue.
>>
>>It's not just a happy eyeballs issue.  It also happens with dual-stack
>>environments where cookies or session or authentication tokens span
>>origins where some servers are dual-stack and some are IPv4-only.   (For
>>example, an auth granting service grants bearer tokens locked to the
>>client IP address and then the client connects to some other service on
>>a different hostname and passes along the tokens.  Even absent Happy
>>Eyeballs these can be on different IP versions.)
>
>I'd think Multipath TCP could also cause these issues, as the MPTCP
>subflows are not limited to the IP protocol that application 'thinks' it
>is talking. Even MPTCP subflows of the same IP version to the same
>destination across session might end up with this issue if the subflows
>come up in different order.
>
>
>>
>>
>>
>>An important thing, in my mind, is that Happy Eyeballs isn’t
>>fundamentally about IPv4 and IPv6, it’s about multihoming, which is to
>>say that I have more than one address and more than one route, and it is
>>conceivable that one or more of my addresses or routes doesn’t work. If
>>I am multihomed in the sense of having multiple IPv4 paths, I can have
>>the same problems, and I can have the same problems if I am IPv6-only
>>but have multiple upstreams.
>>
>>
>>
>>
>>
>>The large-scale NAT/CGN issue does make this not just an IPv6 issue.  At
>>least some systems I've seen then check the IP in the cookie to make
>>sure it's in the same /24 rather than the exact same IP, but that
>>doesn't help in the dual-stack world.
>>>
>>>Another issue beyond Happy Eyeballs is that privacy addressing bites
>>>you here as well for cookies that are used across different TCP
>>>connections spanning a privacy address rotation.
>>>
>>>
>>>Having some more clear "don't do this" to point people to would be
>>>good, but I suspect we'll have many years of cleaning up applications
>>>doing this.
>>>
>>
>>
>>_______________________________________________
>>v6ops mailing list
>>v6ops@ietf.org
>>https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops