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

Stephan Neuhaus <> Sat, 30 July 2016 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C533A127078 for <>; Sat, 30 Jul 2016 11:24:16 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s_PVm_MLmJrW for <>; Sat, 30 Jul 2016 11:24:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C347312B008 for <>; Sat, 30 Jul 2016 11:24:14 -0700 (PDT)
Received: from [] (helo=mairac.home); authenticated by running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1bTYvj-0005mh-Qw; Sat, 30 Jul 2016 20:24:11 +0200
To: Tom Herbert <>, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <>
References: <> <> <> <> <> <> <> <> <> <>
From: Stephan Neuhaus <>
Message-ID: <>
Date: Sat, 30 Jul 2016 20:24:11 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: Brian Trammell <>, Stephen Farrell <>, 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 18:24:17 -0000

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?



Full disclosure: I'm working with Brian and Mirja on the MAMI project.