[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipsec error protocol
This is much simpler. Suppose A and B have SA's in common.
In the combined method, the reboot seq# is actually sent in the last 2 IKE packets. So they are implicitly signed when the whole exchange itself is signed.
In short, all there is to remember is the boot seq# of the peer with each SA you have with a remote peer. I think 32 bits are enough and do not consume much memory.
If A does not have any SA anymore with B (say A crashed or was forced to delete its SA's), no risk that it will send bad SPI's. And any notification/restart from B would be spoof.
If A has at least an SA with B but A and B are out of sync, it still has the seq# and can take the conclusions at the end of the exchange.
So really, are 4 bytes/SA a problem ? And that number could even be a date-time...
And this is just a solution example. It is possible to make better if you think you will have many SA's per peer (space and speed efficiency).
fred
sankar ramamoorthi wrote:
>
> 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 --
References: