SPI collision Re: FW: Tuomas Aura's review of draft-ietf-mobike-protocol-03

Mohan Parthasarathy writes:
> Tero,
> 
> > >Comment 4: 
> > >
> > >IPsec SAs are identified by the <destination IP address, SPI> pair.
> > >Normally, these identifiers are unique for inbound SAs destination
> > >host is responsible for allocating the SPIs and for outbound SAs
> > >because the destination address identifies a unique host. In
> > >Mobike, the latter is no longer true. That is, identifier
> > >collisions may occur for outbound SAs at the responder.
> > 
> > ESPv3 the IPsec SA is identified by the SPI alone for the unicast SAs.
> > There is no destination IP address threre anymore. Implementations are
> > allowed to use SPI and IPsec protocol type also.
> > (draft-ietf-ipsec-esp-v3-10.txt section 2.1).
> > 
> Yes, but that concerns inbound processing. Here we are talking about outbound
> processing i thought.

Ups, I seem to have read the question too quickly.

> Are you saying that this problem cannot happen ? The I1 and I2 are
> two different hosts and they *can* choose the same SPI. When R is
> sending packets to I1 or I2, it does not use the SPI for lookup. It
> uses the selectors from the packet to lookup the SA. The selectors
> are unique (they are still I1 plus whatever the policy requires)
> even after I1 moves to A2. But this leads to two SAs with the same
> SPI.

Same outbond SPI, so that is not a problem.

> This should not cause any problem (in theory) because you never
> lookup this SA directly. You always lookup the SPD which points to
> the SA. But there are implementations (e.g. Linux) where this can
> cause problems if you update an SA that will result in the same
> values (dest address, SPI, protocol) as another SA. So, can you
> clarify ?

When you are sending packets outbound you do lookup from SPD-S based
on the selectors (I1 or I2) and you get SA based on that. Then in the
SA there is the SPI and destination IP to be used for the other end.
Then you simply make tunnel encapsulation and send the packet along. I
do not really see what is the problem there?

So we have case where we have I1 and I2 using addresses A1 and A2
talking to the R and both have selected same SPI for the IPsec SA. Now
if I2 disappears i.e. does not send IKE SA delete to destroy the IKE
SA and the IPsec SA. If the I1 happens to get the same IP-address A2
in the local link, and sends UPDATE_IP_ADDRESSES to the R, we can have
that situation. Note, that this I1 must get A2 before DPD notices that
I2 is dead to this happen. As R uses selectors I1 and I2 to search
from the SPD-S and the SPD-S will then point to the SA, there should
be no problem for the R to send packets out.

The I1 will discard those packets R sends which have keying material
for the I2, and after a while R will start DPD for the I2 IKE SA and
delete it as it does not see any traffic for it.

When finding the SA based on the selectors we match those selectors
against SPD-S, which have the exact selectors based on the SPD and the
PFP flags (populate from packet), so there should not be problem even
when they are using same PFP SPD rule.

The case where we have multiple IKE SAs with the same IP address is
already happening without MOBIKE, in case of NAT-T.

The 4.4.2 of the RFC2401bis says:
...
   For outbound processing, each SAD entry is pointed to by entries
   in the SPD-S part of the SPD cache.
...

The section 4.4.1 describes the SPD-S:
...
       - SPD-S: For traffic that is to be protected using IPsec, the
         entry consists of the values of the selectors that apply to the
         traffic to be protected via AH or ESP, controls on how to
         create SAs based on these selectors, and the parameters needed
         to effect this protection (e.g., algorithms, modes, etc.). Note
         that an SPD-S entry also contains information such as "populate
         from packet" (PFP) flag (see paragraphs below on "How To Derive
         the Values for an SAD entry") and bits indicating whether the
         SA lookup makes use of the local and remote IP addresses in
         addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
         specifications).
...

Does that (correctly) answer the (correct) question?
-- 
[email protected]