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

RE: ipsec error protocol

Hi,

comments inline
>From: sommerfeld@thunk.east.sun.com on behalf of Bill Sommerfeld
>[sommerfeld@east.sun.com]
>Sent: Monday, January 22, 2001 7:01 PM
>To: sankar ramamoorthi
>Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly;
>ipsec@lists.tislabs.com
>Subject: Re: ipsec error protocol
>
>> >In the Detienne/Sommerfeld method, you notify and restart the
negotiation
>> at once (no IPSec<->IKE pingpong), almost immediately (no wasted packets,
no
>> timers), at a stage that is the most efficient in all the cases (phase 1
>> first or directly with phase 2) and with a fraction (at worse 1/2) of the
>> timers required in your method.
>>
>> If I understand the proposal correctly it requires the sender of the
message
>> to remember some unique information known to each peer to get the
>> 'invalid spi' notification authenticated. How can the sender remember
>> this information across reboots?
>
>The message contains a signed sequence number; the "birth cert" sender
>need only keep a single sequence number, shared across all peers.
>
>Replay detection is simple.  the "birth cert" receiver (SA sender)
>needs to hang on to the "current" birth cert for the lifetime of the
>sending side of the SA.  (i.e., the sending end of the SA can throw it
>away when it throws away the SA state).
>
>If it receives a newer birth cert than the old one, it knows that the
>peer has rebooted and its SA state is stale.
>
>If it receives an older birth cert in an error message, it can
>trivially ignore it.
>
Some comments on the scheme. Correct me if am I wrong in my understanding.

This scheme depends upon the sequence number used in a birth cert to be
continously incrasing across reboots. This may not always be possible.
For example time (from which the sequence number may be derived) may be
reset, configuration may be reset etc. In these cases information
about the previous sequence number is lost.

What if the private key that is used to sign the sequence number is lost?
(may be nvram/flash needed to be reprogrammed for some reason) How
does the birth cert owner recover from the situation?
Does it have to create a new ike sa with every existing peer to update
the birth cert information?

What the ways to handle these operational problems?


>There are other tricks you can use to engineer DoS resistance.  (i.e.,
>rate limit how often you'll attempt to validate a signature, skip the
>validation if you've recently received authentic traffic from the
>peer, etc., etc.)
>
>					- Bill

-- sankar --
Follow-Ups: References: