Next:
2.1 001: changeable gw
Up:
FreeSWAN KLIPS version 2
Previous:
1 Executive Summary
2 Detailed Requirements
Subsections
2.1 001: changeable gw wild-side addresses on-the-fly
2.1.1 001: Definition of requirement
2.1.2 001: response
2.2 002: address inertia
2.2.1 002: Definition of requirement
2.2.2 002: response
2.3 003: mini-database of road warriors that persists across reboots
2.3.1 003: Definition of requirement
2.4 004: connection up, down, wanted
2.4.1 004: Definition of requirement
2.4.2 004: Response
2.5 005: routing below tunnel layer to support mobility and multi-homing
2.5.1 005: Definition of requirement
2.5.2 005: Response
2.6 006: SAs entries should be capable of overlapping
2.6.1 006: Definition of requirement
2.6.2 006: response
2.7 007: why do equalizing schedulers not play well with tunnels?
2.7.1 007: Definition of requirement
2.8 008: decouple SA retrieval from DADDR (don't care how it arrived)
2.8.1 008: Definition of requirement
2.8.2 008: response
2.9 009: SPIs unique, independant of protocol and DADDR
2.9.1 009: Definition of requirement
2.10 010: routing above tunnel layer
2.10.1 010: Definition of requirement
2.11 011: granularity smaller than host
2.11.1 011: Definition of requirement
2.11.2 011: response
2.12 012: /dev/ipsecNNN devices that could be chown(1)ed and chmod(1)ed.
2.12.1 012: Definition of requirement
2.12.2 012: response
2.13 013: process to process tunnels
2.13.1 013: Definition of requirement
2.13.2 013: response
2.14 014: ways to manipulate tunnel perms.
2.14.1 014: Definition of requirement
2.15 015: KLIPS as a loadable module (isn't it already?)
2.15.1 015: Definition of requirement
2.15.2 015: response
2.16 016: stats: (number,time_of_last) packets (out,good_in,error_in)
2.16.1 016: Definition of requirement
2.16.2 016: response
2.17 017: integrate IPsec and firewall policy into Security Policy.
2.17.1 017: Definition of requirement
2.17.2 017: response
2.18 018: full inbound policy checking
2.18.1 018: Definition of requirement
2.18.2 018: response
2.19 019: secure ciphers and hashes
2.19.1 019: Definition of requirement
2.19.2 019: response
2.20 020: kernel implementation (should be faster)
2.20.1 020: Definition of requirement
2.21 021: plays well with routing daemons
2.21.1 021: Definition of requirement
2.21.2 021: response
2.22 022: free of export restrictions
2.22.1 022: Definition of requirement
2.22.2 022: response
2.23 023: standard crypto api to add newer ciphers and hashes
2.23.1 023: Definition of requirement
2.23.2 023: response
2.24 024: opportunistic
2.24.1 024: Definition of requirement
2.25 025: SADB hash table will be locked for additions/deletions
2.25.1 025: Definition of requirement
2.26 026: use a refcount on each SA to increase locking granularity
2.26.1 026: Definition of requirement
Michael Richardson
2001-08-12