Re: [TLS] Connection ID Draft
Eric Rescorla <ekr@rtfm.com> Wed, 18 October 2017 16:59 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62AA13234B for <tls@ietfa.amsl.com>; Wed, 18 Oct 2017 09:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 XLjaXJfZiAJk for <tls@ietfa.amsl.com>; Wed, 18 Oct 2017 09:59:39 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2431132031 for <tls@ietf.org>; Wed, 18 Oct 2017 09:59:38 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id l32so1131793ywh.13 for <tls@ietf.org>; Wed, 18 Oct 2017 09:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y57pmKdnsX5FBMIW/Ct2nxYTHjgCEArzgLwNfDlzvSg=; b=1SrVSseIYY2/V2iHkU1vuu3+B7FJlWKZA82uMR/FSl2M/YT4Mzj5UkfEMoyedXn2kU ZzF95ETr29mnngG7TC4LcCgdpIoy+FXTwPq61YwNzCouH8z71SAqcRts3keoH8lLFziC 3NLatH13byQIQymapHeajZ10Tui0RWS5hRpimRB0E0BVyKewCMOEK5dmp/xWollvDHoD b5kvBbFZSjq/dd7bl7+wy8WQetjjd7LKg41ZWvvKKpfOoPdeJu2PG90Q5kyY2T+NZfsf 2djn9B9+A8fN3ePaTsKLN98ZSsSWgw4TEjTaNikaqikpteNMOU1zdm39Y9t4SN2ugaJh kMEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y57pmKdnsX5FBMIW/Ct2nxYTHjgCEArzgLwNfDlzvSg=; b=M1dyNDK5xEAwnUDCQvRO53aFaJu6jEYFTpxqVmxgjmtFM5I4qVybFuSC9gZ/KmdnAE VGJZS8ofpNinkfG3ncB3usoL9mN0PoZCt5Q2Itu/IBwfcjKPDUXHJdaGhCJFWZL83SAM K4NjqrrSKWadT81oBMaIm/PtzTXAcU9Mx6+0eXJN932oz3U9A9M/Nv0ildPS9XNMiAu/ woGMJXPZe/Bgz3K39C/Lpy8QfBZctAnNBRI4xSThC2YwTB3B0IBKvGz0UjZ08Aav66Cd hqpOcJRLqF2SJko42CPQKrzDYVkkdrQoUyuQ7G+JLbAVnkXebVkz7yvU9AEUPVRCz72g 0HJw==
X-Gm-Message-State: AMCzsaXeDPWa0SWu1OgjW6JvIn1cTLwQg+07W/VUpd4foWkQornE0Vqr 9XO3NpRq0gdNmJYQKiBH6OgFGssPzD9e6ChNYtquAQ==
X-Google-Smtp-Source: ABhQp+QJp/PzZAmOKxDoHjqbKuc2hp6ONgAiHeedQBVSKT7ik5yrgOsY+KQUw1S9f9U8+YMa7fSYjuRXWo+wbVECtHA=
X-Received: by 10.13.192.196 with SMTP id b187mr1867782ywd.416.1508345978066; Wed, 18 Oct 2017 09:59:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.194 with HTTP; Wed, 18 Oct 2017 09:58:57 -0700 (PDT)
In-Reply-To: <9a6cbdb6-2064-b7f9-d5bf-8416e06e595a@simonbernard.eu>
References: <CABcZeBPXB6cOSztzDHtKSWUCJrgET+9cF_rAiiE8CYCUSY_uLA@mail.gmail.com> <CABkgnnXT7nv9aNQh12deeitF1CurENpxgUicn9GHjMbojcEvJg@mail.gmail.com> <D0524862-083C-4576-98B8-6D8A4825D458@nokia.com> <CABkgnnW4d=H5RZ0E+Hwo4jQptDpshVVuFtD-xQudJzxLXyReAQ@mail.gmail.com> <9a6cbdb6-2064-b7f9-d5bf-8416e06e595a@simonbernard.eu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 18 Oct 2017 09:58:57 -0700
Message-ID: <CABcZeBO6cy3SqgF_59gazQqkKTevZ8zjyc9qX8ZFFZEb+pUVfg@mail.gmail.com>
To: Simon Bernard <contact@simonbernard.eu>
Cc: Martin Thomson <martin.thomson@gmail.com>, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114edd4838af6f055bd52a56"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fTO6qgcJ7PLpGhwTg-7cijJbDFw>
Subject: Re: [TLS] Connection ID Draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Oct 2017 16:59:41 -0000
On Wed, Oct 18, 2017 at 9:39 AM, Simon Bernard <contact@simonbernard.eu> wrote: > This makes me think about if this is feasible/desirable to use connection > id to do load balancing. > > I think about use cases where you have a cluster of server behind only one > IP address. Often traffic will be load balanced by IP. > But with UDP and Nat environment, the IP can change. > > Thx to CID, if client is redirected to the same server in the cluster, > even if its IP has changed it will be able to communicate without new > handshake. > But if its IP has changed there is little chance than load balancer will > balance it on the same server and so new handshake is needed. (unless > server share their connection state) > The usual procedure is for the server and load balancer to coordinate on the CID algorithm. A trivial version would be for the server to generate the connection ID as <server-id> || <random>. -Ekr > > Any thought about that ? > > > > Le 17/10/2017 à 23:35, Martin Thomson a écrit : > >> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia - >> GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote: >> >>> The following case (NAT box reboot) is problematic: >>> >>> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on >>> host B (B.1); >>> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1; >>> 3. The NAT box reboots (all previous 5-tuple mappings are lost); >>> 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the >>> meanwhile); >>> >>> How is B.1 supposed to correctly interpret the bytes starting at offset >>> +11? (For what it knows, it could be CID from A.1 or the length field >>> from A.2.) >>> >> I don't think that this is a problem. >> >> connection = five_tuples.lookup(packet.five_tuple) >> if (!connection) { >> connection = connection_ids.lookup(packet[c >> onnection_id_offset:connection_id_offset+connection_id_length]) >> } >> if (!connection) { >> // is this a ClientHello? otherwise drop it >> } >> >> Of course this doesn't help you with A.2, but that's why this draft >> exists. >> >> If the server can insist on connection IDs from all clients (in the >> far future perhaps, or for an entirely new protocol), then the code is >> more simply: >> >> connection = connection_ids.lookup(packet[connection_id_offset:connection >> _id_offset+connection_id_length]) >> if (!connection) { >> // is this a ClientHello? otherwise drop it >> } >> >> I might be missing something fundamental here, but isn't the length >>> encoded in the CID field on the wire? >>> >> Not by my understanding. There isn't any need (the intent is to have >> the CID only consumable by the entity that created it, and any others >> that it collaborates with, like a load balancer). >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Martin Thomson
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Martin Thomson
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Martin Thomson
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Nikos Mavrogiannopoulos
- Re: [TLS] Connection ID Draft Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: [TLS] Connection ID Draft yinxinxing
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Matt Caswell
- Re: [TLS] Connection ID Draft Stephen Farrell
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Stephen Farrell
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Stephen Farrell
- Re: [TLS] Connection ID Draft Hannes Tschofenig
- Re: [TLS] Connection ID Draft Eric Rescorla
- [TLS] 答复: Connection ID Draft yinxinxing
- [TLS] 答复: Connection ID Draft yinxinxing
- Re: [TLS] 答复: Connection ID Draft Eric Rescorla
- Re: [TLS] 答复: Connection ID Draft Eric Rescorla
- [TLS] 答复: Connection ID Draft yinxinxing
- Re: [TLS] 答复: Connection ID Draft Eric Rescorla
- [TLS] 答复: 答复: Connection ID Draft yinxinxing
- Re: [TLS] Connection ID Draft Benjamin Kaduk
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Martin Thomson
- Re: [TLS] Connection ID Draft Christian Huitema
- Re: [TLS] Connection ID Draft Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: [TLS] Connection ID Draft Martin Thomson
- Re: [TLS] Connection ID Draft Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: [TLS] Connection ID Draft Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: [TLS] Connection ID Draft Martin Thomson
- Re: [TLS] Connection ID Draft Nikos Mavrogiannopoulos
- Re: [TLS] Connection ID Draft Simon Bernard
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: [TLS] Connection ID Draft yinxinxing
- Re: [TLS] Connection ID Draft Stephen Farrell
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Stephen Farrell
- Re: [TLS] Connection ID Draft yinxinxing
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Stephen Farrell
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft Benjamin Kaduk
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft yinxinxing
- Re: [TLS] Connection ID Draft Eric Rescorla
- Re: [TLS] Connection ID Draft yinxinxing
- Re: [TLS] Connection ID Draft Matt Caswell
- Re: [TLS] Connection ID Draft Martin Thomson
- Re: [TLS] Connection ID Draft yinxinxing
- Re: [TLS] Connection ID Draft Matt Caswell
- Re: [TLS] Connection ID Draft Martin Thomson
- Re: [TLS] Connection ID Draft Fossati, Thomas (Nokia - GB/Cambridge, UK)
- Re: [TLS] Connection ID Draft Matt Caswell
- Re: [TLS] Connection ID Draft Simon Bernard