Subject: [anonsec] rfc2401bis-06: Why there are no names in SAs?

From: kent at bbn.com (Stephen Kent)
Date: Wed, 11 May 2005 14:34:01 -0400

At 3:57 PM +0300 4/29/05, Pekka Nikander wrote:
>[Excuse for cross-posting; followups to ipsec only.]
>
>Folks,
>
>While reading rfc2401bis-06 for considering BTNS, I came up
>with one serious architectural question.  At this point of time
>I don't know if this really relates to BTNS or not, but it seems
>to have some larger relevance in any case.
>
>The essence of this question boils down to the nature of IP
>addresses.  While reading rfc2401bis, it becomes apparent that
>it is very much build around the model that the IP addresses
>used by different hosts are considered to be stable, or at least
>divisible into different security classes in a static manner.
>While that may be fine for most if not all current purposes of
>IPsec, I am afraid that the Internet in general is moving away
>from that notion.

The SPD initially supported static IP addresses well, and names only 
minimally, via ambiguous wording in 2401. This was motivated by the 
fact that we knew how to deal with addresses well, and we did not 
have a clear picture how to handle names.

>However, in addition to the selectors based on this world view,
>the SPD and PAD also have now support for "names", mainly
>meant to be used in situations where at least one of the IPsec
>devices is an end-host (rather than a security gateway).  The
>support for these higher-layer, symbolic identifiers seems to
>be sufficient for key management and outgoing traffic.  What
>seems to be especially good is the use of names in linking PAD
>and SPD entries together (end of section 4.4.3.4).

it is not true that we assume that one end of an SA is a host when 
names are used in lieu of addresses for both ends. However, it is 
fair to say that the primary motivation for supporting names was road 
warriors, even in 2401. 2401 lacked a description of how key 
management (e.g., IKE) and the SPD were to be linked. This was an 
oversight, caused by the fact that two different groups of folks 
worked on each set of documents and there was a rush to get the 
documents out at the end of the process.

In 2401bis we addressed this linkage, motivated in part by the 
ongoing work in the pki4ipsec WG. The PAD is needed whether we use 
symbolic names or static IP addresses to identify peers. In either 
case there has to be a way to express the notion of what set of IDs 
is a peer authorized to represent. These IDs can be names or IP 
addresses, depending on how we will match the ID against the SPD. We 
considered additional uses for names in the PAD, and rejected them 
due to complexity arguments. For example, an SG might have symbolic 
names for source addresses for hosts behind it, but then it would 
have to have a secure way to link the names to the addresses it sees 
in packets.  Given the lack of DNSSEC deployment, DHCP security, etc, 
we didn't think it was appropriate to mention this sort of 
functionality.

>What seems to be missing is support for incoming traffic.

All inbound protected traffic arrives via an SA, and the creation of 
the SA is the time at which we deal with ID and authorization issues.

>More specifically, what I am missing is either
>
>    a) names embedded in (inbound) SAD entries, or

The data in an (inbound) SAD entry is used to manage the processing 
of the arriving packet. Since an IP packet carries addresses, but not 
names, it does not seem appropriate to put a name in an SAD entry.

>    b) back pointers from (inbound) SAD entries to
>       corresponding SPD entries

in 2401 we talked about the need to examine the SPD to match received 
traffic against the selectors associated with an SA. This was one of 
the most complex aspects of inbound traffic processing, the one that 
generated the most questions. 2401bis adopted a decorrelated SPD in 
part to avoid this complexity, and as a result did away with any need 
to provide a back pointer to the SPD for either inbound or outbound 
SAD entries.

>If either of them were in place, that would allow incoming
>packets to be tagged with names.  Those names could then,
>optionally, be available to apps above.

In a host environment this is true, but is is not meaningful for an 
SG. Might there not be other ways to offer these names to an app? 
Also, in the absence of an API, it's hard to decide where one might 
maintain this info, to make it available.

>Furthermore, and probably more importantly, tagging
>the SAs with names would make it also easier to handle
>with potential stale SAs as the SPD is dynamically
>changed.

In my response to your message about why we do not use SPIs as 
selectors, I noted that the SPD is not assumed to be dynamic. So, 
when one starts to talk about dynamic SPD changes, one is moving away 
from the base IPsec model. One might choose to do this, but the IPsec 
WG avoided embracing this sort of complexity for many years, so one 
should be careful when considering such a fundamental change.

>Now, is there a specific reason why the (inbound) SAD
>entries are not tagged/linked with their corresponding
>SPD entries?

As noted above, the SAD has no need for such links, now that 
decorrelation is a fundamental aspect of the processing model.

Steve