klips2-design.txt

网上下到的一个很详细介绍VPN基础知识的资料

#  -*- mode: Outline; fill-column: 78; fill-prefix: "	" -*-
#
#  klips2-design.txt
#	Richard Guy Briggs <[e-mail]>
#
#  RCSID $Id: klips2-design.txt,v 1.17 2001/06/12 15:40:32 rgb Exp $
#

* Outline Commands cheat sheet (C-c C-s to see this)
        C-c C-t         Hide EVERYTHING in buffer
        C-c C-a         Show EVERYTHING in buffer

        C-c C-d         Hide THIS item and subitems (subtree)
        C-c C-s         Show THIS item and subitems (subtree)

        C-c C-c         Hide ONE item
        C-c C-e         Show ONE item

* Introduction

Linux FreeS/WAN IPSec -- KLIPS2 DESIGN
======================================

# This document outlines the proposed design for KLIPS2, the second
# generation Linux FreeS/WAN IPSec kernel implementation.  It is
# accompanied by the following:
#
# klips2-design.dia		dia(1) diagram
# klips2-design-legend.txt	diagram legend
# klips2-design-api.txt		API descriptions
# klips2-design-api-trips.txt	scenarios that force trips through the
#				various APIs to verify all needed resources
#				are available

# This document is devided up into Introduction, Goals, Feature requests,
# Packet path overview, NetFilter overview, IPSec path description, and
# Other issues.
#
# This document was originally written 2.5 weeks after OLS2000, inspired
# from a meeting with Rusty and Marc Boucher in Montreal in November 1999
# and two meetings at OLS2000.
#
# Please comment to the linux-ipsec, netfilter-devel or netdev lists.
#
# Current kernel version reference is 2.4.4 with iptables 1.2

* Goals:

	To get rid of the current IPSec virtual interfaces that associate with
	a specific physical network interfaces and replace them with IPSec
	virtual interfaces that specify a local gateway address as a source
	address, a remote gateway address as a destination address and
	specific tunnel policy or SAs.

	To use existing packet matching engines rather than re-invent.

	To support more of the required selectors, especially source and
	destination ports, and possibly userid.  Security labels are not of
	obvious value, but the selectors will be easy to add in the future if
	they are implemented in the Linux kernel.

	To get access to *all* packets incoming and outgoing to enforce policy
	in both directions.

	To better support opportunistic encryption.

	To take advantage of the parallellism of SMP and H/W encryption.

	To make encryption and authentication modular.

The idea is to redesign KLIPS (kernel parts of FreeS/WAN) to avoid all the
'stoopid routing tricks' (TM) to which we have had to resort since the project
started by disassociating any IPSec devices from physical devices and to add a
proper SPDB to do proper incoming IPSec policy checks.  We are hoping to use
existing pattern-matching tools rather than invent our own.  NetFilter appears
to have all the pattern matching capabilities with the exception of security
labels which Linux doesn't appear to have anyways, but may be limited in other
ways.

There is also a significant interest in enabling FreeS/WAN to communicate with
routing daemons and be able to do load sharing and failover:

	http://www.quintillion.com/fdis/moat/ipsec+routing/



* Feature requests:

Code=Level/Status/Priority
Level:
	S = strategic
	M = middle
	T = tactical
	U = unset
Status:
	U = unstarted
	C = coded
	T = tested
	D = deleted
Priority:
	H = high
	M = medium
	L = low
	U = unset
	D = deprecated

Code	Feature		Implementation
====	=======		==============
S/U/U	changeable gw wild-side addresses on-the-fly
			- road warriors with RSA keys and hooks from DHCP
			  to move to a new set of SAs upon expiry of previous
			  DHCP lease.  Notify peers.  Negociate new tunnels.
			  Handle delayed or denied renewal see: conn up, down,
			  wanted.
M/U/U	address inertia for remote gw's with changeable wild-side addresses
	so local gw reboots will initiate reconnect to remotes.
			- this requires a disk cache.
T/U/U	mini-database of road warriors that persists across reboots.
			- this requires a disk cache.
M/U/U	connection up, down, wanted
			- 
S/U/U	routing below tunnel layer to support mobility and multi-homing
			-
M/U/U	tunnel identified by subnets served?
			-
M/U/U	why do equalizing schedulers not play well with tunnels?
			-
M/U/U	decouple SA retrieval from DADDR (don't care how it arrived)
			- protocol redesign
T/U/U	SPIs unique, independant of protocol and DADDR
			- 
S/U/U	routing above tunnel layer
			-
S/U/U	granularity smaller than host
			- SPORT, DPORT, UID, SecLev
M/U/U	/dev/ipsecNNN devices that could be chown(1)ed and chmod(1)ed.

M/U/U	process to process tunnels

T/U/U	netfilter,pf_key,ioctl,/dev/ipsecNNN ways to manipulate tunnel perms.

S/U/U	KLIPS as a loadable module (isn't it already?)

S/U/U	stats: {number,time_of_last} packets {out,good_in,error_in}

S/U/U	integrate IPSec and firewall policy into Security Policy.
	(What APIs and user-level tools?)

S/U/U	full inbound policy checking
S/U/U	secure ciphers and hashes
T/U/U	kernel implementation (should be faster)
S/U/U	plays well with routing daemons
S/U/U	free of export restrictions
T/U/U	standard crypto api to add newer ciphers and hashes
S/U/U	opportunistic
T/U/U	SADB hash table will be locked for additions/deletions
T/U/U	use a refcount on each SA to increase locking granularity



* Packet path overview:

The basic path through the kernel as it concerns IPSec for the three
types of packets is as follows:

IN:
	NIC
	basic sanity checks
	NF_IP_PRE_ROUTING hook
	route-in
	ip-options processing
	defragmentation
	NF_IP_LOCAL_IN hook
	transport layer demux
	application

FORWARD:
	NIC
	basic sanity checks
	NF_IP_PRE_ROUTING hook
	routing-in
	ip-options processing
	ttl decrement and check
	NF_IP_FORWARD hook
	fragmentation
	NF_IP_POST_ROUTING hook
	fragmentation
	output()
	NIC

OUT:
	application
	transport layer mux
	NF_IP_LOCAL_OUT hook
	route-out
	NF_IP_POST_ROUTING hook
	fragmentation
	output()
	NIC