[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: ipsec error protocol
-----Original Message-----
From: sankar ramamoorthi [mailto:sankar@nexsi.com]
Sent: Wednesday, January 24, 2001 9:58 PM
To: sommerfeld@East.Sun.COM
Subject: RE: ipsec error protocol
>From: owner-ipsec@lists.tislabs.com on behalf of Bill Sommerfeld
>[sommerfeld@East.Sun.COM]
>Sent: Wednesday, January 24, 2001 4:38 PM
>To: sankar ramamoorthi
>Cc: Derek Atkins; fd@cisco.com; sommerfeld@East.Sun.COM; Scott G. Kelly;
>ipsec@lists.tislabs.com
>Subject: Re: ipsec error protocol
>
>> B sees the invalid spi messages,
>> goes through few levels of steps to assure itself the message
>> is genuine and then rekeys.
>
>what exactly does B do to validate the message?
>
>please show your work.
>
> - Bill
B goes through the following steps to assure itself the message
is genuine
I am assuming the 'invalid spi' notice is in the clear.
I am also assuming ipsec error protocol can be used to define the
'invalid spi' and the message is of the form
------------------------------
| ESP-NULL (with reserved spi) |
------------------------------
| ipsec control/error header |
------------------------------
| 8 bytes of the ESP packet for|
| which there was no ipsec-sa |
------------------------------
**note**: An icmp error also could have been used for sending the
'invalid spi' message, though the error code would have to be agreed
upon.
1. Derive the sequence number and SPI from the error packet.
This is retrieved from the information about the offending ESP
packet that was saved in the ipsec error packet.
2. Check if there is an outbound ipsec-SA with the matching SPI. If not
ignore the error
3. Check if the sequence number in the error packet is within a resonable
window of the outbound ipsec packet replay sequence number. If not ignore
the packet.
To cross this point the attacker has to be really be sophisticated.
Not only he has to sniff and spoof the packet, but also send the
'invalid spi' message in a short time window.
This level of assurance may be enough for some hosts. If it is not
enough the following steps can provide furthur assurance.
Detailed description of the messages involved (posted earlier) is
also attached.
4. Mark the SA as 'MAY-BE-OUT-OF-SYNC'. On the next data packet to
be sent using this ipsec SA, use 'receipt-needed' type of ipsec
control packet. Start a counter.
5. If a valid packet is received on the inbound ipsec-sa or
a valid 'receipt' type of ipsec-control packet is received for the
inbound sa, reset the counter and clear the flag. The 'invalid spi'
notification was bogus.
6. If counter reaches n, it implies n packets have been sent using
the outbound-sa without receving a 'receipt' or valid data on
the inbound-da. There is sufficient assurance that the peer genuinely
does not have the ipsec-sa. Delete the ipsec-sa.
--------------------------------------------------------------------
Earlier posting describing the ipsec control message exchange
The format of the ipsec-control packet I had in mind was
something like.
------------------------------
| 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
receipt needed if the encapsulated ipsec packet is successfully
processed
recipt
specified the control packet is a receipt to say that
some previously sent receipt-needed packet was successfully
processed.
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.
Welcome your comments on the described approach
-- sankar --
Follow-Ups: