Subject: RE: [Mip6] question: SA update in dynamic keying scenario

From: "Shinta Sugimoto (TO/NRJ)" <[email-masked]>
Date: Fri, 26 Nov 2004 21:08:10 +0800

Dear Francis,

Thank you for your comments.  Please find my comments/questions inline.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Friday, November 26, 2004 1:47 AM
> To: Shinta Sugimoto (TO/NRJ)
> Cc: [email-masked]'
> Subject: Re: [Mip6] question: SA update in dynamic keying scenario 
> 
> 
>  In your previous mail you wrote:
> 
>    However, I could not find clear description of how IPsec 
> SAs (particularly
>    tunnel mode SA pairs required to protect RR signals and 
> user traffic)
>    should be managed.  My question is, "*who* is responsible 
> for updating
>    /re-establishing IPsec SA in dynamic keying scenarios upon MN's
>    movement ?"  Should MIPv6 always be responsible for updating the
>    endpoint address of the tunnel mode SA (as it does in manual keying
>    scenario) ?  Or IKE daemon should run phase 2 negotiation 
> to establish
>    new IPsec SA ?
> 
> => MIPv6 is responsible of the update of the SAD and the SPD. If you'd
> like to make this by IKE you should go to the Mobike WG, not 
> the Mip6 one.

I am not trying to make a big change to IKE(v1).  Just would like to know
what the correct interpretation of the spec is.  More comments below.

>    When we discussed this issue with MIPv6 implementators from
>    Linux and BSD community, we saw disparity of interpretation.
>    (Some people say that MIPv6 should always be the one who updates
>    tunnel endpoint, and some people say IKE daemon should re-establish
>    IPsec SA in dynamic keying scenario)
> 
> => IKE cannot know what to do if the SPD is not updated.

There is no doubt that SPD should be updated by MIPv6.  But then
I believe that normal IKE daemon can be kicked by the acquire message
since there is no appropriate SA entry.  (from performance perspective,
updating SADB by MIPv6 is far better than running IKE, of course)

BTW, assuming that MIPv6 is totally responsible for updating SPD/SADB
when the MN performs movement, I wonder what would the benefit of
supporting K-bit be ?  Is it just for saving bytes of message exchanges
required for phase 1 negotiation ?  It seems to me that K-bit capability
does not improve latency nor minimize packet drop during the movement.
Is my understanding correct?

Regards,
Shinta

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Fri, 26 Nov 2004 14:29:09 +0100

I am not trying to make a big change to IKE(v1).  Just would like to know
   what the correct interpretation of the spec is.

=> so you'd like to keep MIPv6...

   > => IKE cannot know what to do if the SPD is not updated.
   
   There is no doubt that SPD should be updated by MIPv6.

=> note this is enough: when a packet matches a SPD entry requiring
IPsec protection, if there is no suitable SA it will be established
(cf. outgoing processing, PF_KEY acquire and of course IKE).

   But then
   
=> I agree. SPD update is mandatory, SAD is not but is highly recommended
(better performance, no dangling SA).

   supporting K-bit be ?

=> with IKEv1 K=1 is fine for rekeying: when K=0 the idea is to have a
short phase 1 in order to just setup the needed SAs. When K=1 the phase 1
can be kept as it is reusable in the long term.
With IKEv2 IPsec SAs are managed and the IKE SA should be long term so
K=1 is really needed (i.e., it is no more a marginal optimization).
BTW to implement K=1 is very easy: IKE should keep a correct image of
the SPD so when the SPD/SAD is updated IKE should be noticed by a message.
In this message IKE can get the info (i.e., all the addresses).

   Is it just for saving bytes of message exchanges
   required for phase 1 negotiation ?

=> it is a bit more. Phase 1 adds a lot of delay, a movement can occur
just at the bad time, etc. In fact K=1 simply gives more reliable
operations.

   It seems to me that K-bit capability
   does not improve latency nor minimize packet drop during the movement.
   Is my understanding correct?
   
=> if you reduce movement to home registration you're right. But MIPv6
is supposed to be more.

Regards

[email-masked]

PS: more offline and with some delay?