Subject: RE: [Ipsec] IPsec 2401bis changes

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 23 Mar 2005 01:53:59 -0800

Hi Karen,

There is another small update we may have missed. 

I had raised an issue with the DSCP processing and in private mails
between the AD's, Brian Carpenter, Stephen Kent, David Black as well as
me we had come to a conclusion.

One of the mails in the thread is 
http://www1.ietf.org/mail-archive/web/ipsec/current/msg01172.html

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Karen Seo
Sent: Wednesday, March 23, 2005 12:06 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Barbara Fraser; Theodore
Ts'o; Russ Housley; [email-masked]
Subject: [Ipsec] IPsec 2401bis changes

[Folks -- I sent a multi-colored version of the email below to the 
list.  Unfortunately, it's "being held until the list moderator can 
review it for approval" because the "Message body is too big".  I'm 
assuming this is due to the use of color.  So I'm re-sending the 
email in black/white.  Apologies if you receive both versions.]

Russ,

Below are the changes that we believe have been agreed upon to 
address (a) recent issues brought up on the mailing list, (b) the 
comments at: 
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&
ballot_id=1544&filename=draft-ietf-ipsec-rfc2401bis, 
and (c) other IDSG feedback. We have incorporated these changes into 
a new draft and submitted it to the IETF secretariat.  Please let us 
know if you have any questions.

Thank you,
Karen

Issues in IDSG tracker:
========================================================================
====

1.1. Harald Alvestrand, Brian Carpenter

>4.1 Definition and Scope
...
>    If different classes of traffic (distinguished by Differentiated
>    Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
the
>    same SA, and if the receiver is employing the optional anti-replay
>    feature available in both AH and ESP, this could result in
>    inappropriate discarding of lower priority packets due to the
>    windowing mechanism used by this feature.  Therefore a sender
SHOULD
>    put traffic of different classes, but with the same selector
values,
>    on different SAs to support QoS appropriately.  To permit this, the
>    IPsec implementation MUST permit establishment and maintenance of
>    multiple SAs between a given sender and receiver, with the same
>    selectors.  Distribution of traffic among these parallel SAs to
>    support QoS is locally determined by the sender and is not
negotiated
>    by IKE. The receiver MUST process the packets from the different
SAs
>    without prejudice.

I think it would be helpful to remind readers that (as indicated
in RFC 2983) we are talking here about the "inner" DSCP in a tunnel,
which will not be changed en route (since in general, the DSCP
value may be changed en route and that destroys the model described,
since there would be no fixed relationship between DSCP value and SA).

	Per agreement with Brian, we added the following text at the
	end of the above paragraph.

	These requirements apply to both transport and tunnel mode
	SAs. In the case of tunnel mode SAs, the DSCP values in
	question appear in the inner IP header. In transport mode,
	the DSCP value might change en route, but this should not
	cause problems with respect to IPsec processing since the
	value is not employed for SA selection and MUST NOT be
	checked as part of SA/packet validation. However, if significant
         re-ordering of packets occurs in an SA, e.g., as a result of
	changes to DSCP values en route, this may trigger packet
         discarding by a receiver due to application of the anti-replay
         mechanism.

------------------------------------------------------------------------
---
1.2. Harald Alvestrand, Brian Carpenter

>I also note that there is no reference to the IPv6 Flow Label. Since
this
>is an e2e field (RFC 3697) it would actually be easier to handle than
the
>DSCP, if there was any need to do so.

	After discussion, we agreed to wait for some experience with
	flow label usage before trying to craft language. No change
	was made.

------------------------------------------------------------------------
---
1.3. Harald Alvestrand, Brian Carpenter

>>4.4.2.1 Data Items in the SAD
>...
>>     o Bypass DF bit (T/F) - applicable to tunnel mode SAs

Note that this only applies to IPv4 (ditto section 8.1).

	We changed the text to be:

	4.4.2.1 Data Items in the SAD
	....
	o Bypass DF bit (T/F) - applicable to tunnel mode SAs where
	both inner and outer headers are IPv4.

	8.1 DF Bit

	All IPsec implementations MUST support the option of
	copying the DF bit from an outbound packet to the tunnel mode
	header that it emits, when traffic is carried via a tunnel
	mode SA. This means that it MUST be possible to configure the
	implementation's treatment of the DF bit (set, clear, copy
	from inner header) for each SA. This applies to SAs
	where both inner and outer headers are IPv4.

