[quicwg/base-drafts] Small clarification in 12.2 Coalescing Packets (#2900)

anrossi <notifications@github.com> Mon, 15 July 2019 22: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 []) by ietfa.amsl.com (Postfix) with ESMTP id 8AA35120140 for <quic-issues@ietfa.amsl.com>; Mon, 15 Jul 2019 15:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Status: No, score=-6.597 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id j7JWDAXG2JL3 for <quic-issues@ietfa.amsl.com>; Mon, 15 Jul 2019 15:00:40 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C024D12002E for <quic-issues@ietf.org>; Mon, 15 Jul 2019 15:00:40 -0700 (PDT)
Date: Mon, 15 Jul 2019 15:00:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1563228039; bh=APZ548DE0O/EeCOhyTARJ6YCdzkjlUhoNRoZKzVqpNo=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=VDOqa6b347OtSciQMXB82VkmO6gkvgkGKh0j9Y/Gic9cDQas4CMVKmXJQgpRNG5Ld EKwJn4fiUzh2arB2sImNuOXZQhFIGUveA987C1yU6DmwmztF/DCsKmGnCdZQbFpzru ojZyILAxmOPWq7xDTK7jXbvrnXl5jXb2vcKD+9aA=
From: anrossi <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYZLVODOMW5IB2LNYN3HIVAPEVBNHHBX2UGWQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2900@github.com>
Subject: [quicwg/base-drafts] Small clarification in 12.2 Coalescing Packets (#2900)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d2cf787b092b_73063fca9cecd960989bf"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: anrossi
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/035vy1jhZNSKCs4umc5IBXb-4N8>
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: Mon, 15 Jul 2019 22:00:43 -0000

In some testing with WinQuic, we noticed a small inconsistency in Section 12.2 of the transport spec that needs some clarification.
Section 12.2 says that if decryption fails, an implementation MUST attempt to process remaining packets in a coalesced UDP datagram. However, consider the following scenario:

1. An endpoint received a UDP datagram with a single short header packet, the first of the 1-RTT encryption level. This implicitly ACKs the end of the handshake and the receiver discards the handshake keys.
2. The sender then sends a coalesced datagram with a single long-header packet (an ACK for the handshake), and then a short header packet containing more 1-RTT data.

Since the receiver has thrown away the handshake keys, they are unable to decrypt the long header packet in the second datagram, and without being able to decrypt the header protection on the long header packet, they cannot ascertain the length, and are unable to find the short header packet that follows. As a result, the whole datagram is thrown away.

Can the "MUST" referenced above be clarified for which scenarios are/aren't supported?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: