[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ipsec error protocol
> > What are the kind of attacks possible?
>
> a. I do not see any attack that could not be done on IKE.
>
> b. So far, no one sees one.
>
> c. That is exactly why I asked the list and why I am trying
> to write this ~@#&% draft.
Realistically speaking, there are only 2 attacks we need to worry about: DoS
and excessive generation of known plaintext. Both are possible, to varying
extents, with any of the methods we have seen proposed.
> > If one side needs a very fast recovery, a keep-alive
> > equivalent protocol can be implemented using the messages provided
> > in ipsec error protocol.
>
> NO. Once and for all: keepalives are Bad. Evil. Broken.
>
> You shifted your own scheme from keepalives to acknowledgements...
Can we please not be dogmatic about this? Keepalives come with certain
well-known pitfalls; if you know what they are, you can invent a scheme with
whatever design tolerances you desire.
Anddrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Frédéric Detienne
> Sent: Tuesday, January 30, 2001 5:21 PM
> To: sankar ramamoorthi
> Cc: sommerfeld@East.Sun.COM; skelly@redcreek.com;
> ipsec@lists.tislabs.com
> Subject: Re: ipsec error protocol
>
>
> sankar ramamoorthi wrote:
> > >notice that you made a lot of progress. Your "slight
> changes" actually
> > shift the original paradigm from a "keepaplive in disguise" into
> > "acknowledgement in disguise".
> >
> > No, it is more like 'acknowledgements-when-needed'
>
> turn it the way you want. They are acks.
>
> > >Take my first emails and re-read: acknowledgments are better.
> > >
> > acknowledgements only when needed is still better :-)
>
> no, it is slower.
>
> >
> > >Your problem is that you really want to trigger this with
> an "invalid SPI"
> > message. And you come up with pretty fancy packets. Not
> that I do not like
> > them (they're a valid vector after all) but now your
> philosophically correct
> > pseudo-ICMP's tunnel data :)
> >
> > Yes, but not all error/packets though, only the
> 'receipt-needed' type of
> > control packet.
>
> Not all pink rabits have green sunglasses...
>
> [stuff trimmed]
>
> >
> > As for as I understand the scheme, you have
> >
>
> I corrected your sketch. There is no notification message.
>
>
> peer wih out-of-sync/no ipsecSA peer
> sending data
>
> step1
> send ESP data
> <-----------------------
>
> no ipsec or ike state with
> peer. send notification in
> IKE offer.
>
> step2
> initiate directed-ike phase1
> or phase2 exchange
> (ike for a particular reason)
> sa proposal + 'because I do
> not have SA xxx and you do'
> --------------------------->
>
> if reason is satifactory
> respond to IKE exchange
> from peer
> step4
> <---------------------------
> responder proposal (2nd
> message of ike exchange
> sa proposal + 'because you did
> not have SA xxx'
>
> ... (IKE continues and terminates
> with a CoB).
>
> > Seems to be a neat way to avoid passive attacks. However the
> > initial IKE message is not authenticated and it now carries
> > additional information.
>
> The first four Main Mode IKE packet are NEVER authenticated
> anyway. So what ? They contain keying material and your
> policies... who cares ?
>
> Think of it: there are active attacks against IKE but they
> are very specific and take you nowhere or people live with
> that (been debated). I do not introduce (I think) any [new]
> weakness in IKE. Period.
>
>
> > What are the kind of attacks possible?
>
> a. I do not see any attack that could not be done on IKE.
>
> b. So far, no one sees one.
>
> c. That is exactly why I asked the list and why I am trying
> to write this ~@#&% draft.
>
>
> If you find a problem that is introduced in IKE by my method,
> please mention it. You will save me a lot of time.
>
> If you find a problem in IKE... wow.
>
>
> >
> > Comparing this with an ESP based scheme..
> >
>
> [trimmed] (already discussed that).
>
> > >
> > >. acknowledgements are good but
> > > a) slower than direct notifications (need several lost packets,
> >
> > Yes - but how fast do you want to recover?
>
> Since you ask me: as fast as possible.
>
> >
> > With the ipsec error protocol, speed of recovery is left to the
> > implementation.
>
> Mmmh... heard of round trip time ? High speed high latency ?
>
> Take the time you want but think you can lose quite a few
> packets inbetween.
>
> It could be your broker, your VoIP call to the police, your
> remote surgeon...
>
>
> > If one side needs a very fast recovery, a keep-alive
> > equivalent protocol can be implemented using the messages provided
> > in ipsec error protocol.
>
> NO. Once and for all: keepalives are Bad. Evil. Broken.
>
> You shifted your own scheme from keepalives to acknowledgements...
>
>
> [trimmed things I did not want to comment]
>
> > > b) if uncontrolled, may restart IKE for nothing. E.g.,
> Under a DoS,
> > genuine ESP packets with a valid seq# may not reach the
> destination which in
> > turn could not acknowledge them => forcing an undue rekey.
> > >
> > Agreed. This is a problem. But if genuine ESP packets
> cannot get through,
> > the rekeys also won't succeed
>
> You have very polite hackers around you then.
>
>
> regards,
>
> frederic detienne
>
Follow-Ups:
References: