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

From: Karen Seo <[email-masked]>
Date: Mon, 25 Oct 2004 04:57:14 -0400

Folks,

We just submitted a new draft of 2401bis to the IETF publications 
folks. It has the changes listed below (plus a few typo fixes that I 
didn't list).  Steve Kent and I discussed the various issues that 
have been raised and how to address them, but I was still doing some 
of the edits late tonight.  So he didn't get a chance to review the 
changed text before I sent it in.  So, once again, any errors are 
mine.

Note:	a. The ASN.1 needs to be revised to reflect the addition
	   of local and remote tunnel addresses.  I didn't get
	   a chance to check on this with the local ASN.1 guru.
	b. There are several items that Mark and Francis brought up
	   for which we need further clarification/discussion.  We
	   have sent (or will send) email on these.

Please let us know if you have any questions.  Thank you,
Karen

==============================================================================
1. Lars Volker

5.1 Outbound IP Traffic Processing (protected-to-unprotected), Figure 2 and
5.2 Processing Inbound IP Traffic (unprotected-to-protected), Figure 
3 -- Changed the text in the right side box:

   From:
	"PROTECT (AH/ESP)"

   To:
	"PROCESS (AH/ESP)"

==============================================================================
2. Matthew Condell

4.4.1 The Security Policy Database (SPD), Section on "Decorrelation", 
paragraph 2 -- Added reference for decorrelation "[CoSa04]" and

Informative (References) -- Added a reference for decorrelation

	[CoSa04]  Condell, M., and Sanchez, L. On the Deterministic
	Enforcement of Un-ordered Security Policies", BBN Technical
	Memo 1346, March 2004

==============================================================================
3. Ted Tso (and Mark Duffy)

4.1 Definition and Scope, paragraph 4 -- modified use of curly 
brackets to be consistent by changing:

   From:
    	1. Search the SAD for a match on the combination of SPI,
	   destination address, and source address}.

   To:
	1. Search the SAD for a match on the combination of SPI,
            destination address, and source address.

and also changing

   From:
	3. Search the SAD for a match on only {SPI}....

   To:
	3. Search the SAD for a match on only SPI

==============================================================================
4. Ted Tso (and Mark Duffy)

4.1 Definition and Scope, paragraph 7 -- removed hyphen from "-support"

   From:
	Therefore a sender SHOULD put traffic of different classes,
	but with the same selector values, on different SAs to
	-support....

   To:
	Therefore a sender SHOULD put traffic of different classes,
	but with the same selector values, on different SAs to
	support.....

==============================================================================
5. Ted Tso

4.4 Major IPsec Databases -- added period at end of last sentence of 
last paragraph

==============================================================================
6. Joe Touch

4.1 Definition and Scope, paragraph 10 -- Added a reference for "Use 
of IPsec Transport Mode for Dynamic Routing"

   From:
	A transport mode SA is a security association typically
	employed between a pair of hosts to provide end-to-end
	security services. When security is desired between two
	intermediate systems along a path (vs. end-to-end use of
	IPsec), transport mode MAY be used between security gateways
	or between a security gateway and a host.  In the latter
	case, transport mode may be used to support in-IP tunneling
	(e.g., IP-in-IP [Per96] or GRE tunneling [FaLiHaMeTr00] over
	transport mode SAs.

   To:
	A transport mode SA is a security association typically
	employed between a pair of hosts to provide end-to-end
	security services. When security is desired between two
	intermediate systems along a path (vs. end-to-end use of
	IPsec), transport mode MAY be used between security gateways
	or between a security gateway and a host.  In the latter
	case, transport mode may be used to support in-IP tunneling
	(e.g., IP-in-IP [Per96] or GRE tunneling [FaLiHaMeTr00] or
	Dynamic routing [ToEgWa04]) over transport mode SAs.

Informative ( References) -- Added the following reference

	[ToEgWa04] Touch, J., Eggert, L., Wang, Y., "Use of IPsec
	Transport Mode for Dynamic Routing", RFC 3884, September 2004.

==============================================================================
7. Joe Touch

Fragments carried via SAs pose problems for access control checks. In 
the situation where a transport mode SA is using IP-in-IP tunneling, 
IPsec does not see the inner IP header.  Made the changes shown below

   Section D.1 Transport Mode and Fragments, paragraph 4 -- made the
   two changes in square brackets [].

  	In 2401bis, we have explicitly said that it is OK to use
	transport mode in cases where the IPsec implementation is not
	the ultimate destination, e.g., between two SGs. In principle,
	this creates a new opportunity for outbound, plaintext
	fragments to be mapped to a transport mode SA for IPsec
	processing. However, in these new contexts in which a transport
	mode SA is now approved for use, it seems likely that we can
	continue to prohibit transmission of fragments, as seen by
	IPsec, [inserted "i.e., packets that have an "outer header" with a
	non-zero fragment offset field"]. For example, in an IP overlay
	network, packets being sent over transport mode SAs are
	IP-in-IP tunneled and thus have the necessary inner header to
	accommodate fragmentation prior to IPsec processing. When
	carried via a transport mode SA, IPsec would not examine the
	inner IP header for such traffic, and thus would not consider
	the packet to be a fragment. [deleted last sentence]

   Section 4.1 Definition and Scope, paragraph 13, which starts "Several
   concerns motivate the use of tunnel mode....": added the following
   2 sentences:

	(Use of an IP-in-IP tunnel in conjunction with transport mode
	can also address these fragmentation issues. However, this
	configuration limits the ability of IPsec to enforce access
	control policies on traffic.)

==============================================================================
8. Francis Dupont

4.4.1.2 Structure of an SPD entry -- Added fields for local and 
remote tunnel addresses. (These fields were already present in the 
SAD.)

   From:
          - IPsec mode -- tunnel or transport

   To:
          - IPsec mode -- tunnel or transport
          - (if tunnel mode) local tunnel address -- For a non-mobile
	   host, if there is just one interface, this is straight-
	   forward and if there are multiple interfaces, this must
	   be statically configured. For a mobile host, the specifi-
	   cation of the local address is handled externally to
            IPsec.
          - (if tunnel mode) remote tunnel address -- There is no
            standard way to determine this. See 4.5.3 "Locating a
            Security Gateway".

Did not have a chance to UPDATE the ASN.1 -- need to consult with 
Charlie Gardiner.

==============================================================================
9. Francis Dupont & Mohan Parthasarathy

Clarified issues re: SAD acting as a cache for the SPD with regard to 
inbound IPsec-protected traffic, keeping the SAD up-to-date if the 
SPD changes

   4.4.1 The Security Policy Database (SPD), section on "Handling
   Changes to the SPD while the System is Running" -- changed the MAY
   to SHOULD:

   From:
	If a change is made to the SPD while the system is running,
	a check SHOULD be made of the effect of this change on
	extant SAs. An implementation MAY choose to check the impact
	of an SPD change on extant SAs and to provide a
	user/administrator with a mechanism for configuring what
	actions to take, e.g., delete an affected SA, allow an
	affected SA to continue unchanged, etc.

   To:
	If a change is made to the SPD while the system is running,
	a check SHOULD be made of the effect of this change on
	extant SAs. An implementation SHOULD check the impact of an
	SPD change on extant SAs and SHOULD provide a
	user/administrator with a mechanism for configuring what
	actions to take, e.g., delete an affected SA, allow an
	affected SA to continue unchanged, etc.

   4.4.1 The Security Policy Database (SPD), section on "How To
   Derive the Values for an SAD entry" -- Added a sentence

   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.

   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,
	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).

   4.4.2 Security Association Database (SAD), last paragraph just before
   Section 4.4.2.1 -- modified as follows:

   From:
	For each of the selectors defined in Section 4.4.1.1, the
	entry for an inbound SA in the SAD MUST contain the value or
	values negotiated at the time the SA was created. For a
	receiver, these values are used to check that the header
	fields of an inbound packet (after IPsec processing) match
	the selector values negotiated for the SA....

   To:
	For each of the selectors defined in Section 4.4.1.1, the
	entry for an inbound SA in the SAD MUST be initially
	populated with the value or values negotiated at the time
	the SA was created. (See Section 4.4.1, paragraph on
	"Handling Changes to the SPD while the System is Running"
	for guidance on the effect of SPD changes on extant SAs.)
	For a receiver, these values are used to check that the
	header fields of an inbound packet (after IPsec processing)
	match the selector values negotiated for the SA. Thus, the
	SAD acts as a cache for checking the selectors of inbound
	traffic arriving on SAs...

   5. IP Traffic Processing, paragraph 1 -- inserted a sentence:

   From:
	As mentioned in Section 4.4.1 "The Security Policy Database
	(SPD)", the SPD (or associated caches) MUST be consulted
	during the processing of all traffic that crosses the IPsec
	protection boundary, including IPsec management traffic. If
	no policy is found in the SPD that matches a packet (for
	either inbound or outbound traffic), the packet MUST be
	discarded. To simplify processing, and to allow for very fast
	SA lookups (for SG/BITS/BITW), this document introduces the
	notion of an SPD cache for all outbound traffic (SPD-O plus
	SPD-S), and a cache for inbound, non-IPsec-protected traffic
	(SPD-I).....

   To:
	As mentioned in Section 4.4.1 "The Security Policy Database
	(SPD)", the SPD (or associated caches) MUST be consulted
	during the processing of all traffic that crosses the IPsec
	protection boundary, including IPsec management traffic. If
	no policy is found in the SPD that matches a packet (for
	either inbound or outbound traffic), the packet MUST be
	discarded. To simplify processing, and to allow for very fast
	SA lookups (for SG/BITS/BITW), this document introduces the
	notion of an SPD cache for all outbound traffic (SPD-O plus
	SPD-S), and a cache for inbound, non-IPsec-protected traffic
	(SPD-I).  (As noted earlier, the SAD acts as a cache for
	checking the selectors of inbound IPsec-protected traffic
	arriving on SAs.)....

==============================================================================
10. Francis Dupont & Mohan Parthasarathy

4.4.1 The Security Policy Database (SPD), section on "Decorrelation" 
-- clarified that decorrelation is not required.

   From:
	The processing model described in this document assumes the
	ability to decorrelate overlapping SPD entries to permit
	caching, which enables more efficient processing of outbound
	traffic in security gateways and BITS/BITW implementations.
	Native host implementations have an implicit form of caching
	available, due to the use of, for example, socket interfaces
	for applications, and thus there is no requirement to be
	able to decorrelate SPD entries in these implementations.)

	Note: Decorrelation is a means of improving performance and
	simplifying the processing description; it is not a
	requirement for a compliant implementation. In this section,
	unless otherwise noted, the use of "SPD" refers to the body
	of policy information in both ordered or decorrelated
	(unordered) state.

   To:
	The processing model described in this document assumes the
	ability to decorrelate overlapping SPD entries to permit
	caching, which enables more efficient processing of outbound
	traffic in security gateways and BITS/BITW implementations.
	Decorrelation [CoSa04] is only a means of improving
	performance and simplifying the processing description. This
	RFC does not require a compliant implementation to make use of
	decorrelation. For example, native host implementations
	typically make use of caching implicitly because they bind SAs
	to socket interfaces, and thus there is no requirement to be
	able to decorrelate SPD entries in these implementations.)

	Note: Unless otherwise qualified, the use of "SPD" refers to
	the body of policy information in both ordered or decorrelated
	(unordered) state.

==============================================================================
11. Francis Dupont

4.1 Definition and Scope -- moved "anycast" case from paragraph 2 
(unicast) to paragraph 3 (multicast):

   From (paragraph 2 and 3):
	For an SA used to carry unicast (or anycast) traffic,....

	In many secure multicast architectures,....

   To (paragraph 2 and 3):
	For an SA used to carry unicast traffic,....

	In many secure multicast (or anycast) architectures,....

==============================================================================
12. Francis Dupont

4.1 Definition and Scope, SAD lookup -- removed "ESP" from steps 1, 2 and 3.

   From:
    1. Search the SAD for a match on the combination of SPI,
       destination address, and source address}. If an SAD entry
       matches, then process the inbound ESP packet with that
       matching SAD entry. Otherwise, proceed to step 2.

    2. Search the SAD for a match on both SPI and destination address.
       If the SAD entry matches then process the inbound ESP packet
       with that matching SAD entry. Otherwise, proceed to step 3.

    3. Search the SAD for a match on only {SPI} if the receiver has
       chosen to maintain a single SPI space for AH and ESP, and on
       both SPI  and protocol otherwise. If an SAD entry matches then
       process the inbound ESP packet with that matching SAD entry.
       Otherwise, discard the packet and log an auditable event.

   To:
    1. Search the SAD for a match on the combination of SPI,
       destination address, and source address}. If an SAD entry
       matches, then process the inbound packet with that
       matching SAD entry. Otherwise, proceed to step 2.

    2. Search the SAD for a match on both SPI and destination address.
       If the SAD entry matches then process the inbound packet
       with that matching SAD entry. Otherwise, proceed to step 3.

    3. Search the SAD for a match on only {SPI} if the receiver has
       chosen to maintain a single SPI space for AH and ESP, and on
       both SPI  and protocol otherwise. If an SAD entry matches then
       process the inbound packet with that matching SAD entry.
       Otherwise, discard the packet and log an auditable event.

==============================================================================
13. Francis Dupont

7. Handling Fragments (on the protected side of the IPsec boundary), 
paragraph 3  -- Made use of "non-initial" fragment consistent with 
Section 4.4.  Changed:

   From:
	Note: The term "non-initial fragment" is used here to indicate
	a fragment that does not contain all the selector values that
	may be needed for access control.  As observed in Section 4.4.1,
	depending on the Next Layer Protocol, in addition to Ports, the
	ICMP message type/code or Mobility Header type could be missing
	from non-initial fragments.  Also, for IPv6, even an initial
	fragment might NOT contain the Next Layer Protocol or Ports (or
	ICMP message type/code, or Mobility Header type) depending on
	the kind and number of extension headers present.

   To:
	Note: The term "non-initial fragment" is used here to indicate
	a fragment that does not contain all the selector values that
	may be needed for access control.  As observed in Section 4.4.1,
	depending on the Next Layer Protocol, in addition to Ports, the
	ICMP message type/code or Mobility Header type could be missing
	from non-initial fragments.  Also, for IPv6, even the first
	fragment might NOT contain the Next Layer Protocol or Ports (or
	IPsec message type/code, or Mobility Header type) depending on
	the kind and number of extension headers present.

==============================================================================
14. Francis Dupont

5.1 Outbound IP Traffic Processing (protected-to-unprotected), Step 
3b, 7th sentence -- There was a "may" following a "MAY".  Changed the 
sentence:

   From:
	(A packet that triggers an SPD lookup MAY be discarded by the
	implementation, or it may be processed against the newly
	created cache entry, if one is created.)

   To:
	(A packet that triggers an SPD lookup MAY be discarded by the
	implementation, or it MAY be processed against the newly
	created cache entry, if one is created.)

==============================================================================
15. Francis Dupont

5.1.2.2 IPv6 -- Header Construction for Tunnel Mode -- Added note for 
the table entry for "flow label"

   From:
	"copied or configured"

   To:
	"copied or configured (8)"

   Added note (8)
	8. See [RaCoCaDe04] -- Copying is acceptable only for
	end systems, not SGs.  If an SG copied flow labels from
	the inner header to the outer header, collisions might
	result.

Should we add flow label to SPD and SAD (when configured for a tunnel)?
==============================================================================
16. Francis Dupont

Informational (References) -- updated reference for Mobip

   From:
	[Mobip]	Johnson, D., Perkins, C., Arkko, J., "Mobility
	Support in IPv6", Work in Progress, June 2003

   To:
	[Mobip]	Johnson, D., Perkins, C., Arkko, J., "Mobility
	Support in IPv6", RFC 3775, June 2004

==============================================================================
17. Mark Duffy

3.1 What IPsec Does, 2nd paragraph, 4th sentence -- corrected next to 
last word from "unprotected" to "protected".

   From:
	In this document, the term "inbound" refers to traffic
	entering an IPsec implementation via the unprotected
	interface or emitted by the implementation on the
	unprotected side of the boundary and directed towards
	the unprotected interface.

   To:
	In this document, the term "inbound" refers to traffic
	entering an IPsec implementation via the unprotected
	interface or emitted by the implementation on the
	unprotected side of the boundary and directed towards
	the protected interface.

==============================================================================
18. Mark Duffy

4.1 Definition and Scope, paragraph 10, sentence 3 -- clarified to 
what case the sentence was referring.  Changed

   From:
	In the latter case, transport mode may be used to support
	in-IP tunneling...

   To:
	In the case where transport mode is used between security
	gateways or between a security gateway and a host, transport
	mode may be used to support in-IP tunneling...

==============================================================================
19. Mark Duffy

4.4.1 The Security Policy Database (SPD), paragraph on "SPD-S, SPD-I, 
SPD-O", sentence 9 -- removed "the same rule applies here" which 
appears to be old text that once meant something, but now is just 
confusing.

   From:
	Since the SPD-I is just a part of the SPD, the same rule
	applies here, i.e., if a packet that is looked up in the
	SPD-I cannot be matched to an entry there, then the packet
	MUST be discarded.

   To:
	Since the SPD-I is just a part of the SPD, if a packet
	that is looked up in the SPD-I cannot be matched to an
	entry there, then the packet MUST be discarded.

==============================================================================
20. Mark Duffy

4.4.1 The Security Policy Database (SPD), paragraph on SPD-S, SPD-I, 
SPD-O -- added a sentence at the end.

	In an ordered, non-decorrelated SPD, the entries for the
	SPD-S, SPD-I, and SPD-O are interleaved.  So there is one
	look up in the SPD.

==============================================================================
21. Mark Duffy

4.4.1.1  Selectors, "Next Layer Protocol", sentence 4 -- Changed IP to IPv6.

   From:
	To simplify locating the Next Layer Protocol, there SHOULD
	be a mechanism for configuring which IP extension headers
	to skip.

   To:
	To simplify locating the Next Layer Protocol, there SHOULD
	be a mechanism for configuring which IPv6 extension headers
	to skip.

==============================================================================
22. Mark Duffy

4.4.1.1  Selectors, "Mobility Header, sentence 4 -- Clarified that 
the directions re:placement of values applied to IKE.

   From:
	The IPv6 mobility header message type (MH type) is placed
	in the most significant eight bits of the 16 bit local
	"port" selector.

   To:
	For IKE, the IPv6 mobility header message type (MH type)
	is placed in the most significant eight bits of the 16 bit
	local "port" selector.

4.4.1.1  Selectors, "ICMP", sentence 4 -- same clarification as above.

   From:
	The message type is placed in the most significant 8 bits
	of the 16-bit selector and the code is placed in the least
	significant 8 bits.

   To:
	For IKE, the message type is placed in the most significant
	8 bits of the 16-bit selector and the code is placed in
	the least significant 8 bits.

==============================================================================
23. Mark Duffy

4.4.1.3 More re: Fields Associated with Next Layer Protocols -- 
clarified where the values were being set:

   From:
	A. If a Next Layer Protocol has no "port" selectors, then
         the Local and Remote "port" selectors are set to OPAQUE, e.g.,

   To:
	A. If a Next Layer Protocol has no "port" selectors, then
         the Local and Remote "port" selectors are set to OPAQUE in
         the relevant SPD entry, e.g.,

   From:
	B. If a Next Layer Protocol has only one selector, e.g.,
         Mobility Header type, then that field is placed in the
         Local "port" selector, and the Remote "port" selector is
         set to OPAQUE, e.g.,

   To:
	B. If a Next Layer Protocol has only one selector, e.g.,
         Mobility Header type, then that field is placed in the
         Local "port" selector in the relevant SPD entry, and the
	Remote "port" selector is set to OPAQUE in the relevant
	SPD entry, e.g.,

==============================================================================
24. Mark Duffy

Name isn't really a selector like local or remote address.

   4.4.1.1  Selectors -- modified Name section to indicate it's not
   really a selector

   From:
	- Name: A name may be used as a symbolic identifier for an
	  IPsec Local or Remote address. Named SPD entries are used
	  in two ways:

   To:
	- Name:  This is not a selector like the others above.  It
	  is not acquired from a packet. A name may be used as a
	  symbolic identifier for an IPsec Local or Remote address.
	  Named SPD entries are used in two ways:

   4.4.1.2  Structure of an SPD entry

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

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

==============================================================================
25. Mark Duffy

4.4.2.1 Data Items in the SAD -- Added Bypass DF bit and Bypass DSCP to SAD

	o Bypass DF bit (T/F) - applicable to tunnel mode SAs

	o Bypass DSCP (T/F) or map to unprotected DSCP values (array)
	if needed to restrict bypass of DSCP values - applicable to
	tunnel mode SAs

==============================================================================
26. Mark Duffy

5.1.1  Handling an Outbound Packet That Must Be Discarded -- 
generalized the first case.

   From:
	b1. The IPsec system\was unable to set up the SA required
	    by the SPD entry matching the packet because the IPsec
	    peer at the other end of the exchange is administratively
	    prohibited from communicating with the initiator.

   To:
	b1. The IPsec system successfully reached the remote peer
	    but was unable to negotiate the SA required by the SPD
	    entry matching the packet, e.g., because the remote
	    peer is administratively prohibited from communicating
	    with the initiator, or the initiating peer was unable to
	    authenticate itself to the remote peer, or the remote peer
	    was unable to authenticate itself to the initiating
	    peer, or no suitable SA could be negotiated with the remote
	    peer, etc..

==============================================================================
27. Mark Duffy

5.1.2 Header Construction for Tunnel Mode, 4th bullet -- clarified 
that "DS field" is "outer DS field."

   From:
	o IPsec offers certain controls to a security administrator
	to manage covert channels (which would not normally be a
	concern for tunneling) and to ensure that the receiver
	examines the right portions of the received packet re:
	application of access controls. An IPsec implementation MAY
	be configurable with regard to how it processes the DS field
	for tunnel mode for transmitted packets. For outbound
	traffic, one configuration setting for the DS field will
	operate as described in the following sections on IPv4 and
	IPv6 header processing for IPsec tunnels. Another will allow
	the DS field to be mapped to a fixed value, which MAY be
	configured on a per SA basis. (The value might really be
	fixed for all traffic outbound from a device, but per SA
	granularity allows that as well.) This configuration option
	allows a local administrator to decide whether the covert
	channel provided by copying these bits outweighs the
	benefits of copying.

   To:
	o IPsec offers certain controls to a security administrator
	to manage covert channels (which would not normally be a
	concern for tunneling) and to ensure that the receiver
	examines the right portions of the received packet re:
	application of access controls. An IPsec implementation MAY
	be configurable with regard to how it processes the outer
	DS field for tunnel mode for transmitted packets. For outbound
	traffic, one configuration setting for the outer DS field will
	operate as described in the following sections on IPv4 and
	IPv6 header processing for IPsec tunnels. Another will allow
	the outer DS field to be mapped to a fixed value, which MAY be
	configured on a per SA basis. (The value might really be
	fixed for all traffic outbound from a device, but per SA
	granularity allows that as well.) This configuration option
	allows a local administrator to decide whether the covert
	channel provided by copying these bits outweighs the
	benefits of copying.

==============================================================================
28. Mark Duffy

7.2 Separate Tunnel Mode SAs for Non-Initial Fragments, paragraph 1, 
next to last sentence.  Clarified the motivation:

   From:
	Also, because an SA of this sort will carry ALL non-initial
	fragments that match a specified Local/Remote address pair
	and protocol value, users and administrators are advised to
	protect such traffic using ESP (with integrity) and the
	"strongest" integrity and encryption algorithms available
	at both peers.

   To:
	Also, an SA of this sort will carry ALL non-initial
	fragments that match a specified Local/Remote address pair
	and protocol value, i.e., the fragments carried on this SA
	belong to packets that, if not fragmented, might have gone
	on separate SAs of differing security. Therefore users and
	administrators are advised to protect such traffic using
	ESP (with integrity) and the "strongest" integrity and
	encryption algorithms in use between both peers.

==============================================================================
29. Mark Duffy

2.1 Goals/Objectives/Requirements/Problem Description, first 
paragraph, last sentence.  Changed:

   From:
	These services are provided at the IP layer, offering
	protection for all protocols that may be carried over IP
	in a standard fashion (including IP itself).

   To:
	These services are provided at the IP layer, offering
	protection in a standard fashion for all protocols
	that may be carried over IP (including IP itself).

==============================================================================
30. Mark Duffy

4.4.1.1  Selectors, section on Remote IP Address and section on Local 
IP Address -- Changed "each a trivial ranges" to "each a trivial 
range"

==============================================================================
31. Mark Duffy

4.4.1.1  Selectors, section on Remote IP address -- changed last 
sentence of paragraph:

   From:
	Address ranges are used to support more than one destination
	system sharing the same SA, e.g., behind a security gateway.

   To:
	Address ranges are used to support more than one remote
	system sharing the same SA, e.g., behind a security gateway.

==============================================================================
32. Mark Duffy

4.4.2.1 Data Items in the SAD
   From:
	o Sequence Number Counter: a 64-bit used to generate
	the Sequence Number field in AH or ESP headers. 64-bit sequence
	numbers are the default, but 32-bit sequence numbers are also
	supported if negotiated.

   To:
	o Sequence Number Counter: a 64-bit counter used to generate
	the Sequence Number field in AH or ESP headers. 64-bit sequence
	numbers are the default, but 32-bit sequence numbers are also
	supported if negotiated.

============================================================================
33. Mark Duffy

5.2 Processing Inbound IP Traffic (unprotected-to-protected), step 3b 
-- inserted the word "cache" into last sentence below:

   From:
	3b. If the packet is not addressed to the device or is
	    addressed to this device and is not AH or ESP, look up
	    the packet header in the (appropriate) SPD-I cache. If
	    there is a match and the packet is to be discarded or
	    bypassed, do so. If there is no cache match, look up
	    the packet in the corresponding SPD-I and create a
	    cache entry as appropriate. (No SAs are created in
	    response to receipt of a packet that requires IPsec
	    protection; only BYPASS or DISCARD entries can be
	    created this way.).....

   To:
	3b. If the packet is not addressed to the device or is
	    addressed to this device and is not AH or ESP, look up
	    the packet header in the (appropriate) SPD-I cache. If
	    there is a match and the packet is to be discarded or
	    bypassed, do so. If there is no cache match, look up
	    the packet in the corresponding SPD-I and create a
	    cache entry as appropriate. (No SAs are created in
	    response to receipt of a packet that requires IPsec
	    protection; only BYPASS or DISCARD cache entries can be
	    created this way.).....

============================================================================
34. Mark Duffy

Clarified which header info is checked upon receipt for ICMP error messages:

   6.2 Processing Protected, Transit ICMP Error Messages, paragraph 4,
   first sentence:

   From:
	If an SA exists that accommodates an outbound ICMP error
	message, then the message is mapped to the SA and only
	the ICMP header is checked upon receipt, just as would
	be the case for other traffic....

   To:
  	If an SA exists that accommodates an outbound ICMP error
	message, then the message is mapped to the SA and only
	the IP and ICMP headers are checked upon receipt, just
	as would be the case for other traffic....

   6.2 Processing Protected, Transit ICMP Error Messages, paragraph 6,
   first sentence:

   From:
	If an IPsec implementation receives an inbound ICMP error
	message on an SA, and the header of the message does not
	match the traffic selectors for the SA, the receiver MUST
	process the received message in a special fashion.

   To:
	If an IPsec implementation receives an inbound ICMP error
	message on an SA, and the IP and ICMP headers of the message
	do not match the traffic selectors for the SA, the receiver
	MUST process the received message in a special fashion.

============================================================================
35. Mark Duffy

Remove some inconsistencies re: fragmenting outbound packets

   5.1 Outbound IP Traffic Processing (protected-to-unprotected) --
   deleted 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 match rules only
	having port (or ICMP message type and code, or MH type)
	selectors of OPAQUE or ANY. (See section 7 for more details.)

   7. Handling Fragments (on the protected side of the IPsec boundary)
   -- deleted first sentence

   From:
	Earlier sections of this document describe mechanisms for
	(a) fragmenting an outbound packet after IPsec processing
	has been applied and reassembling it at the receiver before
	IPsec processing and (b) handling inbound fragments received
	from the unprotected side of the IPsec boundary.  This
	section describes how an implementation should handle the
	processing of outbound plaintext fragments on the protected
	side of the IPsec boundary. (See Appendix D for discussion
	of Fragment Handling Rationale.) In particular, it addresses:

   To:
	This section describes how an implementation should handle the
	processing of outbound plaintext fragments on the protected
	side of the IPsec boundary. (See Appendix D for discussion
	of Fragment Handling Rationale.) In particular, it addresses:

============================================================================
36. Mark Duffy

7.2 Separate Tunnel Mode SAs for Non-Initial Fragments, paragraph 3
-- corrected first sentence:

   From:
	Note: In general, for approach 2, one needs only a single
	SA between two implementations to carry all non-initial
	fragments....

   To:
	Note: In general, for the approach described in this
	section, one needs only a single SA between two
	implementations to carry all non-initial fragments....

============================================================================
37. Mark Duffy

7. Handling Fragments (on the protected side of the IPsec boundary),
paragraph 2 -- added sentence clarifying the meaning of 
a"non-trivial" selector value.

   From:
	Note: In Section 4.1, transport mode SAs have been defined
	to not carry fragments (IPv4 or IPv6).  Note also that in
	Section 4.4.1, two special values, ANY and OPAQUE, were
	defined for selectors and that ANY includes OPAQUE.

   To:
	Note: In Section 4.1, transport mode SAs have been defined
	to not carry fragments (IPv4 or IPv6).  Note also that in
	Section 4.4.1, two special values, ANY and OPAQUE, were
	defined for selectors and that ANY includes OPAQUE. The term
	"non-trivial" is used to mean that the selector has a value
	other than OPAQUE or ANY.

============================================================================
38. Mark Duffy

13. Differences from RFC 2401 -- Deleted the following claim.  It's 
in AH and ESP.
	o A definition of reserved SPIs has been added.

============================================================================
39. Mark Duffy

5.2 Processing Inbound IP Traffic (unprotected-to-protected), step 3a 
-- clarified when to discard the packet.

   From:
	3a. If the packet is addressed to the IPsec device and AH
	or ESP is specified as the protocol, the packet is looked
	up in the SAD. For unicast traffic, use only the SPI (or
	SPI plus protocol). For multicast traffic, use the SPI
	plus the destination or SPI plus destination and source
	addresses, as specified in section 4.1.  If there is no
	match, discard the traffic....

   To:
	3a. If the packet is addressed to the IPsec device and AH
	or ESP is specified as the protocol, the packet is looked
	up in the SAD. For unicast traffic, use only the SPI (or
	SPI plus protocol). For multicast traffic, use the SPI
	plus the destination or SPI plus destination and source
	addresses, as specified in section 4.1.  In either case
	(unicast or multicast), if there is no match, discard the
	traffic....

============================================================================
40 BBN

6.1.1 ICMP Error Messages Received on the Unprotected Side of the Boundary

   From:
	If an ICMP PMTU message passes the checks above and the
	system is configured to accept it, then it should be
	processed as described in Section 8.2.

   To:
	If an ICMP PMTU message passes the checks above and the
	system is configured to accept it, then there are two
	possibilities. If the implementation applies fragmentation
	on the ciphertext side of the boundary, then the accepted
	PMTU information is passed to the forwarding module
	(outside of the IPsec implementation) which uses it to
	manage outbound packet fragmentation. If the implementation
	is configured to effect plaintext side fragmentation, then
	the PMTU information is passed to the plaintext side and
	processed as described in Section 8.2.

============================================================================
41 BBN

5.1 Outbound IP Traffic Processing (protected-to-unprotected), Figure 2
5.2 Processing Inbound IP Traffic (unprotected-to-protected), Figure 3
-- added note to the SPD caches in both diagrams indicating:

	(*) = The SPD caches are shown here. If there
               is a cache miss, then the SPD is checked.
               There is no requirement that an
               implementation buffer the packet if
               there is a cache miss.

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

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 25 Oct 2004 07:11:51 -0700

Because the Internet Drafts queue is probably jammed right now, this 
draft is available as 
<http://www.vpnc.org/ietf-ipsec/TEMP-draft-ietf-ipsec-rfc2401bis-04.txt>. 
That link will go away when the draft is officially published.

--Paul Hoffman, Director
--VPN Consortium