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

 > 
> > 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.
> 
Yes, this is the case. Now, when R receives the
UPDATE_IP_ADDRESSES, it need to update the information
in SA about where the packets should be tunneled out.
How do you locate the SA to update its peer address ?
If you locate the SA based on peer SPI, destination
address and protocol (it does not matter how the peer
chose the SPI i.e it can be unique for the whole
system etc.), some implementation might have wrongly
assumed that it will be unique. As you point out
below, it does not work for NAT-T. So, you need a
different way to lookup the SA. I am merely *guessing*
that the original question was based on this. 

> 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.
> 
Yes, this is not an issue.
> 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.
> 
Agreed. This happens when there are two hosts (I1 and
I2) behind the SAME NAT establishing the SA with a
responder (R). If I1 and I2 picks the same SPI, then
the destination address (public address), SPI and
protocol as seen by the responder R will not be
unique.


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

Yes.

-mohan

> -- 
> [email protected]
>