Re: Getting to consensus on packet number encryption

Jana Iyengar <jri.ietf@gmail.com> Mon, 23 April 2018 22:49 UTC

Return-Path: <jri.ietf@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 D4474126C2F for <quic@ietfa.amsl.com>; Mon, 23 Apr 2018 15:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-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 jDAf_UejErxw for <quic@ietfa.amsl.com>; Mon, 23 Apr 2018 15:49:17 -0700 (PDT)
Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (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 1A69E124319 for <quic@ietf.org>; Mon, 23 Apr 2018 15:49:13 -0700 (PDT)
Received: by mail-wr0-x243.google.com with SMTP id z73-v6so45502235wrb.0 for <quic@ietf.org>; Mon, 23 Apr 2018 15:49:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3y9VYEUf4Kalm3ZgEgybYY01yblmXGjje5t5Fd5NqYk=; b=BbpVYagIdstKOxIyEi4r8yr0XncDeeu1Gj9HV26iPu/tLRwNSJ6hmglL1YvT39XpuF 6QetxUXE7u8f0Qu8E753CwtFRClqvfokyJvtSD/WU8dZY5qqrSQOd1QkhIVSYrm1uXUk Xz1ybdacKofUL8wkpUNgCIIuSGqVCZGmE7cBqOgZC3DgITVcofdTOyeUEToqaAerd3Y8 0zzDfnwDkeOdvfNHOMXLCu04IT1bX/F5pv8wBiFytY5X/UliABVJlnOMBct3K7gDwyfV 1o35CArvfx5j2XbqrwxPhPt4LX8AMErYELhoxoRENeImw/7BkSx+Nk1fxR/kEG21VgPp +1pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3y9VYEUf4Kalm3ZgEgybYY01yblmXGjje5t5Fd5NqYk=; b=gfDBjUVU9UdaCOPsvPF3wqy3Xh11kJJQ6Vp8GtA4082hCYlJh8WxJ/YstGf5x6kETG uCPlnbcRg0YULyKPYjPx/3SQ1LtSvZhx1vhWrSBIKkvsQ3L5AHJSnR6fPFYv6y/KfAb6 2yaWAQKkxsslG338AnKP1v7gAXR6RcCDWVzdOv/w5K3d0vFqki7URLz5tVpkQu+nN6fx C+Wh4/CeO0WoO8VWX/6bWUaRfoj8NXKSl6xUbkoD0mCKH6YR/PvyllwpyvsQ4IPCbWeZ mJG3bLTkoEiAo4y35NwsxW1eQMzc5k+NhZhIIUJQu3IS8Qj523roT2b3vDpL8B9nI0DB 3yAQ==
X-Gm-Message-State: ALQs6tDmPWBBt0gXF76wPMN1Pa5CEXb7NsPDUCkS3RWGLsAFvxcaRL+S Id2BaIGux4risMq20dNW6gNLCx1J2dfaaRIJQE0=
X-Google-Smtp-Source: AIpwx49xMN22p4izIB+Wx5wYEadmbqI5djIolWZcNeJAVVMG9HS2PEeo5PNDB39qgWP5DH0MJO04FUN214V2rVbU7a8=
X-Received: by 10.28.26.83 with SMTP id a80mr10822299wma.36.1524523751567; Mon, 23 Apr 2018 15:49:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.187.9 with HTTP; Mon, 23 Apr 2018 15:49:11 -0700 (PDT)
In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <B176FC07-887D-4135-B01E-FE8B4986A5EE@mnot.net> <CAKcm_gOCeocLyrYpOS7Ud332xdz3xHSH0psPN8T6BGRjoL9ptQ@mail.gmail.com> <CY4PR21MB0630FA0EDD343396AD414641B6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <CAN1APde13JTzCvKFFvMd183Fka6QGD1kGBjsa9fcoLrYeA2hsA@mail.gmail.com> <CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> <B0F49097-F77A-4831-B68B-4266AA880A86@tik.ee.ethz.ch> <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch> <BY2PR15MB0775B4ACF7DB9124E89016F0CDB00@BY2PR15MB0775.namprd15.prod.outlook.com> <c8e60ba4-d6be-c4fc-5bac-d569a28fb4e8@huitema.net> <56CE3592-EB1D-40A3-B1D2-965B238FA402@mnot.net> <ae7a63fe-0a32-893f-aa6b-e8d97b8ba87a@huitema.net> <1F436ED13A22A246A59CA374CBC543998B60C6DD@ORSMSX111.amr.corp.intel.com>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Mon, 23 Apr 2018 15:49:11 -0700
Message-ID: <CACpbDccOiELKrC1Dfs2tmC02T8awete8TcMgDEU5s_eQS8igOw@mail.gmail.com>
Subject: Re: Getting to consensus on packet number encryption
To: "Deval, Manasi" <manasi.deval@intel.com>
Cc: Christian Huitema <huitema@huitema.net>, Mark Nottingham <mnot@mnot.net>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114cce38a9f5c9056a8bd846"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/1iLiXPUee92HdiFJ0leyn1-tGVU>
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: Mon, 23 Apr 2018 22:49:19 -0000

Thanks for the update, Manasi. In practice, can you state what this small
cost is? Is it the second crypto pass, or are there other deployment costs
that you are thinking about?

On Mon, Apr 23, 2018 at 10:55 AM, Deval, Manasi <manasi.deval@intel.com>
wrote:

> Hi All,
>
> I had brought up the issue with PNE several weeks ago as a barrier to
> hardware offload. After further review, it looks like a hardware offload
> can implement the PNE at a small cost.
>
> The implementation can modify current HW crypto accelerators to support
> encrypting a buffer in the first pass and then encrypting packet number in
> the 2nd pass as already discussed on this thread. The exact requirement
> (header checksum, packet length encoding) is still in flux so there may be
> some small variations depending on the accelerator and final algorithm
> chosen for PNE. Future offload designs can do more to further reduce the
> overhead.
>
> This re-opens the issue of crypto offload in the context of other
> offloads. There is another thread talking about the offload in context of
> segmentation. I'll respond to that thread separately.
>
> Thanks,
> Manasi
>
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
> Sent: Wednesday, April 18, 2018 9:38 AM
> To: Mark Nottingham <mnot@mnot.net>
> Cc: quic@ietf.org
> Subject: Re: Getting to consensus on packet number encryption
>
>
>
> On 4/18/2018 1:09 AM, Mark Nottingham wrote:
> > Thanks Christian; that's extremely helpful (and considering that I was
> about to embark on the same task, but do a much worse job, I'm especially
> appreciative).
> >
> > Everyone please have a read and direct your comments back here.
> >
> > One aspect that still hasn't been made clear AFAICT -- you say:
> >
> > """The process requires two passes, fetching some output of the
> encryption to seed the PN encryption. This is problematic for hardware
> implementations that typically don't buffer the output for further
> access."""
> >
> > .... and then later:
> >
> > """Single pass, thus mostly implementable in hardware if we assume that
> the PN encryption/decryption can be done in software."""
> >
> > Having a bit more context about the hardware implementation limitations
> here would be extremely helpful. Specifically, is "problematic" one of:
> >
> > * "More difficult for existing hardware (e.g., without firmware updates,
> etc.)"
> > * "Impossible for existing hardware, but possible for bespoke hardware"
> > * "Impossible in any hardware"
> > * Prohibitively expensive for current/future hardware
> > * Something else?
>
> I tried to express the issue in my own words, based on discussions in this
> list. But as I said, this is a Wiki. People with more hands-on experience
> on hardware acceleration would be welcome to add a small section describing
> the issue with hardware implementations.
>
> -- Christian Huitema
>
>