[quicwg/base-drafts] Defense against version number corruption (#3532)

Christian Huitema <notifications@github.com> Wed, 18 March 2020 18:24 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 BCE8B3A19DD for <quic-issues@ietfa.amsl.com>; Wed, 18 Mar 2020 11:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Status: No, score=-3.098 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GzdobCouv0ob for <quic-issues@ietfa.amsl.com>; Wed, 18 Mar 2020 11:24:12 -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 1B83A3A19E0 for <quic-issues@ietf.org>; Wed, 18 Mar 2020 11:23:21 -0700 (PDT)
Date: Wed, 18 Mar 2020 11:23:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584555799; bh=/9p8lMYvzSHZPMWTfj+kPHad5bco6PQlhvdHQB2VZ3c=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=GMZwsX8MvAp68THD3kHDpBDSBd9x3ayFpdpgqT7HvBGACjnO0CxFve0kfYh2+/xf0 BSWG/RUFG6ia3R8EGIe4jvXxPhGjWbvIMSdHlYMYp6Ix4v+EHFbjbKGKFk8k/LhL72 +witkPUj0AdX/+isWLx6vRjWKeY3Dk/p1E5aV0TY=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4CWNIZERKT7B4FRSV4PZEBPEVBNHHCFTPLZM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3532@github.com>
Subject: [quicwg/base-drafts] Defense against version number corruption (#3532)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e726717aead3_358b3fcc56ecd96822784"; 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/gBpBHu1dbFYnwOXnBOsZmuZ8qXk>
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: Wed, 18 Mar 2020 18:24:18 -0000

The "packet corruption" test that @marten-seemann added to the interop-runner has surfaced an issue about version number corruption. Suppose that a long header packet is corrupted in transit, and that the corruption changes the value of the version number. Per spec, the server will respond with a version number negotiation packet. In the test, we observe that when clients receive such packets, they abandon the connection attempt.

Obviously, this is a rare event. We don't know how frequent packet corruption is today. The [1997 paper by Vern Paxson ](https://cseweb.ucsd.edu/classes/wi01/cse222/papers/paxson-e2e-packets-sigcomm97.pdf) measured "1 packet in 5000". In theory, only one in 2^16 of these corruptions would not be detected by the UDP checksum, leading to undetected corruption in 1 in 300 million packets.

That's a very small number, but I don't know whether the 1997 measurements are still valid. They could be higher. I also don't know whether the loss patterns would be detected by the UDP checksum, since some middleboxes appear to rewrite these checksums. Faced with exactly the same issue, we decided recently to add a checksum to the Retry packets.

Clients can protect against such corruptions by checking the incoming VN packets for sanity. If the server issues a VN in response to a corrupted packet, the list of supported versions will include the version proposed by the client. That should normally never happen. Ignoring such bogus VN does protect against most version number correction issues. Should we point that out in the spec?

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