Re: 51 - spi collisions

--- [email protected] wrote:

> 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.
> 
I would remove the last sentence. 

Otherwise looks good...

-mohan

> Any comments?
> 
> Best regards,
> Pasi
>