------------------------------------------------------------------------
---
1.4. Harald Alvestrand, Brian Carpenter

>>4.4.2.1 Data Items in the SAD
>...
>>     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

This is unclear to me and needs some explanation. Actually, it's
unclear how the earlier suggested treatment of DSCPs works,
since the DSCP value(s) corresponding to an SA aren't stored anywhere
that I noticed, so the model does not allow for demultiplexing on
DSCP values in any case.

	Per agreement with Brian, we added the following text:

       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. This feature maps DSCP values from an inner header
	to values in an outer header, e.g., to address covert channel
	signalling concerns.

       o DSCP values: the set of DSCP values allowed for packets
	carried over this SA. If no values are specified, no
	DSCP-specific filtering is applied. If one or more values
	are specified, these are used to select one SA among several
	that match the traffic selectors for an outbound packet.
	Note that these values are NOT checked against inbound
	traffic arriving on the SA.

------------------------------------------------------------------------
---
1.5. Vishwas Manral and David Black (as part of above discussion with 
Brian Carpenter)

	See item 1.1 above.  The last sentence was added which says
	"However, if significant re-ordering of packets occurs in an
	SA, e.g., as a result of changes to DSCP values en route,
	this may trigger packet discarding by a receiver due to
	application of the anti-replay mechanism."

------------------------------------------------------------------------
---
2.1. Ted Hardie (and elsewhen Brian Carpenter)

This seems to have a mix of RFC 2026 and RFC 3668 boilerplates.

	We believe we've addressed this.  The document passes the
	checks done by the idnits tool.

------------------------------------------------------------------------
---
2.2. Ted Hardie:

In Section 4.1, the draft says:

In many secure multicast (or anycast) architectures, e.g., [RFC3740],
a central Group Controller/Key Server unilaterally assigns the Group
Security Association's (GSA's) SPI.

3740 does not seem to mention anycast.  Is there a similar reference
for anycast?

	There isn't any RFC for secure anycast. We removed the
	"(or anycast)" from the above text and all other instances
         of anycast have been deleted. We really do not have appropriate
	provisions to support anycast, since the MSEC WG addresses only
         multicast.

------------------------------------------------------------------------
---
2.3. Ted Hardie:

Section 4.4.1 uses 192.168 addresses, rather than the example prefix
192.0.2.x/24

	Replaced all 192.168.2.y with 192.0.2.x.

------------------------------------------------------------------------
---
2.4. Ted Hardie:

I found the use of "road warrior" in section 4.5.2 distracting.

	Deleted the "(road warrior)" from Section 4.5.3 Locating
	a Security Gateway, paragraph 2:

	"Consider a situation in which a remote host (SH1) is
	using the Internet to gain access to a server or other
	machine (H2) and there is a security gateway (SG2),
	e.g., a firewall, through which H1's traffic must pass. An
	example of this situation would be a mobile host (road
	warrior) crossing the Internet to his home organization's
	firewall (SG2)."

------------------------------------------------------------------------
---
3.1. Sam Hartman:

[issue 1]

	Added at the end of Section 3.3 (Where IPsec Can Be Implemented)

	A host implementation of IPsec may appear in devices that might
	not be viewed as "hosts." For example, a router might employ
	IPsec to protect routing protocols (e.g., BGP) and management
	functions (e.g., Telnet), without affecting subscriber traffic
	traversing the router. A security gateway might employ separate
	IPsec implementations to protect its management traffic and
	subscriber traffic. The architecture described in this document
	is very flexible. For example, a computer with a full-featured,
	compliant, native OS IPsec implementation should be capable of
	being configured to protect resident (host) applications and to
	provide security gateway protection for traffic traversing the
	computer. Such configuration would make use of the forwarding
	tables and the SPD selection function described in Sections
	5.1 and 5.2.

	Added the following text to the beginning of section 11
	(Security Considerations)

	IPsec imposes stringent constraints on bypass of IP header data
	in both directions across the IPsec barrier, especially when
	tunnel mode SAs are employed. Some constraints are absolute,
	while others are subject to local administrative controls,
	often on a per-SA basis. For outbound traffic, these
	constraints are designed to limit covert channel bandwidth. For
	inbound traffic, the constraints are designed to prevent an
	adversary who has the ability to tamper with one data stream
	(on the unprotected side of the IPsec barrier) from adversely
	affecting other data streams (on the protected side of the
	barrier). The discussion in Section 5 dealing with processing
	DSCP values for tunnel mode SAs illustrates this concern.

