IPC M2 Critical Issues

[matejpavlovic]

This is a meta-issue for tracking progress on IPC M2 that relates to Mir and Trantor.

• Cleanup
  • Sanitize external events and messages #186 (3d)
  • Make sure that the starting checkpoint is consistent with params #404 (1d)
  • Add stack traces to errors #425 (3d)
  • Remove deprecated use of duplicated types due to now resolved issue #356 #430 (<1d)
  • PBFT inViewChange variable effectively not used. #438 (1d)
  • Declare generated code as such #450 (<1d)
• Enhancements
  • Implement weighted voting in Trantor #394 (1w)
  • Write a high-level description of Trantor #451 (1-2w)
  • Trantor Performance Evaluation #392 (2w) - only do after the above is resolved, may slip a bit

[ranchalp]

I feel like #402 is critical for M2 as well, although I agree with your comment to that issue that it is non-trivial at all.

[matejpavlovic]

Well, I'd say it is not critical if we accept to be vulnerable to long-range attacks for M2. And personally I'd say it should be acceptable for now.

[ranchalp]

Are you sure the only vulnerability of the way we currently handle non-verified stable checkpoints is that? It seems to me like we just restore the state if we receive a checkpoint far ahead enough in the future, and is precisely those that we may not be able to verify (and in the current believe we just "believe").

If we just dropped anything that is far ahead enough but that we cannot verify then we would risk being to available. But unless I am missing something, it seems too easy for the adversary to break safety in the aforementioned way, so assuming some level of synchrony is a far more reasonable assumption.

[matejpavlovic]

Not quite sure I understand what you mean. To answer your question, I'm not sure about that being the only potential vulnerability. But regarding the verification of checkpoints we restore our state from, until external membership verification is implemented, we fundamentally face a safety vs. liveness dilemma. If we get a checkpoint far ahead in the future (we currently restore state from any checkpoint from the future, btw.), currently we choose liveness over safety - we just "believe" the checkpoint. If we didn't believe it, we risk loosing liveness if the checkpoint is genuine (everybody already garbage-collected their state we are in and the checkpoint is our only way to catch up).

Of course this is a severe problem and I'd like to have it fixed ASAP, ideally before M2. Let's see what can be done after we fix the other issues that are equally critical.

[ranchalp]

What I mean is whether the adversary sending a fake checkpoint for any time far enough in the future, assuming the recipient just believes it, can, even if liveness is guaranteed, cause undefined behavior of the recipient. This is because the recipient has already assumed the checkpoint he received in the past as valid and prepped state for the future according to it.
If the above scenario is not possible in synchrony, then I agree with you that this is not M2 critical. Otherwise, this is an important consideration that goes beyond liveness vs. safety.