[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