Any "INVALID_IKE_SPI" or "INVALID_SPI" message can trigger DPD (or, as RFC 4306 calls it, "liveness check"). These messages are very easy to spoof.
But liveness check is just one round trip between the peers and it's supposed to be rate-limited. I don't think an off-path attacker can cause the liveness check to fail. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nicolas Williams Sent: Wednesday, August 12, 2009 9:57 PM To: [email protected] Subject: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?]) Over at BTNS WG we're wondering how hard it is for off-path attackers to cause a node to think that a peer is dead. We'd appreciate your input. See forwarded post. Thanks, Nico ----- Forwarded message from Nicolas Williams <[email protected]> ----- Date: Wed, 12 Aug 2009 13:06:08 -0500 From: Nicolas Williams <[email protected]> Subject: Re: [btns] Q: How to deal with connection latch breaks? To: Michael Richardson <[email protected]> Cc: [email protected] On Fri, Aug 07, 2009 at 12:36:16PM -0400, Michael Richardson wrote: > 2) system W's SA with system C expires (or is deleted by > INITIAL-CONTACT), and system W sees that has a broken latch. Just one clarification: "system W's SA with system C expires" does not mean that "system W sees that has a broken latch". That's because the current I-D says that latch breaks occur only as a result of conflicts; dead peer detection does not cause latch breaks. It might be useful to say that dead peer detection does cause latch breaks now that we have chosen to reset faster, so to speak. But I wouldn't want to have to specify any specific timeouts, or, really, any details of dead peer detection -- those would take time to work out. Fortunately we could leave those details to IKEv2 and just add that "if IKEv2 DPD concludes a given peer is dead then all latches with that peer SHOULD be transitioned to the BROKEN state". Possible wrinkle: - Is it possible for an off-path attacker to DoS IKEv2 between two peers? If so then we must not allow DPD to cause latch breaks! DNS poisoning is not an issue here, but ICMP redirects and ARP spoofing are. If you can spoof ARP you're on link, so that's not an issue. And ICMP redirects should be getting ignored. Any other ways to trigger IKEv2 DPD via an off-path attack? My preference: leave the text as-is on this; don't allow DPD to break latches, or perhaps allow it as a MAY, but not a SHOULD, much less a MUST. Rationale: a) there's a fairly strong distinction between "dead peer" and "SA/policy conflict", with the latter being an absolutely necessary cause of latch breaks while the former is not; b) it's easy to show that to cause such an SA conflict one must be on-path (or be able to spoof routing protocol updates) and policies must permit the conflict to arise (e.g., BTNS is in use), whereas it's harder to show the same for IKEv2 DPD -- we'd have to spend some time working that out; c) ULP/app timeout timers will generally result in DPD at the ULP/app layer anyways; d) we can always add DPD->latch break rules later if we need them, or we could let it be a MAY now and later upgrade it to SHOULD or even MUST if it proves useful. Nico -- _______________________________________________ btns mailing list [email protected] https://www.ietf.org/mailman/listinfo/btns ----- End forwarded message ----- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Email secured by Check Point _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
