a few tinc questions

[Guus Sliepen]

On Thu, May 24, 2007 at 07:34:45PM -0400, Lonnie Cumberland wrote:

> 1. I am trying to understand the ideas that allow a TINC host to join 
> multiple networks which raise questions. What prevents a user from 
> joining multiple networks without authorization to join. How is that 
> authorization managed and can a type of network administrator who sets 
> up the network revoke someones privilege to be on that network. If 
> someone, ie.. a particular network creator, is in charge of that network 
> then can that admin control the access to the net.

Nothing prevents a user from doing that. As long as someone authorises a
user (currently, by having the user's host config file in his hosts/
directory), the user can join a network.  No finer-grained access
control has been built in to the current version of tinc. 
Tinc was designed with a decentralised, peer-to-peer architecture in
mind, not with a client-server architecture.

It's also hard to disallow a user of VPN 1 to join VPN 2 at the same
time; tinc is open source, so a malicious particpant in a VPN could
easily remove those restrictions from his VPN software, but he could
also just set up masquerading or other routing tricks in his network
that achieve the same effect.

> 2. To have access multiple networks then does there have to be multiple 
> daemons running on the system. ie.. does there have to be a daemon for 
> each network that the user may wish to have access to? Also, is there a 
> limit to the number of daemons that a single user can be running? 

In principle, you need one daemon per network. However, if one user
configures his tincd to connect to two different networks, they
effectively become one network.

There is no limit to the number of daemons you can run simultaneously,
although the operating system may limit the number of processes, tun
interfaces, and maybe other resources.

> 3. If a users has access to multiple networks then can I presume that 
> the act of having multiple daemons running on a single machine does not 
> allow other users on network "A" to access network "B". My guess is that 
> users should not be able to access the other network if they do not have 
> permission and authorization certificates, right?

If a user runs a tincd for each network, then they are completely
separate as far as tinc is concerned. However, it is very easy to set up
routing, bridging or masquerading between two networks.

> 4. What are some of the anticipated scalability limitations of TINC?  
> Can a TINC network scale into the 1000's without major problems?

I've run tests with up to almost 1024 tinc daemons on a single computer,
with each daemon connecting to about 8 others. This worked without
problems. When I got to 1024 the Linux kernel complained about a lack of
file descriptors. This limitation could then be removed by recompiling
the kernel with a larger limit. I think current kernels allow you to set
the maximum number in /proc.  I didn't test this on other operating
systems, and I didn't test with more, but there is no limit in tinc
itself.

> 5. When a TINC daemon becomes active, I would like to prevent the host 
> that it is running on from seeing anything except what is on the 
> accessible VPN networks. ie... When TINC is ON then the users machine is 
> no longer visible on the unsecure non-vpn network and can only be see on 
> the VPN networks. When it is OFF then the machine acts like a normal 
> non-VPN machine without TINC.

You can do that with appropriate tinc-up and tinc-down scripts. But
again, the local user can easily circumvent these restrictions.

> I hope that these are relatively easy to answer and would greatly 
> appreciate as much information that someone is willing to share with me 
> on these types of things.

If you want a client-server architecture, and push network configuration
settings to the user, then right now OpenVPN is probably what you want.
Otherwise, you could modify tinc to fit your needs. In
http://www.tinc-vpn.org/svn/tinc/branches/1.0-gnutls/ you can find a
version of tinc that uses the GNUTLS library and actually uses TLS with
X.509 certificates. It still needs some work, but you could use this as
a basis for a tincd that allows more centralised management.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.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/attachments/20070525/5a8216e5/attachment.pgp