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

RE: ipsec error protocol



>From: sommerfeld@thunk.east.sun.com on behalf of Bill Sommerfeld
>[sommerfeld@east.sun.com]
>Sent: Tuesday, January 23, 2001 9:40 AM
>To: sankar ramamoorthi
>Cc: sommerfeld@east.sun.com; fd@cisco.com; Scott G. Kelly;
>ipsec@lists.tislabs.com
>Subject: Re: ipsec error protocol 
>
>Note that snmpv3 security also uses a boot sequence number as part of
>its replay detection, so any box which does snmpv3 security must
>already have solved this problem ;-)
>
>> 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.
>
>I can think of a number of ways; I'm sure there are others..
>
>The boot sequence number could be put in part of NVRAM which is not
>cleared on a config reset.
>
>After a config reset, some sort of config reload is generally
>required; that can include resetting system time to a known correct
>value.

What if the previous time was wrong for some reasons?

>
>> What if the private key that is used to sign the sequence number is
>> lost?
>
>The intent is that the key used to sign the birth cert is the same as
>the key used to authenticate the IKE exchange.
>
>If you lose that, you need to generate a new one and have certificates
>reissued, etc.,

Which means during the intervals when certs are reissued and propagated,
the 'invalid spi' notification cannot be sent out because the private
key with with it has to be signed is lost.

>
>					- Bill

As I try to understand the scheme better I see a number of problems

. operational problems (as described above - there could be more)
  They probably could be worked around but it seems to me the solution
  is now extending from ipsec to ike to device configuration and
  management. 

. lack of a time-variant(replay sequence as in ESP or AH) allows
  one conjure some scenarios where replay attacks are possible

. extra overhead of authenticating notifications during DOS attack.


Considering all this I feel an error control protocol in ipsec is
preferable as a mechanism towards ipsec-state synchronization problem. 
The protocol is limited to ipsec, does not try to impose a solution
to state synchronization but provides a building block. Conforming
implementations just need to support simple ipsec error processing
and no other changes are required.

There are a lot of similarities to proposed ipsec error control
mechnism and icmp. icmp is an ip error control protocol and uses
a reserved protocol number from the transport-layer protcol space.
The proposed ipsec error control mechanism uses a spi from the
reserved spi space. Like icmp, ipsec error control can be used
to provide a number of error/control functionality.

As for DOS resistant solution, my personal take is that it is 
difficult to provide a complete solution for DOS prevention. 
One can only provide guidelines on how systems can react to DOS 
to minimize the damage.


-- sankar --






Follow-Ups: References: