[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ipsec error protocol
Hi,
When describing DOS prevention, I assumed that is okay to incur a
symmetric encryption overhead. If that is not acceptable secure
state-synchronization can occur in the following manner
On the station receiving the 'invalid spi' error
check if spi from the sender matches any of its ipsec sa.
If not ignore the error message (This should take care some
attacks where the sender is not aware of any currently active
spi)
send a clear ping command - send it using the ipsec control packet.
The payload of the control contains a ping request and the spi
in queston. The receiver on receiving the echo request, will
reply with an echo-reply if the spi specified in the ping-request
packet is still valid. If ping-reply is not received even after a
few retries assume that the 'invalid spi' error was bogus (This
should take care of passive attacks)
This step is of questionable usefulness from DOS prevention point
of view, but can help assure both the parties that the ipsec-sa
parameters in both sides are in sync and encryption/decryption is
working fine. send an encrypted ping command for the sa in question
and send it using the ipsec control packet. The payload of the control
packet contains an encrypted ping encapsualted by an ESP header with
the SPI of the SA in question. If the original error message
is genuine the peer will not be able to decrypt it and will silenty
drop the packet (similiar to icmp, control packets do not generate
more control packets). The sender after a number of retries can
assure itself that the SA has gone stale for good and request IKE
to recreate the ipsec SA.
Note: At this point it is still possible for an
active attacker intercepting the packets to make the sender
unnecessarily send an encrypted ping and there by incur encryption
overhead or restart an IKE exchange by grounding the encrypted
pings (If someone is able to do this level of damage, they can also
ground the IKE packets or data traffic).
On the other hand if the first error was a spurious one, the
encrypted pings will be successfully decrypted by the receiver.
The receiver will send the encrypted echo-replies in the ipsec control
packet and the sender can now knows the SA is still valid and
encryption/decryption/authentication are working fine.
It can safely ignore the initial error message or go tracking
the sender of the initial message.
Thus we can do ipsec state synchronization while proofing it against attacks
from passive attacker.
Welcome your comments,
-- sankar --
-----Original Message-----
From: sankar ramamoorthi [mailto:sankar@nexsi.com]
Sent: Wednesday, January 17, 2001 10:45 PM
To: fd@cisco.com
Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com
Subject: RE: ipsec error protocol
Actually it works like this
When a sending IPsec receives unknown spi error (let us say as
an ipsec control packet using the reserved spi) it can do the
following to ensure that is is a valid error message before asking
IKE to recreate the SA
check if the spi from the sender matches any of its ipsec sa.
If not ignore the error message.
send an encrypted ping command for the sa in question and send
it using the ipsec control packet. The payload of the control packet
contains an encrypted ping encapsualted by an ESP header with the SPI
of the SA in question. If the original error message
is genuine the peer will not be able to decrypt it and silenty
drop the packet (similiar to icmp, control packets do not generate
more control packets). The sender after a number of retries can
assure itself that the SA has gone stale for good and request IKE
to recreate the ipsec SA.
On the other hand if the first error was a spurious one, the
encrypted pings will be successfully decrypted by the receiver.
The receiver will send the encrypted echo-replies in the ipsec control
packet and the sender can now knows the SA is still valid.
It can safely ignore the initial error message or go tracking
the sender of the initial message.
Thus DOS problem can be avoided.
-- sankar --
-----Original Message-----
From: goofy@cisco.com [mailto:goofy@cisco.com]On Behalf Of Frédéric
Detienne
Sent: Wednesday, January 17, 2001 10:09 PM
To: sankar ramamoorthi
Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com
Subject: Re: ipsec error protocol
Agree but let me reverse the argument: once IPSec has detected the problem,
what can it do on its own ? Little but asking IKE to fix it...
Notice that I see your point: you'd let IPSec delete the offending SA and
the lack of SA on the sender side would trigger IKE as it exists today and
the tunnels would be recreated. But as I was telling you: you had the choice
of the transportation method and you chose a dedicated SA. But you do not
tell us what to do with it...
Now, if you think of it: IPSec *does* detect the problem (unknown SPI
received). And it is simply asking IKE to do something about it. We just
give IKE the possibility to do something without opening a DoS door.
It is not very different than the usual case: IPSec misses an outbound SA
and it asks IKE to fix it (and IKE negotiate SA's on the fly).
Now, maybe we could start criticizing the exchange itself... and see if we
can improve it or forget it. Is everyone filtering out threads on recovery
mechanisms ? :)
frederic
sankar ramamoorthi wrote:
>
> Yes, the primary reason for the existance of ike is to establish and
> destroy ipsec state, but not vice-versa ie: ipsec state can exist
> independent of ike state once established. Also ipsec sa can be created
> independent of IKE (manual sa).
>
> We have had a number of arguments in the past about dangling ipsec SAs
> and the general consensus was that ipsec-sa can exist independent of
ike-sa.
>
> IMHO, creating an ike-sa to handle ipsec state synchronization seems
> to avoid the real issue, which is the lack of an error mechanism for
ipsec,
> similar to what ip has (ie: icmp).
>
> -- sankar --
>
> -----Original Message-----
> From: sommerfeld@thunk.east.sun.com
> [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld
> Sent: Wednesday, January 17, 2001 6:18 PM
> To: sankar ramamoorthi
> Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly;
> ipsec@lists.tislabs.com
> Subject: Re: ipsec error protocol
>
> > 1. Extending IKE (with new payloads etc) to what is basically an ipsec
> > problem seems to be an incorrect.
> > If ipsec state (ipsec-SA) is out of sync between two peers, it should
> be
> > dealt in ipsec.
>
> this is a weak argument; the primary reason for the existance of ike
> is to establish and destroy ipsec state.
>
> - Bill
--
------------------------- * oOo * -------------------------
Frederic Detienne
Cisco Systems Escalation Engineer
Security & Network Services
Tel 32 2 704 55 55
Follow-Ups:
References: