Some questions about SPTPS

[Guus Sliepen]

On Mon, Aug 11, 2014 at 12:00:11PM +0100, Etienne Dechamps wrote:

> That said, I do agree that it is a much simpler solution compared to my
> stateful conflict resolution proposal so it might not be that big of a
> problem. I guess this makes sense if it allows us to make node identifiers
> significantly smaller (with 48-bit it just doesn't matter, the chances of
> collision are simply too small for the added complexity to be worth it). But
> still, going from 48-bit node identifiers to as low as 24-bit would only
> reduce overhead by 0.3 percentage points on a MTU-sized packet, so meh...
> Honestly I doubt this is worth the effort.

The chance of the 48-bit hash failing is indeed very small, but if it
does fail it fails permanently for one or more nodes, unless you rename
them. Then I rather have something in place that, in this unlikely case,
may in itself fail, but at least has a lot higher chance to /do/ work.

But implementing the simplest solution with 48-bit hash and getting that
working is the first priority, then afterwards we can see if we want to
try out the salted hash version.

> >>Wire format: SPTPS in SPTPS with cleartext signed node identifiers;
> >>identifiers would also appear in direct (non-relayed) packets as well to
> >>make unknown-source-address key selection faster at the receiving end.
> >
> >Yes, that would be very good to have, but as soon as there is an 1.0
> >node in the network you'd still have to check the source address of
> >packets to determine if it's from that one.
> 
> Indeed, but what tinc would do is, it would try to blindly decode a source
> identifier first and see if it refers to an existing node; if it does, the
> packet is assumed to come from an 1.1 node and the source is recognized
> instantly, if it doesn't, then it would fall back to the usual 1.0
> mechanism.

Ok, and tinc could easily check if the source address of the packet
matches that of the source node it derived from the source identifier.
That's an easy lookup. If it fails, then first assume there is a valid
1.1 identifier, and try to decode the packet using the corresponding
node's key. If that also didn't work, then finally fall back to 1.0
style try_harder().

> (Of course, that means that when a 1.0 node sends a packet to a 1.1 node,
> there is a very small chance that it could get "unlucky" and accidentally
> "land" on a valid source node identifier value. I believe this is fine since
> it would only result in extremely small packet loss that would be impossible
> to notice)

That's probably true, 1.0 packets have a monotonically increasing
sequence number in the first 4 bytes, and we can assume the next bytes
to be totally uncorrelated to anything else, so packet drop this way is
guaranteed to be limited to a fraction equal to the number of nodes in
the graph divided by 2^96.

-- 
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: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20140811/0632f32c/attachment.sig>