RE: SOI QUESTIONS: 2.4 Number of crypto operations

["Stephane Beaulieu" <stephane@cisco.com>]

>  > > Please discuss and answer this question.....
>  > >
>  > > 2.4 Number of crypto operations
>  > >
>  > > 2.4.A) JFK requires substantially more cryptographic operations for
>  > > rekeying (two more signatures, two more signature validations, and
>  > > three more hashes).  Is this a problem?  More generally,
> does SOI need
>  > > to be able to support "fast" rekeying?
>  >
>  > Yes.
>  >
>  > To be more precise, SOI should have a 2 phases.  This will
> help with fast
>  > rekeying, fast tunnel setup (for multiple tunnels), and better tunnel
>  > management (this was the BIGGEST problem with IKEv1, IMO).
>
> Perhaps a more sensible balance would be have the
> initial exchange be able to produce a real IPsec
> SA (ie self-contained), and be able to specify a
> zero life for the SOI SA. That way, a compliant
> implementation could choose not to implement
> "quick mode" where there's no particular need.
>
> I propose the following requirement:
>
> "If SOI defines subsequent SOI exchanges derived
>  by the shared state of an initial SOI exchange,
>  the protocol MUST make these subsequent exchanges
>  optional to both parties. A minimal SOI
>  implementation MUST NOT be required to implement
>  the subsequent exchanges."

That would defeat the purpose of the Management Channel I spoke of.  If your
SOI SA goes away immediately (or doesn't get created at all), it gets much
harder to detect / correct error conditions (black holes for example),
without opening yourself up to a bunch of DoS attacks.

We have lots of bad experiences with this in IKEv1, which is why (I
think...) that Dan et al, added a mgt channel to IKEv2.

Dangling SAs (what you're advocating) and Mgt Channel (what I'm advocating)
don't play together very well (at least not in the real world, where packets
get dropped, and VPN boxes reboot).




>
> 		Mike