Re: Issue 70: Non-SAD updates (was: 51 - spi collisions)

Francis Dupont wrote:

>    Presumably, the process is something like this:
>    
>      1. Determine the right peer for the IPsec SA
>      2. Determine whether we have an active IKE_SA with this peer
>      3. If not, create an IKE_SA 
>      4. Create the IPsec SA using CREATE_CHILD_SA exchange 
>         (possibly piggybacked in IKE_AUTH if we needed a new IKE_SA)
>    
> => I agree. 1 is only for outgoing traffic in all implementations
> I know but it doesn't matter (if the policies are symmetrical the
> other peer will establish the SAs, if they are not this is an error).
> 
>    The text I quoted above basically says steps 1 and 2 are beyond
>    the scope of 2401bis (and IMHO also MOBIKE).
> 
> => I disagree about step 1 which is in the scope of 2401bis (only).
>
>    Step 3 is discussed in Section 3.1 of MOBIKE draft (basically,
>    finding out the peer addresses is beyond the scope), and step 4
>    should be very simple.
>    
> => to find the peer addresses is IMHO a part of step 1.

IMHO at least some parts of step 1 are beyond the scope of 2401bis
(e.g. Section 4.4.3.4 says "RFC 2401 and 2401bis do not specify how A
determines the address of the IKE peer serving X.")  On the other
hand, 2401bis does not specify that exactly these four steps must be
done in this order, so it's a matter of taste how you want to describe
it... 

<snip>

>       Some implementations are known to use a single IP address as an
>       identifier for the right peer in steps 1 and 2 (in which case
>       step 3 becomes trivial). This approach may complicate the
>       implementation of MOBIKE; however, these implementation details
> 
> => IMHO here we have to explain why, i.e., this IP address has to 
> be updated when it changes.

Hmm... actually the text I proposed was not quite right. Using a
single IP address as the sole identifier for the right peer simply
doesn't work correctly, since an IP address does not uniquely identify
a peer (for similar reasons as in issue 51).  More likely, it has to
also take into account information in the PAD etc..

How about rephrasing the last paragraph to something like this?

   When performing these steps, implementations may use information
   contained in the SPD, the PAD, and possibly some other
   implementation-specific databases.  Regardless of how exactly the
   steps are implemented, it is important to remember that IP
   addresses can change, and that an IP address alone does not always
   uniquely identify a single IKE peer (for the same reasons as why
   the combination of the remote IP address and SPI does not uniquely
   identify an outbound IPsec SA; see Appendix A.1).  Thus, in steps 1
   and 2 it may be easier to identify the "right peer" using its
   authenticated identity instead of its current IP address.  However,
   these implementation details are beyond the scope of this
   specification.
  
Best regards,
Pasi