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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 01 August 2016 19:56 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 0E22712D60D for <spud@ietfa.amsl.com>; Mon, 1 Aug 2016 12:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eSWHYyMF0S6F for <spud@ietfa.amsl.com>; Mon, 1 Aug 2016 12:56:50 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 54D6E126579 for <spud@ietf.org>; Mon, 1 Aug 2016 12:56:50 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id u134so182641802ywg.3 for <spud@ietf.org>; Mon, 01 Aug 2016 12:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fG0QxlxNyNF2ip9mYK2Vu58RaZzSWzZ32ohrCf0AYms=; b=uBLhQWUVN4Aip0vllvA5AIY+ICnvGCWW1g+zBqkPxkTYRjkyviTYx9rGbxuYfykwGM jxMtkv58dh6cm0Rr5P4bzFaoGotv5iiwMdLJThUcv0tGJTDykKEr2SiASPhyDPSkdUh6 RozL8I4PCfgPcF/LIBKU57AlHw31zHMkNaPkBuJVOdw51lVMbR5IBGVNGsocmVwEBMxK 55WeXwgMZyesbXu9/K6OSvY1Mha6GhOrENVt4NWdqQV/cN+Adqhcsu5zCBlT6SzMR3+5 TkeR0TZP8XkJGL+SEHunFoS7AbDJfOA/uLTz5PfGKIlVQXFcw6S11XBScXPWaa0sXnEF YU6Q==
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=fG0QxlxNyNF2ip9mYK2Vu58RaZzSWzZ32ohrCf0AYms=; b=K92Oujq9+a+2XENhEx1mp+d72weD/9S0ovRlvrf+r46hu7B6+2XcrRZKcFqh2Vl/OI vewoeuZNUnd2+F3B7AfIp5FyQh4ixvppGil5UMe3609aRmJdiBHGqMd/6S8u/WvUfmD/ fV1wpqAXvp95ByS4sgMYzX5y3aHSf1SIDVH3mi0I0fimllA2RIwz8LMSEe/rrt0+RVk5 PJ5GjYWOSsW0tKojdta2/CvjkHLxXS4i4M5bXY1qYocEaGBgIAmIhvFJ86ZzEQFjrpil Yn2HJoe7vyAtKhqvEuKlcY5rFTJfN56n5Lx6ybKtwTLpPV+AkBEHfhMvKzZzA811gUfn 3WRA==
X-Gm-Message-State: AEkoouvRo6hHlqD9MRGnUFnu6cLhUoStomAm1l8P/F/V7jVDNYiHICa2HJYQimtwUXi82y5AWT8tDIrvmNm1nA==
X-Received: by 10.37.60.67 with SMTP id j64mr9462545yba.111.1470081409495; Mon, 01 Aug 2016 12:56:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.210.132 with HTTP; Mon, 1 Aug 2016 12:56:48 -0700 (PDT)
In-Reply-To: <CALx6S37Ni=qA-BcnNQepRwe3ZC48RNmirRVjCe1fv2bT3gQnWw@mail.gmail.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> <CALx6S37Ni=qA-BcnNQepRwe3ZC48RNmirRVjCe1fv2bT3gQnWw@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 1 Aug 2016 14:56:48 -0500
Message-ID: <CAKKJt-d02CmE7cW59s=A68SL=EQVTEVYOBzP74bnVXsEmfsY=A@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Content-Type: multipart/alternative; boundary=001a114bdd4c343f970539080012
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/PUCIKmRSj38dCHx9I7ktM8G7pD0>
Cc: Eliot Lear <lear@cisco.com>, spud <spud@ietf.org>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Stephan Neuhaus <sten@artdecode.de>, Brian Trammell <ietf@trammell.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: Mon, 01 Aug 2016 19:56:53 -0000

Hi, Tom,

On Mon, Aug 1, 2016 at 10:56 AM, Tom Herbert <tom@herbertland.com>; wrote:

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


I'm not going to guess what wireshark would show on your home network or on
Verizon's, but I'm having a hard idea understanding how a TCP connection
identified by a 5-tuple that includes a local address from your wifi routed
through Comcast stays active when you get in a car and drive away, so that
the only active interface on your smart phone now has a local address that
is routed through Verizon.

Mine don't (admittedly, mine are Comcast and T-Mobile), but. When I walk to
my car and get away, streaming media I was listening to in the house stops
when I run out of wifi range.

Are you sure you're not using (for instance) applications which open new
TCP connections periodically?

Spencer


> > 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
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>