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

Re: ipsec error protocol

Hi Sankar,

FD>>. you need 3 packets and a number of timeouts before deleting the SA and
FD>> only restarting some IKE negotiation (slow)
SR> Yes - that is true. Since it happens only when states go out-of-sync
SR> I do not think it is a big issue. If it happens during a DOS, the
SR> probes describes should be able to take care of most DOS attacks

Exactly not. In a DoS attack, the probing party may have to maintain a large number of timers (say this is a hub with a few thousands remote spokes connected to it; multiply the number of spokes by the number of outbound phase 2 SA's per host; now, flood the hub with spoofed invalid (but existing) SPI's from the spokes).

FD>>. you still can not decide if you restart just a phase 2 or also a phase 1
FD>> (e.g. If the phase 2 SA was administratively deleted on one host and the
FD>> notification lost, we may still have a phase 1 available and phase 2 could
FD>> be enough).
 
SR> Isn't acknowledged deletes one of the new features of son-of-ike document?

and ? Even if you acknowledge the delete, what does that bring to you ?

SR> In any case if the sender detects that ipsec SA has gone out of sync,
SR> it decides to restart phase2 SA, if phase2 SA times out, restarts phase1
SR> SA.

Exactly: additional delay.


FD>> . last but not least, because you force the IPSec stack to send a
FD>> deterministic response in exchange of something known, you offer cribbles to
FD>> the attacker. This is something that we never see appearing anywhere else in
FD>> IPSec, I believe. I think you introduce a weakness in IPSec, in particular
FD>> on the DATA session key (again, cryptographers...).
 
SR> Yes - we are asking ipsec to send a deterministic error when it does not
SR> have
SR> an SA with a matching spi. How does it open up ipsec attack? The spi is
SR> already
SR> in the clear. The only additional thing now available to the hacker sniffing
SR> on the wire is the knowledge that a receiver does not have the matching spi.
SR> How does it help the hacker? He already is able to find out all the valid
SR> spis to the receiver.

The clear text SPI is not really the problem here.

Because we know the shape of the "echo request" (you will have to come up with a spec for this), an attacker will know what to attack (clear text attack).

Say A and B share SA's. E is our evil attacker. E sends spoofed (B's source address) unauthenticated "invalid SPI" notifications to A. A responds with an "SPI echo-request" to B. The echo request is encrypted and has a known form. So E will now have a pair of clear and cypher text "echo-request" (in other words, a cribble) => leading to a possible clear text attack.

If you noticed, the "next protocol" field in ESP is actually hidden in the encrypted portion. Because we do not know what is carried within this encrypted portion (not even the value of the "next protocol" field), a clear text attack can not be performed.


FD>>(same in my case but I only weaken the phase 1 session key + the fact that
FD>>IKE already offers *many* cribbles BUT (solution) you can protect the phase
FD>>2 session keys with PFS. You have no such solution).

SR> Can u expand on this point? The probes we discussed do not include
SR> creation of the phase 2 session key. It is left to the sender to
SR> decide whether to use IKE to recreate phase2 SA (with or without PFS)?
SR> The probes only help to identify ipsec-sa has gone out of sync in a
SR> secure way.

I think you missed my point. What I mean is that there *are* cribbles in IKE (think of the well known shape of the packets in an exchange and the "next protocol" fields). I just add a few more things to the protocol but who cares since I do not make it worse ?

In short: while I do *not* introduce anything (bad&new) in IKE, you *do* introduce something (bad&new) in IPSec.


Now, I would also add: you said that I was relying on ISAKMP/IKE to recover and you prefer an all-IPSec based method. Well, think of your method: you send an unauthenticated IKE message to notify. You verify the notification with IPSec probes and finally, you let IKE restart in the worst possible way (slowly). Is that really what you wanted ?


In the Detienne/Sommerfeld method, you notify and restart the negotiation at once (no IPSec<->IKE pingpong), almost immediately (no wasted packets, no timers), at a stage that is the most efficient in all the cases (phase 1 first or directly with phase 2) and with a fraction (at worse 1/2) of the timers required in your method.

Sorry but until someone attacks our method, I find it much faster, safer and more homogeneous. And btw, I have not received any technical comment on this yet... still waiting. Anyone ?

Finally, let me repeat that I would consider a (our) notification/renegotiation method in conjunction with an acknowledgement based method embedded within IPSec (can be done without cribbles). The main reason is that we need to rate limit the notifications (in ALL methods, not only our). So it is still possible that we do not recover easily in a case of DoS/true error pair (i.e. a true recovery is needed AND we are under DoS at the same time).

Regards,

	Frederic Detienne


-- 
------------------------- * oOo * -------------------------
                     Frederic Detienne
              Cisco Systems Escalation Engineer
                 Security & Network Services

                     Tel 32 2 704 55 55
Follow-Ups: References: