Hardware acceleration and packet number encryption

Christian Huitema <huitema@huitema.net> Sat, 24 March 2018 12:19 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64C91250B8 for <quic@ietfa.amsl.com>; Sat, 24 Mar 2018 05:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 5ZGlyZsNxEZk for <quic@ietfa.amsl.com>; Sat, 24 Mar 2018 05:19:02 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06218124F57 for <quic@ietf.org>; Sat, 24 Mar 2018 05:19:02 -0700 (PDT)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx62.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ezi8R-000B5n-Kn for quic@ietf.org; Sat, 24 Mar 2018 13:19:00 +0100
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ezi8L-0001xB-3u for quic@ietf.org; Sat, 24 Mar 2018 08:18:57 -0400
Received: (qmail 17591 invoked from network); 24 Mar 2018 12:18:50 -0000
Received: from unknown (HELO [10.8.50.80]) (Authenticated-user:_huitema@huitema.net@[80.195.152.82]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <manasi.deval@intel.com>; 24 Mar 2018 12:18:50 -0000
To: IETF QUIC WG <quic@ietf.org>, "Deval, Manasi" <manasi.deval@intel.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net>
Date: Sat, 24 Mar 2018 12:18:49 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Hardware acceleration and packet number encryption
X-Originating-IP: 168.144.250.190
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.59)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5jEwTgml3lBOBQJBSS+BCld602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViqeAP0hNbcl/nfwsk9d/Bks7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBCnY1T4UEFfy74vbELeG6IB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpW4c1OgHtPoe1bkMdZgVo8q7xvCa9sG2GyQFmTjRwvmJWH6SvC0OUAc YdvfvRyEr5pz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVza72Z2UDJg76YkOZZOKE0FYE7tCqypI5WX0qWh4YQLDbyEIxfN6kqWlq iOeDWuvPbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLUf8vaazCGNJnnU8AZaEIofQKHY 6H+wSCoVvwvquzDDiPkKIKnisj+1ZHYjRAh7nr2Ydub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0=
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/sMcOe0eby5kM_Xj17etaklotJ04>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Mar 2018 12:19:04 -0000

There were a number of corridor discussions of hardware acceleration of
Quic during the IETF meeting. In particular, Manasi Deval asked many of
us our opinion about packet number encryption. From the conversation, I
understand that packet number encryption as specified would make
acceleration of Quic difficult to implement on Intel's hardware. She was
trying to convince us that privacy is an unattainable goal, and that we
should just as well ditch the linkability requirement in order to
facilitate hardware acceleration. I would much rather see the issue
debated in the open than in a series of 1-1 conversations. After all,
open discussion is a key tenet of the IETF.

When I look at the potential trade-offs, I see the following, which have
been proposed at different times:

1- Single sequence number of all paths, starting at 0 (or 1), numbers
sent in clear text;

2- Single sequence number for all paths, starting at 0 (or 1),
obfuscated via a different random offset for each path. (We will assume
that the offset is tied to the connection ID used in the path.)

3- Single sequence number for all paths, starting at 0, combined with
packet number encryption as specified in PR1079.

4- Separate sequence number for each path, starting at 0 (or 1), numbers
sent in clear text. (We will assume that the there will be a separate
connection ID per path, so the combination of connection ID and sequence
number is unique.)

5- Single sequence number for all paths, starting at 0, combined with a
simpler packet number encryption than specified in PR1079.

These options have different costs in term of privacy (linkability),
ossification, hardware acceleration, and software complexity.

Having a single sequence number sent in clear text on all paths (option
1) makes it very easy to correlate different paths. We also know that
the random offset solutions (option 2) only provide a modest defense
against linkability if the activity on two paths overlaps. It would
definitely now be adequate for multipath, and it is probably not
adequate either for the "make before break" variants of path migration.
The other variants prevent linkability either by encrypting the sequence
number, or by using different sequence numbers on different paths.

Only encryption prevents ossification. If we send packet numbers in
clear text (option 1 or 4), or even if we use simple obfuscation (option
2), middle-boxes can find the position of the sequence numbers by
comparing the headers of successive packets. There are high chances that
we would then see half-brained schemes, such as delaying packets for
reordering, or enforcing some kind of sequence range. This is a classic
ossification scenario.

Packet number encryption as specified in PR 1079 relies on a two-pass
algorithm. First encrypt the packet, then use the result of the
encryption as a nonce when encrypting the sequence number. It seems that
this two-pass approach forces double buffering in the acceleration
hardware. Opinions vary about how bad that is, and hardware specialist
should really explain the problem if they believe it is important. There
may be different ways to encrypt the packet number (option 5) that do
not require double buffering, but this is merely a theoretical
possibility. Those schemes are not specified.

Using separate packet number for each path would prevent linkability and
facilitate acceleration, but it makes the protocol and the software
significantly more complex. It requires using different keys or IV for
different paths, and it also require management of several sequence
number spaces. Since the packet with number "3" on path 1 will not be
the same packet as number "3" on path 2, the acknowledgements will need
to be tied to a path, either implicitly because they are sent on that
path, or explicitly by tagging the ACK frame with a path specific
connection ID. We would probably need both, because in migration
scenarios it is useful to send on the new path acknowledgement of
packets received on the old path. This kinds of complexity breeds bugs
and interoperability issues. Plus, this solution does not prevent
ossification, as discussed above.

My personal preference is to start with PR 1079, which is a sound
solution to all problems except acceleration. The acceleration issue
should be discussed in the open, and we probably want to hear from more
than one possible hardware vendor. Do all hardware makers have an issue
with double buffering, or is this just specific to one particular
architecture? Is it worth exploring alternative packet number encryption
techniques that would not have the double buffering issue?

-- Christian Huitema