Detect desynchronization #33
Conversation
|
The wording might need a bit of wordsmithing, the goal is not to endlessly cache delta serials & hashes, but just check for the last 100 or 200 whether the server is rewriting history. In the RPKI RRDP this approach has proven useful |
|
Might edit words a bit, but it's a good scenario to detect, and I think this approach is light enough to expect the client to run every minute. |
|
Rephrased a bit to make clear what the exact comparison is. And changed client behaviour to just reject on mismatch: it indicates something very wrong with the server, and rejecting further updates and logging errors seems like a better approach. |
|
The advantage of switching to the Snapshot is that it automatically resets the state to something consistent. I think this auto repair is desirable over "halt and catch fire", because ultimately the administrator will want to reset the state anyway. So logging an issue and automatic remediation would be my preference, just like is done in RRDP |
|
But it resets the state to something consistent generated by a really broken nrtmv4 server implementation. If we know the server can't generate correct deltas, what makes us think it will generate a correct snapshot? Why trust anything it says until it is actually fixed? |
Modeled after https://www.ietf.org/archive/id/draft-ietf-sidrops-rrdp-desynchronization-00.html