[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