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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Tom,

On Mon, Aug 1, 2016 at 10:56 AM, Tom Herbert <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>