Subject: [Ipsec] IPsec 2401bis -- new draft

From: Karen Seo <[email-masked]>
Date: Mon, 6 Dec 2004 02:07:23 -0500

Apologies if this is a duplicate -- the first try is currently stuck 
in the IPsec mailer queue because it was "too big".  I'm not sure why 
-- I may have inadvertently included color/underlining.

Folks,

We just submitted a new draft of 2401bis to the IETF publication 
folks... In addition to fixes to typos/etc, this revision includes 
the changes listed below.   Although Steve and I discussed most of 
these changes, he has again maintained plausible deniability by being 
on vacation when I completed the final edits :-).

Please note:

1. On November 12th, Steve Kent requested a poll of the working group 
to confirm which option we should put into 2401bis for handling of 
BYPASS'd fragments.
However, there wasn't any subsequent poll/consensus as to whether to 
make the change below that Mark Duffy proposed for Section 7.4 
BYPASS/DISCARD traffic, sentence 2, so I didn't change the text.

    From:
	An implementation MUST support stateful fragment checking to
	accommodate BYPASS traffic for which a non-trivial port
	range is specified.

    To:
	An implementation MUST NOT forward fragmented BYPASS traffic
	without performing stateful fragment checking.

2. All changes below after the 2 rows of ==== were made based on 
feedback from Russ Housley during the current working group last 
call.  Hence they didn't show up on the list

Thank you,
Karen

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

Section 5.1 "Outbound IP Traffic Processing (protected-to-unprotected)" --
restored the following NOTE after step 4.  I also inserted some new 
text saying that "(This applies only to IPv4.  For IPv6 packets, only 
the originator is allowed to fragment them.)"

	Note: With the exception of IPv4 and IPv6 transport mode,
	an SG, BITS, or BITW  implementation MAY fragment packets
	before applying IPsec.  (This applies only to IPv4.  For IPv6
	packets, only the originator is allowed to fragment them.)
	The device SHOULD have a configuration setting to disable
	this.  The resulting fragments are evaluated against the SPD
	in the normal manner.  Thus, fragments not containing port
	numbers (or ICMP message type and code, or Mobility Header
	type) will only match rules having port (or ICMP message type
	and code, or MH type) selectors of OPAQUE or ANY. (See section
	7 for more details.)

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

Appendix B.1 -- clarified text by changing the 2nd sentence:

     From:
	In appendix B.1: "The resulting entries that are decorrelated
         with the decorrelated set of entries are then added to that
         decorrelated set."

     To:
	The nodes of the tree are the selectors that may overlap
	between the policies.  At each node, the algorithm creates a
	branch for each of the values of the selector.  It also
	creates one branch for the complement of the union of all
	selector values.  Policies are then formed by traversing the
	tree from the root to each leaf.  The policies at the leaves
	are compared to the set of already decorrelated policy rules.
	Each policy at a leaf is either completely overridden by a
	policy in the already decorrelated set and is discarded or
	is decorrelated with all the policies in the decorrelated set
	and is added to it.

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

Section 4.4.1 "The Security Policy Database (SPD)", subsection on 
"How To Derive the Values for an SAD entry" -- Changed:

     From:

	For each selector in an SPD entry, the entry specifies how to
	derive the corresponding values for a new Security Association
	Database (SAD, see Section 4.4.2) entry from those in the SPD
	and the packet. The goal is to allow an SAD entry and an SPD
	cache entry to be created based on specific selector values
	from the packet, or from the matching SPD entry. For outbound
	traffic, there are SPD-S cache entries and SPD-O cache entries.
	For inbound traffic, there are SPD-I cache entries and there
	is the SAD, which represents the cache for inbound
	IPsec-protected traffic (See Figure 3 in Section 5.2).

     To:
	For each selector in an SPD entry, the entry specifies how to
	derive the corresponding values for a new Security Association
	Database (SAD, see Section 4.4.2) entry from those in the SPD
	and the packet. The goal is to allow an SAD entry and an SPD
	cache entry to be created based on specific selector values
	from the packet, or from the matching SPD entry. For outbound
	traffic, there are SPD-S cache entries and SPD-O cache entries.
	For inbound traffic not protected by IPsec, there are SPD-I
                             ^^^^^^^^^^^^^^^^^^^^^^
	cache entries and there is the SAD, which represents the cache
	for inbound IPsec-protected traffic (See Figure 3 in Section
	5.2).

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

Section 7.4 BYPASS/DISCARD traffic and Section D.4 BYPASS/DROP 
Traffic (last paragraph) -- corrected TCP port 25 (Telnet) to be TCP 
port 23 (Telnet).

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

Section 5. "IP Traffic Processing" -- Clarified that the mapping of 
one cached SPD entry to one SA is not a consequence of decorrelation.

     Added the following sentences at the end of the paragraph 1:

	"For the purposes of this specification, it is
	assumed that each cached entry will map to exactly
	one SA.  Note, however, exceptions arise when one
	uses multiple SAs to carry traffic of different
	priorities (e.g., as indicated by distinct DSCP
	values) but the same selectors."

     Changed paragraph 2, sentence 3 from:

	But, if the SPD entries are first decorrelated, then the
	resulting entries can safely be cached and each cached entry
	will map to exactly one SA, or indicate that matching traffic
	should be bypassed or discarded, appropriately.

     To:
	But, if the SPD entries are first decorrelated, then the
	resulting entries can safely be cached. Each cached entry
	will indicate that matching traffic should be bypassed or
	discarded, appropriately.

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

We made the following changes to clarify how the looping of traffic 
protected by nested SAs is handled if there are multiple SPD-I's

Section 5.1 "Outbound IP Traffic Processing 
(protected-to-unprotected)", step 4 -- Added the following sentences 
at the end of step 4 (The packet is passed to....):

	If necessary, i.e., if there is more than one SPD-I,
	the traffic being looped back MAY be tagged as
	coming from this internal interface.  This would
	allow the use of a different SPD-I for "real"
	external traffic vs looped traffic, if needed.

Appendix E - "Example of Supporting Nested SAs via SPD and Forwarding 
Table Entries", paragraph 1 -- Added the following sentence at the 
end of this paragraph:

	For simplicity, this example assumes just one SPD-I.

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

Section 8.2.1 "Propagation of PMTU" -- Modified last sentence to 
clarify when to send a PMTU ICMP message:

     From:
	When such traffic arrives, if the traffic would exceed the
	updated PMTU value the traffic MUST be discarded and an
	appropriate ICMP PMTU message sent.

     To:
	When such traffic arrives, if the traffic would exceed the
	updated PMTU value the traffic MUST be handled as follows:

	Case 1: Original (cleartext) packet is IPv4 and has the DF
                  bit set.  The implementation SHOULD discard the packet
                  and send a PMTU ICMP message.

	Case 2: Original (cleartext) packet is IPv4 and has the DF
                 bit clear. The implementation SHOULD fragment (before
	        orafter encryption per its configuration) and then
	        forward the fragments.  It SHOULD NOT send a PMTU
		ICMP message.

	Case 3: Original (cleartext) packet is IPv6. The implementation
                 SHOULD discard the packet and send a PMTU ICMP message.

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

