[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ipsec error protocol
Ignore this if it is a duplicate.
Thanks,
-- sankar --
>From: goofy@cisco.com on behalf of Frédéric Detienne [fd@cisco.com]
>Sent: Monday, January 22, 2001 9:06 AM
>To: sankar ramamoorthi
>Cc: sommerfeld@East.Sun.COM; Scott G. Kelly; ipsec@lists.tislabs.com
>Subject: 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).
I see it more of an implementation issue. If an implemantion
wants to scale large number of connections, it should be able to effectively
deal (and many have dealt) with bookkeeping of large number of timers.
How is the overhead of maintaining probe timers more than authenticating
notifications? In fact if it is DOS, I would rather prefer the computation
overhead with simple probing.
>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.
Additional delay only when the peers are out-of-sync or when
there is DOS. In the DOS case both the probe and IKE packets
could be wasted but atleast in the probe seems to be light weight
compared to ike. In the out-of-sync case the sender would have
to be make sure the notification is genuine before starting IKE.
>
>
>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.
As for the probe being a cribble, as you said the format has not been
specified - There are many possiblities to avoid cribbles here.
The probe has to be specified in such a way that replay attacks
must not be possible - it means it will use the sequence numbers from
the SA of interest. For all purposes the probe packet will be
similiar to that of data packet through an ipsec SA except that
it comes through the error packet and is thrown away. Hence it will
be as difficult/easy to crack as an ESP packet. In short, the probe
offers no more information than a regular packet through the SA.
>
>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.
>
That still applies to the probe packet encapsulated inside the ipsec
error packet
>
>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 ?
As I said, it is possible to design encrypted probes purely with in the
protection offered by ipsec without offering any cribbles to some attacker
in the middle.
>In short: while I do *not* introduce anything (bad&new) in IKE, you *do*
introduce something (bad&new) in IPSec.
>
same here
>
>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 ?
>
Yes - all I am expecting from ipsec is a building block to deal with
the out-of-sync ipsec endpoints. I am not looking for a complete solution
since that solution is out of scope of ipsec. The solution also may vary
depending on the need.
Note: The unauthenticated notify need to be sent when there is no existing
phase1 SA to the peer ie: when there are no phase 1 SAs with the peer.
>
>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.
If I understand the proposal correctly it requires the sender of the message
to remember some unique information known to each peer to get the
'invalid spi' notification authenticated. How can the sender remember
this information across reboots>
If that is not necessary, how is replay protection provided for the
authenticated notify messages?
Regards,
-- sankar --
References: