Dieses Wiki ist ein Archiv bis 2023. Das aktuelle Wiki findet sich unter https://wiki.hamburg.ccc.de/
Difference between revisions of "ChaosVPN:geekend0"
(→Issues) |
m (moved ChaosVPN::geekend0 to ChaosVPN:geekend0) |
||
(10 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
+ | {{Vergangenheit}} | ||
= what? = | = what? = | ||
Line 21: | Line 22: | ||
Deploy Root DNS servers and sub DNS servers for the Agora/Chaos network | Deploy Root DNS servers and sub DNS servers for the Agora/Chaos network | ||
− | * In the DNS implementation we need to have a | + | * In the DNS implementation we need to have a core hidden server and the trusted DNS servers able to be updated at each of the trusted root hackspaces. |
* Automatically register IP address and hostname for new nodes on the VPN | * Automatically register IP address and hostname for new nodes on the VPN | ||
* Distributed DNS server? | * Distributed DNS server? | ||
+ | |||
+ | * Have multiple DNS servers, all using the same IP address. | ||
+ | Change tinc to select the best reachable DNS based on distance/weight. | ||
+ | Needs only change in ChaosVPN backend, to set weight of Subnets differently when distributing config files to nodes. | ||
+ | |||
+ | * Let clients use ChaosDNS only when they have a working connection to the VPN. | ||
+ | Suppose the DNS server runs at node "dns", then you can add a dns-up and dns-down script to tinc that will use resolvconf to add/remove a nameserver entry in /etc/resolv.conf on the fly: | ||
+ | #!/bin/sh | ||
+ | # /etc/tinc/chaos/hosts/dns-up | ||
+ | resolvconf -a $INTERFACE << EOF | ||
+ | nameserver ip.of.chaos.dnsserver | ||
+ | search chaos | ||
+ | EOF | ||
+ | |||
+ | #!/bin/sh | ||
+ | # /etc/tinc/chaos/hosts/dns-down | ||
+ | resolvconf -d $INTERFACE | ||
+ | To ensure the ChaosDNS server is preferred above other servers, add "chaos" to theh top of /etc/resolvconf/interface-order. | ||
== hackint == | == hackint == | ||
Line 53: | Line 72: | ||
** Determine what we need in the immediate future, to be implemented in tinc 1.0.13. | ** Determine what we need in the immediate future, to be implemented in tinc 1.0.13. | ||
** Determine milestones working towards the perfect ChaosVPN. | ** Determine milestones working towards the perfect ChaosVPN. | ||
− | |||
* Determine minimal environment tinc should run in, eg. a Fonera system. | * Determine minimal environment tinc should run in, eg. a Fonera system. | ||
** Can we use C++, including libstdc++? | ** Can we use C++, including libstdc++? | ||
+ | *** Fonera has (uclibc?) libstdc++ installed already | ||
** Can we use crypto libraries other than OpenSSL? (For example, gcrypt, GnuTLS, Botan.) | ** Can we use crypto libraries other than OpenSSL? (For example, gcrypt, GnuTLS, Botan.) | ||
+ | * Can we make more people part of tinc development team? | ||
+ | |||
+ | === Trust model === | ||
+ | |||
+ | * Decentralised | ||
+ | ** Have multiple trust anchors | ||
+ | * Delegate trust, also partially if possible | ||
+ | * Revoke trust | ||
+ | * Must be able to run it on a small devices | ||
+ | * Trust can be transitive, but must be limitted | ||
+ | * Perhaps limit trust transitivity to certain subnets (a trusts b with subnet 172.16.0.0/12, b trusts c with subnet 172.17.0.0/16) | ||
+ | ** If not possible, have supernode do the work for us? | ||
+ | ** Use DHT to be able to store/retrieve information from the network | ||
− | * | + | === Data transfer === |
+ | |||
+ | * End to end encryption | ||
+ | ** But should be able to use intermediate nodes as relays | ||
+ | ** For this the one end-node needs to know the public key of the end-node it wants to reach, it either needs to know all keys, or have a way to fetch it on demand | ||
+ | |||
+ | === Scalability === | ||
+ | |||
+ | Fonera has only 32 MB flash of which much less is writable, unless external USB stick is used. | ||
+ | It has only 64 MB of RAM. MIPS processor is not fast. | ||
+ | If ChaosVPN grows towards 1000 nodes, perhaps there should be lightweight tinc daemons that connect to "supernodes", or limit the spread of routing information somehow (like with OSPF zones). | ||
= Goals = | = Goals = | ||
Line 80: | Line 122: | ||
= questions? answers! = | = questions? answers! = | ||
+ | [[Category:ChaosVPN]] |
Latest revision as of 04:18, 16 October 2012
This page is about an event in the past. Please do not edit/add content without good reason.
Diese Seite beschreibt ein Event der Vergangenheit. Bitte füge ohne triftigen Grund keine neuen Inhalte hinzu.
Contents
what?
Lets do a geekend and get things done on the chaosvpn.
where
hamburg. The new Hackerspace of attraktor and ccc hamburg.
when
The idea is 9. - 11. of April. The weekend before is easterhegg in munich and breakpoint at bingen. it seems that most ppl have time on that weekend.
Issues
Need to finalize and get the OpenWRT packages supported for the Fonera2.0n
- Need to have all the basic routing and security features in the OpenWRT package, but tailored for our networks.
- Need to have a TINC and ChaosVPN code implementation so that we can have multiple concurrent VPN's that don't interefere
- The independent VPN's need to be tied to a individual port.
- Need to have a signing system so we don't have haegar supporting 1000 users in 24 times zones all the time. Need to build a way so we can have a trusted region manager to add on nodes.
- already possible - the master config already is in a special non-public git repository, trusted managers can get their ssh key added to the access list for it. After pushing a change to the repository the server automatically executes a post-push-hook and recreates the signed and encrypted datafiles for all the clients (and mails me the changes, to have an eye on it) - without the trusted managers needing access to the secret data signing key. --Haegar 00:59, 24 March 2010 (UTC)
dns
Deploy Root DNS servers and sub DNS servers for the Agora/Chaos network
- In the DNS implementation we need to have a core hidden server and the trusted DNS servers able to be updated at each of the trusted root hackspaces.
- Automatically register IP address and hostname for new nodes on the VPN
- Distributed DNS server?
- Have multiple DNS servers, all using the same IP address.
Change tinc to select the best reachable DNS based on distance/weight. Needs only change in ChaosVPN backend, to set weight of Subnets differently when distributing config files to nodes.
- Let clients use ChaosDNS only when they have a working connection to the VPN.
Suppose the DNS server runs at node "dns", then you can add a dns-up and dns-down script to tinc that will use resolvconf to add/remove a nameserver entry in /etc/resolv.conf on the fly:
#!/bin/sh # /etc/tinc/chaos/hosts/dns-up resolvconf -a $INTERFACE << EOF nameserver ip.of.chaos.dnsserver search chaos EOF #!/bin/sh # /etc/tinc/chaos/hosts/dns-down resolvconf -d $INTERFACE
To ensure the ChaosDNS server is preferred above other servers, add "chaos" to theh top of /etc/resolvconf/interface-order.
hackint
hackint irc server
connect people
connect the router at some spaces
packages
build debian and openwrt packages
- debian
- build Packages
- get in squeeze?
- OpenWRT
- package
- image with tinc and config for fonera 2.0n
os builds
- BSD?
- mac os x
tinc development
We need to discuss what we want tinc to do for ChaosVPN:
- Define requirements
- Determine what we need in the immediate future, to be implemented in tinc 1.0.13.
- Determine milestones working towards the perfect ChaosVPN.
- Determine minimal environment tinc should run in, eg. a Fonera system.
- Can we use C++, including libstdc++?
- Fonera has (uclibc?) libstdc++ installed already
- Can we use crypto libraries other than OpenSSL? (For example, gcrypt, GnuTLS, Botan.)
- Can we use C++, including libstdc++?
- Can we make more people part of tinc development team?
Trust model
- Decentralised
- Have multiple trust anchors
- Delegate trust, also partially if possible
- Revoke trust
- Must be able to run it on a small devices
- Trust can be transitive, but must be limitted
- Perhaps limit trust transitivity to certain subnets (a trusts b with subnet 172.16.0.0/12, b trusts c with subnet 172.17.0.0/16)
- If not possible, have supernode do the work for us?
- Use DHT to be able to store/retrieve information from the network
Data transfer
- End to end encryption
- But should be able to use intermediate nodes as relays
- For this the one end-node needs to know the public key of the end-node it wants to reach, it either needs to know all keys, or have a way to fetch it on demand
Scalability
Fonera has only 32 MB flash of which much less is writable, unless external USB stick is used. It has only 64 MB of RAM. MIPS processor is not fast. If ChaosVPN grows towards 1000 nodes, perhaps there should be lightweight tinc daemons that connect to "supernodes", or limit the spread of routing information somehow (like with OSPF zones).
Goals
Need to have the Agora/Chaos/Warzone networks running smoothly with the basic features. Root DNS - and distributed systems. Have a infrastructure that has more than one trusted manager able to add or remove nodes in different regions. The warzone server has to go live at the end of the weekend after solving the issues with NAT on the openwrt Fonera 2.0n unit, and multiple port support with multiple TINC VPN's.
infrastructure
lodging
- best western queens hotel hamburg around the corner
- limited sleeping in the hackerspace is possible
attendes
- mc.fly
- guus (will sleep in hackerspace)
- Haegar (most likely)
- ryd (most likely)
- Tcrown (In spirit, and Chicago)