Some questions about SPTPS

[Guus Sliepen]

On Sun, Aug 10, 2014 at 06:12:27PM +0100, Etienne Dechamps wrote:

> Since this is a complex issue that involves a lot of different approaches
> and tradeoffs, I took the liberty of writing a design doc to flesh it all
> out:
> 
> https://docs.google.com/document/d/1lOo05SsylNMMLLavdzJwdQ37Y25i6AkVMFhztcCDu6o/edit?usp=sharing

That's a very nice and clear document you wrote!

> To my dismay, I realized that my original proposal for transporting node
> identifiers in UDP packets using a simple cleartext header is not viable
> because it would introduce a nasty security vulnerability allowing an
> external attacker to trick any node into sending packets to *any* IP address
> (including addresses outside the graph). Details can be found at the end of
> the "unauthenticated relay header" section in the doc.

This is true. Actually, a MITM than can change the source IP address
could already do tricks like that, but the damage he could do would be
limited. With the unauthenticated forwarding header, a MITM could cause
many packets to be sent to an IP address of its choice. The way to limit
the attack would be for tinc to restart PMTU discovery immediately when
the source address changed, and not allow any packets to be forwarded
that are larger than the discovered minimum MTU. This might actually
make sense even in the case of normal direct packets, since if the
source IP address of a node really changes, it might also change the
PMTU, and having to wait for the PingTimeout before we detect this is
not so nice.

> Therefore I believe Guus' SPTPS-in-SPTPS idea is the only viable one when it
> comes to the UDP packet format for relaying.

> Regarding the node identifiers, the document lists all ideas that were
> brought up.
> 
> After carefully weighing the tradeoffs, and realizing that I was probably a
> little too concerned about overhead (10 bytes is only 0.6% of a MTU-sized
> packet after all...), I would vote for the following:
> 
> Node identifiers: hash-based identifier, 48-bit hash, no conflict
> resolution.

One way to do conflict resolution in as stateless way as possible is to
split the hash in an 8 bit salt and a 40 bit hash of the name and the
salt. The salt is normally 0. Have the sender check (this only has to
be done when node_add() is called) whether the whole 48-bit identifier
is unique, if not increment the salt and recalculate the 40 bit hash
until it does not conflict anymore with any other node's identifier.
(Well, it should be done in such a way that it's deterministic and all
nodes converge to the same identifiers.)

If there are no conflicts, then this gives you a stable mapping between
node names and identifiers, albeit with a slightly smaller hash space.
Once you do get conflicts, almost all names still keep the same mapping
to an identifier, and only the conflicting node names will see a
temporary disruption until all nodes get their acts straight, but at
least it recovers from hash conflicts.

Maybe I'm paranoid.

> 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.

-- 
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/429b9fc1/attachment.sig>