TrustedNodes option in TINC

Guus Sliepen guus at tinc-vpn.org
Wed Apr 13 14:46:28 CEST 2005


On Fri, Apr 08, 2005 at 02:37:30PM +0200, Mathieu GIANNECCHINI wrote:

> >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.
> >
> Can you explain that or give us an example, we're not sure to understand 
> where is the problem ?

I tried to implement something alike some time ago, and IIRC it was not
just "don't forward anything to/from untrusted nodes", because some
trusted nodes might trust others which you don't trust yourself, and
vice versa. AFAIK it requires some extra bookkeeping to do it right.

> >>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.
> > 
> >
> Our question was about an option "trustedNodes". For us the meaning of 
> "trusted" is a node which is in a fixed list of trusted nodes.

Ah, ok. Hm, well if all the untrusted nodes are leafs in the network
(they will appear to be leafs if every trusted node ignores the
ADD_EDGEs the untrusted nodes send) then an untrusted node will never be
a nexthop for a trusted node. I hope that is what you want.

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus at 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/20050413/88eb8e95/attachment.pgp


More information about the tinc-devel mailing list