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

Tom Herbert <> Mon, 01 August 2016 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D088512D9C4 for <>; Mon, 1 Aug 2016 07:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vXYKQOr2Fnxa for <>; Mon, 1 Aug 2016 07:59:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E172012D594 for <>; Mon, 1 Aug 2016 07:59:26 -0700 (PDT)
Received: by with SMTP id m101so185149901ioi.2 for <>; Mon, 01 Aug 2016 07:59:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dnRBIbtGQcTCq/70oS6jjKziPhrqeRLrZ6deeLsGvQ0=; b=eV9RQrTzuxctKA+Lc8JZOWA8XiVB6IO8Yu7BymFKguKK1B8y0dEuS+xe5IuNDkANHN 13DfBKVfMTfLdB27qk/c9cZKVavfehK0BdE6vrhXhjqFcKRHkW6qfL7OQAsoHT9h87nJ swjSqKF1Jmsv7hDJW2hbz2QAAKQWOa8AotVEzdo8DpafeWTkuc0CZtJMS0SeV/RVNLEk l/KbQmr3cNhaKaMCG5i0fm93M7aFCIWuZdUYmNVaUgcXye7bFZmQOOG1KN3PpiFt9XGZ mBAKLI/1OoaJ0Dos1uJee52MthYgt6EIom1iP6fSBd0CZjBvHt0xp0HwuHkLN7BwUEoa GHXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dnRBIbtGQcTCq/70oS6jjKziPhrqeRLrZ6deeLsGvQ0=; b=cuVoAkMYcFgPEmQFfZBXb7oV8avGLKTv88D0+GYoR2kAN4eiZxPPs2aKcqfZ8Rw0qm LiZNeaQz1eMw5FE3ln6xoRhxAWaIaootGAOHbaIeylEXGOOe/D8s9hRtnEf0SAgN3/Rs OSA+bTQLH54wqy90XrJs66i7xpKieJNeigMR9YhmKv9MU/LJOKsMxJ7wPrhKfEMrg6Mx NtaTqyUy14afoyIY1XTfV5QwvHdDnQR70MMe9XbNPIOEzkIzWq5sBgBQLFJ93BzOoXto vAVfQp5VuwGlzxIl6BaJN6E1K82yv5MVIVUVr9Mzrw+ZBOhNZ+22WsqwkviG0oQHcJWw IpjQ==
X-Gm-Message-State: AEkoouv0nFtcvhZjPSKzl2iL4tJxBWo89Khm+5rtu5Cyx8tSv6P1rrAhnMbtdAwt8VBySBp2ogI1vh+ZMgw/Lg==
X-Received: by with SMTP id 72mr57414920ioz.50.1470063566128; Mon, 01 Aug 2016 07:59:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 1 Aug 2016 07:59:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Mon, 1 Aug 2016 07:59:24 -0700
Message-ID: <>
To: Eliot Lear <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Stephan Neuhaus <>, Stephen Farrell <>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>, spud <>, Brian Trammell <>
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 14:59:29 -0000

On Sun, Jul 31, 2016 at 11:34 PM, Eliot Lear <> wrote:
> On 7/30/16 9:59 PM, Tom Herbert wrote:
>> No, it's not. In fact, exposing flow start/stop information is a good
>> example of something that facilitates intrusiveness by middleboxes at
>> the transport layer.
>> The purpose of exposing this information is to allow network devices
>> to track connections, but connection tracking in the network is
>> fundamentally flawed since there is no requirement that all packets of
>> a connection go any single network device (i.e. the Internet is packet
>> switched not circuit switched).
> Except that I will bet you that over 99.999% of connections do, and that
> this is particularly sufficient for home routers.

If that number it is correct it is only because home routers have
ossified the Internet in that regard, not because the standard was
ever changed to require it. Desktops sitting behind home routers is no
longer a sufficient model for the Internet; mobile devices are
currently predominant and the Internet needs to adapt accordingly.

Consider that mobile devices are multihomed having at least two
network connections. We want the ability to seamlessly switch between
networks (say from wifi to mobile) or between mobile networks as we
drive down the road. Performing 3WHS is very expensive on mobile
(literally for some of our users), so we need connections to survive
across these path changes. If we hide the transport layer from the
network devices (e.g. from home routers) then they can't enforce the
single path assumption. In fact, once we disassociate location
(addressing) from connection endpoint identification (like described
in TOU) then connections should be able survive even across an address
change and between two completely providers. This is of huge value to
our users and IMO justifies encrypting the transport layer.