[quicwg/base-drafts] What if the packet number of a retry packet is not zero? (#1448)

Christian Huitema <notifications@github.com> Fri, 15 June 2018 03:35 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 3E036127332 for <quic-issues@ietfa.amsl.com>; Thu, 14 Jun 2018 20:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 3IkETGjciWMy for <quic-issues@ietfa.amsl.com>; Thu, 14 Jun 2018 20:35:56 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECD1130ED1 for <quic-issues@ietf.org>; Thu, 14 Jun 2018 20:35:52 -0700 (PDT)
Date: Thu, 14 Jun 2018 20:35:51 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1529033751; bh=dviBe1oJ3uHvNEXyKDOcD9XAnE03obVMtGlAUf51MKs=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=OF5UZiHIfJxSyv9QiA1gQXFnvASDyim6yJkftzcU63SLu+7X/k56ejnF0ARnEL1AY r6O8wkurRe4aVY99Bf9l3xEoUEmbgrVEHbojfdCxyRkmeqU3c4h8Vu9UVs9J3UQloc ob16oI7ywn7XsU9ZwjgA/Umed7TnvnllGXvBxzIs=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abbec0fe6d428f7fcefceecd9acda7ff1a571ef4a992cf00000001173af61792a169ce13d39f1e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1448@github.com>
Subject: [quicwg/base-drafts] What if the packet number of a retry packet is not zero? (#1448)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b23341740823_3b793fb433c7ef802860c7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/HHOHX6efVvG8WNjfxYuLuPvZw9E>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 15 Jun 2018 03:35:59 -0000

The draft-12 spec says:
```
   The Packet Number field of a Retry packet MUST be set to 0.  This
   value is subsequently protected as normal.  [[Editor's Note: This
   isn't ideal, because it creates a "cheat" where the client assumes a
   value.  That's a problem, so I'm tempted to suggest that this include
   any value less than 2^30 so that normal processing works - and can be
   properly exercised.]]
```
I understand the requirement on the sender side, but what about receivers? Does it mean that the number is ignored by receivers, or that packets with non-zero numbers are just dropped on the floor, or that this is treated like a protocol error and a connection close is sent? Oh, wait, this is a retry packet, the sender side connection is already closed!

Of course, if the receivers do not somehow enforce the requirement, broken senders will have no incentive to fix their code. But then, if receivers do enforce the requirement by dropping the packet, they will end up repeating the Client Hello 4 times, receive an incorrect retry each time, ignore it, and finally release the connection after the last timer elapsed. Not ideal either.

My proposal would be to add text. "Clients who receive an otherwise valid Retry packet with a non-zero PN value should treat this as a protocol error and immediately terminate the connection."

-- 
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/1448