Support upgrades on libp2p_quic::GenTransport

[kayabaNerve]

Description

Support InboundConnectionUpgrade, OutboundConnectionUpgrade, on libp2p_quic::GenTransport.

Motivation

I have an InboundConnectionUpgrade and OutboundConnectionUpgrade to replace the encryption layer's PeerIds with my own long-lived identity keys (unsupported by libp2p, hence the need for the custom middleware). While tcp lets me provide such upgrades, quic doesn't, with the quote:

Note that QUIC provides transport, security, and multiplexing in a single protocol. Therefore, QUIC connections do not need to be upgraded. You will get a compile-time error if you try. Instead, you must pass all needed configuration into the constructor.

I spent a few hours seeing if I could manually wrap GenTransport, or compose with and_then, to achieve the desired effects but I was unable as libp2p-quic yields Connection, not Stream to these locations. I'd have to further wrap Connection into my own which applies upgrades while manually calling poll_inbound/poll_outbound. While I am debating doing that, having just spent a notable amount of time attempting to do this and wanting to be successful, I don't feel I should have to. I should be able to just provide arbitrary connection upgrades. QUIC may be great and not need upgrades, but that doesn't mean it should be limited as to not support upgrades.

Requirements

• Make an underlying type which accepts connection upgrades
• Make GenTransport an alias to the underlying type with no connection upgrades (optional)

Open questions

No response

Are you planning to do it yourself in a pull request?

No, as I don't believe I have the proper expertise

[kayabaNerve]

Actually, I'm unsure even Connection would be the possible place for me to do this as that's after libp2p has yielded a PeerId for this connection. While and_then lets me malleate it, I can't read/write without obtaining a stream. While I could spend the time to work on if that's valid, the fact it's a Poll-based API (not a Future-based API) reaffirms my belief this should be supported in a first-party sense.

[elenaf9]

How exactly do you use your custom keys in the network? Just to verify that the remote peer is a authenticated peer in the network (i.e. to check if a connection should be established or not), or as an identifier for peers in the network?
In case of the latter: is my assumption correct that your key can be converted into a PeerId?

[kayabaNerve]

The latter.

Yes, in the sense PeerIds are bytes and you can put whatever you want there. Referring to the examples/common practice, if you use noise, the long-lived Ed25519 key used with noise becomes your PeerId. My key isn't Ed25519 so I cannot use it directly with noise. I need to define my own security upgrade, whereas noise returns the long-lived Ed25519 key as its PeerId, I return my key.

https://github.com/serai-dex/serai/blob/next/coordinator/p2p/libp2p/src/authenticate.rs for my literal upgrade. I use this with allow-block-list, populated with PeerIds of this form.

I'm sure I could alternatively use a construction on top of identify, or my own behavior, yet then I can't identify peers by their keys without defining, maintaining, and passing around an additional mapping for the translation. This was by far the most ergonomic solution.

[elenaf9]

While looking into alternative solutions to solve this, I just remembered that we also have Transport::map.
If I understand it correctly, it allows you to map a transport's Output (in case of quic the (PeerId, Connection) into a new output future.
I think you can there just perform your custom authentication handshake on the connection and output your custom PeerId together with the unchanged connection. Is that what you were looking for / would that work?

[kayabaNerve]

It doesn't immediately. That'd be passed the libp2p::quic::Connection which implements StreamMuxer. For TCP, this is applied before multiplexing, and ideally this would be here too. Else, I'd have to figure out polling for the substream to the relevant peer, negotiate over that substream, then drop that substream (expecting it to be re-opened at a higher level?) as I propagate the impl StreamMuxer but with the new PeerId.

[elenaf9]

Well yes you'd have to once open a new substream to perform your custom handshake, within your map future. But you don't have to wrap the Connection itself or implement StreamMuxer on a custom type, if that's what you mean.
The internals of Connection or Stream don't care about PeerIds. They just output it once after connection establishment, so that the higher layers can use it.

[github-actions]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

[elenaf9]

@kayabaNerve apart from having to (once) open and poll a new substream for your handshake, is there any other reason that the above won't work for you? I still think it is the simplest solution.

Given that the multiplexing is embedded in the QUIC protocol and quinn implementation, the only other way I can think of is a custom (rus)tls config that implements your authentication. However, that would then completely swap out the libp2p authentication, and I am not sure if we should expose such an option.

[github-actions]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

[github-actions]

This issue was closed because it is missing author input.