[HN Gopher] tcpcp - passing TCP connections between hosts (2005)
___________________________________________________________________
tcpcp - passing TCP connections between hosts (2005)
Author : pabs3
Score : 49 points
Date : 2022-04-25 02:17 UTC (20 hours ago)
(HTM) web link (tcpcp.sourceforge.net)
(TXT) w3m dump (tcpcp.sourceforge.net)
| remram wrote:
| Is there a similar tool that will handle a TLS layer on top? Or
| is there something like renegotiation that makes it trivial?
| jandrese wrote:
| There is some security concerns with exporting the ephemeral
| private key material over a network connection. Technically
| there is nothing that makes this impossible, but from a policy
| perspective it may be a nonstarter.
| remram wrote:
| That's why I was thinking more about a key renegotiation,
| which I know exists in SSH and existed in TLS at one point
| (at least I know there's a shortcut for it in openssl's
| s_client).
| touisteur wrote:
| One of the ideas of tcp checkpoint restore, at least for
| me, is to avoid a round-trip delay when restoring the
| connection. Wouldn't a key renegotiation cause at least one
| round-trip? I'm probably being dense here...
| toast0 wrote:
| If you're OK with transferring tcp state, I don't see why you
| wouldn't be ok with transferring TLS state, too. You don't
| even need to transfer the certificate private key. I've seen
| some systems where the certificate private key isn't present
| on most edge nodes; session signing is proxied to centralized
| nodes and the edge nodes just do the bulk ciphered with the
| session keys, which necessitates sharing the session keys
| over a network.
| dxld wrote:
| I was looking into this some years back when I was considering
| building a high-availability IRC bouncer that can pass the TLS
| IRC connections around with this.
|
| There isn't anything out of the box that I could find, but
| there was some discussion/prototyping around adding an API for
| exporting all the necessary key material and metadata to the
| mbedtls API. With that it would have been "relatively" "easy"
| to do the TLS bits :)
|
| See https://github.com/Mbed-TLS/mbedtls/issues/3141 and linked
| ML posts.
| touisteur wrote:
| Was there a recent update to the project? I think the state-of-
| the-art on this (on Linux) is libsoccr (from CRIU) that uses
| Linux kernel support for tcp checkpoint-restore. If you're ever
| for real doing that, you'll need some serious plumbing to make
| sure your tcp socket is doesn't get updated under your nose while
| you're checkpointing it. Hint: it involves qdiscs, ifb and
| netlink. Fun project.
|
| I keep hoping one day I'll be able to do the checkpoint operation
| in one chained io_uring op series :-)
| Uptrenda wrote:
| I read the paper briefly on this. I get that you can 'transfer' a
| socket to another host by sending where you are in the stream and
| its state. What I don't get is how exactly does the 'peer' change
| to the new socket? They will be sending packets to the old IP.
| Second machine has it's own IP.
|
| If the purpose of using tcpcp is for 'load balancing' or w/e,
| then why does it seem to need the connections behind a single
| machine for routing? I assume this is what redirects inbound
| traffic from the peer to the new machine. But if it still
| requires a single machine for routing then it will be just as
| congested and not load-balanced.
|
| What am I missing here?
| leohonexus wrote:
| The concept at least seems insanely useful with EC2 spot
| instances - I've always wondered what's the easiest way to
| transfer stream connections to another host pending imminent
| shutdown without the client experiencing any downtime.
|
| It might even be possible to run a service fully on a moderate
| fleet of ephemeral instances and save over half of the EC2 costs.
| Thaxll wrote:
| This does not work AZ / zones most likely, also how do you
| transfert the state from the upstream routers?
| kreetx wrote:
| What about using a load balancer in front of any two instances?
| toast0 wrote:
| a) how do you handle pending shutdown of a load balancer
|
| b) sure ok, if it's an http load balancer, you can finish up
| the existing requests and any new requests will go to new
| servers; but if it's a tcp load balancer, those don't
| generally let you swap the server in the middle
| wanderer_ wrote:
| Heh, I guess screw them and shut it down anyway - at least
| that seems to be the policy in my IT department :)
| kevin_nisbet wrote:
| a) There are several load balancers that allow sharing the
| state tables. So if you control the network, you
| share/transfer state tables ahead of removing the LB node
| from routing. Can even be the same IP with ECMP. I don't
| know how you would do this on something like an AWS
| network.
|
| b) In general your right, but this is already a fairly
| niche use case. But I do wonder if reprogramming the
| conntrack entry in linux would work, or for lvs which
| already has a userspace daemon for state synchronization,
| how it would behave if reprogramming an existing state.
| It's at least not implausible to do that rewrite somewhere
| real time... if you control the edge system.
|
| Also, again in a you control the network scenario, OpenFlow
| switches might allow you to reprogram the state tables
| while they're live.
| touisteur wrote:
| netlink has all you need
| https://github.com/tgraf/libnl/blob/master/src/nf-ct-
| add.c
|
| The Linux kernel stack is crazy.
| rzzzt wrote:
| The paper mentioned in the documentation section is available in
| the Wayback Machine:
| http://web.archive.org/web/20050515132831/http://www.finux.o...
___________________________________________________________________
(page generated 2022-04-25 23:01 UTC)