[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SOI QUESTIONS: 2.4 Number of crypto operations





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


The DoS attack comment I made was unrelated to the DoS attack of getting
peers initiating to you (which is the phase 1 DoS protection).  It was in
reference to past experiences with IKEv1 where you don't have a mgt channel.
For example, what do you do if you receive an ESP packet with an invalid SPI
and don't have an IKE SA?  You can send an unauthenticated INVALID-SPI
message and pray the other peer corrects the error (opening him up to DoS),
or you can try and initiate and IKE SA so you can send INITIAL-CONTACT
(which consumes resources, and opens you up to  DoS) or you can ignore it,
which leads to a peeved customer.

Anyways, just trying to point out the value of having a management channel
around.  The channel can exist whether you have 1 or 2 phases (as you
pointed out).

However, I still say that fast rekeying is important, and that implies
having 2 phases.  If phase 2 can be made to be self sufficient management
wise, then your proposal would work.  However, I don't think that most
people on this list (including myself) would like to have mgt properties in
a phase 2 SA.


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

IKE didn't have a *mandatory* management channel.  This is where
interoperability took a turn for the worse.  Some people kept their phase 1
SAs to handle INVALID-SPI, etc..., some people tossed it to save on
resources.  Throw in DELETEs that can get lost on the wire, and you have a
management nightmare.

BTW:  The Quick Mode comment was a typo right?


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

OK.  Perhaps.  Or maybe we just disagree on the requirements.  Some of my
requirements are fast rekey, fast tunnel setup (for single & multiple
tunnels), and good error detection / handling.  I haven't figured out how to
handle all this in 1 phase.  Hopefully, at the end of the day, we can agree
on these requirements.  If not, then I guess our votes will cancel each
other out ;)

Stephane.


>
> 	      Mike