Subject: [Mobike] Issue 70: Non-SAD updates (was: 51 - spi collisions)

From: <[email-masked]>
Date: Sun, 6 Nov 2005 20:24:30 +0200

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
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Sun, 06 Nov 2005 20:33:42 +0100

=> I agree but the intersection between 41 and 70 is not void.

=> yes, this is very implementation dependent so the specs should
provide no details, but should say something as it is in fact needed...

   
=> 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
   
=> to find the peer addresses is IMHO a part of step 1.

=> oops. The term "initial contact" meant something else for me.

   
=> yes, my concern is the step 1 has to be done so there are some infos
somewhere which must be updated by MOBIKE.

=> this is a way to solve the issue

=> s/will/shall/ ? BTW it is more a SA pair but I agree the text is
more readable as it is.

   

=> the last sentence is loose enough to make MIPv6 to work (:-)!

=> IMHO here we have to explain why, i.e., this IP address has to be
updated when it changes.

Regards

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