RE: SOI QUESTIONS: 2.4 Number of crypto operations

[Michael Thomas <mat@cisco.com>]

Stephane Beaulieu writes:
 > 
 > >  > > 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.

   Huh? The DoS protection is conferred by the
   phase 1 DoS protection. All I'm saying is that
   phase 1 should be necessary and sufficient in
   SOI. This is not the case in IKE, but is part
   of the SOI requirements. Thus there is no
   reason for phase 2 to be mandatory.

 > 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.

   IKE has a "management" channel, it's just that
   it was poorly designed. That channel is Quick 
   Mode.

 > 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).

   I'm advocating no such thing. If you have a
   problem which is only solvable by having a 
   phase 2, you haven't met the necessary and
   sufficient requirements for phase 1.

	      Mike