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

[Michael Richardson <mcr at sandelman.ottawa.on.ca>]

>>>>> "Julien" == Julien Laganier <Laganier> writes:
    Julien> Not sure I caught all the details of the discussion, but
    Julien> just to make sure I understand correctly: If a peer
    Julien> restarts, DPD will eventually detect it, and then the peers
    Julien> can proceed with re-establishing IKE and CHILD SAs. In the
    Julien> BTNS case where the BTNS IKE SA gets re-established after
    Julien> DPD, each of the BTNS peers can verify that they're talking
    Julien> to the same peer right? 

yes. The channel-binding information that would be maintained by at
least one of the peers (even if the application does not ask for it),
would indicate if it was the same peer.

    Julien> Thus I think the latches shouldn't
    Julien> be broken automatically when DPD concludes a peer is
    Julien> dead. They should only be broken in case it's not possible
    Julien> to re-establish a BTNS IKE SA after DPD, or a BTNS IKE SA
    Julien> can be established but to a different peer.

1) "not possible to re-establish a BTNS IKE SA after DPD"
this may be hard to define.

2) "BTNS IKE SA can be established but to a different peer."
this is easy to define, and we are all in agreement about this.
(And why treating it like a TCP RST may be appropriate)

For (1) the best we can do is to let the ULP timeout, I think.

-- 
]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby  guy");  [