Re: Asymmetric CIDs

Ian Swett <ianswett@google.com> Fri, 16 February 2018 22:45 UTC

Return-Path: <ianswett@google.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B2912008A for <quic@ietfa.amsl.com>; Fri, 16 Feb 2018 14:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xIJq8bevMkba for <quic@ietfa.amsl.com>; Fri, 16 Feb 2018 14:45:24 -0800 (PST)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 9895C1243FE for <quic@ietf.org>; Fri, 16 Feb 2018 14:45:24 -0800 (PST)
Received: by mail-io0-x22a.google.com with SMTP id 72so5698331iom.10 for <quic@ietf.org>; Fri, 16 Feb 2018 14:45:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r79g4ggi+k92QhRYIdyfGN43PvRXSKASCNaHB2UBV5Y=; b=F3kmLu4vydS/2eiyF2oS8pAbscEQ6+Jf4pnygeAQTRYtKdacdhgpBHx2VazX1oQMG/ cNtBFeIl+UndcZZcC9jD+7qVvv7pEoe9Fg4m/5KRFMT93//uuHZGLbq5I1esRB97sZ0X MgwwOEPmA9ZGuDcxfpEl7VGsDYHb2tl5l1FcJp+XaIcLFW6so3fZ7ightFQlTpV52uU4 xQsbSeVb/pxOjvKeTZai0lNaOEZWYe/4GSkkAEW4X/+qWYxbn76UUJSj2bpOVhKkJHpc X86vCKDIC+QScWmAXvK9qQf+7eFEITJpIZpy9avpe69J3YgaJabTku2CFCoizrz+n2Gj t5eg==
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=r79g4ggi+k92QhRYIdyfGN43PvRXSKASCNaHB2UBV5Y=; b=aWHDr7aFusKC+w/M16A2eOMQws0XEqGhUnO8dF25IQTu081k4LjAzig5V7pLnbnj7/ ls8wXFCm4dB68JqeNB5dsDPUOL3VhdK/Hb20B6OjcM/f0aFqqy45rQC45yY2w/5ObRWa awl9eTaRegBrvE1vVTVcD3IZOML/+vSgzgcRaFzel/ozN4yqGOMl7cQJxh4s85qlggGa zvDmBrZuS3orrhEMDlUIH8k2omd5ILUr7j4TbnmrBioGOaHcZl4apQec+fcef7ukc4kA sBH8A1VK5h875aTRSVTwQj+RlSs6aSNaQeEyZXIck4uCqt6HaQ3K7Fuo8ZO9RtQgjddO ksbw==
X-Gm-Message-State: APf1xPAdtCGsBfP7UHCi7NYNh74h9nV78yqPB61p0ubOTgLydIPqI9HA Y4JQUqy6t+8CpkfZNnzXR1RmzQwW8DNhmbSt33k3ng==
X-Google-Smtp-Source: AH8x224he77bOox9fuCHi81rH3vXVM337eb6TN6gHHL+/R2phcxEw8WAniFl2Josm0UORMRZAU9xfJhtQxOgLUs5Jzs=
X-Received: by 10.107.131.82 with SMTP id f79mr10315786iod.102.1518821123582; Fri, 16 Feb 2018 14:45:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.222.4 with HTTP; Fri, 16 Feb 2018 14:45:02 -0800 (PST)
In-Reply-To: <BN6PR21MB0178395DC04C19D991436525B3CB0@BN6PR21MB0178.namprd21.prod.outlook.com>
References: <CABcZeBMVabN9LQ42BxpSwK71hzu_TbzwqhHTJV1uJBKr5g-N3A@mail.gmail.com> <CAKcm_gOvf0N7sq2so38sQaD+2jHGnDpsSQHEwU8HPgSpMJRfzA@mail.gmail.com> <CAM4esxQW1-dVfJSi4zoURNV-7u0EP6h-Xdyx5Wbo0QMdrkLk=w@mail.gmail.com> <AA0705E2-7A79-47DD-846A-C0B74A8A4B24@huitema.net> <D7E469CD-B9D8-41ED-8F5C-9933DCBA90E6@fb.com> <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> <BN6PR21MB0178395DC04C19D991436525B3CB0@BN6PR21MB0178.namprd21.prod.outlook.com>
From: Ian Swett <ianswett@google.com>
Date: Fri, 16 Feb 2018 17:45:02 -0500
Message-ID: <CAKcm_gNeFJUP_1VFxSri=V+iDJR9RxvTwmca45bLM0m0BHo-Hw@mail.gmail.com>
Subject: Re: Asymmetric CIDs
To: Nick Banks <nibanks@microsoft.com>
Cc: huitema <huitema@huitema.net>, Roberto Peon <fenix@fb.com>, Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>, Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a113fb9268cf19905655c19f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/yMEh3FveVmFaTd5LkHKTbsTO5Dg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Feb 2018 22:45:26 -0000

I agree that could be a concern, but I think it's no more difficult to
solve than the status quo.  It just means both sides need to have more
connection IDs, not just one side.

Nick's solution is a good suggestion, but one can also imagine cases when
other connection IDs have previously been made available.

In practice, for most of the cases we're discussing, I'm expecting the
connection ID from server to client will be 0 bytes in length, making this
a non-issue.