About peer UDP address detection

Guus Sliepen guus at tinc-vpn.org
Mon Jul 22 17:47:28 CEST 2013


On Sun, Jul 21, 2013 at 06:52:47PM +0100, Etienne Dechamps wrote:

> I would like to discuss the following commit:
> https://github.com/gsliepen/tinc/commit/4a0b9981513059755b9fd15b38fc198f46a0d6f2
> ("Determine peer's reflexive address and port when exchanging keys")
> 
> This is a great feature as it basically allows peers to do UDP Hole
> Punching (via MTU probes) even when both are having their source
> ports rewritten by a NAT, which is extremely useful. However, I have
> a few questions and concerns about the way it's currently
> implemented in ANS_KEY messages:
[...]
> Thoughts? I get the feeling that Guus already thought about doing it
> this way and that there is some fundamental problem that would break
> my nice proposal :/

Your concerns are all valid. The problem is that the protocol in tinc 1.x is
more or less frozen; at least I won't want to make any changes that are
backwards incompatible. Features like UDP hole punching were added after 1.0
was released, and because the protocol was not designed with extensibility in
mind some features could only be bolted on to existing protocol messages. With
tinc 1.1, which adds a new protocol, there is room for improvement.

One of the flaws of the legacy protocol is the notion that a node has only one
public address and port. That is unfortunately only true for simple hosts with
one interface that are not behind a NAT. Instead, we should deal with nodes
having multiple addreses. Ideally, I don't want to include addresses in struct
edge_t and ADD_EDGE messages anymore. Instead, there should be a protocol
message to query the list of known addresses from a node. A node knows its own
local addresses, but not necessarily its public address(es) if it is behind a
NAT. To that end, there should be another protocol message to have a node ask
another node what it thinks its public address is. By separating all these
issues and by allowing multiple addressess per node, more possibilities open up
(including link aggregation).

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20130722/89e085aa/attachment.sig>


More information about the tinc-devel mailing list