Modeling and Analysis of the SCION Dataplane in Tamarin

Research Collection

Master Thesis

Modeling and Analysis of the SCION Dataplane in Tamarin

Author(s):

Frankovska, Zuzana Publication Date:

2021

Permanent Link:

https://doi.org/10.3929/ethz-b-000477332

Rights / License:

In Copyright - Non-Commercial Use Permitted

This page was generated automatically upon download from the ETH Zurich Research Collection. For more

information please consult the Terms of use.

of the SCION Dataplane in Tamarin

Master Thesis Zuzana Frankovsk´ a

25 ^th March, 2021

Professor: Prof. David Basin

Supervisors: Dr. Christoph Sprenger, Dr. Ralf Sasse, and Tobias Klenze

Department of Computer Science, ETH Z¨ urich

Abstract

The Internet we use today has not been designed to be as secure as we need it to be. New future Internet architectures, such as SCION, are being designed with stronger security demands. SCION includes a controlplane protocol for discov- ering the network topology and designating authorized paths, and a dataplane protocol for transferring data packets along authorized paths.

In this thesis, we study not only the initial dataplane protocol used in SCION, but also the protocol used in the SCION implementation by Anapaya, and the four protocols in the EPIC family, which can also be used in the SCION architec- ture. The analyzed security properties of these protocols are path authorization, packet authentication, source authentication, and path validation. By achieving these properties, the protocols can help in preventing various routing attacks and provide more control over the paths traversed by packets.

We analyze the security properties by symbolic modeling of the protocols and

automatic verification in the Tamarin tool. This gives us formal guarantees of

the security of the studied protocols. We are able to model the protocols for

an arbitrary network topology and an arbitrary set of authorized paths, but the

maximum length of authorized paths has to be limited. Furthermore, we create

an infrastructure that can be easily reused for analyzing more similar protocols

and properties in the future.

I want to thank my supervisors for spending a lot of time guiding me through this thesis and for all their feedback. Namely, I want to thank Christoph Sprenger for proposing the project and laying the foundation for my work, Ralf Sasse for his help with the peculiarities of Tamarin, and Tobias Klenze for being able to understand my models and always having many ideas.

I am thankful to Prof. David Basin for the opportunity to do this thesis in his

research group.

Contents

1 Introduction 1

1.1 Motivation . . . . 1

1.2 Contributions . . . . 2

1.3 Related Work . . . . 3

1.4 Outline . . . . 3

2 Background 4 2.1 SCION . . . . 4

2.1.1 SCION Controlplane . . . . 5

2.1.2 SCION Dataplane . . . . 6

2.1.3 Implementation by Anapaya . . . . 7

2.2 EPIC . . . . 8

2.2.1 Level 0 . . . . 8

2.2.2 Level 1 . . . . 8

2.2.3 Level 2 . . . . 9

2.2.4 Level 3 . . . . 10

2.3 Security Properties . . . . 11

2.4 Tamarin . . . . 12

2.4.1 Terms . . . . 12

2.4.2 Rules . . . . 13

2.4.3 Properties . . . . 15

2.4.4 Proof search . . . . 16

3 Attacker Model 18 3.1 Classic Dolev–Yao . . . . 18

3.2 Localized Dolev–Yao . . . . 19

4 Modeling Security Properties 22 4.1 Path authorization . . . . 22

4.2 Packet authentication . . . . 25

4.3 Source authentication . . . . 27

4.4 Path validation . . . . 27

5 SCION Dataplane Model 31

5.1 Infrastructure rules . . . . 31

5.2 Protocol rules . . . . 34

6 Anapaya Implementation model 39 7 EPIC protocol model 42 7.1 Level 0 . . . . 42

7.2 Level 1 . . . . 42

7.3 Level 2 . . . . 44

7.3.1 Localized Dolev–Yao . . . . 44

7.3.2 Classic Dolev–Yao . . . . 46

7.3.3 Protocol rules . . . . 46

7.4 Level 3 . . . . 48

8 Fixed Network Topology 50 8.1 Generating topologies . . . . 50

8.2 Generating authorized paths . . . . 51

8.3 Model with fixed topology . . . . 51

9 Experiments 54 9.1 Infrastructure . . . . 54

9.2 Speed improvements . . . . 54

9.3 Results . . . . 56

10 Conclusion 59 10.1 Discussion . . . . 59

Bibliography 61

Chapter 1

Introduction

1.1 Motivation

While the Internet is widely used for many different purposes today, it was not designed with such scale and versatility in mind. The underlying protocols are outdated and have many security vulnerabilities. The routing is based on the insecure Border Gateway Protocol.

The vulnerabilities have become a significant issue since today’s society heavily relies on the Internet, using it for banking, voting, and more. For some of them, there are existing solutions working on top of the old architecture, but they are constrained by the old design and often too slow to be used in practice. For others, such as distributed denial of service attack, there are no solutions without spending a large amount of resources, which not everyone can afford. The goal of the SCION project [1] is to completely redesign the infrastructure of the Internet from a clean slate, greatly improving security, privacy and trust, while retaining high efficiency. Currently, there already exists a working implementation of SCION by Anapaya [2].

In the current Internet, there is little control over the paths that packets travel, and that leaves space for various routing attacks. One of the guarantees that SCION aims to provide is path authorization, which means that packets can travel only along paths that are authorized for them. This could prevent some of the routing attacks and enable new functionality of the net- work. Network operators can enforce routing policies, balance the amount of traffic between different routes to increase efficiency, or even offer different routes at different prices. Even stronger guarantees would be packet authentication, source authentication, and path validation, which are promised by the EPIC dataplane protocols [3] that can be used with the SCION architecture. Packet authentication prevents modifications of the packet. Source authentica- tion forbids spoofing the source address and thus provides accountability for each packet.

Path validation gives assurance about the traveled path to the source or the destination of the packet. Together, these security properties help to prevent many attacks that are nowadays very concerning, but also create possibilities for new ways how to make the Internet faster and fairer.

There are tools that can help to prove that these properties hold by automating parts of the

process. One such tool is Tamarin [4], which provides static automatic verification of symbolic

protocol models. Automatic verification can greatly speed up the proving process and pro-

vide formal guarantees and thus also greater credibility of the results. Additionally, once we

have specified a model in Tamarin for one protocol, it is easy to modify it for more similar

protocols and quickly verify the properties. Modeling the protocols in Tamarin introduces

a few challenges. To analyze the above-mentioned properties, we have to take into account that there can be arbitrarily many participants in a single protocol run, since each on-path AS is participating. Furthermore, we are not only interested in one authorized path, but how different paths, some of them authorized, can interact with each other. For example, we are interested in observing whether the adversary can combine two authorized paths to create a path that is not authorized, and send a packet along that path.

1.2 Contributions

