[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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.

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

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 ???

regards
Mukesh