|Main Archive Page > Month Archives > ipsec archives|
Adding an empty REAUTH_SA notification in the original IKE_AUTH exchange
is a nice way to determine in advance of a reauth if both peers support
the protocol. It might be sufficient to only include it in the response
as is done with the CHILDLESS_IKE_SUPPORTED notification in
draft-nir-ipsecme-childless. For the sake of argument though, I could put
an empty REAUTH_SA notification in the original IKE_SA_INIT exchange and
accomplish the same thing. The essential change to avoid the SPI probe
that Yoav pointed out is that the REAUTH_SA notification be in the
IKE_AUTH exchange regardless of whether the initiator knows in advance
that the responder supports the protocol. At this point, including the
REAUTH_SA notification in the IKE_AUTH exchange seems like the right thing
to do and I like your suggestion too. I can use the peer protocol support
knowledge to disambiguate the following case:
If the response
does not include the REAUTH_SA notification it indicates that either
the responder does not recognize the IKE SA to be reauthenticated or
the responder does not support the REAUTH_SA notification.
I also think that the right thing to do is to make
draft-nir-ipsecme-childless a normative reference in my draft and
incorporate it's methods for making the IKE_AUTH exchange childless.
Yaron Sheffer <firstname.lastname@example.org> wrote on 10/06/2010 02:33:28 PM:
> Hi Keith,
> I think you can exchange the REAUTH notification in the *original*
> IKE_AUTH exchange (when you authenticate for the first time), probably
> with an empty notification data. This would let both peers know that
> they both support the protocol. And then during reauth, you can still
> have the notification in IKE_AUTH. Am I missing anything?
> On 10/06/2010 11:17 PM, Keith Welter wrote:
> > I'm not sure those three reasons outweigh your SPI probing concern.
> > assuming there is not already a way to probe for SPIs without the
> > REAUTH_SA (I did a quick review of RFC 5996 from that angle and
> > see another way to accomplish such a probe). If I could still omit the
> > piggy-backed child SA from the IKE_AUTH exchange for a
> > I would be happy to move the notification back to the IKE_AUTH
> > where I originally had it.
IPsec mailing list