[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heartbeats draft
>
>Ricky Charlet wrote:
>>
>> Howdy,
>> Below is the text of the heartbeat presentation I made at the
ipsec
>> WG meeting. Is this the real problem? If so, is this the right way to
>> rank cantidate solutions.
>>
>> --
>> Ricky Charlet rcharlet@redcreek.com usa 510-795-6903
>>
>> ===========================================
>> slide 1
>> Ricky Charlet
>>
>> Redcreek Communications
>> rcharlet@redcreek.com
>>
>> ============================
>> slide 2. the problem
>>
>> black hole detection
>> for redundancy/error messaging
>> for resource recovery
>> for time based accounting
>
> Here I claim there is only one problem that we are trying to solve
with
>heartbeats, 'black hole detection'. But we all have differing
>motivations for wanting black-hole-detection. These motivations are at
I would rather change it to 'black hole detection in a manner
that is proofed against DOS' - otherwise I agree with you that
this seems to be the crux of the problem.
In my understanding of things
The following assumptions have been made
1. It is assumed sending error notification in the clear will
not work, since the peer will not accept it for fear of DOS
attacks.
2. It is also not possible for the party sending the 'invalid spi'
notification to create a new IKE SA to send the error
notification securely because
a. Fear of DOS attacks - spoofed 'invalid spi' packets
may cause a party to initiate IKE SAs with peers which
can be considered as DOS attack
b. There may not be sufficient information to set up an IKE SA
with the peer - for example in the case of remote client
access, the server may not have enough information about
the peer to make the right SA proposal.
Based on the above assumptions, solutions have been proposed along
the following lines to handle the different scenarios
1. Out of sync ipsec SAs scenario
Try to ensure the IKE sa corresponding to the IPSec SAs remains
around. This ensures that there is an IKE SA for every active
ipsec SA. So if the peers go out of step and a packet arrives
with invalid spi a 'invalid spi' notification can be sent
securely through the IKE SA.
2. Out of sync IKE SAs and IPSec SAs scenario
It is always not possible to ensure the IKE SAs between the
peers are in sync because
a) one side might have rebooted (minimized somewhat with
INITIAL-CONTACT notification)
b) one side might have crashed
c) one side might have just have plain gone out of step
(software bug, IKE SA has been deleted due to want of
resources and the delete notification packet got dropped..)
In these cases it is not possible to send a secure message
through IKE SA since it does not exist. Therefore the designers
have come up with a mechanism to detect the failure of an
IKE SA and react immediately - Hence the proposal for a
heartbeat protocol.
I request that we should explore the possiblity of sending
the error notification in the clear, before coming up with
heartbeat protocol as the only means of synchronizing out-of-sync
peers.
Here is a proposal.
This proposal assumes that a ping like mechanism is supported
in both and IKE and ipsec SAs.
I am assuming the error notifications are sent as a result of
processing some message from peer. I also assume that the
error notify payload format can be enhanced to carry some information
about the original message that caused the error notification
(similiar to icmp error notification).
As an example consider the 'invalid spi' error notification.
'invalid spi' is a result of a incoming packet. So if the 'invalid spi'
notifiation message can be enhanced to carry the first 8 bytes of the
original packet that caused the error - that information can be used by
the peer to verify it is indeed a valid error notification for one of
its active ipsec SAs. The peer can then use a IPSec ping to ensure
that this notification truly came from the source of the ip packet
carrying the error notification. If the ping succeeds the notification
was a spoof can be ignored - else the peer can act on the notification
and clean up the stale SA.
The sequence is as follows
<----- ipsec packet
No matching SA
parties out of sync
------> invalid spi
+ original 8 bytes of packet
causing this error
The error notification message
is sent in the clear.
recover spi from
error notification
packet. Find sa
corresponding to spi,
protcol and peer
address.
If sa not found
drop notification
message and return.
<------ echo on ipsec SA
If echo reply was
not received even after
a few retries, the
error notification is
genuine - clean up the
stale ipsec SA
------> echo reply on ipsec SA
echo reply successfully
received - therefore
the ipsec sa is
active. Ignore the
error notification and
return.
The above proposal would work for all the cases except the case where
the peer has crashed and remains crashed. In this case the peer is
dead and will not send a error notification. This case can be solved
by using an inactivity timer. If an IKE SA exists with the peer and
no packet has been received on any active SAs from the peer for a
period of time, send a hello message through the IKE SA. If no reply
is received, then clean up the inactive IKE SA and corresponding
ipsec SAs.
Thanks,
-- sankar --