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

[Stephen Kent <kent@bbn.com>]

At 4:57 PM -0700 9/25/02, Mukesh Gupta wrote:
>Hi Jean-Mickael,
>
>Thanks for the correction. You are right. Word OSPF needs to be removed from
>there. The new sentence should be
>"In the incoming path, protocol, SPI and ingress interface ID MUST be used
>to locate the SA to be applied."
>where the protocol can be ESP or AH.
>
>Check against the inbound policy linked to the SA should be done by the
>general IPsec implementation. I don't see anything that needs to be handled
>differently for OSPFv3. So, I think, we don't need to add anything about it
>in this draft.
>
>I will make the suggested correction in the next version of the draft.
>
>Cheers.
>Mukesh

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.

Steve