Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
briar
briar
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 695
    • Issues 695
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 14
    • Merge Requests 14
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • briar
  • briarbriar
  • Issues
  • #1326

Closed
Open
Opened Jun 22, 2018 by akwizgran@akwizgranOwner

Prevent old messages from aborting client protocols

Some client protocols that use an abort message to reset the state machine are vulnerable to a race condition where incoming messages that were already in flight when the abort message was sent are received after resetting, causing further aborts. This is harmless if the state machine is still in the start state when the messages are received, but it may cause problems if the state machine has moved out of the start state.

The problem can be avoided by using an abort counter:

  • Each party keeps a counter for each other party they sync with
  • The counter is part of the session state
  • The counter is initialised to zero
  • The counter is reset to zero if the other party is removed as a contact
  • The counter is included in every outgoing message
  • Incoming messages with counters lower than the local counter are ignored
  • The counter is incremented after sending or receiving an abort message

If two parties concurrently abort the protocol they may ignore each other's abort messages, but this appears to be harmless: either both will increment their counters once, or both twice.

Client protocols that use abort messages without counters will need to be upgraded to accommodate counters. It may be possible to do this with a minor version upgrade.

Edited Jun 22, 2018 by akwizgran
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: briar/briar#1326