Re: Packet number encryption

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 06 February 2018 13:35 UTC

Return-Path: <mikkelfj@gmail.com>
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 D6B5B12E043 for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 05:35:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 h96TgyG80s4q for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 05:35:14 -0800 (PST)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314BF12E041 for <quic@ietf.org>; Tue, 6 Feb 2018 05:35:14 -0800 (PST)
Received: by mail-it0-x22d.google.com with SMTP id h129so2452918ita.2 for <quic@ietf.org>; Tue, 06 Feb 2018 05:35:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=lWHv6VkWpbGqt46tX9om1sWxqxe4C+jpxiuhddqdeqU=; b=Z6d+QAMjcHvA1WydQnFs08oTG7ZEa7hIhHFl9hBNoZETskTKxDJ+9x1jo35AxEJnEB 0AXPV/QAtVoPbsbg0L9kN7bfSU0yuqm+d955HTir6MeQQXHb7hk+9xA7X0mJnUKlxMdn 5HaMw9O+7Qv7SIng+Whk9Kl30dAe2HbSMyoly41Fz061QL8uIT9B+m6QC/MnqZjQOk/A bz74fFMz4AJ1H/ThrfcUDw2ScnpmVO2+mtk7ScgspGpUR5ZLvrU0y0oaRlnYw7XN9Ljz i+0BFo4KCn2gNZIsPiWmerv5dabj/xdxakBpbakWTU3SJk2BBXUsfjczeBUyR/eVw+uf EDBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=lWHv6VkWpbGqt46tX9om1sWxqxe4C+jpxiuhddqdeqU=; b=N9/pBXwSZtDvIoCdudg3jEUxSGsYjRzSIqqk2TTPVipM/ezil6BM667s3dpyJMRHZO /g20GzXF3/CBsZ7T9dPx3ThugKGsYFtoLdekLl2eEaz2sHRTTeuU+KIxDdZ6W2D/Pm3L aCr6vp2Fw3ZTF1E+dkoqxgpu1SFyTloujKB6ASh8xZ6rDMMxa5Qo//ds2rtTKbGv8f7o 8PaLYUaf1F8UxMGDeOn3uxNLdcFe5Hp0h4fJlR4CHPHeYK8iBO2WccDsWvSLfeAb/eol aWbOeRaCEDvJFfBeUrOYfTNGBZu2m1waMCZdFbUZUPif2Cbf6pIgoCWWvu+UxFSM63vw Vlqw==
X-Gm-Message-State: APf1xPBv7zyNbMmmElsgSjQCWgu2OEBCA6BQbHzHAFFddoQ+bhW7Sewf 2TgeElMaCIrb23vWyskAcOIJzpLMjDJN59Wf5ts=
X-Google-Smtp-Source: AH8x227xNbpIxqPu1KrdrQbtj/D5vRVk4FrFqGNLt/p2pnZVXzMuh8FEm1HYiYNlFvECYPG73bDL7pBSPYVIW6+GWKA=
X-Received: by 10.36.10.207 with SMTP id 198mr3030754itw.42.1517924113377; Tue, 06 Feb 2018 05:35:13 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Feb 2018 08:35:12 -0500
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <CABcZeBMbwdwyC9TxxHBLYaZKfNB-FG2wCGjqUZ_mNR-A1R47FA@mail.gmail.com> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <CABkgnnWRQSAufwPss+qf=xAzCwRYeNNH8XLPm3yFaHxOb+ba4g@mail.gmail.com> <BF80500A-6277-45DC-8525-9C3FE138B76D@tik.ee.ethz.ch> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <F990E064-E6F8-41A3-B791-F776C9955E15@nokia.com> <CAGD1bZab0GaZFsHwC+nw3AxxC4VusxMJ6oDanzk3dSDdWKAXdw@mail.gmail.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <BY2PR15MB07757473DB9788558B902EB5CDF80@BY2PR15MB0775.namprd15.prod.outlook.com> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <e529144067624fcba636fc8c24ee3ff4@usma1ex-dag1mb5.msg.corp.akamai.com> <BY2PR15MB07754D83A1721F2BD742359BCDFE0@BY2PR15MB0775.namprd15.prod.outlook.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <CAGD1bZaUuNxqpDkn62B0wWcFD8=mCUWrAwWGG-rAOxH7Mf1=cQ@mail.gmail.com> <CY4PR21MB01334E30C7AF6AE75F58EEFDB6FE0@CY4PR21MB0133.namprd21.prod.outlook.com> <CAGD1bZaxrqzdkk0wxRaULwOTgg6wnrSrXNBK31s4uxdozaACBA@mail.gmail.com> <CAGD1bZbOAaSBcQw4nVtGuwRunaAW8MYHq9yPxNN6DdKHzt5HtQ@mail.gmail.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 06 Feb 2018 08:35:12 -0500
Message-ID: <CAN1APde6o6=aCXuWajPFSU=jXv-ERdVHk=uyjM71uQ_uU-oMTg@mail.gmail.com>
Subject: Re: Packet number encryption
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Jana Iyengar <jri@google.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>, "Salz, Rich" <rsalz@akamai.com>, QUIC WG <quic@ietf.org>, Roberto Peon <fenix@fb.com>, "Lubashev, Igor" <ilubashe@akamai.com>
Content-Type: multipart/alternative; boundary="001a1144b82892eefa05648b3fb7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Nl6rOJlDd8F5TQsYV_tkgvdAF1c>
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: Tue, 06 Feb 2018 13:35:21 -0000

Some overhead considerations of packet encryption:

Sensor and control devices:

The power overhead on sensor networks is small compared to just listening
on the radio and if not using radio, the latency is probably not critical
compared to the speed of encryption. To be a bit sci-fi - low-latency
encrypted control signals in robotics might be relevant. Think exo-skeleton
hacked by enemy through targeted signal injection. Still, packet number
encryption is likely fast enough in such cases.

For servers:

The overhead of packet encryption (single block AES-CTR) is probably around
100 cycles with AES-NI and possibly 160 cycles table based for one block
for Intel arch. This is because parallel multi-block optimisations are not
possible. AES-CTR of one block is about the same as AES-CTR of 4 blocks,
and GCM auth tag adds perhaps 50% to that. Thus packet number encryption
might be twice as fast as AES-GCM of a 64 byte message which is still a 50%
overhead.

High speed low latency applications might receive a packet concurrently on
two cores, one with a fast path reacting specifically to packets containing
only small stream messages, and one core handling everything else. The
message handler could experience a delay of 50% compared to not encrypting
packet numbers.

It is not possible to significantly improve on this in hardware because the
packet number must be decrypted before AEAD can be applied. That is, unless
the encrypted packet number is used as the IV of AEAD in which case
encryption gets a new bottleneck but decryption can be processed faster.

My take is that I prefer to avoid packet number gaps because they are messy
and I don’t believe they provide any significant privacy, but I also don’t
like the crypto cost in low-latency scenarios.

If the argument is for ossification and not privacy, I think the encryption
is the only option as Marten has pointed out. For this reason it makes
sense to apply crypto. Low-latency systems could create a QUIC variant that
drops the packet encryption.

Mikkel

On 6 February 2018 at 11.13.40, Brian Trammell (IETF) (ietf@trammell.ch)
wrote:


> On 6 Feb 2018, at 01:30, Jana Iyengar <jri@google.com> wrote:
>
> I don't think we're converging here, so I'd like to try and encourage us
to move towards it. I have my opinion, but I care more about forward
progress at this point.
>
> There are three designs so far:
> 1. Packet numbers as is, with random gaps around migration.
> 2. Packet numbers encrypted, as per Martin's PR.
> 3. Packet numbers encrypted, plus a small modulo sequence number
somewhere.
>
> The concrete ones here are (1) and (2). I'm listing (3) but am not
inclined to consider it seriously, since it's not concrete enough, (and I
don't want more bits to be spent in the QUIC packet header if that's where
this info goes.)

Unsurprisingly, I'm still for (3). :)

