Alternative ways to keeps ODCID on the server

Dmitri Tikhonov <dtikhonov@litespeedtech.com> Fri, 24 January 2020 22:24 UTC

Return-Path: <dtikhonov@litespeedtech.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 B3ED8120A2E for <quic@ietfa.amsl.com>; Fri, 24 Jan 2020 14:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-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 ZBp0r4qI3O0t for <quic@ietfa.amsl.com>; Fri, 24 Jan 2020 14:24:45 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 0B5DC120A05 for <quic@ietf.org>; Fri, 24 Jan 2020 14:24:45 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id 21so3697572qky.4 for <quic@ietf.org>; Fri, 24 Jan 2020 14:24:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=idNCEI8F11OK96Hn3OG4ZwL3uTy9TBHV6W1qlzw2LHo=; b=VrMQYquWovBm5Z8d3cLuBeoTdhFxwJ/HQNYgAtp7iwt4rshPvd/r0FE+uv4BUfRYk8 E4R2mrkPsjOY9t7i0pa3aA/ISF8b5HNHxFNXetGi7Gda/NQBdFuTKLAPYMfaj9NaWl6H IYbgD0JkcH0BdGtw+0XmynhunrtIrOke2nlkcropiKS+pf+IY06ouC0MmYTmWjjpP75x Y37FeX6GvtOK9QL9XZpDb9yhfpeLCMZEMmIiJFNLBDShy7lMQIdh1obx+5KlKZ9/qEKZ RLqP1rwW0NV/ZIys3ikEkptZ2JtTsyx53OiF6xgSmaLHlSbOsDM6+LV+/OdhZEZbHvzM pn1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=idNCEI8F11OK96Hn3OG4ZwL3uTy9TBHV6W1qlzw2LHo=; b=D1ymfVv3XzwwT2PUgW7Kv9cKw7dIaRrwI2WHu/aS0R9/bsNyWIkPcBn9MK10WPvKdV Suci8iTZ+C1WSg1ugtrBEjQE6dGDAK2gAtz2Jh/okRFiqziNjHh/8MJwtjeU37IFxZnT fVe15j8zFtOEHCPSTBuc1NplDfICSiTw18MWIpuKq5DGN6Qqrd0A+0Ln6RkSvqUlqywi KWaP+N1FgwwEaR3xDU3p4K89c4l9wkV8Px4yhE9ddGYR8UxXoKRmitYxFIpoO/ybsKDX g6SVSzxjV54XKtTxFeITei93zL/nBw6tLO8T2uRhp/cXUeIESRD3X7d8pN/RStUaUqUI GYrQ==
X-Gm-Message-State: APjAAAVJq/JZsAqdb+cQ0OCt0SQ7XaWv9Am7sQqPW0asL1pLESKYgF5A 5t/XLtCwKQKkAnTtRfM9bKHVDlUkoTo=
X-Google-Smtp-Source: APXvYqw2UBQMDKOwGOFuN88aUjMwEjQpgy0aIPdXOk5dfpFiiny4w25vsjA8fnC7nlRlCRV1MVRZ/A==
X-Received: by 2002:a05:620a:718:: with SMTP id 24mr5042564qkc.77.1579904683783; Fri, 24 Jan 2020 14:24:43 -0800 (PST)
Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id s20sm4053855qkj.100.2020.01.24.14.24.43 for <quic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jan 2020 14:24:43 -0800 (PST)
Date: Fri, 24 Jan 2020 17:24:35 -0500
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: IETF QUIC WG <quic@ietf.org>
Subject: Alternative ways to keeps ODCID on the server
Message-ID: <20200124222434.GA8279@ubuntu-dmitri>
Mail-Followup-To: IETF QUIC WG <quic@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/yKT-ywRQPoR186w-ZuA468eus3o>
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, 24 Jan 2020 22:24:47 -0000

Hello,

PR 3107 introduced the following text:

   If a server receives a client Initial that can be unprotected but
   contains an invalid Retry token, it knows the client will not accept
   another Retry token.  The server can discard such a packet and allow
   the client to time out to detect handshake failure, but that could
   impose a significant latency penalty on the client.  A server MAY
   proceed with the connection without verifying the token, though the
   server MUST NOT consider the client address validated.  If a server
   chooses not to proceed with the handshake, it SHOULD immediately
   close (Section 10.3) the connection with an INVALID_TOKEN error.
   Note that a server has not established any state for the connection
   at this point and so does not enter the closing period.

The problem with the "server MAY proceed" part is that the server's
transport parameters MUST include original_connection_id.  If ODCID
cannot be extracted from the invalid Retry token, then the server
cannot let this connection proceed.

Questions:

    1. The Retry token seems like the obvious place for the server
       to store ODCID.  Is there an implementation that does something
       else (state on server)?

    2. Should we spell out this caveat in the draft?  I.e. "server MAY
       proceed if it possesses ODCID."

Thanks,

  - Dmitri.