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

Eliot Lear <lear@cisco.com> Tue, 02 August 2016 07:47 UTC

Return-Path: <lear@cisco.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE0B12B008 for <spud@ietfa.amsl.com>; Tue, 2 Aug 2016 00:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level:
X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBCNepS00eT6 for <spud@ietfa.amsl.com>; Tue, 2 Aug 2016 00:47:46 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D6712B035 for <spud@ietf.org>; Tue, 2 Aug 2016 00:47:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8696; q=dns/txt; s=iport; t=1470124065; x=1471333665; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=V6qDePNefp4Ux7wV5w/ZQVGtRAEtoguez/TgYK39z/c=; b=Qhn3/KoUMkOT25IRcvboqJCokrzwxnbXD7/lJKXpA0OmJfc/+QdXt/x5 HJuJQlUuA3GdSzWJzwgE9Araq3sCbdYaIiS5737Inl5duYqG8WP8p933f 6vipH6uf1D1+1ptCEMAPRrtC5WaNCAe+gvuS1hGu1Gj7Pl1uqFrxt+bI3 o=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DICACQT6BX/xbLJq1chEW0dIcDgmaDN?= =?us-ascii?q?wKCAwEBAQEBAV4nhF8BBAEjVgULCwQ+AgJXBgEMCAEBiCUIsQSQBwEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQ4OiCIIgk2EDIM1gloBBJkzgzqBcIlVgWuEWoMOhWyQJ?= =?us-ascii?q?1SCEhyBTjqISQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,459,1464652800"; d="asc'?scan'208,217";a="639025745"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2016 07:47:43 +0000
Received: from [10.61.168.28] ([10.61.168.28]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u727lgje025530; Tue, 2 Aug 2016 07:47:42 GMT
To: Tom Herbert <tom@herbertland.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <dc29fa73-88fd-3dc4-7497-f1bd2fa60422@cs.tcd.ie> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <D2CEDF13-E508-4732-B8F6-98FBBDDC7EE6@tik.ee.ethz.ch> <CALx6S34gVFDJ6mV=GVrfK5doTK2BbRRWXvxeqFUtidfPp5XGKg@mail.gmail.com> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> <CALx6S36zv4=S8tgRNqwee0j973Y_gJ7RBnnnV+0vBq_4kn7PVw@mail.gmail.com> <aa2afa2c-23d0-bf50-a82e-654fd08f373a@cisco.com> <CALx6S375si8km=8NhMfgWAtqE09Xju3CH1k3ktuae6gi8XT5ww@mail.gmail.com> <a2426583-22d7-85a1-e7a5-791c755f9209@cisco.com> <CALx6S37Ni=qA-BcnNQepRwe3ZC48RNmirRVjCe1fv2bT3gQnWw@mail.gmail.com> <CAKKJt-d02CmE7cW59s=A68SL=EQVTEVYOBzP74bnVXsEmfsY=A@mail.gmail.com> <CALx6S36paAxPP317aDGybkrPWtJ9L+ZuTYOHTQ11ejwUgJ7vFg@mail.gmail.com>
From: Eliot Lear <lear@cisco.com>
Message-ID: <214f5f15-5466-f93c-1d37-cb57398f4d1e@cisco.com>
Date: Tue, 2 Aug 2016 09:47:41 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CALx6S36paAxPP317aDGybkrPWtJ9L+ZuTYOHTQ11ejwUgJ7vFg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0OI3i50SweanneBI5S5p1Mk5MkbReBWGx"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/Hig8SovCIL6GXnMGvYJmJFXqmFw>
Cc: Brian Trammell <ietf@trammell.ch>, Stephan Neuhaus <sten@artdecode.de>, spud <spud@ietf.org>, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 07:47:47 -0000

Hi Tom,


On 8/1/16 10:06 PM, Tom Herbert wrote:

> TOU will negotiate a session identifier (similar to connection
> identifier) in QUIC. With this the TCP endpoints no longer use the
> 5-tuple to identifier the connection, they use the session identifier.
> This provides unambiguous connection identification that is
> independent of addresses or encapsulating UDP ports (the most
> immediate problem this resolves is NAT state remapping). Strong
> security is required to prevent connection hijacking and there are a
> couple of other caveats. Please look as section 3 in
> draft-herbert-transports-over-udp for details.
>

TOU is similar in many ways to what HIP did in the early days, and the
HIP developers had a pretty cool demo of it.  The threats we faced back
then were nowhere near as advanced as they are today, nor are they as
prevalent.  There is not a single platform upon which you base your
software that hasn't been attacked successfully, although some have been
attacked more regularly than others.

Let me be as clear as I possibly can be: I view a protocol that doesn't
offer an answer to the question “who initiated the communication” as
unsafe to be deployed on the Internet.  I will make another bet with
you, that at least half of your user base is running on old code with
known vulnerabilities.  This is even more critical on battery-powered
constrained devices, where a broad-scaled and sustained DDoS attack
could drain those batteries and harm a lot of people, in a short period
of time.

If there are tradeoffs to be made in mobility design because of this,
then those tradeoffs should be made.  But before you view it in that
light, lengthy research has demonstrated that RF requires repeated
selection queries to determine what is available.  That is the work done
by SCTP researchers such as Randy Stewart, and so mobility isn't being
traded off at all.**

You are seeking formal agreement of network behavior.  I am seeking an
answer to my question.  If we formalize the answer to that question,
then you have what you want and I have what I want.  I've been told that
QUIC has such an answer to my question, which is good.
I'd like to understand how that is accomplished in a secure manner. 
Certainly integrity protecting the 5-tuple and any sequence #s sounds
like a good idea, to say the least, if it can be efficiently accomplished.

Eliot