If a concrete proposal would incline you to consider it seriously, I'm
happy to write one or two points in this space up, probably for the list at
first. (Indeed, I'll probably go ahead and do this anyway today).

> There are opinions about ossification, privacy, and manageability. I'm
not hearing bloody murder, so for what it's worth, I'd like to stipulate
first that we can all live with the final design, whichever one it is. If
anyone disagrees, please say so -- I think it'd be useful to hear if there
are folks who think a particular design is fundamentally problematic.
>
> My opinion is still for (2) over (1), but I can live with either.

FWIW, I prefer (2) over (1) as well, modulo a little discomfort about the
crypto: the proposed encryption scheme uses a secret derived from the
end-to-end secret to ECB-encrypt a plaintext which is completely known to
an on-path observer in a place to see all packets in the common case that
packets are neither lost nor reordered on the path -- namely the sequence
0x00 - 0x3f, 0x4000 - 0x7fff and so on. I Am Not A Cryptographer, but that
property of this algorithm used in this way screams "Call A Cryptographer
Before Deploying" to me.)

Cheers,

Brian


> On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar <jri@google.com> wrote:
> Praveen,
>
> That was precisely my point about the ecosystem evolving. Now that we
have the ability to classify flows, various things have been built around
being able to tell TCP flows. This obviously has benefits as you point out,
but the downside is that that I can't get good network utilization with a
single flow. I understand the scaling point, but speaking of common cases,
any server in the wild is usually serving a large number of connections at
moderate speeds, not a single one at 25-35 Gbps... which makes that sort of
scaling less exciting than in a microbenchmark.
>
> FWIW, the other downside of ECMP is that multipath transport doesn't work
-- you need to hash on something else besides the 4-tuple. (We had to work
around this in Google's deployment of connection migration.)
>
> I'll disagree with your point about reordering being the uncommon case.
While that's true today, this is again an expectation that the network
works hard to maintain, though the ecosystem and what we expect as "usual"
would be quite different had we not built TCP's requirements into the
network. There's nothing wrong with having n-modal latencies... we can
engineer around that. Any sensible load distribution scheme within the
network will give you increased variance but it should limit the worst-case
latency. You'd perhaps agree that that's a net win.
>
> This was an example of how exposing packet number or not can have long
term ecosystem effects. My point was about the fact that exposing can cause
ossification.
>
> - jana
>
> On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian <
pravb@microsoft.com> wrote:
> >> This was definitely true for implementations of TCP, but that is TCP's
problem, not the network's
>
> Flow classification happens through the network and also on the end host
with RSS where a flow is mapped to a core. This allows for building high
performance receive processing that could be lock free for the most part.
The only downside of ECMP on the network and RSS on the CPU is that a
single flow will not take multiple paths or get processed on more than one
core. Windows on server machines today can saturate 25-35 Gbps for a single
TCP connection before being CPU limited. This is a reasonable trade off
because I don’t know of cases where a single flow is driving more than that
amount of traffic. Assumptions about how flows get classified help make for
more efficient processing. They also lead to consistent latency. You do not
want the traffic to take a bi-modal or N-modal paths (on the network or the
host) to being processed because the fluctuations in latency will hurt the
workload. I am not arguing for TCP not being resilient to reordering but
IMO that should be the uncommon case not the common case. With QUIC if
streams were exposed on the network you could take advantage of stream
level ECMP and RSS to scale better than TCP but we have chosen to keep the
4-tuple (or the 5-tuple) as the flow classifier on the network which is ok
by me since it leads to TCP parity.
>
>
>
> Thanks
>
>
>
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
> Sent: Sunday, February 4, 2018 8:35 PM
> To: Salz, Rich <rsalz@akamai.com>
> Cc: Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon <fenix@fb.com>;
QUIC WG <quic@ietf.org>
> Subject: Re: Packet number encryption
>
>
>
> Privacy-protection can't be a user choice, for the reasons others have
noted on this thread.
>
>
> That said, my primary argument is for encryption to avoid ossification.
Not that it matters now, but I'll note that much of GQUIC's original
motivation for encrypting headers was to avoid ossification.
>
>
>
> I'll reiterate that fields we expose will get ossified and there are
long-term ecosystem effects to this. Let me illustrate this with precisely
the packet number field. Middleboxes commonly assume that a TCP flow can
only handle packets in-order. This assumption comes from the fact that TCP
implementations get poor performance when packets are reordered. This was
definitely true for implementations of TCP, but that is TCP's problem, not
the network's. However, almost all load-balancers I know of now will pin
all packets within a TCP flow to one path, leading to sub-optimal
performance in the network, and destroying incentives for the endpoints to
deploy reordering-resilient TCP implementations (even though there are
plenty of ways of doing this.)
>
>
>
> Exposing QUIC's packet number field (as any field) is likely to have
similar consequences and a similar ecosystem arc.
>
>
>
>
>
> On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <rsalz@akamai.com> wrote:
>
> > Optional security tends to devolve to non-secure.
>
>
>
> That’s a great aphorism. And sadly all too true.
>
>
>
>
>