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

Tom Herbert <> Sat, 30 July 2016 19:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2FC412D10D for <>; Sat, 30 Jul 2016 12:59:57 -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 vApqiSL7vwNB for <>; Sat, 30 Jul 2016 12:59:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3D9612D0AE for <>; Sat, 30 Jul 2016 12:59:56 -0700 (PDT)
Received: by with SMTP id f6so136052921ith.0 for <>; Sat, 30 Jul 2016 12:59:56 -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=QD3aKKeBvAQRyVM4TjSb7c2l44QCf+kSaDiyh+sg8AI=; b=Knk/HWSCWZY62OWMRRiLp2u8ahlwCTjlTUYHkS1BELvY9kKHr7i5zhTu4xluKCvJWo dOUaQvxNd4TKfbQMKoZzvL01dodeoEZ864Fr42BggeYt0bdGADVJg+pM1wwpUIO8uym3 cMf+AM3ExonXTescBBlGfzNpEchXV47Qa9Ls3Ggv8N6KseaqbeT3S2LwbKxEDIkyVdK3 +lKc0DlJJlVpwCENG5QVoVMparRNGOs7Oq+VoGhoxz3C6dgRXKvaqW35ToZhNkJ1kjF0 UdizP8XJBVh/qmA65+FaFlPLedjEps/2TT8UMAQavslUjQwqMu7JqWmOH+9Yhi5z+XlZ PMrQ==
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=QD3aKKeBvAQRyVM4TjSb7c2l44QCf+kSaDiyh+sg8AI=; b=b1DmB24kqRkTyhUi5BV8md+WEBaC5gQXN7ZMgFXQX6edqAHAv21N6SHsi9TrgXpYhY R3xzxvSSX7RXSREkiqRMNaBkPcSw8B2MTe/xAC+uYE0ujlYKt/Nvv9vbSUDPp1Stfpyj Q5fmcMfR42UbUKBMEIEkQzxkHYJo60axgoxyTDZiA/5FJ6SpOpUhUO3pq/cFzYDaebA/ fujhpAqKv6IXv/e+zV3KcjBnb188M5KPswupVigzgEiViydU1Sbchb3oNe6Pub9BCT5c 9mGnG1lekHP7UKIHnjB0Q3COCmZgdI4skCgx2fSzj/0ALC/V79t0WyQ3AxYXusbd9RVM 10Yg==
X-Gm-Message-State: AEkooutaH9/PSvNlBxEjkTrE4/jA1M2OLzta46ixMYqZ/8495mw9cb5IjCKRY3t/JXssQDKtfyVgp3/KFHVPVQ==
X-Received: by with SMTP id m2mr7558690itb.37.1469908795801; Sat, 30 Jul 2016 12:59:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 30 Jul 2016 12:59:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Sat, 30 Jul 2016 12:59:54 -0700
Message-ID: <>
To: Stephan Neuhaus <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: Brian Trammell <>, Stephen Farrell <>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>, spud <>
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: Sat, 30 Jul 2016 19:59:58 -0000

On Sat, Jul 30, 2016 at 11:24 AM, Stephan Neuhaus <> wrote:
> On 2016-07-30 19:21, Tom Herbert wrote:
>> I this is very debatable. The reason we want to encrypt the transport
>> layer in the first place seems to get easily lost in these
>> discussions; it is to hide transport layer information *from* the
>> network. This prevents intrusiveness of the network in transport
>> layers, stops middleboxes from trying to actively participate in
>> transport layer protocols, and thus resolves one major source of
>> protocol ossification and gets us back to the E2E model.
> PLUS offers mostly fields that are set by the endpoints and that are
> protected by MACs, so the can't be changed by middleboxes, at least not
> without the endpoint finding out. (There are a few fields that are
> supposed to enable signaling from the path to the endpoint(s) and these
> obviously need to be changeable by the middleboxes. These will be things
> such as "tell me the path MTU".)
> The PLUS fields will be stuff like "this packet starts a new flow", or
> "this packet ends a flow", and the read-only nature of these fields
> (unlike what we have now) means that middleboxes can not intrude, and
> they can't actively participate. This is exactly what you want, isn't it?
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). It is therefore incorrect for a
middlebox to assume that it can maintain correct connection state for
any connections. This becomes intrusive when the middlebox makes
decisions based on imperfect state that affects the connection, for
instance when a firewall drops packets for a legitimate established
connection but doesn't have state since it was not in the path of the