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

Eliot Lear <lear@cisco.com> Mon, 01 August 2016 15:09 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 9A15F12DA16 for <spud@ietfa.amsl.com>; Mon, 1 Aug 2016 08:09:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.809
X-Spam-Level:
X-Spam-Status: No, score=-15.809 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, 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 xlNpCyxYsGnD for <spud@ietfa.amsl.com>; Mon, 1 Aug 2016 08:09:00 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D574512DC41 for <spud@ietf.org>; Mon, 1 Aug 2016 08:08:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4539; q=dns/txt; s=iport; t=1470064139; x=1471273739; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=FZn5rD/VwL1NZj7HoZcSLsZntW/sGbZaRdLJLzf2P9g=; b=EIc+KWZOFj2MEjnVCQgKVvE84CwlntN8ud0/ycInfCBo32adkALTNDaR oRazEa/miijVfCHIBvYY442d15D72kRevarXzBCmJ42wZt8uPptnejQYe Zk+Z+JsEp3HzNJurKZasWdsJEPGsMApaDPAVAaS8qkCMIT5ijNROXA5w6 8=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBADkZJ9X/xbLJq1dhEW7YoYdAoFoE?= =?us-ascii?q?QEBAQEBAQFdJ4RfAQUjVhALGCoCAlcGDQgBAYgtsGyPaAEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBEg6IIoJVh0GCWgEEmTODOoFwiVWJU4VskCc0IIN8OohHAQEB?=
X-IronPort-AV: E=Sophos;i="5.28,455,1464652800"; d="asc'?scan'208";a="680415254"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 15:08:57 +0000
Received: from [10.61.168.28] ([10.61.168.28]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u71F8vWt008352; Mon, 1 Aug 2016 15:08:57 GMT
To: Tom Herbert <tom@herbertland.com>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <d27266cf-87f6-17b1-3038-e0f614c6c773@cs.tcd.ie> <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>
From: Eliot Lear <lear@cisco.com>
Message-ID: <a2426583-22d7-85a1-e7a5-791c755f9209@cisco.com>
Date: Mon, 1 Aug 2016 17:08:57 +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: <CALx6S375si8km=8NhMfgWAtqE09Xju3CH1k3ktuae6gi8XT5ww@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wJ9fXFAS74nTNFbakANxabDwaCNrPGcQH"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/9BEKYSvhNDk677xHsbUDTj0Q1LM>
Cc: Stephan Neuhaus <sten@artdecode.de>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, spud <spud@ietf.org>, Brian Trammell <ietf@trammell.ch>
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: Mon, 01 Aug 2016 15:09:01 -0000

Hey Tom,


On 8/1/16 4:59 PM, Tom Herbert wrote:
> If that [99.999%] number it is correct it is only because home routers have
> ossified the Internet in that regard

I realize that people have ossification on the head, but I'm sure you
recognize that the right answer here is that most people only have a
single connection into their homes.  For those who have more than one,
the two either are disconnected networks or they come together in the
same box.  We do not have the routing infrastructure today in place to
multihome to your laptop/iPhone/tablet/Android/FB phone, something I
deeply regret we have not yet worked out. Maybe some day.


> , 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.

But the way this is done is through multiple pesistent transport
connections bound off of separate L3 local addresses.  We have attempted
to do otherwise through MIPv6 and LISP-MN.  Not widely deployed, and
even were they so, it is probably sufficient for something like the LISP
header to be above PLUS (think about that until you're 103)!

Eliot