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

Spencer Dawkins at IETF <> Mon, 01 August 2016 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E22712D60D for <>; Mon, 1 Aug 2016 12:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eSWHYyMF0S6F for <>; Mon, 1 Aug 2016 12:56:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54D6E126579 for <>; Mon, 1 Aug 2016 12:56:50 -0700 (PDT)
Received: by with SMTP id u134so182641802ywg.3 for <>; Mon, 01 Aug 2016 12:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id j64mr9462545yba.111.1470081409495; Mon, 01 Aug 2016 12:56:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 1 Aug 2016 12:56:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Spencer Dawkins at IETF <>
Date: Mon, 1 Aug 2016 14:56:48 -0500
Message-ID: <>
To: Tom Herbert <>
Content-Type: multipart/alternative; boundary=001a114bdd4c343f970539080012
Archived-At: <>
Cc: Eliot Lear <>, spud <>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>, Stephan Neuhaus <>, Brian Trammell <>, Stephen Farrell <>
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: Mon, 01 Aug 2016 19:56:53 -0000

Hi, Tom,

On Mon, Aug 1, 2016 at 10:56 AM, Tom Herbert <> 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?


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