Section D.3. The Problem of Non-Initial Fragments, -- Since Section 
7.2 allows separate SAs to be used for non-initial fragments, we 
modified the text that said the WG had "rejected" this option:

   2nd paragraph, last sentence
      From:
	However, RFC 2401 did not provide detailed guidance on this
	and thus it may not have been apparent that use of this
	feature would essentially create a "non-initial fragment
	only" SA, precisely the solution that the WG rejected.

     To:
	However, RFC 2401 did not provide detailed guidance on this
	and thus it may not have been apparent that use of this
	feature would essentially create a "non-initial fragment
	only" SA.

  3rd paragraph, 1st sentence
     From:
	In the course of rejecting the "fragment-only" SA approach,
	it was noted that some subtle problems, problems not
	considered in RFC 2401, would have to be avoided.

     To:
	In the course of discussing the "fragment-only" SA approach,
	it was noted that some subtle problems, problems not
	considered in RFC 2401, would have to be avoided.

  Section D.6 "Other Suggested Solutions", paragraph 4:
     From:
	The Working Group rejected the convention of creating an SA
	to carry only non-initial fragments, something that was
	supported implicitly under the RFC 2401 model via use of
	OPAQUE port fields, but never clearly articulated in the RFC
	2401. The (rejected) text called for each non-initial
	fragment to be treated as protocol 44 (the IPv6 fragment
	header protocol ID) by the sender and receiver.

     To:
	The Working Group rejected an earlier version of the
	convention of creating an SA to carry only non-initial
	fragments, something that was supported implicitly under the
	RFC 2401 model via use of OPAQUE port fields, but never
	clearly articulated in the RFC 2401. The (rejected) text
	called for each non-initial fragment to be treated as
	protocol 44 (the IPv6 fragment header protocol ID) by the
	sender and receiver.

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

Section 13 "Differences from RFC 2401" -- Added the following bullet

	o With respect to IP addresses and ports, the terms "Local"
           and "Remote" are used for policy rules (replacing source
	  and destination).  "Local" refers to the entity being
	  protected by an IPsec implementation, i.e., the "source"
	  address/port of outbound packets or the "destination"
	  address/port of inbound packets. "Remote" refers to a peer
	  entity or peer entities. The terms "source" and
	  "destination" are still used for packet header fields.

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

Section 5.1 "Outbound IP Traffic Processing (protected to 
unprotected)" -- Added back the following note after Step 4

NOTE: With the exception of IPv4 and IPv6 transport mode, an SG, BITS, or BITW
implementation MAY fragment packets before applying IPsec.  The 
device SHOULD have a configuration setting to disable this.  The 
resulting fragments are evaluated against the SPD in the normal 
manner.  Thus, fragments not containing port numbers (or ICMP message 
type and code, or Mobility Header type) will only match rules having 
port (or ICMP message type and code, or MH type) selectors of OPAQUE 
or ANY. (See section 7 for more details.)

===========================================================================
===========================================================================
All the following changes were suggested by Russ Housley...
===========================================================================
===========================================================================

In addition to fixing typos that he caught, we made various edits 
including but not limited to:

1. Spelled out acronyms -- NAT, ECN, DSCP, TCAM....
2. Used SA instead of Security Association after initial definition
3. Put in requests to RFC Editor to replace ?? with RFC numbers for
    the various IDs that are about to become RFCs and which are in
    the Reference section.
4. Changed all "Note" or "NOTE" to be consistently just one
    style --> "Note:"
5. Tried to change SPD-I, SPD-O, SPD-S and SPD-ID to use non-breaking
    hyphens, but I ran into a Microsoft Word glitch with this. So
    I may have missed some.
6. Replaced "system"/"systems" with "implementation"/"implementations
    in a number of places
7. Replaced "drop"/"DROP" with "discard"/"DISCARD" for consistency.
8. Replaced "2401bis" with phrases like "this document".

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

Section 2.1, "Goals/Objectives/Requirements/Problem Description", 
paragraph 5 -- Changed:

     From:
	A set of default cryptographic algorithms for use with AH and
	ESP is specified in [Eas03] to facilitate interoperability in
	the global Internet. The use of these cryptographic algorithms....

     To:
	To facilitate interoperability in the global Internet, a set
	of default cryptographic algorithms for use with AH and ESP
	is specified in [Eas03] and a set of mandatory-to-implement
	algorithms for IKEv2 is specified in [Sch03].  [Eas03] and
	[Sch03] will be periodically updated to keep pace with
	computational and cryptologic advances.  By specifying these
	algorithms in documents that are separate from the AH, ESP,
	and IKEv2 specifications, these algorithms can be updated or
	replaced without affecting the standardization progress of
	the rest of the IPsec document suite. The use of these
	cryptographic algorithms...

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

