[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ipsec error protocol
>From: owner-ipsec@lists.tislabs.com on behalf of Frédéric Detienne
>[fd@cisco.com]
>Sent: Wednesday, January 24, 2001 1:19 AM
>To: sankar ramamoorthi
>Cc: sommerfeld@East.Sun.COM; Scott G. Kelly; ipsec@lists.tislabs.com
>Subject: Re: ipsec error protocol
>
>
>On your side, you still have not explained the shape of your probe packets
and the way you protect them (key usage and generation). Can you proceed ?
>
I will try to address this point.
On furthur thinking, I belive the scheme can be refined to avoid
timers and minimize delays.
The format of the state-synchronization ipsec-control packet I hadin mind
was
something like (Note: other ipsec-control packets can be defined but they
are
not interest here).
------------------------------
| ESP-NULL (with reserved spi) |
------------------------------
| ipsec control/error header |
------------------------------
| ESP packet for ipsec-sa of |
| interest |
------------------------------
ipsec error header is of the form (similiar to icmp)
type | code | checksum
type = control or error
code is different codes we want to use for the control/error
For ipsec-state-synchronization purposes I was visualizing two
codes namely
recipt-needed
specifies that if the encapsulated ipsec packet is successfully
processed a recipt should be sent to the peer. The encapsulated
ipsec packet is a valid data packet, that should be sent to the
upper layers if successfully processed.
recipt
specified the control packet is a receipt to say that
some previously sent receipt-needed packet was successfully
processed. The receipt packet is accepted as a valid receipt
only it passes successful inbound ipsec processing. The
receipt data is not a valid data packet and should not be
sent to the upper layers. It should be discarded after processing.
Using the above messages ipsec-state synchronization would proceed
along these lines.
Assume two peers communicating packets over an ipsec tunnel and
one peer lost the ipsec-sa-state.
peer without the ipsec-sa peer with the possibly
state out-of-sync ipsec-sa
(1)
(on receiving an ipsec packet
for which there is no matching ipsec-sa
send a 'invalid spi' error in the clear)
-------------------------------------------------->
(2)
on receiving 'invalid spi'
error, if the selectors
specified in the error,
match an exisiting ipsec-sa
mark the ipsec-sa with
'MAY-BE-OUT-OF-SYNC' flag
and set counter to 0
(2B)
If there is data to send and
the ipsec-sa has
'MAY-BE-OUT-OF-SYNC' flag set,
send the ipsec packet
encapsulated
in a control packet of type
'receipt-needed'. Increment
counter.
(3)
if a control-packet of type
'receipt-needed' is received,
do normal inound-ipsec processing
on the encapsulated ipsec packet
using the ipsec-sa specified in
the control packet. If processing
is unsuccessful do not send receipt.
If processing is sucessful, pass
packet to upper layers and send
a receipt to peer.
To send a receipt, generate an
ip packet containing random data.
Do normal outbound ipsec-processing
on the packet using the ipsec-sa
of interest. Build an ipsec control
packet of type 'receipt' and send it
to the peer.
(4)
If an ipsec-control packet of
type 'receipt' is recieved,
do normal inbound ipsec
processing on the packet using
the ipsec-sa specified in the
control packet. If the ipsec-sa
was not found or if if the
ipsec-sa
is not in 'MAY-BE-OUT-OF-SYNC'
state or if the inbound
processing was unsuccessful,
drop the packet. If processing
is successful, reset the counter
reset the 'MAY-BE-OUT-OF-SYNC'
flag and throw away the data
from the decrypted packet.
If a valid ipsec packet is
received from the peer and if the
'MAY-BE-OUT-OF-SYNC' flag is set
clear the flag and reset the
counter.
If counter has reached a max.
value, then it implies the peer
is out-of-sync. delete the
ipsec-sa
There are probably furthur refinements possible to this scheme.
But as you can see, it rides on the replay protection scheme provied
by ESP and AH protocols, does not add additional overheads in terms
of the need to buffer data, timers etc.
Now spoofing can occur at step (2), (3) and (4).
packets spoofed at step (2)
This may cause the receiver of the 'invalid spi' error to incorrectly
set the SA in 'MAY-BE-OUT-OF-SYNC' state. This is not much a harm
since it sends a 'recipt-needed' control packet only when there is
data to be sent to the peer. There are no wasted round-trips since
the data is sent in the 'receipt-needed' control packet.
packets spoofed at step (2)
This may cause an implementation to receive spoofed 'receipt-needed' ipsec
control packets. The spoofed packets can be detected because,
the encapsulated packet has to match an exisiting ipsec sa,
has to be with in the replay window of the inbound-ipsec sa and has to
be sucessfully processed for inbound-ipsec-processing.
packets spoofed at step (3)
This may cause an implementation to receive spoofed 'receipt' ipsec
packets. Agains spoofed packets can be detected because, the encapsulated
packet has to match an existing ipsec sa, has to with in the replay window
of the inbound ipsec-sa and has to be sucessfully processed for
inbound-ipsec processing.
There are no timers maintained since the 'receipt-needed' packets are
sent only when there is data to be sent.
The overhead is the processing of valid 'receipt' packets.
An attacker can induce a lot of them to be generated by spoofing
a lot of 'invalid spi' packets which could force the communicating
parties to go through step 2), 3) and 4). This is somewhat minimized
if there is bidirectional communication since in that case a normal
ipsec packet would act like a receipt. In the case of unidirectional
traffic, the sender may receive a lot of valid receipt packets.
This would have to be minimized by rate limiting.
Welcome your comments on the described approach
-- sankar --
>Regards,
>
> frederic detienne
Follow-Ups:
References: