Hi, here's a small list of things that need to be done, and the
version when it should be ready.
smartcard support 1.1
LDAP support 1.1
public/private keys for authentication 1.1
don't store passphrases in files that are called after IP addresses
1.0
use names to identify connections instead of IP addresses
1.0
use one passphrase for multiple IP subnets 1.0
use OpenSSL crypto libraries 1.1
compress data before encrypting >1.1
inherit TOS flags 1.1
autoconfigure the tap interface 1.1
MAC address translation 2.0
config file layout/syntax change >= 1.1
multiple threads 2.0
crypto accelerator support 2.0
send "fake" packets (chaffing) 1.1
routing based on MAC 2.0
ABC-protocol & tinc-ARP 2.0
TCPonly proper 1.0
bind to specific interface or IP address 1.0
check whether passphrases are properly protected 1.0
PPP/SLIP support 2.0
L2TP, PPTP, IPSec support 2.0
modularity 2.0
support for tun device >1.1
admin scripts: tinc-on/tinc-off/tincconfig/tinc-add/tinc-keygen 1.1
fix "make rpm" 1.0
use DESTDIR in po/Makefile 1.0
sequence numbers for packets & metaprotocol 1.0
delay before reconnect on inconsistency 1.0
configurable timeout 1.0
force IndirectData by server 1.1
support for tinc in ifup/ifdown 1.1
metaprotocol over SSL 2.0
fix license problem 1.0
--
Ivo Timmermans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url :
http://brouwer.uvt.nl/pipermail/tinc-devel/attachments/20000821/8120dde9/attachment.pgp
Revisiting the todo list that was posted on August the 21st:
smartcard support 1.1
LDAP support 1.1
public/private keys for authentication 1.1 DONE
don't store passphrases in files that are called after IP addresses
1.0 DONE
use names to identify connections instead of IP addresses
1.0 DONE
use one passphrase for multiple IP subnets 1.0 DONE
use OpenSSL crypto libraries 1.1 DONE
compress data before encrypting >1.1
inherit TOS flags 1.1
autoconfigure the tap interface 1.1 sort of
MAC address translation 2.0
config file layout/syntax change >= 1.1 sort of
multiple threads 2.0
crypto accelerator support 2.0
send "fake" packets (chaffing) 1.1
routing based on MAC 2.0
ABC-protocol & tinc-ARP 2.0
TCPonly proper 1.0
bind to specific interface or IP address 1.0 not tested
check whether passphrases are properly protected
1.0
PPP/SLIP support 2.0
L2TP, PPTP, IPSec support 2.0
modularity 2.0
support for tun device >1.1 DONE
admin scripts: tinc-on/tinc-off/tincconfig/tinc-add/tinc-keygen
1.1
fix "make rpm" 1.0 DONE
use DESTDIR in po/Makefile 1.0 DONE
sequence numbers for packets & metaprotocol 1.0
delay before reconnect on inconsistency 1.0 DONE
configurable timeout 1.0 DONE
force IndirectData by server 1.1
support for tinc in ifup/ifdown 1.1
metaprotocol over SSL 2.0 sort of
fix license problem 1.0 DONE
Some things I would like to add:
use balanced trees for most datastructures >= 1.1
use Wessels authentication scheme :) 1.0
-------------------------------------------
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@sliepen.warande.net>
-------------------------------------------
See also: http://tinc.nl.linux.org/
http://www.kernelbench.org/
-------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url :
http://brouwer.uvt.nl/pipermail/tinc-devel/attachments/20001112/723ff33b/attachment.pgp
Some changes I would like to make:
Smart card support is really for echelon I think:
-smartcard support 1.1
+smartcard support 2.0
Compression will improve both speed and security:
-compress data before encrypting >1.1
+compress data before encrypting 1.0
These things are not really necessary for most VPN situations:
-inherit TOS flags 1.1
-send "fake" packets (chaffing) 1.1
+inherit TOS flags 2.0
+send "fake" packets (chaffing) 2.0
Sequence numbers are not necessary. Ethernet does not give any guarantees about
packet duplicition, so neither should tinc. The higher level protocols already
check for duplication. For the metaprotocol: we encrypt in cipher feedback mode,
which inherently blocks replay attacks, so no sequence numbers needed there
either:
-sequence numbers for packets & metaprotocol 1.0
Comments?
-------------------------------------------
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@sliepen.warande.net>
-------------------------------------------
See also: http://tinc.nl.linux.org/
http://www.kernelbench.org/
-------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url :
http://brouwer.uvt.nl/pipermail/tinc-devel/attachments/20001112/18b659d4/attachment.pgp