------------------------------------------------------------------------
---
3.2. Sam Hartman:

[issue 2]

	We changed 4.4.1.1 Selectors paragraphs re: Name as follows.

	Added a sentence to the paragraph re: named entry used by an
	initiator:

	"Support for this use is optional for multi-user, native host
	implementations and not applicable to other implementations.
	Note that this name is used only locally; it is not
	communicated by the key management protocol.  Also,
	name forms other than those used for case 1 above (responder)
	are applicable in the initiator context (see below)."

	Altered the examples given for the types of names as shown
below:

	"For case 1, responder, the identifiers employed in named
	SPD entries are one of the following four types:

         a. a fully qualified user name string (email), e.g.,
            [email-masked]
            (this corresponds to ID_RFC822_ADDR in IKEv2)

         b. a fully qualified DNS name, e.g.,
            foo.example.com
            (this corresponds to ID_FQDN in IKEv2)

         c. X.500 distinguished name, e.g.,
	   C = US, SP = MA
            O = BBN Technologies, CN = Stephen T. Kent
            (this corresponds to ID_DER_ASN1_DN in IKEv2, after
            decoding)

          d. a byte string
            (this corresponds to Key_ID in IKEv2)

  	For case 2, initiator, the identifiers employed in named SPD
	entries are of type byte string.  They are likely to be Unix
	UIDs, Windows security IDs or something similar, but could
	also be a user name or account name. In all cases, this
         identifier is only of local concern and is not transmitted."

	Modified the ASN.1 as shown below:

	NameSets ::= SEQUENCE {
           passed      SET OF Names-R,     -- Matched to IKE ID by
responder
           local       SET OF Names-I }    -- Used internally by IKE
initiator

	Names-R ::= CHOICE {                     -- IKEv2 IDs:
           dName       DistinguishedName,     -- ID_DER_ASN1_DN
           fqdn        FQDN,                  -- ID_FQDN
           rfc822      [0] RFC822Name,        -- ID_RFC822_ADDR
           keyID       OCTET STRING }         -- KEY_ID

	Names-I ::= OCTET STRING          -- Used internally by IKE
initiator

------------------------------------------------------------------------
---
3.3. Sam Hartman:

[issue 3]

	Per discussione with Sam Hartman, we modified Section 4.4.1.1
	re: Name by re-ordering the components of the distinguished
	name as shown below and adding a Normative reference for
	RFC 2253:

         From:

		c. X.500 distinguished name, e.g.,
		   C = US, SP = MA,
		   O = BBN Technologies,
		   CN = Stephen T. Kent

		   (this corresponds to ID_DER_ASN1_DN in IKEv2, after
		   decoding)

	To:

		c. X.500 distinguished name, e.g., [WaKiHo97],
		   CN = Stephen T. Kent, O = BBN Technologies,
		   SP = MA, C = US

		   (this corresponds to ID_DER_ASN1_DN in IKEv2, after
		   decoding)

	Added:

	[WaKiHo97] Wahl, M., Kille, S., Howes, T., "Lightweight
	Directory Access Protocol (v3): UTF-8 String Representation
	of Distinguished Names", RFC 2253, December 1997

------------------------------------------------------------------------
---
3.4. Sam Hartman:

[issue 4]

	Addressed Sam's concerns in email exchange -- no change was
made.

------------------------------------------------------------------------
---
3.5. Sam Hartman:

[issue 5]

	Per discussion, we added the following text to
		- Section 4.4.2 Security Association Database (SAD)
		  at the end of paragraph 2.
		- Section 5 IP Traffic Processing, paragraph 1:

	Note also, that there are a couple of situations in which the
	SAD can have entries for SAs that do not have corresponding
	entries in the SPD. Since 2401bis does not mandate that the
	SAD be selectively cleared when the SPD is changed, SAD
	entries can remain when the SPD entries that created them
	are changed or deleted. Also, if a manually keyed SA is
	created, there could be an SAD entry for this SA that does
	not correspond to any SPD entry.

	And changed Section 4.4.1, paragraph on "How To Derive the
	Values for an SAD entry"

	From:

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

	To:

	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 Section 4.4.2).

	And added two footnotes to Figure 3 to clarify where the
         SAD's role as an SPD inbound

        (**) = This processing includes using the packet's SPI, etc
	       to look up the SA in the SAD, which forms a cache of
	       the SPD for inbound packets (except for cases noted
	       in Sections 4.4.2 and 5) - see step 3a below.
         (***) = This SAD check refers to step 4 below.

------------------------------------------------------------------------
---
3.6. Sam Hartman:

[Issue 6]

	Changed the text of Section 5.2 by taking the first paragraph
	after step 4 and turning it into step 5 and un-indenting the
	2nd and 3rd paragraphs after step 4 so that they are NOT part
	of the processing steps:

	From:

	4. Apply AH or ESP processing as specified, using the SAD entry
	   selected in step 3a above.  Then match the packet against
	   the inbound selectors identified by the SAD entry to verify
	   that the received packet is appropriate for the SA via which
	   it was received.

	   If an IPsec system receives an inbound packet on an SA and
	   the packet's header fields are not consistent with the
	   selectors for the SA, it MUST discard the packet......

	   To minimize the impact of a DoS attack, or a mis-configured
	   peer, the IPsec system SHOULD include a management control
	   to allow an administrator to configure ....

	   After traffic is bypassed or processed through IPsec, it is
	   handed to the inbound forwarding function for disposition...

	To:

	4. Apply AH or ESP processing as specified, using the SAD entry
	   selected in step 3a above.  Then match the packet against
	   the inbound selectors identified by the SAD entry to verify
	   that the received packet is appropriate for the SA via which
	   it was received.

	5. If an IPsec system receives an inbound packet on an SA and
	   the packet's header fields are not consistent with the
	   selectors for the SA, it MUST discard the packet......

	To minimize the impact of a DoS attack, or a mis-configured
	peer, the IPsec system SHOULD include a management control
	to allow an administrator to configure ....

	After traffic is bypassed or processed through IPsec, it is
	handed to the inbound forwarding function for disposition...

------------------------------------------------------------------------
---
3.7. Sam Hartman:

[Issue 7]

	We added the following text to Section 7.4

	As noted above, in network configurations where fragments of
	a packet might be sent or received via different security
	gateways or BITW implementations, stateful strategies for
	tracking fragments may fail.

------------------------------------------------------------------------
---
3.8. Sam Hartman:

[Issue 8]

	Inserted new PAD text into section 4.4.3 replacing previous
	text.  Added a reference for (IKEv1 (RFC2409) by Harkins and
         Carrel).

------------------------------------------------------------------------
---
3.9. Sam Hartman:

[Issue 9]

	The ASN.1 has been modified to compile as is. So the problem
	text at the top of the appendix has been replaced with text
	saying that this code compiles. Changes included:

	Replaced DistinguishedName with RDNSequence

	Changed ANY DEFINED BY to ANY -- DEFINED BY algorithm....

	Checked for any duplicate tags

------------------------------------------------------------------------
---
3.9. Sam Hartman:

[No issue number assigned]

Section 6.1.2 creates requirements for incoming ICMP packets on the
protected side of the IPsec boundary.  As best I can tell the attacks
described in that section are potential problems for any Internet
gateway and have nothing to do with IPsec.  If so, why should the
IPsec architecture add requirements for additional administrative
controls to mitigate these attacks?  (I think the administrative
controls are a good idea; I'm just unsure why this specification is
the right place for them.)

	Based on discussion, no changes were made.

------------------------------------------------------------------------
---
3.10 Sam Hartman:

[No issue number assigned]

	Section 4.5.3 Locating a Security Gateway.  Since the
	IPSP working group was just closed, the last 2 sentences of
	this section were deleted.  The corresponding text in Section
	13. "Differences from RFC 2401" was also deleted.

	"The IP Security Policy (IPSP) Working Group is a possible
	future source of guidance. One of its goals is to produce an
	Internet Draft on a "Security Gateway Discovery, Policy
	Exchange and Negotiation Protocol".

