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

Tom Herbert <tom@herbertland.com> Mon, 01 August 2016 15:56 UTC

Return-Path: <tom@herbertland.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 162FB12D0D3 for <spud@ietfa.amsl.com>; Mon, 1 Aug 2016 08:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 bOiuFZNZc_aW for <spud@ietfa.amsl.com>; Mon, 1 Aug 2016 08:56:04 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08D912B044 for <spud@ietf.org>; Mon, 1 Aug 2016 08:56:03 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id f6so249252846ith.1 for <spud@ietf.org>; Mon, 01 Aug 2016 08:56:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DBS17KeJoJtZWyAcX6V4rwJk/jlNKKnr7GAU7gtTxi0=; b=TgwSNUzDtJk1PSSxruq6iarL6mccvPM/R7YnVdCOSdXqZeaMCig7imWj0VssIUSMSY NnF9AAaBWs2RXM5jprtBGP55nWVAY+gV9DWRGz9kRwB+AoRZ0rXG3ATAmXVWM4Hdgb+N sL/CSi62ZNZOp98m20zWjnvBR/O/eYfv2Ua/8NARce9maO+fHB/m3hbgvukTLaQ0KC1k VyqzcZ7KifMEXd7/qHR39NqnlqEAugge6K+ZLSBe2NLrikUdbN00F/07s3wMWgIdRigt b2FVj1Fow7mfmYOn3ycTqK1u5R7rUhLyp4Hc0Lb69/NzIPbUjgft+7l6oKRMAteTsDtM NyjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DBS17KeJoJtZWyAcX6V4rwJk/jlNKKnr7GAU7gtTxi0=; b=hnsPTzhZwgfcgXnDuRb3BU4UZDuMWGF461VFsTcugoHee79hu9IDPlB7OM/PAVp84e RlviD+tnmdh2F2EknvlLxXu6Re++sYSetQ72Q638wMXyx/VlAwtG2/c8U2SWlXA43b5V hjlm/88i3VBxlJreagneiB+kv3YQWVldD6Lo6+fK0Bm03ejON3//foewEq1Mw4M82zGb HmF6p3elkH9XG6hm8MZdu6bRD7/Qwp4ELaHgW5BPZHRjJdxC1i6cfE1YbACcLi0PgB9K fbtcX2X0TACvHI1S/3bfiIryt8qDDkLdxw+Py8M6l2UVdOHoDB4FEb/LSRLRZtuOZGOw NPdg==
X-Gm-Message-State: AEkoousFwzcs/uvt6CiqHaUWrVguvt6iKRRcV1h6+wDPhODKgi4eQ24ztGDRaKEmQ1Vsnvj5ZibKDBM5hh/HTg==
X-Received: by 10.36.14.193 with SMTP id 184mr60324089ite.91.1470066963226; Mon, 01 Aug 2016 08:56:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.130 with HTTP; Mon, 1 Aug 2016 08:56:01 -0700 (PDT)
In-Reply-To: <a2426583-22d7-85a1-e7a5-791c755f9209@cisco.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> <a2426583-22d7-85a1-e7a5-791c755f9209@cisco.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 1 Aug 2016 08:56:01 -0700
Message-ID: <CALx6S37Ni=qA-BcnNQepRwe3ZC48RNmirRVjCe1fv2bT3gQnWw@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/kx5bbTJYK9ZZgoe4BakmFF10CIE>
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:56:05 -0000

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

Well, I'm sitting here in my home looking at my Nexus 6 and I can
confirm that it is attached to Internet my via Comcast wifi as well as
Verizon's mobile network. So my smart phone is definitely a multihomed
and I definitely have multiple connections into my home. Right now I'm
using the wifi link, but if I walk into my backyard out of range then
I don't want the device to have to restart all my TCP connections when
switching to the mobile network. Neither do I want to have to create
2x connections like in MP-TCP just because I might at some point walk
into my back yard (it's kind of gloomy right now so I don't think I'll
be doing this anyway).

> 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.
>
We don't need routing infrastructure to change and we are really not
asking for any changes in the network other than they forward UDP
packets, respect E2E protocols, and otherwise implement the Internet
standard. The transport layer is being changed to facilitate
multihoming. Please look at connection identifiers in QUIC and
disassociated location in TOU ( draft-herbert-transports-over-udp) to
see how this is being done.

>
>> , 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)!
>
Those some of the possible ways to do handle multihoming, but by no
means does this define the complete solution space. There is still
room for innovation in alternatives as I pointed out above.

Tom