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

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 07 February 2018 00:29 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 1368412DA1A for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 16:29:22 -0800 (PST)
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 ouSA47tMN1H6 for <quic@ietfa.amsl.com>; Tue, 6 Feb 2018 16:29:20 -0800 (PST)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 0860B126DFB for <quic@ietf.org>; Tue, 6 Feb 2018 16:29:20 -0800 (PST)
Received: by mail-pg0-x22e.google.com with SMTP id g2so1802735pgn.7 for <quic@ietf.org>; Tue, 06 Feb 2018 16:29:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=UdP74149GAl+lbDMzQjabs8ZZaSxe5hU2LZraKhPNMQ=; b=KIhMoJmKbxl9ZC2E8mqcyTnNvzwIkhwLzPK6TvxR9igcRLNgjGDtyX55oNhgB7Yn13 6rR/21zbFGZkMMSPAX5Ahf5Qh46xN+pJVMOXruznCyzeOKgXTJPld6t/oCplEcyUuNPW LSIOlZfIqIAOa3k6qf47FQ0HASTafC30SlDpQJKG3MClBhclnKvnFlIucfSuc3lyOhmq HALlvHchwjOkSQlNerhjDn0aO/MJ5Coaoiosu4csgGakwIa+X9+nMepLqGN5yXri7At8 50CkkXU2Y7ZLdpiIvpDEhJVC5cb+YxPdxzDjNhKf1xpyTbdzJnv5uruKd/l3lSpy9REG 3qiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=UdP74149GAl+lbDMzQjabs8ZZaSxe5hU2LZraKhPNMQ=; b=JLzIaeHJyfuuBNyg67pCNjH3cQ4R73s2AHzjlDOr+7Vfy03axan1YCaAjCDGONBKBk Ag2qdAgFqsL/I7U1nvS5vmwXS3AHGcx/T1CxLToC3H5JoHVmhnVwueGJy4YSEesuUOiR CskRgWAyJL/b9aMEW7rXms5fn2VW+MUbOCQI1jC1yaU0nBI28cyLW96/8GDtgGlAfXUB wniu9qnBcrGx2I1ZbGmes48ng0wRk9ubXKMSsHzJia5ksgO72eVkcq3F2V8uemAF63uS NjWH8Oz8Lyrn/qRbkuru89Y2cF3pv/5wzS86ha1LebpLYomqDnLZ/a2vgafQ0Bvd0j9Y tbhA==
X-Gm-Message-State: APf1xPByFAmpdH+d3Nb0LQI9/XK56ydTurJkCD3UcCAqWgF3CI7gVksd 5AbU5j7BpdhGpX3GbZqfP5o=
X-Google-Smtp-Source: AH8x227LT+AXd1sAfNwo9SyUi6GLnl/Tm1QR9JsoQEOSZP7cyP+LzmmPhFhXoZZQWhPO4tYS47udwA==
X-Received: by 10.98.247.25 with SMTP id h25mr4054058pfi.162.1517963359693; Tue, 06 Feb 2018 16:29:19 -0800 (PST)
Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id y131sm337915pfg.69.2018.02.06.16.29.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 16:29:18 -0800 (PST)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
CC: "Brian Trammell (IETF)" <ietf@trammell.ch>, QUIC WG <quic@ietf.org>
Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)
Thread-Topic: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)
Thread-Index: AQHTn1cqSR45mit5E0WzVadd6SuPAaOXdfgAgAAYvoCAAH9lgIAACJBJ
X-MS-Exchange-MessageSentRepresentingType: 2
Date: Wed, 07 Feb 2018 00:29:12 +0000
Message-ID: <DB6PR10MB176682C63A91007574BBEAECACFC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.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>, <CANatvzz3rmGPRgu1Z5+bAHhgjiN3L5OVTDhb4fmpPX+M8o4z3w@mail.gmail.com>, <DB6PR10MB17661B9957DF90733FA28EC5ACFD0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <DB6PR10MB17661B9957DF90733FA28EC5ACFD0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DB6PR10MB176682C63A91007574BBEAECACFC0DB6PR10MB1766EURP_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/YVYpoqWDV-J_kiThUy9Gb_peTYI>
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: Wed, 07 Feb 2018 00:29:22 -0000

Also note that this approach is insensitive to skipped packet numbers in optimistic ACK attack defence. It leaks zero information when the network is perfect and if the CID hash is random.

________________________________
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Sent: Wednesday, February 7, 2018 12:58:33 AM
To: Kazuho Oku
Cc: Brian Trammell (IETF); QUIC WG
Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)

I actually think a static 1KB table of Pi could work quite well.

A subset of samples could be indexed in a hashtable and yield loss data early with some probability. Some samples would miss due to reordering or loss. If more exact analysis is wanted the levenshtein distance of a sample sequence against Pi from a synced offset would tell a lot about the data. Or DNA sequencing. This could be hardware optimized.

Yet, transmission is always just the next bit in the Pi table.

Since Pi is effectively random it will ebentually detect mutations if the observed sequence is long enough.

Wrt privacy, the CID may be used as a start offset hash into the Pi table.

There isn’t any need to cover a full RTT worth of Pi bits unless it is used for latency detection, but in that case the spin could be a pattern like 10101010 and 00001111 injected into the Pi sequence. A separate spin bit would be simpler.


________________________________
From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Tuesday, February 6, 2018 5:22:35 PM
To: Mikkel Fahnøe Jørgensen
Cc: Brian Trammell (IETF); QUIC WG
Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)

2018-02-06 23:54 GMT+09:00 Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>:
> 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.

That's definitely an option.

Actually, I considered using sin wave (that distributes the error
among 1-bit samples) as an example instead of the square wave.

The primary reason behind my preference to using a square wave is that
it is easier to implement; in fact, emitting a square wave with the
length of 512 packets is as easy as just taking the 9th bit (counting
from LSB) of the packet number (if we forget about the gaps for a
moment).


--
Kazuho Oku