------------------------------------------------------------------------
---
4.1. Russ Housley:

   When will the module identifier be assigned for Appendix C?
   If you want IANA to do it, then it needs to be called out in
   the IANA Considerations section.

	There is currently no IPsec arc (just the ISAKMP and IKE arcs)
	So we requested one from IANA and we changed Section 12. IANA
	Considerations

	From:

	This document has no actions for IANA.

	To:

	This document contains a "magic" number to be maintained by
	the IANA. Upon approval of this draft for publication as an
	RFC, IANA is to create a registry for ASN.1 Modules under
	the Prefix:

         iso.org.dod.internet.security.mechanisms.ipsec (1.3.6.1.5.5.8)

	In Appendix C "ASN.1 for an SPD Entry", the number assigned
	to the ASN.1 Modules registry is to replace the xx
	corresponding to the asn1\(hymodules and the object
	identifier assigned to spd\(hymodule is to replace the "yy"
	for the spd\(hymodule.

------------------------------------------------------------------------
---
4.2. Russ Housley:

   Section 4.1:
   s/Memory (TCAM0 features/Memory (TCAM) features/

   Section 4.4.1:
   s/SPD-SPD-S, SPD-SPD-I, SPD-SPD-O/SPD-S, SPD-I, SPD-O/
   s/The SPD-SPD-S/The SPD-S/

   Section 4.4.2:
   s/Database(SAD),/Database (SAD),/

   Section 8.2.1:
   s/SAD entry When/SAD entry. When/

	The above changes have been made.

------------------------------------------------------------------------
---
4.3. Russ Housley:

In making the other changes to the document, you added the 
"addresses" element to the "TunnelOptions" structure.  You forgot the 
comma after "DF" when this change was made.  Here is an ASN.1 module 
that compiles (using the 1990 syntax).

	Updated ASN.1 module (Appendix C)

------------------------------------------------------------------------
---
5.1. Alex Zinin:

Discuss:

How does the in/out-bound processing model defined in section 5 work 
in the case
of a VPN gateway? In particular, how does presence of multiple routing
realms
and a two-stage forwarding process affect it (imagine a gw that uses
dynamic
routing over the VPN tunnels protected by IPsec transport mode as
encapsulated
packets leave the box)? What about locally-originated messages, such as
routing
messages in this case. I know how to make it work, the question is how
the
described model addresses these scenarios.

	We answered Alex's questions.  No change was made.

------------------------------------------------------------------------
---
5.2. Alex Zinin:

Section 4.4 Major IPsec Databases:

>     Forwarding vs Security Decisions
>        The IPsec model described here embodies a clear separation
between
>        forwarding (routing) and security decisions, to accommodate a
wide
>        range of contexts where IPsec may be employed. Forwarding may
be
>        trivial, in the case where there are only two interfaces, or it
>        may be complex, e.g., if there are multiple protected or
>        unprotected interfaces or if the context in which IPsec is
>        implemented employs a sophisticated forwarding function.

minor note: complexity of forwarding doesn't depend directly on the
number of
local interfaces.

	We deleted "if there are multiple protected or unprotected
	interfaces or" so that the text now says:

      Forwarding vs Security Decisions
	The IPsec model described here embodies a clear separation
	between forwarding (routing) and security decisions, to
	accommodate a wide range of contexts where IPsec may be
	employed. Forwarding may be trivial, in the case where there
	are only two interfaces, or it may be complex, e.g., if the
	context in which IPsec is implemented employs a sophisticated
	forwarding function.

------------------------------------------------------------------------
---
5.3. Alex Zinin:

>        IPsec assumes only that outbound and inbound traffic that has
passed
>        through IPsec processing is forwarded in a fashion consistent
with
>        the context in which IPsec is implemented.

What does the above statement really mean?

	We answered Alex's question in email exchange.  No change was
made.

------------------------------------------------------------------------
---
5.4. Alex Zinin:

Though Appendix E is not normative, I should note that it is rather
confusing.
Specifically, though the document states that no changes to the
forwarding
function are introduced, the appendix mentions two different forwarding
tables--one for protected, and one for unprotected side. Also, the
representation of the forwarding tables themselves creates an impression
that
routes usually include both source and destination prefixes, which 
clearly isn't
true (unless we're talking about a special case of policy-based 
routing). Again,
I know how to make it work, but I don't think the doc is very good at 
explaining
this.

	We answered Alex's questions in email exchange.  No change was
made.

========================================================================
====
Per discussion with Russ Housley, the following changes were made to 
address various issues brought up on the IPsec mailing list:

	Re: handling multicast:

	Section 4.4.1.1, added the text below after the paragraphs on
	remote and local IP address(es).

	Note: The SPD does not include support for multicast address
	entries. To support multicast SAs, an implementation should
	make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD
	entries require a different structure, i.e., one cannot use
	of the symmetric relationship associated with local and
	remote address values for unicast SAs in a multicast context.
	Specifically, outbound traffic directed to a multicast address
	on an SA would not be received on a companion, inbound SA with
	the multicast address as the source.

	Section 4.4.2, added the following text after the 2nd paragraph:

	Note: The SAD  can support multicast SAs, if manually
	configured. An outbound multicast SA has the same structure
	as a unicast SA. The source address is that of the sender
	and the destination address is the multicast group address.
	An inbound, multicast SA must be configured with the source
	addresses of each peer authorized to transmit to the
	multicast SA in question. The SPI value for a multicast SA
	is provided by a multicast group controller, not by the
	receiver, as for a unicast SA. Because an SAD entry may be
	required to accommodate multiple, individual IP source
	addresses that were part of an SPD entry (for unicast SAs),
	the required facility for inbound, multicast SAs is a
	feature already present in an IPsec implementation. However,
	because the SPD has no provisions for accommodating
	multicast entries, this document does not specify an
	automated way to create an SAD entry for a multicast,
	inbound SA. Only manually configured SAD entries can be
	created to accommodate inbound, multicast traffic.

	Section 4.4.1.1, the 2 paragraphs on Remote and Local
	IP Address(es) -- references to "multicast group" were removed.
------------------------------------------------------------------------
---
	Re: handling ECN or DS

	Section 5.2.2, replaced the bullet

       o IPsec describes how to handle ECN or DS.

	with

       o IPsec describes how to handle ECN and DS and provides the
	ability to control propagation of changes in these fields
	between unprotected and protected domains. In general,
	propagation from a protected to an unprotected domain is a
covert
	channel and thus controls are provided to manage the bandwidth
of
	this channel. Propagation of ECN values in the other direction
	are controlled so that only legitimate ECN changes (indicating
	occurrence of congestion between the tunnel endpoints) are
	propagated.  By default, DS propagation from an unprotected
	domain to a protected domain is not permitted.  However, if the
	sender and receiver do not share the same DS code space, and the
	receiver has no way of learning how to map between the two
	spaces, then it may be appropriate to deviate from the default.
	Specifically, an IPsec implementation MAY be configurable in
	terms of how it processes the outer DS field for tunnel mode for
	received packets. It may be configured to either discard the
	outer DS value (the default) OR to overwrite the inner DS field
	with the outer DS field.  If offered the discard vs. overwrite
	behavior MAY be configured on a per SA basis. This
	configuration option allows a local administrator to decide
	whether the vulnerabilities created by copying these bits
	outweigh the benefits of copying.  See [RFC 2983] for further
	information on when each of these behaviors may be useful, and
	also for the possible need for diffserv traffic conditioning
	prior or subsequent to IPsec processing (including tunnel
	decapsulation).

	In 5.1.2.2, changed the the header construction table for DS
	Field, so that the column for the decapsulator says

	"no change" (9)

	and added note 9:

	9. An implementation MAY choose to provide a facility to pass
	the DS value from the outer header to the inner header, on a
	per SA basis, for received tunnel mode packets. The motivation
	for providing this feature is to accommodate situations in
	which the DS code space at the receiver is different from that
	of the sender and the receiver has no way of knowing how to
	translate from the sender's space. There is a danger in
	copying this value from the outer header to the inner header,
	since it enables an attacker to modify the outer DSCP value in
	a fashion that may adversely affect other traffic at the
	receiver.  Hence the default behavior for IPsec implementations
	is NOT to permit such copying.

------------------------------------------------------------------------
---
	Re: decorrelated vs not-decorrelated SPD and what is passed
	between peers to negotiate an SA.  Also re: addressing the
	mis-alignment of the semantics of IKEv2 with those of the SPD

	Section 4.4.1, Decorrelation subsection, deleted last 4
	sentences of 2nd paragraph:

	"Note also that if a decorrelated SPD is employed, the original
	entry from the (correlated) SPD should be retained and passed
	to the SA management protocol, e.g., IKE. Passing the
	correlated SPD entry to the SA management protocol keeps the
	use of a decorrelated SPD a local matter, not visible to peers.
	When acting as a responder, the peer uses a correlated SPD
	entry for matching, and for issuing a "narrowed" response.
	Then the decorrelated entries are used to populate the SPD-S
	cache."

	and replaced them with the following 5 paragraphs:

	If a decorrelated SPD is employed, there are three options for
	what an initiator sends to a peer via an SA management
	protocol (e.g., IKE). By sending the complete set of linked,
	decorrelated entries that were selected from the SPD, a peer
	is given the best possible information to enable selection
	of the appropriate SPD entry at its end, especially if the
	peer has also decorrelated its SPD. However, if a large number
	of decorrelated entries are linked, this may create large
	packets for SA negotiation, and hence fragmentation problems
	for the SA management protocol.

         Alternatively, the original entry from the (correlated) SPD
	may be retained and passed to the SA management protocol.
	Passing the correlated SPD entry keeps the use of a
	decorrelated SPD a local matter, not visible to peers, and
	avoids possible fragmentation concerns, although it provides
	less precise information to a responder for matching against
	the responder's SPD.

	An intermediate approach is to send a subset of the complete
	set of linked, decorrelated SPD entries. This approach can
	avoid the fragmentation problems cited above and yet provide
	better information than the original, correlated entry. The
	major shortcoming of this approach is that it may cause
	additional SAs to be created later, since only a subset of
	the linked, decorrelated entries are sent to a peer.
	Implementers are free to employ any of the approaches cited
	above.

	A responder uses the traffic selector proposals it receives
	via an SA management protocol to select an appropriate entry
	in its SPD. The intent of the matching is to select an SPD
	entry and create an SA that most closely matches the intent
	of the initiator, so that traffic traversing the resulting SA
	will be accepted at both ends. If the responder employs a
	decorrelated SPD, it SHOULD use the decorrelated SPD entries
	for matching, as this will generally result in creation of SAs
	that are more likely to match the intent of both peers. If the
	responder has a correlated SPD, then it SHOULD match the
	proposals against the correlated entries.  For IKE v2, use of
	a decorrelated SPD  offers the best opportunity for a responder
	to generate a "narrowed" response.

	In all cases, when a decorrelated SPD is available, the
	decorrelated entries are used to populate the SPD-S cache. If
	the SPD is not decorrelated, caching is not allowed and an
	ordered search of SPD MUST be performed to verify that inbound
	traffic arriving on an SA is consistent with the access
	control policy expressed in the SPD.

	Section 4.4.1.2, 2nd paragraph.  Changed

	From:
	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. The management GUI can
	offer the user other forms of data entry and display.....

	To:

	This text describes the SPD in a fashion that is intended to
	map directly into IKE payloads to ensure that the policy
	required by SPD entries can be negotiated through IKE.
	Unfortunately, the semantics of the version of IKE v2 published
	concurrently with this document [Kau05] do not align precisely
	with those defined for the SPD. Specifically, IKE v2 does not
	enable negotiation of a single SA that binds multiple pairs of
	local and remote addresses and ports to a single SA. Instead,
	when multiple local and remote addresses and ports are
	negotiated for an SA, IKE v2 treats these not as pairs, but as
	(unordered) sets of local and remote values that can be
	arbitrarily paired. Until IKE provides a facility that conveys
	the semantics that are expressed in the SPD via selector sets
	(as described below), users MUST NOT include multiple selector
	sets in a single SPD entry unless the access control intent
	aligns with the IKE "mix and match" semantics. An
	implementation MAY warn users, to alert them to this problem
	if users create SPD entries with multiple selector sets, the
	syntax of which indicates possible conflicts with current IKE
	semantics.

	The management GUI can offer the user other forms of data
	entry and display...

Additional issue from the list
========================================================================
====
2/15/05 Atul Sharma brought up the case of two tunnels protecting the 
same addresses/hosts but with different tunnel endpoints...  To 
clarify matters, we  made the following changes.

	Section 4.4.3 Peer Authorization Database (PAD) -- modified
	the last bullet of paragraph 3 in the new PAD text.

	from:

	o peer gateway location info, e.g., an IP address or a DNS
	  name, MAY be included for peers that are known to be
	  "behind" a security gateway

	to:

	o peer gateway location info, e.g., IP address(es)
	  or DNS name(s), MAY be included for a peer that is known to
	  be "behind" a security gateway or gateways.

	and added the following sentence at the end of the section:

	Note that the PAD information MAY be used to support creation
	of more than one tunnel mode SA at a time between two peers,
	e.g., two tunnels to protect the same addresses/hosts, but
	with different tunnel endpoints.

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Mar 2005 10:30:42 -0500

Vishwas,

I suggest you search the message for the string "DSCP" to locate all 
of the new text that deals with this topic.  I believe the several 
changes we have made are consistent with the conclusions of the 
discussions we had on the topic with various parties.

Steve