tinc devel - Apr 2005 - TrustedNodes option in TINC

Hi,

We want to deploy a tinc VPN, with more than 50 sites connected all 
arround the world. But we cannot trust all our sites with the same 
level, so the tinc solution (automatic full mesh) is "too automatic"
for
us : *any* node can add a new node which will be connected directly to 
others.

A solution could be TLS (signing public keys), but create a PKI is 
another issue for us.

Instead, we have an idea : would it be possible to have a option in 
tinc.conf like "TrustedNodes=aaa,bbb,ccc" ?

With this option :
(a) any ADD_EDGE/ADD_SUBNET/ANS_KEY/... will be cancelled if it comes
    from a non-trusted connection
(b) all REQ_KEY will be sent to trusted nodes only.

(a) is easy, but we do not know how to manage (b).

In net_packet.c and protocol_key.c we see :
        send_req_key(n->nexthop->connection, myself, n);

The question is : how to be sure that "n->nexthop->connection"
will be a
"trusted connection" ? (c->name in TrustedNode). One of our
question is
: if we cancel any ADD_* from untrusted node, can nexthop be a untrusted 
node ?...

As far as we can see, nexthop is set in graph.c [sssp_bfs()]... but we 
are not very easy with this nice piece of code. :-)

Thanks,

-- 
Mat

On Fri, Apr 08, 2005 at 01:07:09PM +0200, Mathieu GIANNECCHINI wrote:
> We want to deploy a tinc VPN, with more than 50 sites connected all 
> arround the world. But we cannot trust all our sites with the same 
> level, so the tinc solution (automatic full mesh) is "too
automatic" for
> us : *any* node can add a new node which will be connected directly to 
> others.
> 
> A solution could be TLS (signing public keys), but create a PKI is 
> another issue for us.
> 
> Instead, we have an idea : would it be possible to have a option in 
> tinc.conf like "TrustedNodes=aaa,bbb,ccc" ?
Since 1.0.3 there is an option called TunnelServer, if set to "yes"
then
a tincd will only allow ADD_EDGE/ADD_SUBNETs from others if they match
nodes and subnets found in the local hosts/ files. However in that case
noone is trusted. Mixing trusted and untrusted nodes in one VPN has all
sorts of consequences and is hard to implement right, so it hasn't been
done yet.
> With this option :
> (a) any ADD_EDGE/ADD_SUBNET/ANS_KEY/... will be cancelled if it comes
>    from a non-trusted connection
> (b) all REQ_KEY will be sent to trusted nodes only.
> 
> (a) is easy, but we do not know how to manage (b).
> 
> In net_packet.c and protocol_key.c we see :
>        send_req_key(n->nexthop->connection, myself, n);
> 
> The question is : how to be sure that
"n->nexthop->connection" will be a
> "trusted connection" ? (c->name in TrustedNode). One of our
question is
> : if we cancel any ADD_* from untrusted node, can nexthop be a untrusted 
> node ?...
The nexthops are always trusted.
> As far as we can see, nexthop is set in graph.c [sssp_bfs()]... but we 
> are not very easy with this nice piece of code. :-)
I agree it looks like black voodoo magic. It only works because I wrote
it when the moon was full and I had sacrificed a few chickens. But
anyway, a "nexthop" is always a node with whom we have a TCP
connection,
and tinc only makes TCP connections with other tinc daemons for which it
knows the public key.

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus@sliepen.eu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://brouwer.uvt.nl/pipermail/tinc-devel/attachments/20050408/abb5da4b/attachment.pgp