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

["Laganier, Julien" <[e-mail]>]

Nico,

Pls. see below.

Nicolas Williams wrote:
> 
> 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.

Not sure I caught all the details of the discussion, but just to make sure I understand correctly: If a peer restarts, DPD will eventually detect it, and then the peers can proceed with re-establishing IKE and CHILD SAs. In the BTNS case where the BTNS IKE SA gets re-established after DPD, each of the BTNS peers can verify that they're talking to the same peer right? Thus I think the latches shouldn't be broken automatically when DPD concludes a peer is dead. They should only be broken in case it's not possible to re-establish a BTNS IKE SA after DPD, or a BTNS IKE SA can be established but to a different peer.

--julien