Re: [quicwg/base-drafts] Client that does not PAD does not negotiate? (#4021)

Mike Bishop <notifications@github.com> Wed, 19 August 2020 20:00 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBA53A0A64 for <quic-issues@ietfa.amsl.com>; Wed, 19 Aug 2020 13:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 zQZQUDmj5E7h for <quic-issues@ietfa.amsl.com>; Wed, 19 Aug 2020 13:00:31 -0700 (PDT)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDD43A0A66 for <quic-issues@ietf.org>; Wed, 19 Aug 2020 13:00:31 -0700 (PDT)
Received: from github-lowworker-1b8c660.ash1-iad.github.net (github-lowworker-1b8c660.ash1-iad.github.net [10.56.18.59]) by smtp.github.com (Postfix) with ESMTP id 5E9A9560065 for <quic-issues@ietf.org>; Wed, 19 Aug 2020 13:00:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1597867230; bh=Zf4uqjRRPOKi2NmX9EtrWPXQvbB/xVMM4JZ/1OeKZbU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=fMqjxhkqz+dis0kpbuEDGmI+vXTPytARVBie3NSaFzEJP1IMMsQ89jTKLE6JmpCP7 RSW3b4mQcaXc2KVFhxcieMkQ3Va+3pbz4fwDh1MMD5HbcSQSMmiEKtGcsZcGv3If2c mTeftsFkAx7bHkwbn/qUfGp0hdjCjJkSBaa9dvQ0=
Date: Wed, 19 Aug 2020 13:00:30 -0700
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4SARCDAXYV7GXWG455JFS55EVBNHHCRJGOKE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4021/676631755@github.com>
In-Reply-To: <quicwg/base-drafts/issues/4021@github.com>
References: <quicwg/base-drafts/issues/4021@github.com>
Subject: Re: [quicwg/base-drafts] Client that does not PAD does not negotiate? (#4021)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f3d84de4f340_7efa19641797aa"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/GL5OPFZFqx5wf6iCAAZwi1XlvQM>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2020 20:00:33 -0000

Yes, a client that does not pad to at least the minimum packet size for some version the server supports will not receive a Version Negotiation packet in response.  The corresponding server text is in 5.2.2:

> If a server receives a packet that indicates an unsupported version but is large enough to initiate a new connection for any supported version, the server SHOULD send a Version Negotiation packet as described in Section 6.1. A server MAY limit the number of packets to which it responds with a Version Negotiation packet. Servers MUST drop smaller packets that specify unsupported versions.

This is both to prevent an attack vector from spoofed packets, and to reduce the risk that a non-QUIC packet will trigger Version Negotiation in response.  There is a slight risk that the client might only support version of QUIC with smaller minima and the connection attempt will time out instead of discovering via VN that there are no mutually supported versions.  However, if there is any overlap, compliance with this SHOULD enables the client to trigger the server's VN response.

Yes, this aligns with the guidance in Section 8.1:

> Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary.

and Section 14:

> A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see Section 12.2.
> ...
> A server MUST discard an Initial packet that is carried in a UDP datagram with a payload that is less than the smallest allowed maximum packet size of 1200 bytes.

However, those are in regards to a packet from *this* QUIC version, while the text you're asking about regards packets when the peer's QUIC version is unknown as of yet.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4021#issuecomment-676631755