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

Francis Dupont wrote:

>  In your previous mail you wrote:
> 
>    > => 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.
>    
>    Currently, it's beyond the scope of MOBIKE how the initial
>    contact is handled. Section 1.2 says:
>    
> => I don't speak about the initial contact but the case where
> there are many SPD entries requiring IPsec protection between
> the two peers and only some of them have active IPsec SA pairs.
> The peer addresses are somewhere in the SPD (this is highly
> implementation dependent) and this information must be updated.

(I created a new issue for this -- this is clearly different
from issue 51 where the IPsec SAs already exist)

In fact, 2401bis does not specify how the peer is determined
when an outgoing packet triggers the creation of an SA.
Section 4.4.3.4 writes:

   For example, assume that IKE A receives an outbound packet
   destined for IP address X, a host served by a security
   gateway. RFC 2401 and 2401bis do not specify how A determines the
   address of the IKE peer serving X. However, any peer contacted by
   A as the presumed representative for X must be registered in the
   PAD in order to allow the IKE exchange to be
   authenticated. Moreover, when the authenticated peer asserts that
   it represents X in its traffic selector exchange, the PAD will be
   consulted to determine if the peer in question is authorized to
   represent X.

In particular, there can be several peers that are allowed to
represent X (several different security gateways we could contact to
establish an SA for the triggering packet).

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)

The text I quoted above basically says steps 1 and 2 are beyond the
scope of 2401bis (and IMHO also MOBIKE). 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 come back to the main point, the peer addresses are dynamic and
> included somewhere in the SPD or the PAD. The way this is supported
> is very implementation dependent but the fact the information must be
> updatable by MOBIKE is not at choice.

Hmm.. as long as we agree that the inital contact (how to determine
addresses when establishing the IKE_SA) is beyond the scope of
MOBIKE (as Section 3.1 currently says), the question seems to be
just about steps 1 and 2 above, right?

But since 2401bis is not very light reading in this area, perhaps it
would be a good idea to mention that depending on exactly how those
unspecified steps are implemented, the implementation may be
affected by MOBIKE.

How about adding something like this to the "implementation
considerations" appendix?

A.2  Creating Outbound SAs

   When an outbound packet requires IPsec processing but no suitable
   SA exists, a new SA will be created. In this case, the host has
   to determine (1) who is the right peer for this SA, (2) whether
   the host already has an IKE_SA with this peer, and (3) if no
   IKE_SA exists, the IP address(es) of the peer for contacting it.

   Neither [IPsecArch] nor MOBIKE specifies how exactly these three
   steps are carried out. [IPsecArch] Section 4.4.3.4 says:

      For example, assume that IKE A receives an outbound packet
      destined for IP address X, a host served by a security
      gateway. RFC 2401 and 2401bis do not specify how A determines
      the address of the IKE peer serving X. However, any peer
      contacted by A as the presumed representative for X must be
      registered in the PAD in order to allow the IKE exchange to be
      authenticated. Moreover, when the authenticated peer asserts
      that it represents X in its traffic selector exchange, the PAD
      will be consulted to determine if the peer in question is
      authorized to represent X.  

   In step 1, there may be more than one possible peer (e.g.,
   several security gateways that are allowed to represent X).  In
   step 3, the host may need to consult a directory such as DNS to
   determine the peer IP address(es).

   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
   are beyond the scope of this specification.

Best regards,
Pasi