Section 3.2 "How IPsec Works", paragraph 1, bullet 2 -- changed

     From:
	o The Encapsulating Security Payload (ESP) protocol [Ken04a]
	  offers the same set of services, and also offers
	  confidentiality. Use of ESP in a confidentiality-only mode
	  is discouraged.
     To:
	o The Encapsulating Security Payload (ESP) protocol [Ken04a]
	  offers the same set of services, and also offers
	  confidentiality. Use of ESP to provide confidentiality
	  without integrity is NOT RECOMMENDED.

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

Section 4.2 "Security Association Functionality" (changed in the rev 
to SA Functionality), paragraph 2 -- changed

     From:
	For example, both AH and ESP offer integrity and authentication
	services, but the coverage differs for each protocol and
	differs for transport vs. tunnel mode. If the integrity of an
	IPv4 option or IPv6 extension header must be protected en-route
	between sender and receiver, AH can provide this service,
	except for the mutable (non-predictable) parts of the IP or
	extension headers.....

     To:
	For example, both AH and ESP offer integrity and authentication
	services, but the coverage differs for each protocol and
	differs for transport vs. tunnel mode. If the integrity of an
	IPv4 option or IPv6 extension header must be protected en-route
	between sender and receiver, AH can provide this service,
	except for IP or extension headers that may change in a fashion
	not predictable by the sender....

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

Section 4.4.1.2  "Structure of an SPD entry", 1st sentence -- Changed 
to indicate that the ASN.1 in Appendix C is an example, not normative.

     From:
	This section contains a prose description of an SPD entry.
	Also, an ASN.1 definition of an SPD entry is provided in
	Appendix C.

     To:
	This section contains a prose description of an SPD entry.
	Also, Appendix C provides an example of an ASN.1 definition
	of an SPD entry.

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

Section 4.4.1.2 "Structure of an SPD entry", 2nd paragraph, 1st 
sentence -- Changed:

     From:
	This text describes the SPD in a fashion that maps directly
	into IKE payloads. One should not create SPD entries that
	cannot be mapped into something that IKE can negotiate.

     To:
	This text describes the SPD in a fashion that maps directly
	into IKE payloads to ensure that the policy required by SPD
	entries can be negotiated through IKE.

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

Section 4.4.1.2 "Structure of an SPD entry", paragraph 3, bullet 1 -- Changed

     From:
	o Name -- a list of IDs.  This quasi-selector is optional.

     To:
	o Name -- a list of IDs.  This quasi-selector is optional.
	  The forms that MUST be supported are described above in
	  Section 4.4.1.1 under "Name".

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

Section 4.5 SA and Key Management, first sentence -- Changed as follows

     From:
	IPsec mandates support for both manual and automated SA and
	cryptographic key management.

     To:
    	All IPsec implementations MUST support both manual and
	automated SA and cryptographic key management.

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

Section 8.2.2 "PMTU Aging", paragraph 1 -- Changed as follows:

    From:
	In all IPsec implementations the PMTU associated with an
	SA MUST be "aged" and some mechanism is required to update
	the PMTU in a timely manner, especially for discovering if
	the PMTU is smaller than it should be,
     To:
	In all IPsec implementations the PMTU associated with an
	SA MUST be "aged" and some mechanism is required to update
	the PMTU in a timely manner, especially for discovering if
	the PMTU is smaller than required by current network conditions.

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

Section 13. "Differences from RFC 2401" -- Changed as follows:

    From:
	o Support for AH in both IPv4 and IPv6 is now a MAY.

    To:
	o Support for AH in both IPv4 and IPv6 is no longer required.

    Deleted redundant bullet:
	o Text and an ASN.1 desription have been added to clarify
	  the structure of an SPD entry and its alignment with what
	  can be negotiated in IKEv2.

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

Appendix C -- ASN.1 for an SPD Entry -- made about a dozen 
corrections and changes.  It should compile.  Let me know if you want 
the details.

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec