Subject: Re: [Mobike] 51 - spi collisions

From: <[email-masked]>
Date: Wed, 2 Nov 2005 13:24:48 +0200

Mohan Parthasarathy wrote:
 
> The text is too simple to help the readers understand the
> issue. At least providing an example (like the one given in Thomas
> mail) as a background before the suggested text might help read it
> better.

Here's a proposal for text:

Appendix A.  Implementation Considerations

A.1.  Links from SPD Cache to Outbound SAD Entries
   
   [IPsecArch] Section 4.4.2 says that "For outbound processing,
   each SAD entry is pointed to by entries in the SPD-S part of the
   SPD cache". The document does not specify how exactly this
   "pointing" is done, since this is an implementation detail that
   does not have to be standardized.

   However, it is clear that the links between the SPD cache and the
   SAD have to be done correctly to ensure that outbound packets are
   sent over the right SA. Some implementations are known to have
   problems in this area.

   In particular, simply storing the (remote tunnel header IP
   address, remote SPI) pair in the SPD cache is not sufficient,
   since the pair does not always uniquely identify a single SAD
   entry.  For instance, two hosts behind the same NAT can
   accidentally happen to choose the same SPI value.  The situation
   can also occur when a host is assigned an IP address previously
   used by some other host, and the SAs associated with the old host
   have not yet been deleted by dead peer detection.  This may lead
   to packets being sent over the wrong SA or, if the key management
   daemon ensures the pair is unique, denying the creation of
   otherwise valid SAs.

   Storing the remote tunnel header IP address in the SPD cache may
   also complicate the implementation of MOBIKE, since the address
   can change during the lifetime of the SA. Thus, we recommend
   implementing the links between the SPD cache and the SAD in a way
   that does not require modification when the tunnel header IP
   address is updated by MOBIKE. For instance, in the C programming
   language, an ordinary pointer could be used.

Any comments?

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Nov 2005 13:58:27 +0100

In your previous mail you wrote:

   Any comments?
   
=> I am afraid it is not enough: the link issue is not the only issue:
if the SPD has no indication of what are the new endpoint addresses
to use after an update, one cannot guarantee a new SA pair will be
create using the right addresses. So an update should impact something
somewhere in the SPD.

Regards

[email-masked]

PS: NAT-T and MIPv6 have the same issue. In NAT-T it is solved by
making the initiator always behind the NAT (so the address can "float"
as it is never used :-). In MIPv6 a solution is described in
draft-sugimoto-mip6-pfkey-migrate-01.txt and in the real world
an "unique" tag is used.
BTW a C pointer is not a good solution because there is no one-to-one
mapping between SPD and SAD.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 2 Nov 2005 15:23:02 +0200

>    language, an ordinary pointer could be used.

Fine by me.
-- 
[email-masked]

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 2 Nov 2005 09:33:51 -0800 (PST)

--- [email-masked] wrote:

>    can change during the lifetime of the SA. 
>Thus,
> we recommend
I would remove the last sentence. 

Otherwise looks good...

-mohan