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

Christian Huitema <> Mon, 01 August 2016 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAFE112D603 for <>; Mon, 1 Aug 2016 13:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Status: No, score=-2.003 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_H2=-0.001, 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 hc3lcaUrnVbG for <>; Mon, 1 Aug 2016 13:16:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F041612B062 for <>; Mon, 1 Aug 2016 13:16:00 -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=rNjV0m7PBIHc9VMbwAUpAf8w5U1dLqhq/igMPr+52yo=; b=nD9I0a6D6FeioK4A6XPUBg2Ln3pj7Kxfyt69SfqmnywgmTu4F+p32jnYxhfAIZLoqox6k6ElnEon1tR5+RskFTmbemmlg7Lk3C/VyXLPCy+1MjIRmu8Pcjx/pZKe39/lVd/B8qiFY0PBODkiibklO9QuBBpQDnLBSc3Vsb83nWI=
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; Mon, 1 Aug 2016 20:15:57 +0000
Received: from ([]) by ([]) with mapi id 15.01.0549.022; Mon, 1 Aug 2016 20:15:57 +0000
From: Christian Huitema <>
To: Spencer Dawkins at IETF <>, Tom Herbert <>
Thread-Topic: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks
Date: Mon, 1 Aug 2016 20:15:57 +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: [2001:4898:80e8:8::593]
x-ms-office365-filtering-correlation-id: 9c1e65cd-71d9-4da5-0358-08d3ba48a638
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2674; 6:JIDYNWS1GEofDgGsHqEcEkJUhU+tW8FesKLUEE4no2GiEVgowKnaKKldSjmcFpTdiKkVIBIyHl/xqR2zuygLbst7O/EXVJkGCKlTjPFdtF1zsfm9aLRMSY2/O4/GXB+b8Efg8d8WKMgoR3LTJYZR5mLDG3grAF6ANXkUrOiH7nWUs3ymWnrqPeqPW3fIm4fEkfJsL8fMX9sgZnyHmZGMK5GaySoqsOMGiMZTNdD/x/rhvWpFIgaciDaPDOqezKTYlphEzyykTiUa2bTzEC4rcn55vks2nmsv0C5sVxqTyUDLDj8/1ULiHe6ktQDuuIpeDDozDMi9DP+czQ3IQczE7Q==; 5:p2zAnjlOoTIk1S7ckg3UJ75NvvUFqB4NMQOYLaEPP4+Hviqulm99Ir1XyLF8h8OPd1+/LSbfaLQuboaNQsEIsvBNTx3VR0vcK9080Zmii+kYmrEHVvfMnv4enmPMNMLN0w7Ev5pE6ZkQk21HHkJFAA4MsunuBMhAbr/LYISYyvE=; 24:urzj1bxVI7O3y+4CqH5i0o4ExvTvQfyTd+DUZincCG7jhPtuJIWUBMTJg3vWRLIH3+fHJhoMCzzhriOUXzK1lVchK/LQ0hg9L7Fw46ui6Hs=; 7:FlXSDwnSvPI7Roxo4S+uXJbbzf8zKW/ktCT1V+nMyTVbOnJN83luGgQ0eSZLTBwH6rGBVsqoT/y26VjTYiRYjEhznrfvoyXQ9bLPB7owc05ZaXKRj/Q32hwNcPCq9reKdpmNp33X3GEAMj+O+02ekpEjX2l7VGMiMIednDZiYT0eD5ZewxqhqNbwH3jiqRatCsvKomWkMzj4Af48pZ0s1YrFNKf+ZBUGcsEXteAxrXdZAgY2qW0KwRbEVvJDNThx
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2674;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863);
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:(304825044); SRVR:BN6PR03MB2674;
x-forefront-prvs: 0021920B5A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(24454002)(189002)(106356001)(54356999)(101416001)(33656002)(50986999)(77096005)(122556002)(8936002)(93886004)(6116002)(5002640100001)(2906002)(76176999)(8990500004)(81166006)(81156014)(586003)(4326007)(8676002)(106116001)(74316002)(9686002)(76576001)(7696003)(189998001)(11100500001)(2900100001)(102836003)(10400500002)(86612001)(561944003)(7846002)(3280700002)(7736002)(2950100001)(3660700001)(10290500002)(92566002)(87936001)(305945005)(99286002)(105586002)(10090500001)(68736007)(97736004)(5001770100001)(5005710100001)(86362001)(3826002); 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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2016 20:15:57.5870 (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: <>
Cc: Eliot Lear <>, spud <>, =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <>, Brian Trammell <>, Stephan Neuhaus <>, Stephen Farrell <>
Subject: Re: [Spud] [Privsec-program] 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: Mon, 01 Aug 2016 20:16:03 -0000

On Monday, August 1, 2016 1:10 PM, Spencer Dawkins wrote:
> AH - I didn't realize you were talking about your proposal. I've read that. I lost any
> reference to it in the post I replied to - hence my confusion.

The question was whether it is a good idea to have special marks for packets that "start a connection," and specifically for packets sent over UDP by encrypted transports. Tom's point is that this will create breakage in many conditions, such as multi-homed nodes. I can see at least two scenarios in which we could see breakage with QUIC:

1) Client is sitting behind a nonplussed NAT. The QUIC session with the server becomes silent for a short period, and the client's NAT releases the UDP mapping. The client then sends more data. The NAT will assign a different port mapping. The server will use the connection-ID field in the QUIC header to route the packets to the right server, and automatically repair the connection. Suppose now that somewhere on path, maybe at the ISP router, some piece of software traces the connections and relies on "start of connection" marks. The "repair" packet comes from a different UDP port, and does not carry any "start" mark. Will it be dropped?

2) Client is sitting on a multi-homed network, managed by outgoing NAT. At some point, NAT management causes the packets to the server to be routed through the "fall back" ISP. The packets reach the server, the connection-ID filed does its magic, and the connection is automatically repaired. But of course, the routers on the new path don't see any "start of connection" mark.

There are probably more cases, but these two can happen today, with shipping code and existing hardware. The NAT mapping refresh, in particular, is quite common. This is why I much prefer "implicit start" processes to "explicit marks."

-- Christian Huitema