[quicwg/base-drafts] When to send Version Negotiation (#1038)
martinduke <notifications@github.com> Mon, 08 January 2018 03:39 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 A6A9C1201FA for <quic-issues@ietfa.amsl.com>; Sun, 7 Jan 2018 19:39:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, 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 nEi9HnNkm5WU for <quic-issues@ietfa.amsl.com>; Sun, 7 Jan 2018 19:39:54 -0800 (PST)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext8.iad.github.net [192.30.252.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3461200C1 for <quic-issues@ietf.org>; Sun, 7 Jan 2018 19:39:54 -0800 (PST)
Date: Sun, 07 Jan 2018 19:39:53 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1515382793; bh=wSjxhCZ+5xZSuMDK2AjNqbfWCfPb1BavSnNwId9elzg=; h=From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=DhYqozLBcWln+CCQeM0xQMIsTndjEF23PONiKJi26ii0M6N+RDAISCfjX73rh3BQV 0c91ZLtBAJhdZUyE7zf8fUkFAzkpWDtybvd7Z7Fcs7K1NOBn1pxmdqUGi81ye6uPtl Mh0YqIjwvJXNFI8dZEprTwJAEsyDYUjpgL0qZ8ss=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab819e7f3d98cb73aa824f06d3286a721f9a68187b92cf00000001166aaa0992a169ce1115b3ed@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1038@github.com>
Subject: [quicwg/base-drafts] When to send Version Negotiation (#1038)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a52e809e4473_e2e03fd3f28caf2c4428cd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/w44BCe7pptzG_XlDUwUJVyIcWPM>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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, 08 Jan 2018 03:39:56 -0000
The invariants draft only reserves the 0x80 and 0x40 codepoints in the first byte of the packet. The Initial Packet byte (0xff) is not invariant. The transport draft suggests that only initial packets should trigger version negotiation. However, if QUIC v2 picks an initial packet byte that is not 0xff, then servers will ignore it and VN breaks. There are two solutions that came up on the mailing list. 1) Servers must send VN packets for any long header type where the version is unsupported . We explored the possibility that 0RTT packets larger than 1200 bytes would create a storm of VN packets, but this is not an amplification attack vector. Furthermore, the case where a client has 0RTT keys but not an accurate list of server versions is a rare one. Even in this rare case, if the Initial is lost this change could actually save us an RTT. 2) Make 0xff for the Initial Packet an invariant. This is easy, but raises the question about the proper response to other Long Headers that arrive first (short headers will trigger stateless reset). I don't have a strong opinion on which we should do, as long as we do one. I'm happy to do a PR for either. What do people think, or is there a third option? -- 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/1038
- [quicwg/base-drafts] When to send Version Negotia… martinduke
- Re: [quicwg/base-drafts] When to send Version Neg… Martin Thomson
- Re: [quicwg/base-drafts] When to send Version Neg… martinduke
- Re: [quicwg/base-drafts] When to send Version Neg… Martin Thomson