[quicwg/base-drafts] What does a server do with Handshake packets not belonging any connection? (#2333)

Marten Seemann <notifications@github.com> Mon, 14 January 2019 06:37 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 C3F80130F5B for <quic-issues@ietfa.amsl.com>; Sun, 13 Jan 2019 22:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.149
X-Spam-Level:
X-Spam-Status: No, score=-11.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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, 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 g7uvrk1SoUu9 for <quic-issues@ietfa.amsl.com>; Sun, 13 Jan 2019 22:37:28 -0800 (PST)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64B3130F56 for <quic-issues@ietf.org>; Sun, 13 Jan 2019 22:37:27 -0800 (PST)
Date: Sun, 13 Jan 2019 22:37:26 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1547447846; bh=4nuqXl1KqndKg/g7yG8Iy3QOZNo6gtVzoFeKF0diy/A=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=ZcIG0BXdGSD5m5BtFv/iYCS+A+eSC3aULK7LvSclwrcvoU/MK72EDTp3moJyKzIHU mGLYOJQXmw0W+NLqh/cPpWUdpwaSAz6FBq4BCkuW7SbTLEQFJJY5Cbb7GIXZy9sgXH Bs6IV27OSYOB0mtYx7PXxB9l+62UW/8mmUnSYR08=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab75a6a14e9620c18e967b06100f7c0bd0de56c1c292cf000000011853f02692a169ce17c4a8b9@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2333@github.com>
Subject: [quicwg/base-drafts] What does a server do with Handshake packets not belonging any connection? (#2333)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c3c2e264abf9_779f3fc80e6d45b41320184"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/UqxAYeswQm5OrL4Msr530Dv8dM0>
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, 14 Jan 2019 06:37:31 -0000

This could e.g. happen if a server loses state after sending the ServerHello, and comes back up before the client gives up. Or it could just be an incorrectly routed Handshake packet.

Currently, the spec doesn't say anything explicitly about this case, so the general case about receiving a packet that is not associated with any connection applies, thus we'd send a Stateless Reset. There are two problems with this solution:

* We clearly can do better than sending a random data, since we have access to the source connection ID on the incoming packet, so in principle we are able to ensure correct routing of the stateless reset.
* That doesn't really help though, since the client might not have received the stateless reset token yet, and would just drop the stateless reset.

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