The aim of this work is to model the SCION Dataplane protocol and multiple alternative protocols in Tamarin and analyze their security properties. Multiple variants of the protocol are modeled, namely:

• the initial design of the SCION dataplane protocol

• the protocol used in the implementation by Anapaya

• four levels of the EPIC protocols

The relevant security properties analyzed are path authorization, packet authentication, source authentication, and path validation. Path validation has two variants, defined for the destina- tion and for the source. The attacker model is a localized variant of the Dolev–Yao adversary for path authorization and the classic Dolev–Yao model for the rest.

We describe the Tamarin models for each protocol and each attacker model. We show that these properties can be verified for an arbitrary topology and an arbitrary set of authorized paths, as long as we limit the maximum length of authorized paths. All the security prop- erties that are expected to be satisfied are indeed verified by Tamarin for an arbitrary set of authorized paths up to a given length. The verified properties and the maximum authorized path lengths are listed in Table 1.1. If the entry in the table is ’N/A’, it means that the given property is not supposed to hold for the given protocol, therefore it was not analyzed in this thesis.

SCION Anapaya EPIC L0 EPIC L1 EPIC L2 EPIC L3

path authorization 25 11 25 21 15 15

packet authentication N/A N/A N/A N/A 18 18

source authentication N/A N/A N/A N/A 16 16

path validation (dest) N/A N/A N/A N/A N/A 6

path validation (source) N/A N/A N/A N/A N/A 6

Table 1.1: Maximum length of authorized paths for which the listed security properties were verified for the listed protocols

We create a script that can generate a Tamarin theory file for a given maximum authorized

path length for a specified protocol model. Additionally, we can also generate Tamarin theory

files with fixed topologies. We create a script generating different fixed network topologies

with a fixed set of authorized paths, with options to specify parameters and various condi-

tions. These scripts are a part of an infrastructure for generating Tamarin theory files and

subsequently running Tamarin on the theory files. It can be reused for other similar protocols

in the future.

1.3. Related Work

1.3 Related Work

The studied dataplane protocols are described in the following works. The initial design of the SCION dataplane is described in the book ”SCION: A Secure Internet Architecture”

published in 2017 [1]. The protocol used in the implementation by Anapaya is described in the documentation on their website [2]. The EPIC protocols were introduced by Legner et al.

in 2020 [3]. The security properties of the SCION protocol and the EPIC protocols are argued theoretically in these works. We do not know of the existence of any security proofs for the Anapaya protocol used in the implementation. There are also other designs of dataplane protocols, such as ICING [5] or OPT [6], which we do not study.

Security properties of numerous network protocols have been verified by various tools for either automatic or interactive verification. Paulson [7] used Isabelle/HOL [8], a generic proof assistant performing interactive verification, to model network protocols and prove their security properties. Coq [9], another proof assistant, was used by Zhang et al. [10] to prove source authentication and path validation of OPT. Tamarin has been previously used successfully for verification of security properties of network protocols such as TLS 1.3 [11]

or 5G [12]. It has even been used on a different part of the SCION architecture, the hidden paths [13].

More closely related to this thesis, path authorization for the SCION dataplane protocol and the EPIC L1 and L2 protocols has been verified in Isabelle/HOL by Klenze et al. in 2021 [14]. The paper mentions that the authors anticipated that Tamarin can be used for path authorization only with a small fixed topology and a fixed set of authorized paths, which we have disproven. The advantages of using Tamarin instead of Isabelle/HOL are that it performs the proof automatically and it is tailored for the analysis of security protocols.

Another advantage of using Tamarin for modeling the Anapaya protocol is that it has a built- in message theory for exclusive-or [15]. However, while the proofs in Isabelle/HOL hold for an arbitrary topology with an arbitrary set of authorized paths, in our models in Tamarin, we have to limit the maximum length of authorized paths.

1.4 Outline

This thesis is structured as follows. Chapter 2 introduces the studied protocols, the analyzed

security properties, and the Tamarin tool. In Chapter 3, we describe the two attacker models

we use in our models. In Chapter 4, we describe how we model the security properties. In

Chapters 5, 6, and 7, we describe the models for the initial SCION dataplane protocol, the

protocol used in Anapaya’s implementation, and the EPIC protocols, respectively. In Chap-

ter 8, we discuss how we can generate random network topologies and sets of authorized

paths, and subsequently modify the models to use a fixed topology. In Chapter 9, we de-

scribe the conducted experiments and present their results. Chapter 10 discusses the results

and concludes the report.

Background

2.1 SCION

SCION is a clean-slate future Internet architecture designed to provide route control, failure isolation, and explicit trust information for end-to-end communication [1]. It aims to improve availability, transparency, control, efficiency, scalability, and flexible trust.

The Internet is organized into networks called autonomous systems (AS). In SCION, ASes are organized into groups of independent routing planes called isolation domains (ISD). This sepa- ration provides the possibility for each ISD to agree on individual policies, keys, and author- ities. Entities outside an ISD cannot affect routing within that ISD. Traffic is divided into two levels – inside of a domain and between domains. A subset of ASes in an isolation domain forms the core, and so they are the core ASes. They are the root of trust for the ISD, they have the responsibility of managing the ISD, and only they are linked to the other ISDs, so they facilitate inter-domain communication. You can see an example of two ISDs in Figure 2.1.

Each small white circle represents an AS. From now on, we will be focusing only on the intra-domain traffic for the sake of simplicity.

Figure 2.1: Example of isolation domains in SCION

2.1. SCION SCION networking protocols are composed of two parts: controlplane and dataplane. The controlplane is used for discovering the topology and path information. It authorizes path segments by which packets can travel. The dataplane is used for forwarding data transfer.

There are three types of path segments. A path segment from a non-core AS to the core is an up-segment, a path segment from the core to a non-core AS is a down-segment and a path segment between core ASes is a core-segment. Figure 2.2 shows examples of these types of segments. A path traveled by a packet can be comprised of one or multiple of these segments, but at most one of each. From now on, we will be focusing only on the up-segments.

Figure 2.2: Example of different types of path segments in SCION

2.1.1 SCION Controlplane

The controlplane is responsible for discovering and distributing authorized paths. It also ensures that these paths are acyclic and fulfill any potential additional policies. Inside the ISD, core ASes are periodically and asynchronously looking for paths to authorize. This is done by beaconing, i.e. sending path-segment construction beacons (PCBs) to flood the network in the downward direction. That is the opposite direction to the data transfer in up-segments.

Every AS has beacon servers that create and propagate PCBs and path servers that manage the registration and lookup of authorized paths.

While traversing the ISD, PCBs collect information about ASes. A PCB consists of an info field and an AS entry for all traversed ASes. Each AS entry is signed and stores, apart from other information, a hop entry, which stores the information about its interfaces and a hop field. The hop field is composed of hop information (H I) and hop authenticators σ. The dataplane security properties will be expressed in terms of the information contained in these hop fields.

