Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mptcp: Moving laptop from GBit to wireless without applications noticing?

redhat.com

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#31

Post by 1ncorrect »

mister_goo wrote: post #14
fulafel wrote: post #11

Earlier quoted context omitted.

SCTP is over 20 years old. I think the explanation for today's situation is slightly more complex than NAT boxes not having enough advance notice. NAT isn't allowed by the TCP/IP specs, for the exact reason that it breaks IP and new internet applications. Everyone was supposed to move to IPv6 with enough addresses so the temptation to use NAT would go away. Instead we ignored the stewardship of IETF and ISOC, and jus…

So there is a difference between what people are supposed to do and what people actually do. What I am wondering now is why IPv6 didn't adapt NAT as a first class feature, if IPv6 added something like port number in IPv6 header, NAT could not break protocols. It seems IPv6 strongly resists NAT, but in reality, people still use NAT on IPv6.

Using NAT with IPv6 betrays a lack of understanding with how it’s supposed to be used, and a stubborn continuation of IPv4 kludges.

Multiple addresses/prefixes are a required component for IPv6 to function, which I suspect is often the biggest source of misunderstanding from legacy IP competency.

If you need a stable prefix for a host, use a ULA or your own GUA. If you need to provide services from 2 or more upstream networks, configure the host with addresses from each of the delegated prefixes from those networks. If you need to do all of the above, there’s nothing preventing you from configuring them all simultaneously. You can even use the IP and routing stack to provide selective service access and trust thresholds.

Prefix mobility is something that should have been anticipated when IPv6 was being hashed out, and would have made many things much easier, but it’s far from critical, and gives IPvA an easy killer use case.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#32

Post by toast0 »

dr_hooo wrote: post #12
fulafel wrote: post #8

The net community gave up on the TCP->SCTP upgrade because of NAT (and other middle-) boxes breaking IP. It would have fixed many other things too (eg head-of-line blocking). The good side was that we kept the simplicity of TCP. I wonder what's the middlebox story of MPTCP.

In MPTCP each connection from the bundle appears/behaves just like a single "traditional" TCP connection. Therefore - at least in theory - there should be no issues with NAT/middleboxes. In fact this has been a major design goal from the start.

MPTCP uses new TCP options. Middleboxes could mess those up.

OTOH, last I heard, Apple uses MPTCP for Siri, so you've got a popular use with a strong influence on mobile networks, that's going to be pushing for at least safe fallback, if not actually working.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#33

Post by goodpoint »

rubatuga wrote: post #29
goodpoint wrote: post #27

Earlier quoted context omitted.

A VPS is much cheaper and the user is not reqired to trust a VPN-like service not to snoop traffic. But it still does not solve the problem of adding a lot of latency.

If your threat model is based on your ISP not snooping on you then you need to improve your security…

Improve it by not having Internet connectivity I guess?

Even Tor is vulnerable to timing correlation attacks, imagine everything else, given how leaky most protocols are...

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#35

Post by jiveturkey »

goodpoint wrote: post #33
rubatuga wrote: post #29

Earlier quoted context omitted.

If your threat model is based on your ISP not snooping on you then you need to improve your security…

Improve it by not having Internet connectivity I guess? Even Tor is vulnerable to timing correlation attacks, imagine everything else, given how leaky most protocols are...

Parent is referring to end-to-end encryption, ie layer 7. However, as you point out, he is oversimplifying. Or perhaps underthinking.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#36

Post by jiveturkey »

relevant: https://apenwarr.ca/log/20170810

wow, did he write that 5 years ago?

I guess I could just google it, but does anyone know if the OSI stack is portable to the application layer, the way that apenwarr was promoting, and the way that mptcp simulates? Since the time of that article, I've always wondered if that was the case. Or is OSI "broken" in its layering, like TCP/IP.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#37

Post by zootboy »

cmsj wrote: post #22
linsomniac wrote: post #2

MPTCP has been on my radar for a long while and seems very cool. I will say that for seamless wireless/wired switching, Linux bonding works very well. ~15+ years ago I had my laptop set up with eth and wifi bonded, with eth as the preferred, I believe using link-beat as the method. I could be running a big copy, plug in the ethernet and the transfer rate would almost instantly shoot up, and then when done I could unp…

Yep, I used to do that when I had a thinkpad and a docking station and didn't want all my ssh sessions to drop. Before that I was even doing awful things like forcing the same IP onto both eth and wifi :D

I've had a concept in mind for this exact scenario that I'm reasonably certain will work, I've just never taken the time to fully implement it.

No need to bond interfaces or apply the same IP to both interfaces. Let them both acquire different IP addresses in the same subnet. Linux will start announcing its ARP replies on the ethernet path since it has a better path metric. Thus the return path for both the wifi IP and the ethernet IP will become the ethernet link. Any existing connections that were traveling over the wifi link will just move onto the ethernet link automatically.

The only difficulty is new connections. Since the ethernet path has the better metric, new connections will establish with the ethernet link's IP address. But the routing table can be adjusted to instead make the wifi link's IP address the default for both the wifi and the ethernet links. Then new connections will always use the wifi IP, and will migrate over to the wifi link when the ethernet link disappears.

This should work as long as your wifi link always remains up whether or not you're in the dock.

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#38

Post by linsomniac »

zootboy wrote: post #37
cmsj wrote: post #22

Earlier quoted context omitted.

Yep, I used to do that when I had a thinkpad and a docking station and didn't want all my ssh sessions to drop. Before that I was even doing awful things like forcing the same IP onto both eth and wifi :D

I've had a concept in mind for this exact scenario that I'm reasonably certain will work, I've just never taken the time to fully implement it. No need to bond interfaces or apply the same IP to both interfaces. Let them both acquire different IP addresses in the same subnet. Linux will start announcing its ARP replies on the ethernet path since it has a better path metric. Thus the return path for both the wifi IP a…

I guess you could do this by just sending gratuitous ARPs for the wifi IP with the eth MAC addr, over the eth interface. Probably have to turn off rp_filter as well?

Re: Mptcp: Moving laptop from GBit to wireless without applications noticing?

#39

Post by goodpoint »

jiveturkey wrote: post #35
goodpoint wrote: post #33

Earlier quoted context omitted.

Improve it by not having Internet connectivity I guess? Even Tor is vulnerable to timing correlation attacks, imagine everything else, given how leaky most protocols are...

Parent is referring to end-to-end encryption, ie layer 7. However, as you point out, he is oversimplifying. Or perhaps underthinking.

> Parent is referring to end-to-end encryption, ie layer 7

Once my traffic is cleartext, a TCP connection to 209.216.230.240 is enough to infer I'm browsing this site.

Post reply on HN