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

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
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?

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.

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?

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