Support server reflexive TCP candidate type

[joshua-kim]

Support server reflexive TCP candidate type

[stv0g]

@ashellunts I think this might interest you.

[ashellunts]

If peer A is behind NAT and peer B is not, that should work.

If both peers are behind NAT, server reflexive is needed, which is not supported.

[ashellunts]

Hi @joshua-kim,

server reflexive TCP candidates are not supported. Only host ones.

Can you describe what is your use case? Can NAT1To1IPs help you?

[stv0g]

Server reflexive TCP candidates are not supported. Only host ones.

Just wondering, is this even possible/reasonable to implement support for Active/Passive TCP types?
Or is the SimultaneousOpen TCP type better suited here?

Here are the relevant parts of the RFCs:

• https://www.rfc-editor.org/rfc/rfc6544.html#section-5.2
• https://www.rfc-editor.org/rfc/rfc6544.html#appendix-B
• https://www.rfc-editor.org/rfc/rfc5389#section-7.2.2

@ashellunts Do our Passive TCP candidates only accept connections from known remote active TCP candidates? Are we checking their source IP/port when accepting the connections?

[joshua-kim]

Hi @joshua-kim,
server reflexive TCP candidates are not supported. Only host ones.
Can you describe what is your use case? ...

I'm aware that for some reason it's much more difficult to support connections over TCP than over UDP (although to be honest I'm not sure why, I definitely need to research this more). Our use case is that we work on avalanchego which is a p2p blockchain network.

Currently nodes can only connect to each other assuming they're publicly discoverable + not behind a stateful firewall. Ideally, we'd like to support nodes connecting to each other via a STUN server in the case that one of them wants to sit behind a NAT.

... Can NAT1To1IPs help you?

My understanding is that you can pass in some hard-coded ips that will act as candidates to connect to? If this is the case I don't think this will work if two nodes which are both behind their own NATs want to connect to each other, as I think we need a publicly discoverable STUN server to mediate the connection.

[joshua-kim]

Yeah we'd like to ideally support both peers behind a NAT! I know active tcp was only just merged in but just leaving this here as a feature request ^_^. As an aside I don't think this is a bug, I think we can remove the bug label here!

[ashellunts]

@ashellunts Do our Passive TCP candidates only accept connections from known remote active TCP candidates? Are we checking their source IP/port when accepting the connections?

Agent accepts connections from any remote address and marks them as remote peer reflexive active candidate.
At the moment if an agent receives remote TCP active candidate, it ignores it, because it can't use it for initiating connections.

Though it can store it and use it for pair matching. For example to differentiate host and peer reflexive active candidates.

[ashellunts]

Just wondering, is this even possible/reasonable to implement support for Active/Passive TCP types?
Or is the SimultaneousOpen TCP type better suited here?

@stv0g Do you mean for server reflexive type? Per standard active/passive and simultaneous-open are possible. Which one is better I don't know.

[stv0g]

@stv0g Do you mean for server reflexive type? Per standard active/passive and simultaneous-open are possible. Which one is better I don't know.

Yes for server reflexive.. As those candidates are usually used when a NAT-box is in use which block incoming TCP connection attempts. In my understanding simultaneous open could work around that.

But thats just an assumption based on what we usually see in real-world networks. In theory there could be still 1:1 NATs, or NATs which allow incoming TCP connections. So it surely would make sense to also generate passive TCP server reflexive candidates.. I just think that they have a low likelyhood of been selected.

[ashellunts]

Our use case is that we work on avalanchego which is a p2p blockchain network.

@joshua-kim why do you need TCP for your use case?
So you would like to connect 2 nodes with reliable connection? Have you considered webrtc datachannel? It will be reliable connection and works over UDP.

[joshua-kim]

I probably should have mentioned this earlier but we don't use webrtc at all, we have a custom networking protocol we build on top of TCP and we were just hoping to use pion/ice's ice implementation on top of it to connect nodes behind NATs since pion/ice conveniently implements ice discovery over udp/tcp.

I'm aware that pion/ice was built for pion/webrtc in mind however (although to be honest I'm not really knowledgable in webrtc at all) so I totally understand that this is really outside of the typical use case of this library.

As you mentioned we do use TCP for reliable in-order messages, although I understand you can implement this on top of UDP similar to how webrtc datachannel does like you mentioned. I guess we could consider incorporating webrtc into our application based but it's definitely something I need to research more on since it's definitely something I'm not knowledgeable about, or trying to migrate to something built on top of UDP.

[ashellunts]

I am not an expert, but I think TCP hole punching does not have high success rates.
In RFC it is written about 45% success rate, but that is data from 2005. https://datatracker.ietf.org/doc/html/rfc6544#appendix-A

[joshua-kim]

Hmm thanks for the read, had no idea that it was that bad. We're probably going to abandon this feature on our end for now unless we can migrate to something UDP based in the future.... apologies if I wasted anyone's time!