[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: