[WE] won't achieve interoperability unless it's mandated that
[IMPLEMENTORS] 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
We have been having quite a debate in the ICSA IPsec consortium mail list
recently trying to figure out how to handle this in IKEv1 (YES, STILL!!!)
Here is what we know for sure of this problem statement:
(a) detecting liveness/deadness of peer is a good thing, but does not solve
all the failure cases in and of itself
(b) the behavior of a recently rebooted device when it receives an
encrypted packet for an SPI or IKE-SA not in its SADB MUST be mandated, or
else implementations will not interoperate (as is the case in IKEv1, 5 years
later).
(c) the behavior of a peer that receives a new IKE from a peer that it has
an existing IKE-SA with (i.e. the rebooted peer that is trying to initiate a
new connection) MUST be mandated, or else implementations will not
interoperate (as is the case in IKEv1, 5 years later).
Darren Dukes wrote:
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.
I don't believe this will work, since it assumes that an IKE SA is
established. In the scenario, the IKE-SA would have been lost along with the
SPI of the CHILD-SA by the rebooted peer.
Recommendations to solve the solution:
- the empty notify as an aliveness check is a good idea. It accomplishes
what the DPD draft did. Keep using this.
- do what you can to use empty notify to detect dead peer ASAP. The faster
the persisting peer can delete the old SPI and IKE-SA, the better. The best
case is for Persisting Peer to detect death and initiate new IKE to rebooted
peer before rebooted peer gets packets with old SPI, IKE-SA.
- On the Rebooted peer side: If an implementation receives a protected
packet from an unkown SPI,
- simply relying on sending back an unprotected INVALID_SPI is not a good
idea. It is too easy to DoS the persisting peer by simply spoofing the
rebooted peer's address.
- initiate IKE to the persisting peer.
- On the Persisting Peer:
- If you get a new IKE request from a peer already in your SADB, respond
with the under-attack, 6 message method. This will mitigate the DoS attack.
If you get all the way through SA and TS negotiation successfully, you are
assured (unless I'm missing something) that this really is your peer, and
that he re-initiated because he lost the original IKE-SA. Start using the
new IKE-SA and the new CHILD-SA and delete the previous ones after some wait
period.
Would this proposal explicitly solve things?
Gregory.