Re: draft-gupta-ospf-ospfv3-auth-01.txt

[Stephen Kent <kent@bbn.com>]

At 3:55 PM -0700 10/15/02, Mukesh Gupta wrote:
>  > The new text on how to demux SAs, that appeared in the revised ESP
>>  and AH IDs several months ago, does not appear to be consistent with
>>  what appears above, nor does that text appear to be consistent with
>>  the old demuxing text.
>>
>>  What we used to say was that one used the destination IP address,
>>  security protocol (AH or ESP) and the SPI to select an SA.  We
>>  realized that, except for multicast addresses, the destination
>>  address is not relevant to the demuxing, and that the security
>>  protocol was generally not needed, since the 32-bit SA is big enough
>>  to provide lots of SAs without using the protocol field.  So, the
>>  revised text now says that one looks only at the SPI for unicast
>>  traffic, and at the SPI and destination IP address  for multicast
>>  traffic.
>>
>>  There is no notion of per-interface SAD entries, only per-interface
>>  SPD entries. The text above seems to imply that the same SPI might be
>>  used for two different SAs, that are distinguished by the interfaces
>>  via which packets arrive. That is not consistent with the old or
>>  revised IPsec specs. Only if each interface has its own IPsec
>>  implementation would the description above seem to be consistent.
>
>Third paragraph of section 4.4 in RFC2401 says ..
>
>"Each interface for which IPsec is enabled requires nominally separate inbound
>vs. outbound databases (SAD and SPD), because of the directionality of many of
>the fields that are used as selectors."


Another list member pointed this out to me and I have to admit that 
this text does suggest that. However, the rest of the discussion of 
the SAD does not support this interpretation. The discussion of the 
SPI in 2401 and in the AH and ESP specs makes it pretty clear that 
the SPI must be generated on a device-unique basis, which is not 
consistent with the per-interface SAD interpretation. I'm sorry the 
text above was mislesding.
>
>Doesn't this mean that we have separate SAD *and* SPD for each 
>interface ?? With
>that assumption, our text is consistent with RFC2401. The 
>implementation can use
>the interface index to select the right SAD and then the protocol type and SPI
>can be used to locate a unique SA within that SAD.
>
>If there is no notion of per-interface SAD, SPI needs to be a unique 
>identifier
>to locate the SA because of the proposed sharing of SAs among all the OSPF
>neighbours.

Right, unless each interface was a complete IPsec implementation, as 
I suggested. Certainly if each line card, for example, has its own 
IPsec chip and software, there would be coordination among them and 
SPIs might well be duplicated. So, there is a notion of an IPsec 
"device" and SPIs are unique per device. If the device supports 
multiple interfaces, the the SPIs are unique across all of those 
interfaces.

>
>Please note:
>** No modifications in the way SAs are demuxed are required to 
>provide security
>to OSPFv3. **
>
>We are not proposing any modifications to the standard IPsec 
>processing. As long
>as the SPD has the rules specified in section 9, things will work with the
>current demuxing scheme (using protocol, SPI and destination addr) 
>as well as the
>future scheme (using just SPI).

OK.

>In the first version, we didn't have section 9 (IPsec rules). Section 7 was
>written to explain what selectors will be needed in the SPD but 
>looks like it is
>creating some confusion. Now as section 9 clearly dictates all the SPD rules
>required, I think, we can replace section 7 with the following text. (we are
>removing the text about the selectors and elaborating on the granularity)
>
>====
>7. SA Granularity
>
>The user MUST be given a choice to share the same SA among multiple 
>interfaces or
>using unique SA per interface.
>====
>
>Comments ???

In the process if revising 2401, we are trying to better address the 
issues of when routing is done relative to SA lookup and how 
interfaces or virtual interfaces fit into the processing model.

As for the text immediately above (section 7) if you want 
per-interface SAs, then you have to determine how they are different 
in terms that IPsec cares about. One model we have discussed is to 
invoke an abstract routing/forwarding function before the SPD lookup 
and have it return the ID of a virtual interface. then that ID would 
be used to select the appropriate SPD (which we all agree is 
per-interface) for SA selection. That, I think, would meet your 
requirements.

Steve