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

Re: IPSEC SA DELETE in "dangling" implementations



  This sounds like the In-Line ISAKMP work that was abandoned a while
ago. Perhaps we should revisit this. An in-line ISAKMP message could
solve this issue and an also the keepalive problem (also we might want
to consider reserving a SPI for this purpose too to avoid having to
rely on IKE).

  That was one of the nice things about SKIP.

  Dan.

On Fri, 03 Dec 1999 17:55:31 +0530 you wrote
> Slava Kavsan wrote:
> 
> > Here is the dilemma: if "dangling" implementation wants to send IPSec
> SA
> > DELETE message, while the "parent" IKE SA is no longer there (expired
> or
> > deleted), the alternatives are (and I do not like either of them):
> 
> > a) do not send DELETE
> > b) re-negotiate IKE SA before sending DELETE
> 
> > Any suggestions?
> A third option is to design a oneway authenticated message
> (proofed against replay attacks). Such oneway authenticated message
> can be used for 'delete', 'invalid spi' and other notifications.
> If such a design is possible then it is not necessary to establish
> IKE SA to send a 'delete' notification.
> 
> The oneway message could be authenticated using a signatures
> or hash generated using preshared secret, could include the
> id payload to allow the peer to identify the matching shared
> secret in the case of the pre-shared secret. The oneway message
> could also use as part of the hash information from the event
> causing the notification to be generated. This could prevent
> replay attacks.
> 
> Any thoughts on this?
> 
> 
> 
> 
> 


References: