[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: