1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
\section{Background} \label{ctga:sec:background}
First additional prerequisites are provided on CT and the status quo,
then the techniques which allow us to program custom packet processors are
introduced.
\subsection{Certificate Transparency} \label{ctga:sec:background:ct}
The main motivation of CT is that the CA ecosystem is error-prone~\cite{laurie}:
a CA can normally issue certificates for \emph{any} domain name, and
given that there are hundreds of trusted CAs an attacker only needs to
target the weakest link~\cite{ca-ecosystem}.
While the requirement of CT logging all certificates cannot prevent mis-issuance
proactively, it allows anyone to detect it retroactively by monitoring the
logs~\cite{ct}. After a log promises to include a certificate by issuing a
Signed Certificate Timestamp (SCT), a new STH including the appended certificate
must be issued within a Maximum Merge Delay (MMD). Typically, logs use 24~hour
MMDs. Should non-included SCTs and/or inconsistent STHs be found,
binding evidence of misbehaviour exists because these statements are
digitally signed by the logs. Other than MMD a log's policy defines parameters
such as STH frequency:
the number of STHs that can be issued during an MMD, making it harder to
track clients~\cite{ietf-gossip}.
CT is being deployed across Apple's platform~\cite{apple-ct} and Google's
Chrome~\cite{google-ct}. The status quo is to trust a CA-signed certificate if
it is accompanied by two or more SCTs, thereby relying on at least one log to
append each certificate so that mis-issuance can be detected by monitors that
inspect the logs. The next step of this incremental deployment is to
\emph{verify} that these certificates are logged by querying for
inclusion~\cite{google-gossip}, and that the log's append-only property is
respected by challenging the log to prove STH consistency. Finally, to fully
distrust CT logs we need mechanisms that detect split-views. One such mechanism
which is based on programmable packet processors (introduced next) is presented
in Section~\ref{ctga:sec:design}, and it is compared to related work on CT gossip in
Section~\ref{ctga:sec:related}.
\subsection{Programmable Data Planes} \label{ctga:sec:background:pdp}
Packet processors such as switches, routers, and network interface cards
are typically integrated tightly using customized hardware and application-%
specific integrated circuits. This inflexible design limits the
potential for innovation and leads to long product upgrade cycles, where it
takes \emph{years} to introduce new processing capabilities and support for
different protocols and header fields (mostly following lengthy
standardization cycles).
The recent shift towards flexible \emph{match+action} packet-processing
pipelines---including
RMT~\cite{rmt},
Intel Flexpipe~\cite{flexpipe},
Cavium XPA~\cite{cavium}, and
Barefoot Tofino~\cite{barefoot}---%
now have the potential to change the way in which packet processing hardware is
implemented:
it enables programmability using high-level languages, such as P4,
while at the same time maintaining performance comparable to fixed-function
chips.
\subsubsection{P4}
The main goal of P4 is to simplify
\barbelow{p}rogramming of
\barbelow{p}rotocol-independent
\barbelow{p}acket
\barbelow{p}rocessors
by providing an abstract programming model for the network data plane~\cite{p4}.
In this setting, the functionality of a packet processing device is specified
without assuming any hardwired protocols and headers. Consequently, a P4 program
must parse headers and connect the values of those protocol fields to the
actions that should be executed based on a pipeline of reconfigurable
match+action tables.
Based on the specified P4 code, a front-end compiler generates a high-level
intermediate representation that a back-end compiler uses to create a target-%
dependent program representation. Compilers are available for several platforms,
including
the software-based simple switch architecture~\cite{p4bm},
SDNet for Xilinx NetFPGA boards~\cite{p4netfpga}, and
Netronome's smart network interfaces~\cite{p4netronome}.
It is also possible to compile basic P4 programs into eBPF byte
code~\cite{p42ebpf}.
\subsubsection{XDP}
The Berkeley Packet Filter (BPF) is a Linux-based packet filtering
mechanism~\cite{bpf}. Verified bytecode is injected from user space, and
executed for each received packet in kernel space by a just-in-time compiler.
Extended BPF (eBPF)
enhances the original BPF concept, enabling faster runtime and many new
features. For example, an eBPF program can be attached to the Linux traffic
control tool \texttt{tc}, and additional hooks were defined for a faster eXpress
Data Path (XDP)~\cite{xdp}. In contrast to the Intel Data Plane Development Kit
(DPDK), which runs in user space and completely controls a given network
interface that supports a DPDK driver, XDP cooperates with the Linux stack to
achieve fast, programmable, and reconfigurable packet processing using C-like
programs.
|
