About peer UDP address detection

[Etienne Dechamps]

On 21/07/2013 18:52, Etienne Dechamps wrote:
> The only regression from the current solution that I can see is that
> with the current implementation, intermediate nodes can "participate" in
> determining the node's UDP address by rewriting ANS_KEY messages as they
> pass through them. This is not possible in my proposal because that
> would require a node to modify an edge that it doesn't own. However, I'm
> not sure that it's actually that useful considering the directly
> connected nodes usually have the best information about how to reach
> their neighbor anyway. I can think of one example where that isn't true,
> which would look like this:
>
>    A <--> B <---(NAT)---> C <---> D
>
> In this case, B actually holds the best information about how to join D,
> not C. Assuming I'm understanding tinc's graph traversal correctly, what
> will happen (if my proposal is implemented) if that A will try to reach
> D *via C* using UDP address information provided by B - it won't be able
> to use D's edge information because it only contains local addresses. So
> instead of talking directly to D, A will indirect via C. I don't think
> that's much of a concern IMHO because it is only a problem if the link A
> <---> D is significantly more preferable to A <---> C <---> D, which
> seems unlikely in such a topology, and can be fixed by directly
> connecting D to B.

On second thought, this would actually still work, because D would end 
up probing A using its public address, to which A would respond, 
allowing direct communication. To actually arrive at a situation in 
which this wouldn't work, you would have to come up with this topology:

A <---> B <---(NAT)---> C <---(NAT)---> D <---> E

In which case A would end up sending packets to E through D, and E would 
end up sending packets to A through B. Any other communication would 
still be direct, however.

-- 
Etienne Dechamps