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

RE: ipsec error protocol



>From: Derek Atkins [warlord@MIT.EDU]
>Sent: Wednesday, January 24, 2001 2:59 PM
>To: sankar ramamoorthi
>Cc: fd@cisco.com; sommerfeld@East.Sun.COM; Scott G. Kelly;
>ipsec@lists.tislabs.com
>Subject: 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 with minor correction,

B sees the invalid spi messages,
goes through few levels of steps to assure itself the message
is genuine and then rekeys.

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

Assuming he can send the forged 'invalid spi' packet in some reasonable
time window from which the original ESP packet was sent.

Yes, detection of the forged 'invalid spi message' is the problem to be
solved.
That is why the receiver of the 'invalid spi' has to take some
extra steps to ensure the 'invalid spi' actually came from the
intended recipient before rekeying. The suggested approach outlines
ways to do that.

OR

find ways to ensure the 'invalid spi' message is always authenticated
(as in the solution proposed by Bill Sommerfeld and Fredric detienne).

OR

some variations of these (as in keepalive based solutions proposed in
the draft by Andrew krywaniuk and others).


-- sankar --

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