Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks

Christian Huitema <> Sun, 31 July 2016 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6333612D0B9 for <>; Sun, 31 Jul 2016 13:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jUyyzz9bfgbc for <>; Sun, 31 Jul 2016 13:10:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A8B412B020 for <>; Sun, 31 Jul 2016 13:10:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RlyYfAhYpWAO4x8McN+Dffly+xN9/fOGcujogOhv/uw=; b=eUhwlpmbJ2SDkip/sahfWTaf4wflMt+LFi56yO4L/bmgo25JPZFr6LaPqQok2ghi3vCIuOdB9teWSxLGA+EVbRBAqgWyru50g5doa1nYtT5apU546vn3cbyqugW5Y7BJwd3b5yLNzGOjwL8uT99kXOyJAd3uhlBeOAcBY+LptCs=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sun, 31 Jul 2016 20:10:15 +0000
Received: from ([]) by ([]) with mapi id 15.01.0549.022; Sun, 31 Jul 2016 20:10:14 +0000
From: Christian Huitema <>
To: Brian Trammell <>, spud <>, "" <>
Thread-Topic: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks
Thread-Index: AQHR6ZVz3wpM8J2u0ky72gV8CNidkqAy82Uw
Date: Sun, 31 Jul 2016 20:10:14 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 2f2ecbcc-33e2-4df3-d3f5-08d3b97eaf72
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2674; 6:eRmVLRy7HFWMJ61D4DbcBOO340ezNtKiyWFqr30f1K60NutOYMDkiWI3hTHD/DGQoDsCSP1YrY8eaJwwCM3EcgUlHGUnvjqBu00Z/T/DNWOK9U1sBN40WdGkliJjwsvX4fc6gW/UdXqmKovYfHYinFDvrJ1YQJEtw0WnbUy/0ClCtcjPf4B1EC9DBukB7PC9MDoIsrbX7dnNBM+cfs5CitoWDn6+tYMKcQllaQEoSR+hk+Vuu3sYiFKapMJnuer+yYXzkWVJPeAd0rhpCPzZLC87sO8CvvtqitnObgwcoyY4K/UZ4bQJDvcNNZJrWwi/TIaJe4XSPq3pYOg0LhCtbA==; 5:vO0M9AcltnB1R7npnxkLLDPkrBYU/nnTkeZutshG4CtFhyyMdlu59gn7YDiLKPsGXd6TRbtCwyPO2OB91+pql0/b1EViwSH4Mrw6CFdAuaTH2zJaT5OH0hpOBC4tc5RZg4YfHUjYZ5vZTjDPWYqS3g==; 24:LgINKGmyu1quFbWD9lskVnzavXr7xx8FD073vveap1pM1U27JlEjN8CcdBMu3tZ6C8hggbQCnDYa3JJ08+dDV6bSj3wb+ysKQEZcMGAXP+A=; 7:FaEXeFjz3g5H/6CwmiJDWZCgdBxD52wfyRU/sC+sujDajwixifFpeCxat5Q9ptB3G4N9SQ0BsJyEFMWB5EZRifHlr/L0D1ER+MOTvUsyiLAPCQOwfRO8NgVthAFeJeOFVFAfozzoLjsWm+2jb595vqNIQmlT8ON4yCiFZDiRoTf8I/CEeFWg5DvJZFZY4VR2XFgDZYPfSXblD7hNR6fA/eCeOYbiRSXnn+nRw4q0oDPPFbuI2l+WWp72IIDcZx6c
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2674;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2674; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2674;
x-forefront-prvs: 0020414413
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(24454002)(189002)(101416001)(54356999)(106356001)(33656002)(122556002)(50986999)(76176999)(77096005)(66066001)(3846002)(6116002)(8936002)(19580395003)(102836003)(5002640100001)(2906002)(586003)(81156014)(81166006)(8990500004)(8676002)(106116001)(3660700001)(2501003)(2900100001)(9686002)(76576001)(189998001)(10400500002)(7696003)(3280700002)(7736002)(7846002)(2950100001)(86612001)(74316002)(10290500002)(92566002)(87936001)(99286002)(305945005)(105586002)(10090500001)(5005710100001)(68736007)(15975445007)(107886002)(97736004)(5001770100001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2674;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2016 20:10:14.7295 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2674
Archived-At: <>
Subject: Re: [Spud] Detecting and Defeating TCP/IP Hypercookie Attacks
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 31 Jul 2016 20:10:20 -0000

On Friday, July 29, 2016 5:34 AM, Brian Trammell wrote:

>... As I said
> during my presentation last Thursday, Ted Hardie and I sat down to think
> about this at lunch a couple of months ago, and found six ways one could
> execute hypercookie injection or coercion today before our pizza showed up.
> I sat down a little longer to write these up. I found five more, without even
> considering trivial out-of-band metadata leaks or steganographic side
> channels.
> meta-00 is the result. The conclusion: these attacks are trivially easy to
> execute today by exploiting the gap between valid TCP traffic and what will be
> ignored by TCP-indifferent devices and endpoints, as well as all those juicy bits
> IPv6 gives you...

The original message generated a long thread of comments, but I would like to look back at Brian's draft. First of all, this is an interesting piece of information, and I would like to thank Brian for writing it down. Whether we believe that additional shim headers are wise or not, we should certainly look at current privacy threats against TCP and IP, and as much as possible deploy mitigations.

Here is a set of detailed comments:

- Section 4.1.2, regarding DHCPv6, ought to quote RFC 7844, Anonymity Profiles for DHCP Clients, which specifies mitigations for that threat.

- Section 4.1.3, Identification using IPv6 network address translation, probably needs a bit more context. The NAT can only identify the user context if it links that context to a User-ID, which is somewhat hard for shared connections. But we should take this seriously and develop mitigations, e.g. end-to-end encrypted options that report the address seen by the peer. It would not prevent translation, but it would expose the practice.

- Section 4.2.1.  Fragment Identification Rewriting. Maybe it is time to specify in IP that if the "don't fragment" bit is set, the fragment identifier MUST be set to all zeroes, and SHOULD be reset to zero on reception. If enough end systems and intermediaries do that, this side channel becomes unreliable.

- Section 4.3.  Abusing Transmission Control Protocol Features. All that is true, but it is also part of the rationales for deploying encrypted transports like QUIC. As far as I can tell, none of these attacks apply to QUIC. Which is indeed the point made in section 5.

The draft mentions the IPv6 flow-ID, but creative intermediaries might also manipulate the TOS fields, so maybe there should be a subsection describing that too. And we could also have recommendations for API designs that expose the received values, so cooperating endpoints could detect alterations.

I think the draft should be extended to also cover UDP, and in particular the side channel created by the potential gap between IP packet length and UDP packet length. My personal preference would be to instruct middleboxes and end-systems to simply drop packets in which UDP length and IP length do not match.

-- Christian Huitema