Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 06 February 2018 15:09 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 1C63912D7F8 for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 07:09:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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] 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 L94eDGRHG1j6 for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 07:09:18 -0800 (PST)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 4EF551243FE for <quic@ietf.org>; Tue, 6 Feb 2018 07:09:18 -0800 (PST)
Received: by mail-io0-x232.google.com with SMTP id 25so2794884ioj.9 for <quic@ietf.org>; Tue, 06 Feb 2018 07:09:18 -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=yEQpjHDdwhhgsnJXPMLpURwNeKfRu2PYC1V5z59hUqI=; b=eq30si0evv1EBpE7+j1BodCfdCB6CDvFYwTKG5F0dz7w+OZWhT+9EXyzav1ZtSC/8f utpVOVsouhxK1PdCgoswrjFjUXWU9J6i5KtV+/Ql/BgyPIsEvbhKD3CbtNHD5vB+f97q VZZo4IU+9BJYrf+c8x3WqYF+rQwitFNVuRUNMHduhjHN3+gjzCFk6TCUji3OqhKOeS63 +a7cWRBMU7RJ3T/4eCx4syzepwYQsKNxqvk/XBqTIXDj/ccfRybU2qh/3HTOUsHOhDJg dC/E1KwrPhegbJObjGk+ooGM3oBD4Lofro9IwdyD9lJgiNQXD2vpGiw0jD05iLzfl7Z6 5VLA==
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=yEQpjHDdwhhgsnJXPMLpURwNeKfRu2PYC1V5z59hUqI=; b=mJNqB6rgsVANemMHbzASxOnnWbavtSmocAIDHxyFji/YejLVdke4M6tei9UFUas+Ex HP9hqUHMiwoZBqAt4QBDYGScVGBPaFAgP2wkwLZnKlOPlklWzXbIb59ZdD7BCGR53dnU oWLrrJok0SXUSWl5CEBuGj8owIKfylhfq2EUkMP6w/X06ghV07u9r+lbky7bmLh/MSm0 Hn4n/O5PLm8c2I8RzCDdi1/5cLGD0bfG5MotccFxd9Rk2g0sx3DhTqLYLdhxGQ182NaF fowpOIm1VvlU4Zvfiaz/1Q2Cw+LnbRqMUTEPiFjc9VLhfYKrjeYc+ucEPlHvJIbOblvI N35A==
X-Gm-Message-State: APf1xPB/Ly0CfUE3kgzIsHIVcCtPud1Q3dicEYnv3wvyX/irl6zTRKoy PooHdeooTINbGX9bnQYByUwj2auU3RTDeTysysY=
X-Google-Smtp-Source: AH8x2257xf98BsH7unQIrltZLPrNZ4cDipos6jcqb0tLBiH+Q/drg/rU/q+/d9nkUZlRjpNIU0aqfuryeXSkNWrfNm8=
X-Received: by 10.107.168.25 with SMTP id r25mr3288183ioe.16.1517929757737; Tue, 06 Feb 2018 07:09:17 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Feb 2018 07:09:17 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAN1APdcuKSLYw4Odyc4g=+4_+ojsNekeqmM9eYqxykkfxRx3Cg@mail.gmail.com>
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> <CANatvzx+uDHMV5XS=OuVYBqe_RYX=EmVWAmjuONS8BpNYCPweA@mail.gmail.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> <CAN1APdcuKSLYw4Odyc4g=+4_+ojsNekeqmM9eYqxykkfxRx3Cg@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 06 Feb 2018 07:09:17 -0800
Message-ID: <CAN1APdehS5MvNVQS-KQPjFGoLt5qJFOUK0SRm9a_NnkzLkfQLA@mail.gmail.com>
Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Kazuho Oku <kazuhooku@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a11427bca01162c05648c90ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/f3YH2TRJsQhIRd1fXeU_j1DoVqs>
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 15:09:20 -0000

This idea can be taken further: You can modulate the signal so you use
multiple packets to encode a zero or a one for half the wave duration. For
example 1 could be encoded as 0101 over four packets and zero could be
encoded as 0011 over four packets.
If there is any reordering, it would show up as an unexpected value in the
pulse.


You can take it even further and add error correcting codes into the
sequence.

Or likewise, you could generate a known random sequence such as PI, or
perhaps simpler, an AES generated sequence.

It is easy to sync the signal by hashing bits from multiple packets and
therefore easy to detect any missing bits. If there is massive loss, a
binary search can be conducted to find the location of the surviving
packets. It sort of breaks down if every other packet is reordered but you
could still handle that with some consideration.

The signal could repeat with a period significantly larger that practical
RTT rather than running an infinite sequence.

Technically it would also make it possible to remove the packet number
entirely because the number can be estimated by end-points and trial
decrypted, but that would likely not be performance optimal.