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

 In your previous mail you wrote:

   > 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)
   
=> I agree but the intersection between 41 and 70 is not void.

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

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

   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.

   > 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

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

   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.
   
=> yes, my concern is the step 1 has to be done so there are some infos
somewhere which must be updated by MOBIKE.

   How about adding something like this to the "implementation
   considerations" appendix?
   
=> this is a way to solve the issue

   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

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

      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).
   
=> the last sentence is loose enough to make MIPv6 to work (:-)!

      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.

      are beyond the scope of this specification.
   
Regards

[email protected]