Subject: I-D ACTION:draft-ietf-ipsec-rfc2401bis-00.txt

From: [email-masked]
Date: Fri, 24 Oct 2003 10:49:06 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.

	Title		: Security Architecture for the Internet Protocol
	Author(s)	: S. Kent
	Filename	: draft-ietf-ipsec-rfc2401bis-00.txt
	Pages		: 71
	Date		: 2003-10-23
	
This memo specifies the base architecture for IPsec compliant
   systems.  The goal of the architecture is to provide various security
   services for traffic at the IP layer, in both the IPv4 and IPv6
   environments.  This document describes the goals of such systems,
   their components and how they fit together with each other and into
   the IP environment.  It also describes the security services offered
   by the IPsec protocols, and how these services can be employed in the
   IP environment.  This document does not address all aspects of IPsec
   architecture.  Subsequent documents will address additional
   architectural details of a more advanced nature, e.g., use of IPsec
   in NAT environments and more complete support for IP multicast.  The
   following fundamental components of the IPsec security architecture
   are discussed in terms of their underlying, required functionality.
   Additional RFCs (see Section 1.3 for pointers to other documents)
   define the protocols in (a), (c), and (d).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipsec-rfc2401bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipsec-rfc2401bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Mike Taylor" <[email-masked]>
Date: Thu, 30 Oct 2003 08:23:00 -0800

Hi All,

Some comments about the 2401bis draft.

Section 4.4.1 The Security Policy Database

		"...In order to support this, the SPD requires
		distinct entries for inbound and outbound traffic."

	and a few paragraphs later

	   "- each SPD entry is a list of 1 or more selector set pairs - each
	   selector set pair consists of one selector set for the SA from the
	   initiator to the receiver and one selector set for the SA from the
	   receiver to the initiator."

	I don't understand (maybe because I don't yet understand IKE very well)
this
	second paragraph, especially given the prior sentence which indicates
	that the SPD entries for inbound and outbound are separate, as they
	were in 2401.  The second paragraph seems to suggest that an SPD
	entry is bidirectional.  What am I missing?

Section 4.4.2 Selectors

	Still requires that both SPD entries and SAs carry selectors,
	and still requires separate SAD entries for ESP and AH, so that
	if I have a incoming datagram which must be processed through both
	AH and ESP then I can't really make any use of the selectors in the
	AH SA because until the datagram has also gone through ESP the
	selectors are opaque.  From a practical implementation standpoint
	I certainly don't want to waste memory (in my embedded system)
	on information I can't use.

	And of course the RFC mandates that that after processing
	through the SAs the selectors in the datagram must be matched against
	the SPD entry:

	5. IP Traffic Processing

	   As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
	   the SPD must be consulted during the processing of all traffic
	   (INBOUND and OUTBOUND), including non-IPsec traffic.

	Why, if I really have the selectors stored in SAs, would I do this
	on the inbound side in particular?

	Not to mention the wasted CPU cycles matching the packet against
	selectors in the SA and then doing it again for an SPD entry.

	On the outbound side I have to match against the SPD 1st and then
	I guess I could conceivably have multiple SA bundles that have
	different selectors that could match the same policy based on the
	following from 4.4:

	   "For each selector, the policy entry specifies how to derive the
	   corresponding values for a new Security Association Database (SAD,
	   see Section 4.4.3) entry from those in the SPD and the packet (Note
	   that at present, ranges are only supported for IP addresses; but
	   wildcarding can be expressed for all selectors):

           a. use the value in the packet itself -- This will limit use of
the...."

	So I could look through that list to find the right one to use.  But that
would
	suggest some sort of best-fit matching which isn't mentioned anyplace, or,
	I could use the 1st matching SA bundle that I find, BUT, this would seem to
	require that the SAD also support total ordering of entries and only the
	SPD is required to support total ordering that way.

In summary, should any of these requirements, in particular the need to
allow
specification of how selectors for SAs get inherited from SPD entries,
really be
requirements?

Should it even really be a requirement to have separate SAD and SPD entries?
Couldn't adequate security and interoperability be achieved without this
requirement?

I guess I'm just begging for simplification.  Let's focus on getting the
true requirements for good security and interoperability spelled out very
clearly, and not keep all these implementation details from 2401 in 2401bis.
For small embedded systems its essential to clearly spell out the the
requirements rather than implementation details as there is always a desire
to conserve memory and CPU resources in such systems and yet be able to
comply
with the functionality that is truly required.  Please don't assume that
everyone
who implements code per RFCs is only interested in multi-user systems and
high-end workstations.

- Mike Taylor

---

From: Stephen Kent <[email-masked]>
Date: Fri, 31 Oct 2003 13:26:21 -0500

>	entry is bidirectional.  What am I missing?

the first sentence should not have use the term "entries." the 
inbound and outbound traffic distinction is covered by the 
initiator/responder distinction i the entry.

>	on information I can't use.

Each SPD entry must contain selector values because that is how one 
searches for the right SPD entry. The SAD contains values for extant 
SAs, and we put selector values there because we need to check 
inbound traffic to ensure consistency with the selector values 
negotiated during SA establishment.

In Ikev1, you could establish two SAs at once, for the special case 
of AH + ESP.  IKEv2 removed this special case feature, so now two SAs 
must be negotiated separately. the only way you can nest the two SAs, 
and thus apply both AH and ESP, is via creation and processing for 
both SAs. As noted in the revised processing model, nesting requires 
careful configuration of both the SPD and the forwarding tables, to 
cause the traffic to pass through IPsec processing twice, for both 
outbound and inbound processing.

Frankly, the question I would ask is why (when) do you plan to use 
both AH & ESP? Given the current capabilities of ESP, we don't tend 
to see a need to use both.

>	on the inbound side in particular?

this text is left over from 2401 and needs to be updated. it should 
now refer to SPD caches as the first place to look for outbound 
traffic, with reference to the SPD only if the packet cannot be 
matched to the cache. for inbound IPsec traffic, one matches against 
the relevant SAD entry. for other inbound traffic, match against the 
inbound cache, and look at the inbound SPD only if there is a miss.

<SNIP>

>specification of how selectors for SAs get inherited from SPD entries,

I though we had done that, but if not, we will make it clear in the next rev.

>Couldn't adequate security and interoperability be achieved without this

No. think of the SPD as the reference database that describes all 
possible SAs that might be created, whereas the SAD and SPD caches 
represent the SAs that have been created.

>who implements code per RFCs is only interested in multi-user systems and

we don't make those assumptions, but we do require that all 
implementations interoperate, and that they provide users with a 
uniform, minimum set of management capabilities for access control.

Steve

---

From: "Mike Taylor" <[email-masked]>
Date: Fri, 31 Oct 2003 17:34:18 -0800

Hi Steve,

Thanks for your response.  I think it clarifies some
things but I'm still not clear on some points.
See below.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stephen Kent
> Sent: Friday, October 31, 2003 10:26 AM
> To: Mike Taylor
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-ipsec-rfc2401bis-00.txt
>
>

I think what you're saying here is that there will no longer be
separate inbound and outbound policy databases?  Then much more
of 2401bis needs major rewriting.  Is this being imposed by changes
to IKE in IKEv2?  I am finding having the separate policies for
inbound and outbound very useful for debugging during development.
And I can even see an argument for one-way policies in general,
for example, perhaps some kind of remote sensor.  Who knows?
And of course, pragmatically its far too late to change my current
design now.  I have separate policies.  But I'm not really doing
an IPsec v3 implementation anyway.  I was only looking to 2401bis
to clarify some of the confusion I found in 2401.

> searches for the right SPD entry.

If SAs all have selectors one can envision having an outbound SA
cache and 1st searching the SA cache before bothering to look at
the SPD.  After all, this would generally reduce the amount of
time wasted looking at the SPD which is primarily used to create
new SAs but presumably the creation of new SAs occurs far less frequently
than the transmission of a datagram in most systems.

Am I missing something?

> The SAD contains values for extant

But in my implementation I have back pointers from all SAs to
the policy that spawned them.  So when I'm done processing an
inbound datagram through an SA the SA knows where to find the
policy that contains the selectors.  So unless this inheritance of
selectors by SAs provides some required functionality from a blackbox
perspective (improved security and/or interoperability) that cannot
be achieved just as well with multiple policies it seems like one
could just as well only have selectors in SPD entries and none in
SAs, thereby possibly saving significant RAM for a small system
especially with 128-bit IPv6 addresses.

> to see a need to use both.

Well, the problem from my perspective is that 2401 has so much
implementation
detail that it is very hard for me remain clear on what are requirements
and what are just suggestions.  For example, see 4.5 Basic Combinations
of Security Associations.  It shows the case of ESP in AH in transport mode
and begins with the sentence:

	"This section describes four examples of combinations for security
	associations that MUST be supported by compliant IPsec hosts or
	security gateways."

Aside from that, I've seen other references to the fact that since ESP
doesn't authenticate the IP header AH may still be useful for that purpose.
I'm a programmer, not an IT person.  I don't really know what people think
is useful on the real world and I don't have much marketing input.  So
I try to conform to the RFC's requirements.  If ESP in AH isn't useful
then the 2401bis should certainly make it clear that it isn't a required
basic SA combination.

> now refer to SPD caches

SPD caches?  Another implementation detail?

> as the first place to look for outbound

From 2401bis:

   For each selector, the policy entry specifies how to derive the

Now that I re-read this again I see that the keyword MUST is indeed missing
from
the above sentence.  My apologies.  I'm actually rather aggravated by this
since
I guess I've been under the impression for some time that this was a
requirement.
Clearly that is my own fault, but its very easy to become confused when
there
is such a mix of informal implementation suggestions/hints mixed in
intimately
with actual requirements.