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

From: Mukesh Gupta <[email-masked]>
Date: Tue, 15 Oct 2002 16:49:19 -0700

The list server rejected this mail because of a minor change in my email
address.

-------- Original Message --------
Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt
Date: Tue, 15 Oct 2002 15:55:41 -0700
From: Mukesh Gupta <[email-masked]>
Organization: Nokia Networks
To: Stephen Kent <[email-masked]>
CC: Mukesh Gupta <[email-masked]>,Jean-Mickael Guerin
<[email-masked]>,[email-masked],
[email-masked],[email-masked]
References: <[email-masked]>
<[email-masked]>
<p0510031db9d0df010629@[128.89.88.34]>

> 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