[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ipsec error protocol
>From: fdetienn@cisco.com on behalf of Frederic Detienne [fd@cisco.com]
>Sent: Thursday, January 18, 2001 12:38 PM
>To: sankar ramamoorthi
>Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com
>Subject: Re: ipsec error protocol
>
>so much my reading. sorry, I have been too quick.
>
>Now, rereading, I still have a few remarks:
>
>. you use a special SPI to carry the packet but you also have to carry the
SPI being probed *in the clear* in the packet (so the remote side can
possibly respond). Which means the packet also has to be authenticated (or
the SPI could be tampered with). You then have to assume the SA you probe
has keys for encrypting and authenticating while in practice, it could be an
AH related SA or ESP with encryption only (solution ?)
Yes the SPI being probed will be in the clear. It will be part of the
ESP header protecting the probe packet (which is encapsulated in the control
packet identified by the reserved spi). Yes - if the receiver of the
probe wants to respond, it should have a corresponding SA for authenticating
and decrypting the request, encrypting and authenticating the reply.
The SA being probed can be AH or ESP or ESP with authentication or any
such combination(we just have to define the probe packets for the
different types).
>
>. you need 3 packets and a number of timeouts before deleting the SA and
only restarting some IKE negotiation (slow)
Yes - that is true. Since it happens only when states go out-of-sync
I do not think it is a big issue. If it happens during a DOS, the
probes describes should be able to take care of most DOS attacks
>
>. you still can not decide if you restart just a phase 2 or also a phase 1
(e.g. If the phase 2 SA was administratively deleted on one host and the
notification lost, we may still have a phase 1 available and phase 2 could
be enough).
Isn't acknowledged deletes one of the new features of son-of-ike document?
In any case if the sender detects that ipsec SA has gone out of sync,
it decides to restart phase2 SA, if phase2 SA times out, restarts phase1
SA.
>
>. last but not least, because you force the IPSec stack to send a
deterministic response in exchange of something known, you offer cribbles to
the attacker. This is something that we never see appearing anywhere else in
IPSec, I believe. I think you introduce a weakness in IPSec, in particular
on the DATA session key (again, cryptographers...).
Yes - we are asking ipsec to send a deterministic error when it does not
have
an SA with a matching spi. How does it open up ipsec attack? The spi is
already
in the clear. The only additional thing now available to the hacker sniffing
on the wire is the knowledge that a receiver does not have the matching spi.
How does it help the hacker? He already is able to find out all the valid
spis to the receiver.
>
>(same in my case but I only weaken the phase 1 session key + the fact that
IKE already offers *many* cribbles BUT (solution) you can protect the phase
2 session keys with PFS. You have no such solution).
>
>
Can u expand on this point? The probes we discussed do not include
creation of the phase 2 session key. It is left to the sender to
decide whether to use IKE to recreate phase2 SA (with or without PFS)?
The probes only help to identify ipsec-sa has gone out of sync in a
secure way.
>
>(and sorry again for having misread).
>
No problem
>regards,
>
> frederic
>
>
-- sankar --
Follow-Ups:
References: