Architecture draft

[Karen Seo <[e-mail]>]

Folks,

Here is a summary of the changes we've made to the IPsec Architecture
draft.  We've tried to include all the comments/feedback received over
the past few weeks, but there were a few issues that came up at the last
minute which have not yet been resolved (waiting for feedback from the
community, etc.) and which therefore did not get addressed in this
version.  In addition, there is still some text that could benefit from
additional clarification.  Unfortunately, because of the small amount of
time between when we received the comments and today's deadline, we had
to focus on addressing the issues that seemed substantive or that were
just straightforward changes/corrections.  Please accept our apologies
if we've missed any other comments/corrections.

At the request of the WG Chairs, we are sending the draft to both
the IETF secretariat and directly to the mailing list (to minimize
delays.)   This latest version is:
	draft-ietf-ipsec-arch-sec-04.txt.

Thank you,
Karen

===========================================================================


1. Typos/clarifications:
------------------------

Section 1.1 Summary of Contents of Document
	
	fixed formatting of item c.

Section 1.3 Related Documents

	fixed formatting of item d.

Section 4.3 Combining Security Associations -- per H. Redelmeier

	changed first bullet of second paragraph from:
		o Transport adjacency refers to applying more than one
		  security protocol to the same IP datagram, without
		  invoking tunneling.  This approach to combining AH and
		  ESP allows for only one level of combination; further
		  nesting yields no added benefit since the processing
		  is performed at one IPsec instance at the (ultimate)
		  destination.

	to:
		o Transport adjacency refers to applying more than one
		  security protocol to the same IP datagram, without
		  invoking tunneling.  This approach to combining AH and
		  ESP allows for only one level of combination; further
		  nesting yields no added benefit (assuming use of
		  adequately strong algorithms in each protocol) since
		  the processing is performed at one IPsec instance at
		  the (ultimate) destination.

	changed 3rd paragraph from:
		These two approaches also can be combined, i.e., an SA
		bundle could be constructed from one tunnel mode SA and
		one or two transport mode SAs, applied in sequence.

	to:
		These two approaches also can be combined, e.g., an SA
		bundle could be constructed from one tunnel mode SA and
		one or two transport mode SAs, applied in sequence.

Section 4.4.1 The Security Policy Database (SPD) -- per H. Redelmeier

	changed 3rd paragraph to clarify why it is feasible to specify
	that security processing be applied on a "packet by packet
	basis":
		For every IPsec implementation, there MUST be an
		administrative interface that allows a user or system
		administrator to manage the SPD.  This interface must
		allow the user (or system administrator) to specify the
		security processing to be applied to each packet
		entering or exiting the system, on a packet by packet
		basis. (In a host IPsec implementation making use of a
		socket interface, the SPD may not need to be consulted
		on a per packet basis, but the effect is still the
		same.)  The management interface for the SPD MUST allow
		creation of entries consistent with the selectors
		defined in Section 4.4.2, and MUST support ordering of
		these entries.
	to:

		For every IPsec implementation, there MUST be an
		administrative interface that allows a user or system
		administrator to manage the SPD.  Specifically, every
		inbound or outbound packet is subject to processing by
		IPsec and the SPD must specify what action will be taken
		in each case.  Thus the administrative interface must
		allow the user (or system administrator) to specify the
		security processing to be applied to any packet entering
		or exiting the system, on a packet by packet basis.  (In
		a host IPsec implementation making use of a socket
		interface, the SPD may not need to be consulted on a per
		packet basis, but the effect is still the same.)  The
		management interface for the SPD MUST allow creation of
		entries consistent with the selectors defined in Section
		4.4.2, and MUST support (total) ordering of these
		entries.  It is expected that through the use of
		wildcards in various selector fields, and because all
		packets on a single UDP or TCP connection will tend to
		match a single SPD entry, this requirement will not
		impose an unreasonably detailed level of SPD
		specification.  The selectors are analogous to what are
		found in a stateless firewall or filtering router and
		which are currently manageable this way.

Section 4.4.2 Selectors -- paragraph on "Name" -- per D. Piper

	changed "Note that these name forms are supported in ISAKMP" 
	to	"Note that these name forms are supported in the IPsec DOI" 

	changed "[REQUIRED for...."
	to	"[REQUIRED for the following cases...."


Section 4.5 Basic Combinations of Security Associations --per Kai Martius

	changed last sentence of Case 4 from:
		The details of support for this case, (how H1 locates
		SG2, authenticates it, and verifies its authorization to
		represent H2) are discussed in Section 4.4.3, "Locating
		a Security Gateway".

	to
		The details of support for this case, (how H1 locates
		SG2, authenticates it, and verifies its authorization to
		represent H2) are discussed in Section 4.6.3, "Locating
		a Security Gateway".

Section 4.6.3 Locating a Security Gateway -- per Kai Martius

	fixed last word of next to last paragraph from:
		It is assumed that the SPD is also configured with
		policy information that covers any other IPsec
		requirements for the path to the security gateway and
		the destination hos.

	to
		It is assumed that the SPD is also configured with
		policy information that covers any other IPsec
		requirements for the path to the security gateway and
		the destination host.

Section 5.1.2 Header Construction for Tunnel Mode -- per H. Redelmeier

	changed first bullet to clarify the meaning of "original" in
	the presence of tunneling within tunneling:
		o The outer IP header Source Address and Destination
		  Address identify the "endpoints" of the tunnel (the
		  encapsulator and decapsulator).  The inner IP header
		  Source Address and Destination Addresses identify the
		  original sender and recipient of the datagram,
		  respectively....

	to
		o The outer IP header Source Address and Destination
		  Address identify the "endpoints" of the tunnel (the
		  encapsulator and decapsulator).  The inner IP header
		  Source Address and Destination Addresses identify the
		  original sender and recipient of the datagram, (from
		  the perspective of this tunnel), respectively....