Next, we will show how the σs are computed. Let us say that we want to authenticate the

segment W − X − Y − Z from Figure 2.2. A beacon server at the core AS Z creates a PCB. For

the first AS entry corresponding to the AS Z, it computes σ

as a MAC of its hop information

H I

. The secret key K

is used for this MAC. This key is also shared among the AS’s routers.

σ

= MAC

( H I

) [[ 0 : l

]]

The notation [[ 0 : l

]] signifies truncating the byte string to the first l

bytes. The MACs are truncated for efficiency reasons. As the PCB travels down the network, the subsequent ASes also compute their σs, but they include the σ and the H I of the previous AS in their MAC.

For example, σ

and σ

are computed as follows.

σ

= MAC

( H I

|| H I

|| σ

) [[ _{0 :} l

]]

σ

= MAC

( H I

|| H I

|| σ

) [[ 0 : l

]]

This process creates a nested authenticator of the path. The last AS is W and its σ will be equal to the following, if we omit the truncation.

σ

= MAC

( H I

|| H I

||( MAC

( H I

|| H I

||( MAC

( H I

|| H I

||( MAC

( H I

))))) The hop information (H I) consists of an AS identifier, an ingress interface, and an egress in- terface. Each link going in or out of an AS has assigned a unique interface, thus each link between two neighboring ASes is uniquely identified by an ingress and an egress interface.

H I = IgIF || ID || EgIF

Once the PCB arrives at an AS, the AS can decide whether to authorize the path traveled by that PCB. This is decided and recorded by the path server. The path server turns the PCB into a path segment by signing it. An authorized segment is defined by a path description, which is a sequence of H Is, and a sequence of σs. This information is contained in hop fields.

Furthermore, each AS can decide whether or not to propagate the PCB forward.

2.1.2 SCION Dataplane

Once the authorized paths are established, the next step is data packet transfer. If an end host wants to send a packet, it inquires the path server and obtains an authorized segment.

Its signatures are stripped off and the information extracted is a path description and hop authenticators (σs). A path description is a sequence of hop information (H I). The source constructs the packet from this acquired data and the payload. It calculates hop validation fields (HVF) using σs, which are used for authentication. In this protocol, each HVF is simply equal to the corresponding σ. For example, if we take the network from Figure 2.2 and we suppose that an end host H

at the AS W wants to send a packet to an end host H

at Z, the packet would include the following information.

packet = ( src || dest || path || validation || payload ) src = ( W || H

)

dest = ( Z || H

)

path = ( H I

|| H I

|| H I

|| H I

)

validation = ( HVF

|| HVF

|| HVF

|| HVF

) = ( σ

|| σ

|| σ

|| σ

)

The source sends this packet on its path. It also contains a pointer indicating the current hop.

Every AS on the path checks whether the packet was received by the egress interface stated in

2.1. SCION H I, recomputes its HVF, and checks whether it matches the HVF in the packet. The packet is forwarded by the ingress interface from H I only if all checks succeed. In the initial SCION dataplane design, the HVF is a MAC of H I of the current and previous ASes and the HVF of the previous AS.

H I = ( IgIF || ID || EgIF )

HVF

= σ

= MAC

( H I

|| H I

|| HVF

) [[ 0 : l

]]

X is the current AS, Y is the previous one in the direction of beaconing, i.e. top-to-bottom.

These are simplified versions of the computations, omitting some fields that contain public information, which does not affect the security properties or info needed for transfer outside the scope of this work.

The interfaces are ingress (i.e., entrance) and egress (i.e., exit) for the beacon, however, the data transfer happens in the opposite direction. Therefore the packets enter the AS through the egress interface and leave through the ingress interface. This has to be kept in mind to avoid getting confused.

2.1.3 Implementation by Anapaya

The controlplane and dataplane protocols in SCION were designed as described above in Section 2.1.1 and Section 2.1.2, however, the actual implementation by Anapaya [2] includes slightly altered protocols. They utilize exclusive-or (XOR) to accumulate σs. A new variable β is introduced, which is initialized as a random number, recorded in β

.

In the controlplane, a newly created PCB includes β

. At every AS, σ is computed as a MAC of H I and the current β. Then, the next β is computed as XOR of truncated σ and the previous value of β. For example, at the AS Y, it is computed as follows.

σ

= MAC

( H I

|| β

) β

= β

⊕ σ

[[ 0 : 2 ]]

In the dataplane, HVF is again equal to σ. Every AS on the path updates the value of β and then recomputes HVF as follows.

β

= β

⊕ HVF

[[ 0 : 2 ]]

HVF

= MAC

( H I

|| β

)

An incoming packet includes the expected HVF

and the current β

. First, β

is computed with the HVF

from the input. Then, with the newly computed β

, HVF

is recomputed by the AS and compared to the expected HVF

. The packet is only accepted and forwarded if it was received on the interface contained in H I

and HVF

= HVF

.

This new protocol seems to be more complicated since it introduces a new variable, but in

practice, it is supposed to run faster. This is mainly due to limiting the number of conditional

statements needed in the implementation. However, it can be more complicated to prove its

security properties, especially since XOR is used, which has several algebraic properties that

an attacker may try to exploit. These are further described in Section 2.4.1. Using XOR opens

up many uncertainties, for example, what if at some point the variable β could become zero

and the adversary could use that to its advantage. The initial design included only a MAC,

which is one-way, and therefore it is easy to argue about in a security proof.

2.2 EPIC

EPIC [3] is a family of dataplane protocols that can be used in SCION, but also other future Internet architectures. These protocols provide stronger security properties than the initial SCION dataplane protocol or other existing dataplane protocols. They are aiming to make the Internet path-aware. This improved security does not come at the expense of efficiency. The acronym stands for ”every packet is checked” and that is because these protocols achieve their security properties by checking every single packet. It has 4 different levels, with increasingly stronger security.

2.2.1 Level 0

The zeroth level is almost identical to the original SCION design. The only difference for our purposes is that it omits the H I

in the MAC when computing σ. The σ computation is done as follows.

σ

= MAC

( H I

|| σ

) [[ 0 : l

]]

The only target security property is path authorization. Even though H I

is omitted, path authorization still holds, which will be verified in this work. Intuitively, it is because the MAC also contains σ

, which contains H I

, therefore including it twice is redundant.

2.2.2 Level 1

One shortcoming of the EPIC L0 protocol is that the σ is reused as an HVF for all packets traveling the same path. It is therefore vulnerable to brute-force attacks, especially if l

is made small for the sake of efficiency. The first level of EPIC solves this by using per-packet HVFs that include a unique timestamp of the packet. Level 1 introduces the following vari- ables: a segment identifier S and a validation field V. They are used when calculating per-packet HVFs.

In the controlplane, σs are calculated as follows. For the the first core AS, let us say Z, it is calculated as a MAC of just H I

. For all of the other ASes, it is calculated as a MAC of H I and the previous S, which is just a truncated σ. So, for the first three ASes Z, Y and X, σs are calculated as follows.

σ

= _MAC

( _{H I}

) S

= σ

[[ 0 : l

]]

σ

= MAC

( H I

|| S

) S

= σ

[[ 0 : l

]]

σ

= MAC

( H I

|| S

)

In the dataplane, a new variable V is added to the HVF, ensuring that HVF is unique for each packet. The source of a packet receives the path description and the σs from a path server. It calculates all HVFs as follows. First, it generates a packet timestamp ts

. Then, it computes V as a MAC of the timestamp and the source. The key used for the MAC is σ.

Finally, S and V are concatenated to create the HVF.

2.2. EPIC

V

= MAC

( ts

|| src )[[ 0 : l

]]

S

= σ

[[ 0 : l

]]

HVF

= S

|| V

As the packet traverses a network, each AS on the path recomputes its HVF and checks whether it matches the HVF included in the packet. The target security property is path authorization. A potential attack on path authorization is if an attacker can craft HVF for a link that is not authorized without knowing the MAC key K

. They can try guessing this HVF in a brute-force attack. Even if the attacker successfully guesses one HVF, it will only be valid for one timestamp. So, the attacker can only send packets with the same reused timestamp, however, this can be easily detected by a replay-suppression system. Being able to send a single packet by an unauthorized link is not assumed to be a real threat to the protocol.

Therefore, the benefit of the EPIC L1 protocol compared to the EPIC L0 protocol or the initial SCION protocol is that the value l

can be quite small, which helps its efficiency.

2.2.3 Level 2

The second level introduces new shared keys that provide the ability to authenticate the packet and the source. The shared key K

is a key shared between the ASes A and B. It is a Dynamically Recreatable Key (DRKey) [6], meaning it is derived from the secret key of the AS B by a pseudorandom function (PRF). This ensures that the AS B can recompute the key K

faster than fetching it from a key store. The AS A has to securely fetch it from a key store in order to use it.

K

= PRF

( A )

The controlplane collects the same information as in the EPIC L1 protocol. The difference is how the source calculates HVF. Instead of using σ

as the key for the MAC in V

, it uses the key K

and σ

in included in the contents of the MAC. So, the source computes HVF as follows.

σ

= MAC

( H I

|| S

) S

= σ [[ _{0 : l}

]]

V

= MAC

X

( ts

|| src || σ

) [[ 0 : l

]]

HVF

= S

|| V

This key K

is shared between the AS X and the source S. AS X is able to quickly derive the shared key K

and therefore authenticate the source S, since only those two entities have access to the key. The source has to securely fetch all of these shared keys from a key store in order to compute HVFs.

The derivation of these DRKeys is simplified for the purpose of this work. Here, the keys are

only dependent on the ASes, however, they should also be dependent on the end hosts. You

will see later that we are not distinguishing end hosts and their ASes, therefore we can allow

this simplification. Furthermore, in real life, the shared key would probably not be derived

directly from the MAC key. Each AS would have a secret master key, from which all other

keys would be derived, including the MAC key and the DRKey. However, we can model the protocol without this more complex key management system.

Another new component that the source computes and includes in the packet is a destination validation field V

. Its purpose is for the destination to be able to authenticate the packet. It is computed by the source as a MAC of the packet timestamp, the path, and the payload. The MAC key used is K

, a DRKey shared only between the source and the destination.

V

= MAC

D

( ts

|| path || payload )

Every on-path AS X recomputes the key K

and subsequently recomputes HVF

and checks whether it matches the HVF

included in the packet. The destination makes an additional check by recomputing V

and checking whether it matches the V

included in the packet.

The target security properties of this protocol are path authorization, packet authentication, and source authentication.

2.2.4 Level 3

In the third level, on-path ASes not only check the validation fields, but they overwrite them to prove that they were indeed on the path and they processed the packet. The controlplane is again the same. Let us define C

as a MAC of the packet timestamp, the source, and the σ, using the key shared between the current AS and the source. This is equal to how the variable V

is defined in the EPIC L2 protocol but without truncation. Now, we define V

to be equal to the first l

bytes of C

and V

to be equal to the next l

bytes, assuming that the C

has at least 2l

bytes.

C

= MAC

X

( ts

|| src || σ

) V

= C

[[ 0 : l

]]

V

= C

[[ l

: 2l

]]

AS autonomous system ISD isolation domain

PCB path-segment construction beacon H I hop information

HVF hop validation field K

secret key of X

MAC

message authentication code using key K IgIF ingress interface

EgIF egress interface σ hop authenticator S

segment identifier V

validation field

K

shared DRKey between X and Y, which can be efficiently calculated by X PRF

pseudorandom function using key K

V

destination validation field

Table 2.1: Abbreviations and notations

2.3. Security Properties In the dataplane, the sender includes V

s in the packet’s HVFs. Each AS X on the path first recomputes its C

and compares the computed V

to the one included in the packet in the HVF

. Then, it replaces V

with V

as a proof that the packet traverses the AS X.

These new validation fields V

s are also added to the destination validation field V

. The source includes the V

s for all ASes on the path that is intended for the packet.

V

= MAC

D

( ts

|| path || V

|| . . . || V

|| payload )

After receiving the packet, the destination recomputes V

to check whether all the intended ASes were traversed and thus validate the path. Then, if all checks succeed, it sends a con- firmation message back to the source with the packet timestamp and the updated validation fields V

s. To prevent circular confirmations, the message is sent using the EPIC L2 protocol.

The source can then check whether all the V

s are correct and present and thus also validate the path.

Table 2.1 gives an overview of the used abbreviations and notations.

2.3 Security Properties

In the paper introducing the EPIC protocols [3], the analyzed security properties are defined as follows.

Path authorization is satisfied when packets traverse the network only along paths autho- rized by all honest on-path ASes. These are the paths that ASes agreed on by the controlplane protocol. This property protects the ASes routing policies from a malicious sender trying to send a packet along an unauthorized path, for example, to obtain a better service than what they have paid for. There are some exceptions regarding compromised ASes. If a compro- mised AS receives a packet, it can send it along a different path than intended by the source, but only if this path is also authorized. It can also send it to another compromised AS that is adjacent, even though the link between these two compromised ASes is not authorized, or if there are other channels between the compromised ASes. The studied protocols cannot avoid these exceptions. In summary, we can say that path authorization ensures that each portion of the path that a packet traverses along honest ASes is authorized. There is no additional honesty assumption needed.

Packet authentication is satisfied when the destination agrees with the source on the packet origin, path, and payload, unless the destination or the source are corrupted. It provides basic authentication of the packet to the destination, i.e., a guarantee that the contents of the packet were not altered and a guarantee of where the packet originated. This is formalized as a non- injective agreement, which was defined by Lowe [16]. The path that was intended by the source is included in this authentication, which provides some guarantee to the destination about the path intended, but it does not ensure that the intended path is identical to the actually traversed path.

Source authentication is satisfied when every on-path AS agrees with the source on the

packet origin, unless the source or the on-path AS are corrupted. This is also formalized as a

non-injective agreement. This property is useful when the source is sending malicious traffic

because it provides accountability. It prevents spoofing the source address [17] and therefore

makes denial of service attacks easier to recognize and defend against. An important part of this property is that every on-path AS can verify the source, therefore spoofing can be detected before the packet arrives at the destination.

Path validation has two variants. Path validation for the destination is satisfied when the destination can verify that the packet traversed all honest ASes on the path intended by the source, unless the source or the destination are corrupted. Path validation for the source is satisfied when the source can verify that the packet traversed all honest ASes on the path intended by the source, unless the source itself is corrupted. It ensures that the actual path corresponds to the intended path. Unfortunately, we can only check whether all intended ASes were indeed on the path, but we cannot prove that no other ASes were on the path.

We cannot avoid a packet being sent on a detour by a compromised AS, returning to the same AS, and then continuing on the intended path. Also, the adversary can impersonate a compromised AS, so the packet does not have to actually traverse the compromised AS.

However, together with path authorization, it provides strong guarantees about the traversed path.

2.4 Tamarin

Tamarin is a security protocol verification tool that supports both falsification and unbounded verification in the symbolic model. It provides formal guarantees for security proofs. For Tamarin, we specify security protocols as multiset rewriting systems and they are analyzed with respect to first-order properties, a message theory and a user-defined rewriting theory [4] [18].

A protocol model consists of a specification of the actions available to each participating agent, a specification of the adversary, and a specification of the properties to be verified. A model in Tamarin is also called a theory. Tamarin will try to automatically construct a proof for the given properties, even if arbitrarily many instances of the protocol are executed in parallel.

Its search algorithm for trace properties is both sound and complete. Unfortunately, Tamarin is not guaranteed to terminate. If it terminates, its output is either a full proof of correctness for all possible traces or an example of a trace constituting an attack against the property.

Tamarin’s built-in attacker model is Dolev–Yao, but a different attacker model can be defined.

The Dolev–Yao attacker model is further discussed in Section 3.1.

2.4.1 Terms

The smallest building unit of a Tamarin theory are messages that are modeled as terms. They can be constants, variables, or functions. A constant is denoted by ’c’ and is public. Vari- ables can be public $x , fresh ~ x or temporal #x . Fresh variables are used for nonces or keys and are assumed to be unique and private. Temporal variables are used for timepoints and are only used when defining properties or restrictions. A variable denoted just by x can be mapped to any message.

There are two types of functions, built-in and user-defined. Tamarin provides common cryp-

tographic primitives defined in built-in message theories. By default, a newly defined function

is one-way. For example, to define a MAC function, we can just create a user-defined func-

tion of two variables, denoted by mac/2 in Tamarin. These variables are the key and the

content. As a default, a MAC can be computed by anyone who knows these two arguments

and the adversary can extract neither the key nor the content from a MAC. This is enough

2.4. Tamarin to symbolically define MACs and thus we do not need any additional equations. There are cryptographic primitives that need additional properties for an accurate representation.

These properties are modeled by equational theories. For example, relevant to this work is the function XOR. It is included in the built-in message theory xor [15]. In this theory, there are two functions defined: ⊕ /2 and zero/0. They satisfy the following equations.

x ⊕ y = y ⊕ x ( x ⊕ y ) ⊕ z = x ⊕ ( y ⊕ z )

x ⊕ zero = x x ⊕ x = zero

The possibility to model XOR in Tamarin enables faithful modeling of many security pro- tocols, including the one used in the SCION implementation by Anapaya, described in Sec- tion 2.1.3. However, it has been proven impossible for a symbolic model of XOR to be com- putationally sound [19]. A symbolic model is computationally sound if, for any protocol that is secure in the symbolic model, the same protocol is also secure in the computational model.

Moreover, reasoning about XOR in the symbolic model is challenging, and therefore using XOR considerably increases the search space because of the complex equational theory [12].

Two terms can be coupled together by the built-in pair/2 function. This can also be ex- pressed by the symbols < and > , so that <x,y> is the same as pair(x, y) . The projections fst and snd and used to access the first and the second element of a pair, respectively. The pair can be nested to form tuples, such as <w, <x, <y, z>>>, which can simplified to the expression <w, x, y, z> . This can function like an array of a fixed length. Unfortunately, Tamarin does not support structures like an array or doubly linked lists of an arbitrary length, and they are not easy to implement by the existing infrastructure. However, if we nest pairs, we can get a stack of arbitrary depth. For example, <w, <x, <y, z>>> can be represented by <w, X> , where X is the rest of the stack. The term w is on top and thus it is the only directly accessible element by the fst projection. If we apply the snd projection, we get the rest of the stack. The last element cannot be accessed without knowing the exact depth of the stack.

2.4.2 Rules

Every state of the protocol is defined by a multiset of facts that are true at that point. The initial state is the empty multiset. Facts are of the form F ( t

, ..., t

) for a fact symbol F and terms t

. They can represent, for example, the current state of a participating agent or the existence of a key. A change of the state of the protocol is achieved by applying rewrite rules.

A rewrite rule consists of a multiset of facts on the left-hand side, a multiset of facts on the right-hand side, and a multiset of action facts labeling the rule. To execute a rule, instances of all facts on the left-hand side must be present at the current state. By executing the rule, they are consumed and replaced by instances of facts on the right-hand side. Any variable appearing on the right-hand side must also appear on the left-hand side, with the exception of new public values.

Every protocol step is defined as a protocol rule. These usually send or receive a message and

alter the state of an agent. Listing 2.1 shows an example of two simple protocol rules where

agent A sends a message to agent B. The facts Sender and Receiver represent the roles of

rule Send:

[ Sender(A, k, m) ]

--[ Send(A, m), Running(A, B, m) ]->

[ Transfer(A, B, m, mac(k, m)) ] rule Receive:

[ Receiver(B, k), Transfer(A, B, m, mac(k, m)) ] --[ Receive(B, m), Commit(A, B, m) ]->

[]

Listing 2.1: Example of protocol rules

the two agents and their knowledge. The Transfer fact represents a secure communication channel that the agents use. In order for the Send rule to be executed, the multiset has to contain a fact that matches Sender(A, k, m) . In this fact, A , k , and m are general variables that can represent any term. Thus, any Sender fact with 3 terms will match. However, for the Receive rule to be executed, the multiset has to contain facts that match the pattern of the facts Receiver(B, k) and Transfer(A, B, m, mac(k, m)) . While A can again represent an arbitrary term, the first term of the Receive fact and the second term of the Transfer fact must be equal, as they are represented by the same variable B. The fourth term of the Transfer fact has to be an mac function of terms k and m , which are equal to the second term of the Receive fact and the third term of the Transfer fact, respectively.

Apart from protocol rules, there are also infrastructure rules. They are used for initializing anything the protocol needs, for example, keys and initial agent states. For the protocol in Listing 2.1, we would need the infrastructure rules in Listing 2.2. The Keygen rule gener- ates a new key ~k. Fr is a special built-in fact used for generating fresh values. It can only occur on the left-hand side of a rewrite rule. It is generated by the built-in fresh rule [] --> [Fr( ~ x)] . A fact that is starting with ! is persistent and therefore is not consumed by rules, but it stays in the multiset of facts indefinitely. So, the newly generated key is stored in the !Key fact, together with new public variables $A and $B, representing the agents that have access to the key ~ k . The rule Setup creates the Sender and the Receiver facts, dis- tributing the key from the !Key fact and initialized a new public variable $m representing a message.

rule Keygen:

[ Fr(~k) ]

--[ Keygen($A, $B ~k) ]->

[ !Key($A, $B, ~k) ] rule Setup:

[ !Key(A, B, k) ] --[ Setup(A, B, k)]->

[ Sender(A, k, $m), Receiver(B, k) ]

Listing 2.2: Example of infrastructure rules

In this example protocol, the messages are exchanged by a secure channel, represented by

the Transfer fact. So far, the adversary cannot eavesdrop or modify any messages. Tamarin

has a built-in Dolev–Yao network adversary that can interact with the protocol by special Out

and In rules. In can only occur on the left-hand side and Out can only occur on the right-

2.4. Tamarin hand side of a rewrite rule. The protocol would look as in Listing 2.3. In order for the Out fact to change into an In fact, it has to go through the adversary knowledge. The adversary knowledge is represented by K(t) fact for a term t known to the adversary. Adversary rules determine which messages the adversary can derive from his knowledge.

rule Send:

[ Sender(A, k, m) ]

--[ Send(A, m), Running(A, B, m) ]->

[ Out(<A, B, m, mac(k, m)>) ] rule Receive:

[ Receiver(B, k), In(<A, B, m, mac(k, m)>) ] --[ Receive(B, m), Commit(A, B, m) ]->

[]

Listing 2.3: Example of using the In and Out facts

Agents can get compromised by revealing their keys to the adversary. This can be modeled by a Reveal rule, as shown in Listing 2.4.

rule Reveal:

[ !Key(A, k) ] --[ Reveal(A) ]->

[ Out(k) ]

Listing 2.4: Example of a reveal rule

2.4.3 Properties

Rules can be labeled by action facts. These are not handled like state facts, they are rather transition labels that describe what happened in the protocol run. These are used to express properties and restrictions. For example, the Receive rule in Listing 2.3 has two action facts denoted by Receive(B, m) and Commit(A, B, m).

Properties that are to be verified by Tamarin are expressed by first-order logic formulas over action facts and timepoints. They are intended to hold either for the set of all possible traces, indicated by the keyword all-traces , or for at least one existing trace, indicated by the keyword exists-trace . In Tamarin syntax, properties are stated as lemmas.

An example of a property that is only looking for one satisfying trace is executability, shown in Listing 2.5. It checks whether there exists a trace such that a rule with an action fact Receive is executed. This is assumed to be the last step of the protocol. An additional condition is that rule Reveal was never executed, so no party is compromised in this trace since we want to know whether the protocol can be executed with all parties staying honest.

lemma executability: exists-trace

"Ex #i B m.

Receive(B, m)@i

& (All #j X. Reveal(X)@j ==> F)"

Listing 2.5: Executability property

A common security property is authentication. The property shown in Listing 2.6 checks whether agents A and B agree that there was a protocol run between them and message m was exchanged. So, for each time B commits to the message m from A, which is denoted by the action fact Commit , A must have sent m intended for B, which is denoted by action fact Running. Additionally, Running should have happened before Commit, therefore there is a condition that the timepoint j of Running is smaller than the timepoint i of Commit. The property assumes that both agents are honest, so for traces where A or B are revealed before i , it doesn’t check whether there was the correct Running action fact, and so the property holds trivially for such traces.

lemma authentication: all-traces

"All #i A B m. Commit(A, B, m)@i ==>

(Ex #j. Running(A, B, m)@j & j < i)

| (Ex #j. Reveal(A)@j & j < i)

| (Ex #j. Reveal(B)@j & j < i)"

Listing 2.6: Authentication property

Restrictions are properties assumed to hold for all traces, used to restrict the set of possible traces. They are expressed by first-order logic formulas over action facts and timepoints.

For example, a commonly used restriction is one that forces a key to be unique, shown in Listing 2.7. This enforces that the action fact Keygen will happen only once for each agent.

restriction unique_key:

"All #i #j A k1 k2. Keygen(A, k1)@i & Keygen(A, k2)@j ==> #i = #j"

Listing 2.7: Key uniqueness restriction

2.4.4 Proof search

Tamarin uses symbolic backward search to find proofs. That means it starts at an arbitrary state that violates the property and tries to get back to the initial state. If Tamarin succeeds in it, this means that there exists a trace from the initial state to a state violating the property, thus the property is falsified. If Tamarin explores all possibilities but does not get to the initial state, the property is verified. The advantage of a backward search is that it can verify the property for an unbounded number of sessions. Unfortunately, the problem that Tamarin is trying to solve is generally undecidable [20], therefore a proof attempt is not guaranteed to terminate. This follows from Rice’s Theorem, which states that any nontrivial property about the language recognized by a Turing machine is undecidable. In Tamarin, too many sources of infinity are the problem. Messages can be infinitely nested, there can be an infinite number of sessions and infinitely many nonces can be created.

Even if Tamarin is not able to terminate, in some cases, there are ways to change that. During

proofs, there are points where Tamarin decides which goal to resolve first by a heuristic. It

also has an interactive mode with a graphical user interface, where instead of letting the

heuristic choose the goal, the user can do it manually. By doing this, the user can arrive at a

proof, or at least investigate what is causing Tamarin to not terminate.

2.4. Tamarin There are multiple built-in heuristics to choose from. The default one, which works very well in a wide range of situations, is denoted by s for smart. On top of the built-in heuristics, users can create their own search strategy by writing an oracle, which is a script that takes in the current goals described as strings and outputs them sorted by priority. There is an option to first sort the constraints with the smart heuristic and then with the oracle. Apart from enabling verification when not terminating with the default heuristic, it can also significantly speed it up. Another option that Tamarin provides is to use induction.

When verifying properties of complex protocols, one can run into a problem with partial deconstructions that slows down verification or disables it. Before anything else, Tamarin precomputes a set of possible sources for each fact in the model. It can happen that it cannot find sources for some facts and thus a partial deconstruction is left in the set of sources. To resolve this issue, sources lemmas are used. They are applied during precomputation and they prove the source of a fact. There also exist some modeling tricks to help with the issue.

When all else fails, one can rethink the model. There may be ways to change the model such

that it still correctly represents the protocol, but it enables verification to terminate.

Attacker Model

In this chapter, we will specify the attacker models used for the security proofs we per- form. For verifying path authorization, a localized variant of the Dolev–Yao model [21] is needed. For verifying source authentication, packet authentication, and path validation, a classic Dolev–Yao model, as is standard in Tamarin, is enough.

3.1 Classic Dolev–Yao

The Dolev–Yao model is a symbolic attacker model where the adversary controls the whole network. They can eavesdrop on messages, modify them, drop them, or inject new messages.

They can perform cryptographic operations. Furthermore, we assume that we have access to perfect cryptographic primitives.

The Dolev–Yao model is the default attacker model for Tamarin. As described in Section 2.4, we give the adversary all the network capabilities that it should have according to the attacker model by using In and Out facts for modeling of message exchange between parties. When a party wants to send a message through the network controlled by the adversary, it is modeled by a rule that outputs an Out fact with the message. Anything included in an Out fact goes to the adversary knowledge. The adversary can combine any messages that are in the adversary knowledge and apply any function that is present in the model to them. Then, the adversary can produce an In fact with any such message. A party receiving a message through the network is modeled by a rule that consumes an In fact. If a term is initialized as a constant or a public variable, the adversary knows its value. The only terms that are not known to the adversary by default are fresh values, so the adversary does not know secret keys if they were not revealed. Tamarin already has the adversary rules that provide all these capabilities.

Even though the adversary has full control over the network, we still assume that it does not have access into the Intranet of any honest AS.

The only additional rule that Tamarin needs is a reveal rule, shown in Listing 3.1. It mod-

rule Reveal:

[ !Mackey(A, k) ] --[ Reveal(A) ]->

[ !Compromised(A), Out(k) ]

Listing 3.1: Reveal rule

3.2. Localized Dolev–Yao els the situation that an AS is compromised by giving its secret key to the adversary by an Out fact. The model remembers that this AS’s secret key was revealed by a persistent Compromised fact.

In the EPIC L2 protocol, additional keys are introduced. They are shared between two ASes, A and B. As mentioned in Section 2.2.3, these keys are derived by a PRF from the secret key of one of the ASes, say A with secret key K_A . This is modeled by a user-defined function prf/2 and the key is then defined as K_AB = prf(K_A, B) . If the AS A is compromised and its key K_A is revealed, the adversary can easily recompute the shared key. However, if the AS B is compromised, the adversary cannot just recompute the shared key, but it should be able to fetch it from a key store. This is modeled by another reveal rule, shown in Listing 3.2. If the AS B is already compromised, which is denoted by the persistent Compromised fact, the shared key is given to the adversary by executing this rule.

rule Reveal_Shared:

[ !Sharedkey(A, B, prf(K_A, B)), !Compromised(B) ] -->

[ Out(prf(K_A, B)) ]

Listing 3.2: Reveal rule for a shared key

In real life, the adversary would not likely have so many capabilities over the whole network.

The localized variant described below in Section 3.2 is more realistic, however, it is not detri- mental in any way to use a stronger attacker model, given that there are no spurious attacks and we can still model all the necessary behavior. In this case, it has multiple advantages. By having a stronger adversary, we are making the proven security property stronger. Further- more, it is simpler to understand and write down, and the speed of automatic verification is improved.

3.2 Localized Dolev–Yao

For verifying path authorization, we cannot use the classic Dolev-Yao attacker model, because it is too strong. We have to track the exact path traveled by the packet to check whether it is authorized, therefore we need to have a network topology. Moreover, we need to restrict the adversary’s capabilities so that they cannot actively modify the traffic between two honest ASes. We are specifically interested in path segments with only honest ASes, which we would not be able to observe if the adversary had full control over the links between them. Therefore, we need a localized variant of the Dolev–Yao model. The difference is that the attacker does not control the whole network, only a subset of ASes. In Tamarin, this is modeled by limiting the use of the In and Out facts, which are the facts used to interact with the adversary knowledge. Instead, authentic channels are used between ASes. However, the adversary retains the ability to eavesdrop, which we will go into detail about below.

The ASes are sending and receiving packets using the In_IF and Out_IF facts. These do

not interact with the adversary knowledge. Packets are forwarded to the next AS by the

Transfer rule, shown in Listing 3.3, which can be used only if there is an existing link

between the ASes with the correct interfaces. Existing links are stored as persistent Link

facts. The adversary is unable to intercept this transfer in any way.

rule Transfer:

[ !Link(ASIF_X, ASIF_Y), Out_IF(ASIF_X, h, origin, pkt) ] --[ TRANSFER(ASIF_X, ASIF_Y, pkt) ]->

[ In_IF(ASIF_Y, h, origin, pkt) ]

Listing 3.3: Transfer rule

Even though the adversary cannot modify the packets on the network, it has access to all the information in the packets. This can be done by using an additional Out fact, apart from the Out_IF fact, every time a packet is sent that makes the contents available to the adversary.

However, we do not do that, because there is a simpler way. Alternatively, we can take a shortcut and use an Out fact only if a new piece of message appears. For example, if an on- path AS computes a new MAC and includes it in the packet, the AS also makes it available to the adversary by producing an Out fact containing this MAC. In the simpler protocols, such as EPIC L0, this is easily achieved, because all of the information that can be exchanged is included in the public topology or authorized paths. Note that in our models, we do not include the actual payload in a packet. Thus, if the adversary knows the topology and authorized paths, they would not be able to gain any new information by eavesdropping on the network. In the models of protocols EPIC L2 and L3, there are some pieces of information that appear later in the protocol. Each such new piece of information is given to the adversary immediately, e.g. if an AS computes a MAC and includes it in a packet, the Tamarin rule will also create an Out fact with this MAC.

So far, we have a network that has authentic channels between ASes, but the adversary has the ability to eavesdrop on all the messages being exchanged. Next, we need to model how the adversary can craft or modify packets, and them send them. If an AS is compromised, it can stay passive, meaning its secret key is revealed but it follows the protocol honestly. Or, it can become active by sending a packet crafted by the adversary. In real life, there would be compromised ASes on the network that can receive a packet, modify it, and forward it.

As mentioned above, in this model, the adversary already knows every piece of information that can be eavesdropped. Therefore, it is not necessary for the Tamarin model to include a rule that would send packets from compromised ASes to the adversary. So, the last function to model is the ability of compromised ASes to send a crafted or modified packet. This is modeled by the Adv_send rule, shown in Listing 3.4, which receives a packet by an In fact from the adversary. This can be an arbitrary packet that the adversary can craft from their adversary knowledge. This rule also requires the AS to be compromised by consuming a

rule Adv_send:

let

ASIF_X = <AS_X, IF_X>

ASIF_Y = <AS_Y, IF_Y>

h = <<IF_X, AS_X, null>, nil>

origin = <AS_X, AS_Y>

in

[ !Compromised(AS_X), In(pkt), !Link(ASIF_X, ASIF_Y) ] -->

[ Out_IF(ASIF_X, h, origin, pkt) ]

Listing 3.4: Adversary send rule

3.2. Localized Dolev–Yao Compromised fact. The rule forwards the packet to the network by producing an Out_IF fact. The rest of the rule is figuring out where to send the packet next, such that there is an existing link, and updating metavariables.

The studied protocols cannot prevent the adversary from changing the intended authorized path to a new path as long as the new path is also authorized. Therefore, path authorization is theoretically defined in a way that allows this. It requires that each portion of the path traversed along honest ASes is authorized. Thus, when the adversary modifies the path of a packet, we no longer require the whole path to be authorized. The two parts of the path separately have to be authorized, though. In our model, we take care of this by resetting the packet history every time the adversary sends a possibly crafted or modified packet from a compromised AS. The packet history is recorded in the variable denoted by h in the code in Listing 3.4. After the reset, it contains only the current compromised AS. This is explained further in Section 4.1.

Additional adversary behavior considered in our model is a compromised end host sending

the packet. This can cause that the end host includes a path in the packet that is not au-

thorized, even though the AS is honest. It is modeled in the first protocol rule Src_send ,

described further in Section 5.2, by the source AS getting the authorized paths from the ad-

versary by the In fact. Thus, the received path can be an actually authorized one, or it can be

a path crafted by the adversary. This behavior is not modeled by EPIC L2 and L3 protocols,

as explained in Section 7.3. It is modeled for the rest of the protocols.

Modeling Security Properties

In this chapter, we will describe how the analyzed security properties were modeled in Tamarin. When analyzing these properties, we usuallt did not distinguish end hosts and their ASes. For packet authentication, source authentication, and path validation, we can use this abstraction because whenever one of the properties assumes that an end host is honest, it also assumes that its AS is honest, and vice versa. For path authorization, we do not assume that either the source host or the source AS is honest, but the property also does not include end hosts in any way. However, we will describe how we model a malicious source host sending a packet without explicitly modeling the source host. The destination host has no impact on path authorization.

4.1 Path authorization

Path authorization is satisfied when all path segments traversed by a packet are authorized by all honest on-path ASes. To formalize this property in a Tamarin model, we have to recognize which path segments are authorized, record the path traveled by a packet, and finally check whether all traveled path segments were authorized. Recall that properties in Tamarin are expressed with respect to action facts.

In the model, the authorized segments are defined by the Authorized action fact. They become authorized by an Authorize_seg rule, which is described in more detail in Sec- tion 5.1. Importantly, the set of authorized paths is assumed to be closed under suffixing and prefixing. This is because even though an up-segment always goes all the way up to a core AS, it can be used to send a packet to any AS on the segment. If an on-path AS is compromised, we cannot prevent it from using the segment to send the packet, even if it is not the source AS. The traveled path is stored in the history variable, denoted by h , which is included in the packet. It is a metavariable, meaning it is not a part of the exchanged messages in the protocol, but it is rather a separate variable used only for the purpose of recording the state of the packet and then defining path authorization. It cannot be modified by the adversary.

At each hop, the AS appends its H I to h. Also at each hop, there is a History action fact containing the history h . Path authorization is then verified by looking at each History ac- tion fact and checking whether the recorded traveled path is in fact authorized by an existing Authorized action fact.

If there is no compromised AS on the path, the history is recorded from the source until the

destination. Even if there are some compromised ASes on the path, but they are passive and

4.1. Path authorization follow the protocol, the history is still recorded in the same way. However, as mentioned in Section 3.2, if there is a compromised AS modifying the packet, we treat it as a new packet for the purpose of verifying path authorization. This is because we allow the adversary to change the path of a packet as long as the new path is authorized. We allow this because the protocols we study cannot prevent such path-switching attacks. In this situation, the Adv_send rule is used, where the history is reset.

However, there are two exceptions to the definition of path authorization in our model. First, we look at the first and the second ASes on the path, and if both are compromised, then we do not require path authorization to hold in that case. We want to exclude this case because we recognize that the adversary can always take an authorized path and prepend one or multiple compromised ASes to it because the adversary can impersonate the compromised ASes and compute the necessary authenticators. However, we assume this does not introduce any threat. If the adversary sends a packet that first travels a sequence of compromised ASes, we do not have to analyze this first part of the path, because it can be arbitrary. We recognize that packets can be sent between compromised ASes along unauthorized links. Thus, if the first AS is compromised, we disregard all the traces where also the second one is compromised, and only check the traces where the second AS is honest. Unfortunately, Tamarin does not support arrays or doubly linked lists, so the history variable h can only be a stack, therefore the first two ASes recorded in h are not easily accessible. Therefore, we have an additional metavariable origin containing the first and the second AS that is also recorded in the History action fact. The second exception is that we exclude a path if it is of length 1 and the included AS is compromised. This does not pose a threat, but it can happen because of the model specification.

Listing 4.1 shows how this property was specified in Tamarin as a first-order logic formula.

lemma path_authorization: all-traces

"All #i h first second. History(h, <first, second>)@i ==>

(Ex #j. Authorized(h)@j & j<i)

| (Ex #j #k. Reveal(first)@j & Reveal(second)@k & j<i & k<i)

| (Ex #j IgIF EgIF. h = <<IgIF, first, EgIF>, nil> & Reveal(first)@j & j<i)"

Listing 4.1: Path authorization property

One modification that needed to be done to the model was to mask the first egress interface in the history h. The hop information recorded in h includes the ingress and egress interfaces.

However, the very first egress interface and the very last ingress interface are not used. Recall that a packet travels in the opposite direction of beaconing, therefore enters through an egress interface and leaves through an ingress interface. When an active compromised AS sends a crafted packet, it can include an arbitrary value for this egress interface, which is never checked because it is never used. This causes Tamarin to find attacks, although they are spurious. To avoid this, the first egress interface is always changed to the value null in the history variable and in the Authorized action facts.

Here are some examples of scenarios that path authorization prevents and allows in theory.

For each of them, there is a diagram of authorized paths on the left and a diagram depicting

the intended path and the actual traveled path on the right. The darker circles represent

compromised ASes. The first example, displayed in Figure 4.1, is one scenario that path