Incompatible changes, security, and good practice

[Daniel Franke]

On 10/6/16, Gary E. Miller <gem at rellim.com> wrote:
> This is NOT an all or nothing decision.  There are other ways to
> mitigate this problem that do not involve major silent breakage.

You've argued this a few times, but you still haven't specified what
you have in mind.

Here's one option that came to mind recently. I'm not necessarily
advocating it, just pointing out that it's possible.

I think you mentioned that you'd be happy with just changing "peer" to
be a synonym for "server", which basically amounts to desupporting
symmetric active mode and changing those systems to behave as ordinary
clients.

I could make a similar change to the way symmetric passive mode works:
when a host gets a symmetric active mode request, immediately reply
with a symmetric passive response, but *don't* set up a new
association. Basically, respond in the same way it would respond to a
client-mode packet, just with the mode field in the response changed
from 4 to 2.

So, if you update the passive side, symmetric active peers keep
working. The passive side will no longer sync to the active side, but
the active side will keep syncing to the passive side. If you update
the active side, it switches to just being a client of the passive
side, and therefore continues syncing to it.

This still ends up being a silent behavior change, because passive
peers silently stop syncing to the active peers. But it achieves
security, and breaks fewer things.