Section 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode -- per
Indermohan Singh Monga

	changed table entry for checksum from:
	
	                        <-- How Outer Hdr Relates to Inner Hdr -->
	                        Outer Hdr at                 Inner Hdr at
	   IPv4                 Encapsulator                 Decapsulator
	     Header fields:     --------------------         ------------
		......		......				......
	       checksum         constructed                  no change
		......		......				......

	to:	
	                        <-- How Outer Hdr Relates to Inner Hdr -->
        	                Outer Hdr at                 Inner Hdr at
	   IPv4                 Encapsulator                 Decapsulator
	     Header fields:     --------------------         ------------
		......		......				......
	       checksum         constructed                  constructed (2)
		......		......				......


	changed footnote (2) from:

	        2. The TTL in the inner header is decremented by the
		   encapsulator prior to forwarding and by the
		   decapsulator if it forwards the packet.  (The
		   checksum changes when the TTL changes.)

Acknowledgements -- per H. Redelmeier

	removed space after comma and changed 2 years to 3 years:
		For over 2 years (although it sometimes seems *much*
		longer) , this....

	to 
		For over 3 years (although it sometimes seems *much*
		longer), this....

Appendix C -- per H. Redelmeier

	changed each occurrence of "(1 << diff)" to "((u_long)1 << diff)"

	left "test harness" as is -- received no comments


2. Modify to make ESP encryption/confidentiality optional -- per co-chairs
--------------------------------------------------------------------------

Section 3.2 How IPsec Works

	changed 1st paragraph, second bullet from:

		o The Encapsulating Security Payload (ESP) protocol
		  [KA98b] provides confidentiality (encryption), and
		  limited traffic flow confidentiality.  It also may
		  provide connectionless integrity, data origin
		  authentication, and an anti-replay service.

	to:
		o The Encapsulating Security Payload (ESP) protocol
		  [KA98b] may provide confidentiality (encryption), and
		  limited traffic flow confidentiality.  It also may
		  provide connectionless integrity, data origin
		  authentication, and an anti-replay service.  (One or
                  the other set of these security services must be applied
                  whenever ESP is invoked.)

Section 4.2 Security Association Functionality

	changed first and last sentences of the 3rd paragraph from:
		"ESP always provides confidentiality for traffic.
	        (However, the strength of the confidentiality service
	        will depend, in part, on the encryption algorithm
	        employed.)  ESP also may optionally provide
	        authentication (as defined above).  If authentication is
	        negotiated for an ESP SA, the receiver also may elect to
	        enforce an anti-replay service with the same features as
	        the AH anti-replay service.  The scope of the
	        authentication offered by ESP is narrower than for AH,
	        i.e., the IP header(s) "below" the ESP header is not
	        protected.  If only the upper layer protocols need to be
	        authenticated, then ESP authentication is an appropriate
	        choice and is more space efficient than use of AH
	        encapsulating ESP."

	to 

		"ESP optionally provides confidentiality for traffic.
		(The strength of the confidentiality service depends
		in part, on the encryption algorithm employed.)  ESP
		also may optionally provide authentication (as defined
		above).  If authentication is negotiated for an ESP SA,
                the receiver also may elect to enforce an anti-replay
                service with the same features as the AH anti-replay
                service.  The scope of the authentication offered by ESP
                is narrower than for AH, i.e., the IP header(s) "below"
                the ESP header is(are) not protected.  If only the upper
                layer protocols need to be authenticated, then ESP
                authentication is an appropriate choice and is more
                space efficient than use of AH encapsulating ESP.  Note
                that although both confidentiality and authentication
                are optional, they cannot both be omitted. At least one
                of them MUST be selected.

Section 4.4.1 The Security Policy Database (SPD)

	added the following text after paragraph 8 ("As described
	below..."

		Note that if ESP is specified, either (but not both)
		authentication or encryption can be omitted.  So it MUST
		be possible to configure the SPD value for the
		authentication or encryption algorithms to be "NULL".
		However, at least one of these services MUST be
		selected, i.e., it MUST NOT be possible to configure
		both of them as "NULL".
		
Section 4.4.3 Security Association Database (SAD) 

	added the following text at the end of paragraph 1 "For each of
	the selectors defined in Section 4.4.2..."

                Note that for an ESP SA, either the encryption algorithm
                or the authentication algorithm can be "NULL".  However
                they MUST NOT both be "NULL".
                
3. Mention IPSec DOI support for IP compression negotiation 
------------------------------------------------------------                
                
Section 3.1 What IPsec Does

	changed 4th paragraph from:

		NOTE: When encryption is employed within IPsec, it
		prevents effective compression by lower protocol layers.
		However, IPsec does not provide its own compression
		services.  Such services may be provided by existing
		higher layer protocols, or, in the future, in IP itself.
		The IETF working group, "IP Payload Compression Protocol
		(ippcp)" has the charter to "develop protocol
		specifications that make it possible to perform lossless
		compression on individual payloads before the payload is
		processed by a protocol that encrypts it.  These
		specifications will allow for compression operations to
		be performed prior to the encryption of a payload by
		such protocols as IPsec."

	to;

		The IPsec DOI supports negotiation of IP compression,
		motivated in part by the observation that when
		encryption is employed within IPsec, it prevents
		effective compression by lower protocol layers. The IETF
		working group "IP Payload Compression Protocol (ippcp)"
		has the charter to "develop protocol specifications that
		make it possible to perform lossless compression on
		individual payloads before the payload is processed by a
		protocol that encrypts it.  These specifications will
		allow for compression operations to be performed prior
		to the encryption of a payload by such protocols as
		IPsec."