Re: Question about init and retry mecanism and subsequent INIT packet received.
Martin Thomson <mt@lowentropy.net> Mon, 25 September 2023 23:17 UTC
Return-Path: <mt@lowentropy.net>
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 E139EC17EB4A for <quic@ietfa.amsl.com>; Mon, 25 Sep 2023 16:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b="OMpIdwhu"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="qptDOQJj"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnksPlCLQKs5 for <quic@ietfa.amsl.com>; Mon, 25 Sep 2023 16:17:37 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4850C17EB4B for <quic@ietf.org>; Mon, 25 Sep 2023 16:17:37 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7A4CE5C0568 for <quic@ietf.org>; Mon, 25 Sep 2023 19:17:34 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute6.internal (MEProxy); Mon, 25 Sep 2023 19:17:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1695683854; x=1695770254; bh=Qf gPtR4L7DSkKXRfRDQbBxz2OZwX/nv3iv+z1lzqujo=; b=OMpIdwhuj2Oinuz+qO 8eKAuGceZpGoLqr4bndnrpBKMcUzQQ/MtuN1lLqr6Ym6ULzx/Ipu4bJdtfmA0dx9 Q5qmO3ZxU+AkvHzTIRtbBck11G6GTLzOkq04Vrrqid72InKAcTg5K0JisJrh/Di9 jQxXTNyB1nnH/ueilxl5jIBQXKHv8ROMXhAdxiRsNW9r1y6khIT5rS5b2sIJaE8X CMEXnZvN2KpTw8PgSQDmX7Rboudm5NKz2EM0wo9O6Wu2t17KehXLS/tMps7DviG+ AsR5rSaMhG4Hf40TjRPBGPq7YEbrsx6kKvCZHwPRCD/Use4f0POvUzajfFMPG4XO LaoA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1695683854; x=1695770254; bh=QfgPtR4L7DSkK XRfRDQbBxz2OZwX/nv3iv+z1lzqujo=; b=qptDOQJjDU6zaQgqHFA9ns1RV0EdN J5SCpYPeYl8oKOwD2sLMq1chr090bJMo+teAn/K7ToT2TGPc9ISfky9Xp7DpOmTW vnHTvWhCi0JJrZHEL10rYWAA6h4MWjXCpZw0qhSCEx34H7HvH4Sfu4nE85zeLwB1 TaMk74EUZeh3St1lIpCDE7klZCO/+mHeqL9gEiwyCyMx7fx3r5enycjCbMxxPjBM 6iGiI585oQ0dtMtGht+ZDwfk6DG/iJbQWyxdd8JgdSpbV4Vw2xD/14xsSR7Z5iki xSyngV1SMnZ2CDzFjG9V8b3//xQQPlPkcjB6SHodHfyg4gztjFwher46A==
X-ME-Sender: <xms:DhUSZcyAZFpoyA58lW076Kx1eqeP3JZur56IZzVOj_CzKo4g4lXb4A> <xme:DhUSZQQ7iLTftUsTxE8YESMW7YZ2TQP1T7Y25ebo4Y3jXlwcluJGFBr-OtN0DPEcA vf3-DLISNAfryOOVMg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudelhedgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy: <xmx:DhUSZeUQFxrt259xcxhjDG8k4awpetEHKpxa2F5EHbBocPkrfgr08Q> <xmx:DhUSZahb_0K0ymnQCKEabfk3j0EmLAdojh0pjlTAcMeWQzZJPbYXiQ> <xmx:DhUSZeC6Nl5U24c38a4gBrcgUIrdrGtZVHFNSJwrQqnfWRGHgdLbxA> <xmx:DhUSZRO5v_AZ7ooLhTazRFLyM60bh2vDGeHwIk8_phTvztHst-MWxA>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3EDB2234007E; Mon, 25 Sep 2023 19:17:34 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-957-ga1ccdb4cff-fm-20230919.001-ga1ccdb4c
MIME-Version: 1.0
Message-Id: <e24c5dd1-f98c-4cc0-8600-92fac9887c36@betaapp.fastmail.com>
In-Reply-To: <04065bc6-c1fa-896c-dc95-81d72866133d@haproxy.com>
References: <04065bc6-c1fa-896c-dc95-81d72866133d@haproxy.com>
Date: Tue, 26 Sep 2023 09:17:14 +1000
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Question about init and retry mecanism and subsequent INIT packet received.
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/LczXF_ux4lDfeEp686enlk1-RKc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 25 Sep 2023 23:17:43 -0000
Hi Emeric, On Tue, Sep 26, 2023, at 00:03, Emeric Brun wrote: > 17.2.5.2: " A client sets the Destination Connection ID field of this > Initial packet to the value from the Source Connection ID field in the > Retry packet. > > Server must check this? This is what my Server current implementation > tries to do this but doing that it is unable to validate the token at > step (5) and drops some INIT packets from the client. The server does not need to check this part. The client is expected to set the DCID on subsequent Initial packets because this is what will ensure that the packet is routed correctly. Anything else and it is possible that the Initial and token will not reach a server that are able to understand the pair of messages. Consider the case where you have different token keys on different server instances. That is possible under the QUIC design, because the server instance can choose a connection ID that will route to a specific instance. If the client does not follow the rules and copy the SCID from the Retry into the DCID of the subsequent Initial packets, then maybe it will work (because the server doesn't check) or maybe it will. It can fail either because the server does or because the packet gets routed to an instance that rejects the attempt to make a connection. If you want to statically enforce this behaviour at a server, then you will need extra state (either at the server or in the token, as you say), but I don't think you absolutely need to do this enforcement. Perhaps we should have said something about what a server can do here -- maybe with a "MAY" -- though I don't think this is a huge problem. My own implementation of this logic only stores a timestamp and the DCID from the very first client Initial in the retry token plaintext. The source address is added to the AAD to save space. Of course, that is a toy implementation, so don't pay too much attention. You might have good cause to track other state. Cheers, Martin
- Question about init and retry mecanism and subseq… Emeric Brun
- Re: Question about init and retry mecanism and su… Martin Thomson
- Re: Question about init and retry mecanism and su… Emeric Brun