Confusion about PR#3499

Eric Rescorla <ekr@rtfm.com> Fri, 08 May 2020 22:33 UTC

Return-Path: <ekr@rtfm.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 7A48B3A0FFE for <quic@ietfa.amsl.com>; Fri, 8 May 2020 15:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 9_HKSQ4Zmp4V for <quic@ietfa.amsl.com>; Fri, 8 May 2020 15:33:32 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 12EE73A0FFC for <quic@ietf.org>; Fri, 8 May 2020 15:33:32 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id j3so3322500ljg.8 for <quic@ietf.org>; Fri, 08 May 2020 15:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=KJH/HNUbeKGHG7LmCR5C3CkzWK8d3l2SqJjONSq/g3c=; b=vaYTs0/f9hEq5eqMpCSGeL4jr1I+IaZTCTiCZi3TGHOVG4MmQIJ8tyu/OPdHJI/dbP c3c7/XSeuyP6JHUJZ+JsJK2YSaMYG4YS+v+gvf2/c2NDbR62iTTY2+Rgw9Ef5EhO22SL OczsamYO4iyC+oR9pSe9t6BAdIel1B03f6i+MtQkLNdY81L22TEHEovvP0VILxp8MQSc Zue8Xvamkds7TEz2hsTa9SDmsKEeCUr8nKAlvuj8BmQFNvzZkegW3pXM3Z76G5ZfPcdt gcI02tPG+UDFicQPDNsj0dyNtI6dBuCdBgaip0PiowwwG8h/38J5Nf852VgvpgMTuxc6 mxhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KJH/HNUbeKGHG7LmCR5C3CkzWK8d3l2SqJjONSq/g3c=; b=Y+R0+QvoLWLQbfqs/60a68XO9htZqURPEcJU4yKTLRIm8pdCm/NoVInMjDf7Uv8grt KzJFTMGLUMGvWq5tvHFC099Zx2wa9SWLmEdWp0Gq/oQjvetJTAI//e3Hkt4W7msgPAuH oRvipS/+YCX/FC31kXvz7GXzPzHomJ9V5tP6OiJVbGzW5+wT1n2PW24UGkEoZJCkVXNS QttqnzspdyKo/9UeEqdu+wh/z41jVIjsAoxSxjDR2/g11HKIDQWEq3J/IAzvzBruPCUI Dos0h6wQ2WO4sZbQFGYTqo3mcHvk4jNY47iR053aTLMXT7nirpr4kYBLzvmJ3Waa+l3c zFeQ==
X-Gm-Message-State: AOAM531J1RUc7e4R//WKcJmVrVMRjj1lknTetYhGdnIBmBVRGHKd3hbZ lPadmSIA8BNte+ShpVm0R3ItWst0PMML1JuJSykmpMM/JnfHMw==
X-Google-Smtp-Source: ABdhPJzAVNUZWcsVWNt+rFL4WmN9bCvCKxaAF9b+MJPrw3pjnRpwxSmzbXtsZmd0XAaIJX2hM0kfdnj2nIA7tH1DBDU=
X-Received: by 2002:a2e:8813:: with SMTP id x19mr3148633ljh.83.1588977209984; Fri, 08 May 2020 15:33:29 -0700 (PDT)
MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 8 May 2020 15:32:54 -0700
Message-ID: <CABcZeBMw0TvSER9p3anohvm-hq=PZ03ayH+NZfBQ5RfMsxx_EA@mail.gmail.com>
Subject: Confusion about PR#3499
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000286bc405a52a96fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/bYvFYGa7jH-TBZh1tJofMWJYNws>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 08 May 2020 22:33:35 -0000

OK, I'm trying to make sure I understand this PR correctly. It's
possible I'm just misunderstanding a lot of stuff, but as I go through
it, I'm finding things that are confusing to me.

Let's consider the following simple handshake, with each
flight being one arrow below:

   Client                                 Server

   Initial [CH] SCID = C1, DCID = S1 ----------->
   Initial [SH] <----------- SCID = S2, DCID = C1
   Handshake [EE...]  <----- SCID = S2, DCID = C1
   Handshake [CFIN] SCID = C1, DCID = S2 ------->
>
Now, based on this text, let's try to populate these fields.

The client sends only initial_connection_id, which is defined
variously as:

  Each endpoint includes the value of the Source Connection ID field from
the most
  recent Initial packet it sent in the initial_connection_id transport
  parameter; see {{transport-parameter-definitions}}. A server includes the

And:
  The value that the endpoint included in the Source Connection ID field of
the
  first Initial packet it sends during the handshake; see {{cid-auth}}.

Note that these definitions are actually in conflict, because the first says
it's the most recent Initial packet and the other says the first Initial
packet. However, as it happens only one Initial is sent, so it doesn't
matter.

So initial_connection_id = C1



SERVER
The server also sends initial_connection_id, which is S2.

It also sends original_connection_id, defined as:

  parameter; see {{transport-parameter-definitions}}. A server includes the
  Destination Connection ID field it receives in original Initial packets
from the
  client - Initial packets received by the server prior to sending a Retry
packet
  - in the original_connection_id transport parameter. After sending a Retry
  packet, a server also includes the Source Connection ID field from the
Retry
  packet in the retry_connection_id transport parameter.

And

: The value of the Destination Connection ID field from the first Initial
packet
  sent by the client; see {{cid-auth}}.  This transport parameter is only
sent
  by a server.  The value of this parameter depends on whether the server
  sent a Retry packet; see {{packet-retry}}.

And

  A server always includes an original_connection_id transport parameter.
If it
  sends a Retry packet, the server MUST subsequently include the Destination
  Connection ID field from the client's original Initial packets - packets
  received by the server prior to sending the Retry packet - in the
  original_connection_id transport parameter. If the server did not send a
Retry
  packet, the value of the original_connection_id transport parameter MUST
be
  copied from the Destination Connection ID field of the most recent client
  Initial packets.

So again, we have an inconsistency here between "first Initial packet"
and "most recent client Initial packets". In the handshake above it
doesn't matter, but consider what happens if the server's Initial spans
more than one packet and the client sends an ACK. As I understand it, that
would look like this:

   Client                                 Server

   Initial [CH] SCID = C1, DCID = S1 ----------->
   Initial [SH1] <---------- SCID = S2, DCID = C1
   Initial [SH2] <---------- SCID = S2, DCID = C1  // LOST
   Initial [ACK] SCID = C1, DCID = S2 ---------->

So now we have two Initial packets with different DCIDs. Which one
goes in this field? Or have I forgotten how ACKs work with Initials?

I've got some further questions, but I'd like to get unconfused about
this before I keep going.

Thanks,
-Ekr