Subject: Re: [Ipsec] rfc2401bis-06: why ESP and AH SPIs are not considered as (potential) selectors?

From: Stephen Kent <[email-masked]>
Date: Wed, 11 May 2005 14:11:30 -0400

At 3:43 PM +0300 4/29/05, Pekka Nikander wrote:
>Folks,
>
>This has probably been discussed in the death before, but I was
>not able to find the answer in the archives.  Consequently, I'd
>appreciate if someone would enlighten me, perhaps by pointing out
>to the relevant thread of previous discussion.  Please note too
>that this question is more due to academic/architectural curiosity
>rather than that I would be implementing this.
>
>Anyway, while reading rfc2401bis-06 with fresh eyes, I was left
>wondering why aren't the AH and ESP SPI fields considered as
>selectors, similar to TCP/UDP ports, ICMP types/codes, and MH
>message types?  Such support looks trivial to me (but perhaps
>I am missing something), and would make supporting the (admittedly
>dubious) nested SAs much easier.  In other words, if my 2401bis
>implementation would route back outgoing IPsec packets to the protected
>side and then again out, then how do I select the right enclosing
>SA for it unless I can use the SPI?  Likewise, if I receive an
>incoming packet that contains an AH or ESP header after IPsec
>processing, how to I enforce anything on the SPIs before passing
>it again out for nested processing?
>
>So, what is the reason for the current state?

It is the stated intent of IPsec to offer simple, stateless firewall 
access control for traffic (see sections 2.1, 4.4.1, & 5). The 
selectors we defined years ago in 2401 match this intent. We 
augmented the list to accommodate ICMP type/code values and mobility 
header message types in 2401, to better accommodate handling of these 
packet types, but the concept is still the same.  SPIs have no 
counterpart in firewall rules and thus do not match the firewall 
model.

Also, IPsec does not require that the SPD be dynamic. Vendors are 
free to offer dynamic SPD management options in products, e.g., to 
better support protocols like FTP, but this is not mandated. 2401/bis 
notes that adding such functionality may cause interoperability 
problems, depending on what additional features are locally 
supported.  Because SPI's generally are created dynamically, and 
because an SPI for an outbound SA is created by the peer, support for 
them would imply dynamic SPD management, inconsistent with the 
premises I mentioned above.

You are correct that nesting  requires an ability to configure a 
combination of SPD entries and forwarding table entries that will 
cause outbound and inbound packets to be "looped." We gave an example 
of an SPD configuration that supported nesting in an appendix that 
shows how one might accomplish this, and it did not require use of 
SPI's as traffic selectors. Use of SPIs as traffic selectors could 
facilitate nesting, if they were also used in the forwarding tables, 
but this would require dynamic SPD management.

As to your last question, for a nested SA, after processing the outer 
layer of IPsec protection, the SA would be configured to require the 
next IPsec layer (e.g., AH or ESP), and would have port field 
selectors set to ANY. Then the plaintext side forwarding tables would 
have to be configured so that the now visible S/D addresses and the 
protocol called for bypass, vs. delivery to a higher layer protocol 
or to a host behind an SG.

Steve

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