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

RE: Peer liveliness




you won't achieve interoperability unless it's mandated that everyone must
reply INVALID_SPI (in clear or initiate IKE back to the sender) whenever it
receives bad spi packets.  Current IKEv2 draft doesn't address this issue
(only states you MAY reply a clear notify message).

IKEv1 vendors has implemented many ways to solve it which leave poor
interoperability.  We should just pick a method and clarify it in IKEv2.

===============
Michael Shieh


-----Original Message-----
From: Darren Dukes [mailto:ddukes@cisco.com]
Sent: Monday, April 21, 2003 11:28 AM
To: Ravi; ipsec@lists.tislabs.com
Subject: RE: Peer liveliness




> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ravi
> Sent: Friday, April 18, 2003 1:06 AM
> To: ipsec@lists.tislabs.com
> Subject: Peer liveliness
> 
> 
>  Hi,
>   I was going through several drafts related to peer liveliness. 
> But, some of practical
>   problems faced in actual deployment may not be solved by these 
> proposals.
>   INITIAL_CONTACT Notification : It indicates that the Peer was 
> dead and cameback.
>   DPD:  Checks the liveliness of the peer.
>   I feel, we require interoperable solution to check liveliness 
> of SA ie Dead Peer SA detection
>  (DPSD). 

I believe INVALID_SPI does what you are looking for.  If I receive an
INVALID_SPI notify via an IKE SA I know to delete the SA and traffic will
bring up a new one.  

Darren

>   DPD specification can be enhanced to achieve this.
>   Protocol-ID and SPI fields can be made mandatory.
>   Protocol-ID can be ESP/AH/IKE.
>   SPI : In case of IKE, it could be cookies and in case of 
> ESP/AH, it is SPI (inbound SA's SPI
>        on the peer).
>   If peer is not dead, but SAs were deleted either due to 
> temporary failure OR due to 
>   restarting of some processes in the system can be detected with 
> this mechanism.
>   Does this makes sense? If so, I can contribute text to this effect.
> Regards,
> Ravi
> 
> 
> 
> -- 
> 
> 
> The views presented in this mail are completely mine. The company 
> is not responsible for whatsoever.
> 
> 
> Ravi Kumar CH
> Rendezvous On Chip (i) Pvt Ltd
> Hyderabad, India
> Ph: +91-40-2335 1214 / 1175 / 1184
> 
> ROC home page