Re: [quicwg/base-drafts] Curtail CONNECTION_CLOSE for small Initial (#3292)

Kazuho Oku <notifications@github.com> Tue, 10 December 2019 06:47 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 6DD2E1200CC for <quic-issues@ietfa.amsl.com>; Mon, 9 Dec 2019 22:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 FMTPiVEGE5pi for <quic-issues@ietfa.amsl.com>; Mon, 9 Dec 2019 22:47:40 -0800 (PST)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E473120020 for <quic-issues@ietf.org>; Mon, 9 Dec 2019 22:47:40 -0800 (PST)
Received: from github-lowworker-2300405.va3-iad.github.net (github-lowworker-2300405.va3-iad.github.net [10.48.17.39]) by smtp.github.com (Postfix) with ESMTP id 0308A66083E for <quic-issues@ietf.org>; Mon, 9 Dec 2019 22:47:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1575960460; bh=c6xaYU3ellTE1gOds+BVd8mzmbY2fxDwNplEx7Uoxig=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ACUCOQycWN92vnGm+GY3wrv1zriak/gT4mD4I01jdiqWChyHtdOYlCbuhTbqbtY6V VIOkhMNYF67uCyp92oXIECDH/qWJ32XKVvc0zUwbQL/Q3JKdq1Gz+n+499r1oJ/Lli J6FUyJuhCXI3npPiSthUHhb8Jc/NhApybnup62P8=
Date: Mon, 09 Dec 2019 22:47:39 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2QYA36ZLIPHA27RPF37RZAXEVBNHHB7XUJLA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3292/review/329617091@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3292@github.com>
References: <quicwg/base-drafts/pull/3292@github.com>
Subject: Re: [quicwg/base-drafts] Curtail CONNECTION_CLOSE for small Initial (#3292)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5def3f8be72ed_a673fab0a6cd960840bb"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/at5FrCnVBIh9DORDCKbBrB1OCOs>
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: Tue, 10 Dec 2019 06:47:42 -0000

kazuho commented on this pull request.



> @@ -3476,10 +3485,12 @@ Datagrams containing Initial packets MAY exceed 1200 bytes if the client
 believes that the Path Maximum Transmission Unit (PMTU) supports the size that
 it chooses.
 
-A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in
-response to an Initial packet it receives from a client if the UDP datagram is
-smaller than 1200 bytes. It MUST NOT send any other frame type in response, or
-otherwise behave as if any part of the offending packet was processed as valid.
+A server that has no existing state for a connection MUST discard an Initial
+packet that is carried in a UDP datagram that is smaller than 1200 bytes.  Other
+packets in the datagram SHOULD also be discarded.  A server MAY send a
+CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in addition to
+discarding a packet if that does not affect a connection for which the server
+has established state; see {{immediate-close}}.

> The goal is to use CONNECTION_CLOSE as a signal only, with the intent of triggering the corresponding logic at the client.

I think it is not a bad idea to have a MAY for that.

> But the server is discarding this packet and so it won't have any connection state. This won't result in creation or destruction of server state.

I do not think that the sentences reflect what you think. Quoted below are the last two sentences of this paragraph. It is my understanding that the intention of the last sentence is to clarify the rationale behind the previous sentence, but as you can see from the emphasized text, they are discussing about different conditions.

> _A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in addition to discarding a packet if that does not affect **a connection for which the server has previously established state**.  Sending CONNECTION_CLOSE will not affect server state in the same way as an immediate close ({{immediate-close}}) **as the server has no state**, but it will cause any client to terminate a connection attempt._

I think what we actually want to state is something like:  _A server that has no existing state for a connection MUST discard an Initial packet that is carried in a UDP datagram that is smaller than 1200 bytes.  Other packets in that datagram SHOULD also be discarded. In addition to discarding the packet, a server MAY respond with a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION, without creating state. When a server receives such an Initial packet for which it already has connection state, it MUST either drop that packet or close the connection with error code PROTOCOL_VIOLATION ({{immediate-close}})._

-- 
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/pull/3292#discussion_r355866386