more

sections/abstract.tex

@@ -2,8 +2,8 @@ Distributed protocols are the lynchpin of the modern internet,
 underpinning every internet service. 
 This has in turn motivated a massive amount of research ensuring the security, 
 reliability, and performance of distributed protocols. 
-A wide-ranging assumption in these works is assuming distributed
-protocols operate over \textit{faulty} or 
+In these works, a wide-ranging assumption is that distributed
+protocols operate over \textit{imperfect} or 
 \textit{attacker-controlled} channels, where messages can be arbitrarily 
 inserted, dropped, replayed, or reordered. 
 Formal methods work formally verifying distributed protocols 

sections/appendix-revised.tex

@@ -129,7 +129,7 @@ By the previous argument the $\exists$ASP problem corresponds to \ba language in
 \end{proof}
 
 \subsection{Priorities \& On-the-fly B\"uchi Automata Composition}%
-\label{sub:Priority \& On-the-fly B\"uchi Automata Composition}
+\label{sub:Priority}
 
 As described in Appendix Section \ref{sub:Proofs of Soundness and Completeness}, \spin reduces verification problems to deciding B\"uchi Automata intersection emptiness. That is, given $n$ B\"uchi Automata programs $P_1,\ldots.,P_n$, \spin decides:
 \[

sections/case_studies.tex

@@ -1,6 +1,6 @@
 %!TEX root = ../main.tex
 
-In this section we describe two case studies: the Transmission Control Protocol (TCP), a data transfer protocol, and Raft, a state machine replication protocol.
+In this section we describe three case studies: the Transmission Control Protocol (TCP), a data transfer protocol, SCTP, another data transfer protocol, and Raft, a state machine replication protocol.
 
 \subsection{TCP}%
 \label{sub:TCP}
@@ -69,6 +69,10 @@ $\phi_4$ & \rule{0pt}{8pt} x & & & & & & x & & \\
 
 \end{comment}
 
+\subsection{SCTP}%
+\label{sub:SCTP}
+SCTP is a transport-layer protocol proposed as an alternative to TCP, featuring a four-way handshake, multi-homing, and multi-streaming. Among other use cases, SCTP is the data transfer protocol for various telecoms signaling protocols as well as WebRTC. For our analysis, we borrow the ten LTL properties and \promela models derived from the SCTP RFCs as described in \cite{Ginesin2024}. We evaluated the SCTP \promela model against \korg's drop, replay, and reordering attacker models on a single uni-directional communication channel. The drop attacker model was specified to max out at three dropped packets, while the replay and reordering attacker model was specified to max out at two packets. SCTP is designed to resist drop, replay, and reordering attackers \cite{rfc9260}, and we employ \korg to exhaustively demonstrate this is the case.
+
 \subsection{Raft}%
 \label{sub:Raft}
 Raft is a consensus algorithm designed to replicate a state machine across distributed peers, and sees broad usage in distributed databases, key-value stores, distributed file systems, distributed load-balancers, and container orchestration. Historically, verification efforts of Raft using both constructive, mechanized proving techniques \cite{Woos_Wilcox_Anton_Tatlock_Ernst_Anderson_2016, Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson, Ongaro} and automated verification \cite{Ongaro} have reasoned about the protocol under certain assumptions about the stability of the communication channels. Previously, Raft has been proven to maintain properties of interest with respect volatile, attacker-controlled channels constructively using Rocq\footnote{Previously known as Coq} \cite{Wilcox_Woos_Panchekha_Tatlock_Wang_Ernst_Anderson}. However, no previous approach to Raft verification has reasoned explicitly about a coordinated, arbitrary on-channel attacker \textit{external} to the protocol itself. Uniquely, \korg enables us to study Raft in this context.
@@ -109,10 +113,6 @@ Dropping AppendEntryResponse messages & no \\
 \end{figure}
 In our experiments, we found just one attack on our \texttt{raft-bug.pml} \promela model, violating election safety in particular. In this scenario, peer A and peer B are candidates for election. Peer A receives three votes, one from itself and two from other peers, and Peer B receives two votes, one from itself and one from another peer. The replay attacker simply replays the vote sent to peer B. Then, both Peer A and Peer B are convinced they won the election and change their state to leader. Following this, leader completeness is also naturally violated. In this scenario, \korg demonstrates its ability to discover subtle bugs in protocol logic, exploiting the buggy Raft implementation. 
 
-\subsection{SCTP}%
-\label{sub:SCTP}
-SCTP is a transport-layer protocol proposed as an alternative to TCP, featuring a four-way handshake, multi-homing, and multi-streaming. Among other use cases, SCTP is the data transfer protocol for various telecoms signaling protocols as well as WebRTC. For our analysis, we borrow the ten LTL properties and \promela models derived from the SCTP RFCs as described in \cite{Ginesin2024}. We evaluated the SCTP \promela model against \korg's drop, replay, and reordering attacker models on a single uni-directional communication channel. The drop attacker model was specified to max out at three dropped packets, while the replay and reordering attacker model was specified to max out at two packets. SCTP is designed to resist drop, replay, and reordering attackers \cite{rfc9260}, and we employ \korg to exhaustively demonstrate this is the case.
-
 % these attacker models, and we employ \korg to exhaustively demonstrate this is the case.
 
 %our Raft model satisfies $\phi_1$-$\phi_5$ assuming perfect channels, and \korg allowed us to reason precisely about the effect of imperfect, vulnerable channels.

sections/design.tex

@@ -189,7 +189,7 @@ BREAK: }
 \end{figure}
 
 \textbf{Reorder Attacker Gadget Implementation}.
-The final and most complex gadget \korg implements is an attacker that can \textit{reorder} messages on a channel. The gadget works as follows. The attacker model gadget comes with a pre-defined message limit value \texttt{lim}, which defines the length of the gadget storage FIFO buffer \texttt{gadget\_mem}. The gadget also has the highest \textit{execution priority} in the system, which ensures the gadget can always reorder messages on the victim channel without other processes interfering. The gadget first enters the \texttt{INIT} state --- in this state, the gadget non-deterministically chooses to pass messages on the victim channel, or transition to the \texttt{CONSUME} state. In the \texttt{CONSUME} state, the gadget consumes each message it sees and stores them in \texttt{gadget\_mem}, a FIFO buffer. Upon consuming each message from the victim channel, \texttt{lim} is decremented. Once \texttt{lim=0}, the gadget transitions to \texttt{REPLAY}. Then, messages are randomly selected from \texttt{gadget\_mem} to be replayed back onto the channel. Note, because \texttt{gadget\_mem} is a FIFO buffer, we must rotate messages within the channel in order to randomly select a value from it. Additionally, messages can also be nondeterministically removed from \texttt{gadget\_mem}, as all messages do not necessarily need to be replayed. Once \texttt{gadget\_mem} is empty, the gadget transitions to the \texttt{BREAK} state. An example gadget automatically synthesized with \korg against the channel \texttt{cn} is shown in figure \ref{lst:korg_reordering}.
+The final and most complex gadget \korg implements is an attacker that can \textit{reorder} messages on a channel. The gadget works as follows. The attacker model gadget comes with a pre-defined message limit value \texttt{lim}, which defines the length of the gadget storage FIFO buffer \texttt{gadget\_mem}. The gadget also has the highest \textit{execution priority} in the system, which ensures the gadget can always reorder messages on the victim channel without other processes interfering. Further details describing how \spin handles execution priority is provided in Appendix section \ref{Priority}. The gadget first enters the \texttt{INIT} state --- in this state, the gadget non-deterministically chooses to pass messages on the victim channel, or transition to the \texttt{CONSUME} state. In the \texttt{CONSUME} state, the gadget consumes each message it sees and stores them in \texttt{gadget\_mem}, a FIFO buffer. Upon consuming each message from the victim channel, \texttt{lim} is decremented. Once \texttt{lim=0}, the gadget transitions to \texttt{REPLAY}. Then, messages are randomly selected from \texttt{gadget\_mem} to be replayed back onto the channel. Note, because \texttt{gadget\_mem} is a FIFO buffer, we must rotate messages within the channel in order to randomly select a value from it. Additionally, messages can also be nondeterministically removed from \texttt{gadget\_mem}, as all messages do not necessarily need to be replayed. Once \texttt{gadget\_mem} is empty, the gadget transitions to the \texttt{BREAK} state. An example gadget automatically synthesized with \korg against the channel \texttt{cn} is shown in figure \ref{lst:korg_reordering}.
 
 % The attacker model gadget comes with a pre-defined message limit value \texttt{lim}, which defines the length of the gadget storage FIFO buffer \texttt{gadget\_mem}. Then, the gadget enters the \texttt{CONSUME} state and nondeterministically chooses messages on the channel \texttt{cn} to copy into \texttt{gadget\_mem}. Once \texttt{lim=0}, the gadget transitions into the state \texttt{REPLAY}, where items are randomly selected from \texttt{gadget\_mem} to be replayed back onto the channel. Note, because \texttt{gadget\_mem} is a FIFO buffer, we must rotate messages within the channel in order to randomly select a value from it. Additionally, messages can also be nondeterministically removed from \texttt{gadget\_mem}, as all messages do not necessarily need to be replayed. Once \texttt{gadget\_mem} is empty, the gadget transitions to the \texttt{BREAK} state.