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

Re: ipsec error protocol

"sankar ramamoorthi" <sankar@nexsi.com> writes:

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

Ok, so hosts A and B have IPSec SAs, but B is generally communicating
with A, with A rarely having anything to say except in response to B.
A reboots, losing all state.  B sends an ESP packet to A.  A doesn't
understand it, so it builds an invalid spi message to send back to B.
B sees the invalid spi message and knows it needs to rekey before it
can send anything to A.  Is this what you envision?

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

Assuming my last interpretation is correct, an attacker can force a
pair of hosts to rekey just by forging an invalid spi message.  All
they need to do is be able to copy an ESP packet off the wire and then
build an invalid spi message around it.  There is no proof that the
invalid spi actually came from the intended recipient.

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