Re: proposed IPSEC changes/extensions

[Ran Atkinson <[e-mail]>]

In article <[e-mail]> Pau-Chen wrote:

[ASIDE: Pau-Chen, it would be most helpful in improving readability
of your email if you would not have lines longer than ~70 characters
when you send it out. :-]

% My model is the policy will tell which (kind of) SA to use. So the 1st
% search is done through the policy to determine which (knid of) SA, if any,
% should be used. Then we go through the existing SA's to see if an SA meeting
% the policy requirements exists. If one exists, then we can just uses it. If
% not, one can be created. The policy will carry the notions of wildcard,
% address range, protocols, port ranges, etc.(God knows what.). (Of course, a
% simple mechanism is invented to define a "kind of" SA.)

This is not unlike the NRL implementation, which was described in a USENIX
paper last January and is freely available to all.  For background, recall
that the NRL code is based on 4.4 BSD and hence uses mbufs.

OUTBOUND PROCESSING:
	ip_output() calls ipsec_output_policy() for the outbound
	datagram.  ipsec_output_policy() decides whether IPsec is
	required or not and what kind of IPsec is needed (if needed).
	Then ipsec_output_policy() calls the Key Engine to obtain
	either an existing SA that conforms to policy or to have
	the Key Engine obtain an appropriate SA.

	ipsec_output_policy() has 3 possible return values to ip_output()
	when IPsec is needed:
		-- IPsec is needed and the SA data is provided in the return.
		-- IPsec is needed, but the SAs are not yet available.
		-- IPsec is needed, but the SA is not obtainable at all.

	In case 1, the packet goes through IPsec output processing and
	is sent out the interface.  In case 2, the outbound packet is
	temporarily queued until the SAs get created by key management.
	In case 3, the packet is discarded and an appropriate counter
	is incremented.

	Note that none of this NRL code is specific to any particular KM
	protocol.  Anything that can fit on PF_KEY will work just fine.

	Note also that ipv6_output() should be substituted for ip_output()
	throughout the above when IPv6 is used instead of IPv4.


INPUT PROCESSING:

	At ip_input() time _after_ reassembly, IPsec input processing
	is performed if IPsec is present in the packet.  If IPsec input
	processing completes successfully, appropriate flags are set
	in the incoming mbuf header.  Then system policy can be applied
	to the incoming mbuf chain, discarding the chain if policy dictates.  
	Further upper-layer processing occurs next.  Finally, socket-specific 
	application policy is applied and the packet is either discarded 
	or passed to the application.

NRL Source code is available within the US for examination at
	http://web.mit.edu/network/isakmp/
Outside the US, try looking at:
	ftp://ftp.ripe.net/ipv6/nrl/IPv6_domestic.tar.gz

IMHO the "identity" values of an IPsec Security Association can be very
important when implementing support for various policies.  Examples of widely
used identities are USER_FQDN (e.g. "user@full-domain"), FQDN
(e.g. "fully-qualified-domain-name), CONNECTION-ID (e.g. IP address,
upper-layer protocol, port number), IP ADDR (an IP address), and IP ADDR RANGE
(range of IP addresses).

Ran
[e-mail]