Subject: RE: [Ipsec] re-authentication in IKEv2

From: "Bora Akyol \(bora\)" <[email-masked]>
Date: Mon, 23 May 2005 10:36:03 -0700

Having dealt with the separation of IKE and IPSEC SAs in 
IKEv1, I am rather attached to the grouping of IKE and its
child SAs as an atom.

Therefore, I would be strongly opposed to decoupling these one
more time.

So if we come up with a reauth mechanism that involves
a new IKE SA, then we should be able to find a way to transfer
IPSEC SAs.

Regards
Bora

> -----Original Message-----
> From: Yoav Nir [mailto:[email-masked]]
> Sent: Monday, May 23, 2005 10:33 AM
> To: Bora Akyol (bora)
> Cc: [email-masked]; [email-masked];
[email-masked]
> Subject: Re: [Ipsec] re-authentication in IKEv2
> 
> They're erased automatically.  There is no provision (yet) for
> transferring them to the new IKE SA.
> 
> It is an idea for an addition to the re-authentication draft. I don't
> see how we could add it without making a new notification type, which
> may complicate things, so I don't know if it's a good trade-off in
> terms of complexity vs efficiency.
> 

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 May 2005 09:40:48 +0300

I think the obvious solution is a new notification type in the INFO 
exchange that is used to delete the old IKE SA. This payload would say 
that the child SAs of this SA are transferred to the ownership of the 
specified IKE SA.

The reason I'm hesitant to propose this, is that such a notification 
will cause an interoperability problem - what if the other side does 
not know how to transfer child SAs, or does not support this extension 
at all?  You could solve this by requiring the responder to reply with 
the same payload if it understands the message, and if the responder 
does not, delete the SA.  I suppose the format would be something like 
this:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ! Next Payload  !C!  RESERVED   !      Payload Length=24        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !  Protocol ID  !  SPI Size=8   !   Notify Message Type=???     !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                   NEW SPI_I                                   !
       !                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       !                   NEW SPI_R                                   !
       !                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And the exchange can be something like this:
        Initiator                        Responder
       -----------                      -----------
        HDR, SK {[D] [XFER]} -->
                                    <-- HDR, SK {[D] [XFER]}

I'm still not sure it's worth it in terms of complexity vs efficiency.  
I think the typical case for re-authentication is the client-gateway 
(AKA road-warrior) case. I think that it would be very rare for such 
cases to have many child SAs.  In fact, now that we have the ability to 
support complex traffic selectors, a single child SA will be very 
common, and that single child SA can be negotiated within the new AUTH 
exchange. Even if a few more SAs are needed, it only takes two IKE 
messages to set up an SA.