[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Suggestion for ESP 3DES MD5 document



>>>Your point is well taken and I will make sure that compression is
>>>identified as an option within ESP.
>>
>>Should we include compression within ESP or should we include it within
>>its own header?
>>
>>While the Encapsulating Security Payload "is a mechanism for providing
>>integrity and confidentiality to IP datagrams", it might not be the
>>right header to place compression information into.  A separate header,
>>like the one in [draft-thayer-seccomp-00.txt], might work out better.
>>ISAKMP or any other KEP could negotiate the available compression
>>routines (ZLIB, etc..), but the actual decision to compress the packet
>>would be left for the sender.
>>
>>A sample packet might look like this:
>>
>>original: IP { TCP { HTTP { DATA }}}
>>new: IP' { COMP { AH, ESP { IP { TCP { HTTP { DATA }}}}}}
>
My mistake, the new packet would obvisously look like:

new: IP' { AH, ESP { COMP { IP { TCP { HTTP { DATA }}}}}}

>

Date: Wed, 30 Oct 1996 14:21:27 -0800
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199610302221.OAA03485@cornpuffs.cisco.com>
To: ipsec@TIS.COM
Subject: Re: proposed IPSEC changes/extensions
In-Reply-To: <9610301530.AA22586@secpwr.watson.ibm.com>
Organization: cisco Systems
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

In article <9610301530.AA22586@secpwr.watson.ibm.com> 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
rja@cisco.com