Subject: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?])

From: Nicolas Williams <[email-masked]>
Date: Wed, 12 Aug 2009 13:57:19 -0500

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-masked]> -----

Date: Wed, 12 Aug 2009 13:06:08 -0500
From: Nicolas Williams <[email-masked]>
Subject: Re: [btns] Q: How to deal with connection latch breaks?
To: Michael Richardson <[email-masked]>
Cc: [email-masked]

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-masked]
https://www.ietf.org/mailman/listinfo/btns

----- End forwarded message -----

---

From: Yoav Nir <[email-masked]>
Date: Thu, 13 Aug 2009 09:33:41 +0300

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-masked] [mailto:[email-masked]] On Behalf Of Nicolas Williams
Sent: Wednesday, August 12, 2009 9:57 PM
To: [email-masked]
Subject: [IPsec] Can off-path attackers trigger DPD ([FWD: Re: [btns] Q: How to deal with connection latch breaks?])

Thanks,

Nico

----- Forwarded message from Nicolas Williams <[email-masked]> -----

Possible wrinkle:

Rationale:

Nico

----- End forwarded message -----
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

Email secured by Check Point

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 13 Aug 2009 10:57:34 -0500

On Thu, Aug 13, 2009 at 09:33:41AM +0300, Yoav Nir wrote:
> 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.

Thanks!  That's all I needed.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 13 Aug 2009 16:37:43 -0500

> RFC 4306 calls it, "liveness check"). These messages are very easy to

Also, my reading of RFC4306 is that unprotected INVALID_IKE_SPI or
INVALID_SPI messages can trigger DPD, but the ensuing liveness check
should be cryptographically protected.  Can you confirm?

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 13 Aug 2009 16:57:23 -0700

Nicolas Williams wrote:
> Sent: Thursday, August 13, 2009 2:38 PM
> To: Yoav Nir
> Cc: [email-masked]
> Subject: Re: [IPsec] Can off-path attackers trigger DPD ([FWD: Re:
> [btns] Q: How to deal with connection latch breaks?])
> 

FWIW this is what I understand as well from the RFC4306 excerpt below:

   Receipt of a fresh cryptographically protected message on an IKE_SA
   or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its
   CHILD_SAs.

--julien

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 14 Aug 2009 12:38:14 +0300

Nicolas Williams writes:
> INVALID_SPI messages can trigger DPD,

Yes. As can sending ESP packets with unknown SPI or sending ICMP
host/protocol unreachable etc... I.e. if other end feels that the
other end might not be there because it receives some messages from
the net which would give that kind of hints, it trigger DPD. 

> but the ensuing liveness check

The actual DPD is cryptographically protected, and will cause the
IKE/IPsec SAs to be deleted only after "It is suggested that messages
be retransmitted at least a dozen times over a period of at least
several minutes before giving up on an SA, but different environments
may require different rules." (from 4306). 
-- 
[email-masked]