Multipath UDP Hopping / Uplink Migration about kcp-go

[xtaci]

what exactly does Connection migration means?

[heri16]

See https://github.com/devsisters/goquic/blob/master/README.md or https://mosh.org. Means tunnel is kept open even while switching between 3G or WiFi, or connecting over different uplinks.

[heri16]

Zerotier does this very well. UDP Packets can come in over any interface or route but are first validated. Only if successfully validated, will the new udp connection/source be registered as an active path. Tested kcptun with --conn 2 and Kcptun breaks the inside TCP connection when the WAN on client side does failover.

[xtaci]

yes, i mean , connection migration is another layer above connection

so, it's not to be implemented in this layer, It should be designed as an overlay network library.

[heri16]

Tested kcptun with --conn 2 and Kcptun breaks all tunneled TCP connections when the WAN on client-side does failover to another uplink. Should this issue be under kcptun repo?

[xtaci]

this library acts exactly(almost) like a TCPConn, behaves like a TCPConn.

ovpn(or other IP over IP tech) can act as an overlay network above this connection, i think it's the correct way.

[heri16]

Behaves like a TCP connection sounds just like QUIC protocol specification by google. Just that kcp does not do connection migration which is one less feature. Which makes it unsuitable for mobile.

[heri16]

Would the QUIC Google Chrome developers say: oh, just use another overlay network like ovpn to access your website.

[heri16]

Are there other considerations that I am not aware of as to why this feature request is being refused? Yes, KCP should be a reliable transport over UDP, but it does not mean that connection migration is out of scope cause the inside stream should not need to care that the uplink or udp source/dst has changed many times since the stream opened.

[xtaci]

connection migration needs careful design of authentication & authorization, it's so complicated, and like session hijacking, and QUIC hasn't larged deployed in mobile devices(i think), from my experience, application-level auto-reconnection is enough for most non-realtime applications.

[xtaci]

the intention of kcp.conv is connection migration

[xtaci]

but, it's so easy for session hijacking, actually , I haven't found a way for secure connection migration, it's definitely a hard problem.

[heri16]

Thanks for the explanation. Is integrity and authenticity validated on every kcp udp packet in the current implementation? https://en.m.wikipedia.org/wiki/Authenticated_encryption

[AudriusButkevicius]

It would be nice if this was an option. If you are using tls on top of kcp, the only thing you can do by hijacking is DoS. Linux/Android also supports mTCP (multipath tcp) that does the same thing, which could perhaps be an inspiration on how to make hijacking hard.

[xtaci]

We can add AEAD for every outgoing udp packet, but it's far from the entire story.
The hard part is how to prove it's security.

[AudriusButkevicius]

That doesn't really help as the key exchange still happens in plain text as far as I understand.

[xtaci]

most key exchange use DH algorithm, that's not a problem for establishing temporary encrypted session without authorization.
when switching client uplink, how can you tell from a Captured Replay Attack Packet from a Real Uplink change?

[xtaci]

I think we need to figure out the whole picture of how QUIC handles connection migration first.