Re: [btns] Q: How to deal with connection latch breaks?

[Nicolas Williams <[e-mail]>]

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