[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ipsec error protocol



>To: Derek Atkins
>Cc: fd@cisco.com; sommerfeld@East.Sun.COM; Scott G. Kelly;
>ipsec@lists.tislabs.com
>Subject: RE: ipsec error protocol
>
>
>
>
>-----Original Message-----
>From: owner-ipsec@lists.tislabs.com
>[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins
>Sent: Wednesday, January 24, 2001 12:02 PM
>To: sankar ramamoorthi
>Cc: fd@cisco.com; sommerfeld@East.Sun.COM; Scott G. Kelly;
>ipsec@lists.tislabs.com
>Subject: Re: ipsec error protocol
>
>
>But this doesn't help.  If one of your hosts rebooted and lost it's SA
>state, it will receive this message and then do what?  The 'ipsec-sa

By message do you mean the 'invalid spi' message?
If the host does not have the SA state corresponding to the
'invalid spi' message it will ignore the message.

>of interest' wont exist, and even if it did, the rebooted host would
>have lost all state from its peer so it wont have any keying
>information with which to decrypt the inside ESP packet.  So, what
>does this buy you?

I think there is some confusion here. The 'invalid spi' is sent
by the host which has lost the SA state (because of reboot or
other means) and received by one trying to send data.

The rebooted host does not have to worry about the decrypting
the inside ESP packets. It will drop the 'receipt-needed' packets
and the sending host will detect the condition after sending a few packets.

>
>Worse, as there is no authentication of this packet, an attacker could
>cause you to believe that you have stale information.  All they have
>to do is send a message with a 'garbage' inside ESP with a known
>'ipsec-sa of interest' and your host will think there is a state
>error.

By packet, I assume you imply 'invalid spi' packet.

Yes - there is no authentication of the 'invalid spi' message.
But there are ways to ensure the message is genuine. At the first
level, the 'invalid spi' message can be made to carry some information
about the packet it received (8 bytes just as in icmp). That information
can contain the spi and sequence of the packet for which 'invalid spi'
is being generated. This can be used the receiver of the 'invalid spi'
to ensure that the message is reasonably genuine. It still is possible
that the message has been spoofed. The ipsec control packets
'recipt-needed' and 'recipt' as described in the scheme can be used
to ensure the message was really genuine.

>
>My question is: in the case of a rebooted host, where is this key
>information coming from?  The ether?  Or are you assuming
>manually-keyed SAs?

Again, the rebooted host does not have to worry about the failed
SAs or key information in the failed SA.

>
>-derek
>

>"sankar ramamoorthi" <sankar@nexsi.com> writes:
>
>> 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 =3D 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-s=
>> a
>>                                            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
count=
>> er
>>                                            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
s=
>> et
>>                                            clear the flag and reset the
>> counter.
>>
>>
>>                                            If counter has reached a max.
>>                                            value, then it implies the
pee=
>> r
>>                                            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'
ipse=
>> c
>> 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
windo=
>> w
>> 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
>>
>
>--
>       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>       Member, MIT Student Information Processing Board  (SIPB)
>       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>       warlord@MIT.EDU                        PGP key available



Follow-Ups: References: