diff --git "a/README.md" "b/README.md" --- "a/README.md" +++ "b/README.md" @@ -4,482 +4,742 @@ tags: - sentence-similarity - feature-extraction - generated_from_trainer -- dataset_size:4322 +- dataset_size:4321 - loss:MultipleNegativesRankingLoss base_model: Snowflake/snowflake-arctic-embed-s widget: -- source_sentence: How to set up the SCION endhost stack on different platforms to - access to SCION production network +- source_sentence: What are "Authoritative ASes" and their roles relate to TRC? sentences: - - 'Research paper section describing a P4-based SIG implementation attempt and its - limitations. Explains the experiment to isolate packet payload parts for decapsulation, - the limited range of the operation, and the conclusion that the hardware-based - P4 platform lacks the featureset for full SIG framing protocol implementation - (fragmentation/reassembly). Shifted focus to eBPF. - - Max C. Kellaway. "Accelerating the SCION IP Gateway using programmable - data planes." 2022. + - 'Research paper detailing the architecture and implementation of a P4-based SCION + border router. Explains SCION''s ISD and PCFS concepts in Section 2.1 and how + routers use hop fields (HFs) with IFIDs for forwarding. Introduces a modular design + with a "bridge header," separating cryptographic validation from forwarding, addressing + Tofino''s lack of native cryptographic support. Presents two configurations 1BR+2AES + using three pipelines, and 1BR+1AES using only two by recirculating packets, details + how AES implementation is deployed and that key expansion is done in the control + plane. + + Lars-Christian Schulz et al.. "Cryptographic Path Validation for SCION + in P4." *Proceedings of the 6th on European P4 Workshop*, 2023. research paper - 44 + 2 - 34 C HAPTER 5. OPDP- BASED IMPLEMENTATIONS OF THE SIG + EuroP4 ’23, December 8, 2023, Paris, France Lars-Christian Schulz, Robin Wehner, + and David Hausheer + + compare it to other existing implementations. Finally, we conclude + + this paper and give a brief outlook on future work. + + 2 BACKGROUND + + In this section, we briefly describe the architecture of the SCION + + Internet and the Intel Tofino 2 switch. + + 2.1 SCION + + SCION is a path-aware Internet protocol. It introduces Isolation + + Domains (ISDs) as groups of ASes sharing a common jurisdiction. + + SCION is path-aware, i.e., end hosts can choose from available + + forwarding paths and encode the desired one in the SCION header + + as what is known as packet-carried forwarding state (PCFS). Hence, + + the SCION data plane does not rely on longest prefix matching to + + determine the next hop router. Instead, SCION routers examine + + the hop fields (HF) in the SCION header which directly encode the + + AS-level path by means of interface IDs (IFIDs). + + Each AS can uniquely map its IFIDs to a neighbor and even a cer- + + tain link in case there are multiple links to this neighbor. Together + + with the source AS, the chain of ingress and egress IFIDs uniquely + + describes a SCION path. The hop fields are cryptographically signed + + by the AS corresponding to the hop with an AES-CMAC truncated + + to 6 bytes. To avoid forgery of HFs, SCION border routers must + + check the CMAC of every HF they use to make a forwarding deci- + + sion. Packets with invalid HFs should be dropped. In most cases, a + + HF corresponds to a specific border router, requiring each of them + + to only validate a single HF. Hop fields are grouped into segments + + resulting in a special case where a border router has to check two + + HFs when the path switches from one segment to another and the + + AS ingress and egress router happen to be the same device. + + The AES-CMAC is calculated over a 128 bit pseudo-header. As + + this matches up with the block size of the AES cipher, a single round + + of AES encryption is sufficient to generate the authentication tag, + + excluding the subkey derivation AES-CMAC calls for. A precise de- + + scription of the AES-CMAC algorithm is available in the correspond- + + ing RFC [15]. AES-128 is widely supported in commodity server + + hardware, making HF checks much faster than lookups in Internet- + + scale IP routing tables [3]. However, the switching ASICs used in + + hardware routers designed over decades to efficiently forward IP + + traffic do not include AES in their forwarding logic. Fortunately, re- + + cent P4-programmable switches have sufficient match-action stages + + to implement AES in standard P4 [4]. + + For more information on SCION we refer to the corresponding + + literature [3, 5, 19]. + + 2.2 Tofino Architecture + + We develop our SCION border router for Intel Tofino 2 switches. + + The P4 programmable Tofino architecture is an embodiment of the + + Protocol Independent Switching Architecture (PISA) data plane + + model. PISA switches contain three major types of programmable + + components: parsers, deparsers, and match-action units (MAUs). In + + the Tofino architecture, switch pipes consist of an in- and an egress + + pipeline each containing its own parser, MAUs and deparser [18]. + + Each switch pipe is hardwired to a set of, in case of Tofino 2, 8x + + 400G Ethernet ports [1]. + + The number of operations that can be performed per pipeline + + is limited. If a program exhausts the resources of one pipeline, the + + programmer can recirculate packets in order to process them itera- + + tively. If a packet is diverted to a different pipeline and recirculated + + there, there is the option to process the same packet sequentially + + with different P4 programs as each pipeline can be programmed + + independently. This is the key to fit the SCION border router in a + + Tofino 2 switch as described in Section 5.1. + + 3 RELATED WORK + + The SCION reference border router is implemented in Go [2] and + + uses regular IP/UDP sockets for packet I/O. Although being multi- + + threaded, the reference border router is not suitable for high traffic + + volume. Schulz et al. have proposed a BPF implementation of SCION + + packet forwarding [14] which achieves a throughput of 0.676 Mpps + + per core within a virtual machine test environment. However, the + + BPF data path has not been integrated in the reference border router + + yet. A commercial DPDK-based SCION router software is available + + from Anapaya Systems [17], but to our knowledge no production- + + ready SCION routers exist in hardware. - SIG service through IP routing rules. Since all the legacy traffic is routed through + The first attempt at a hardware implementation of SCION was - the SIG, it must be fast to keep up with the packet flow whilst being robust and - able + made by Součková, targeting a NetFPGA SUME development board - to handle packet loss. Furthermore, the SIG functionality should be flexible, - e.g. it + programmable in P4 [16]. The full 10 Gbit/s line rate of the devel- - should detect path changes. + opment platform has been achieved in experiments. However, the - 5.2 Hardware-based Implementation using P4 + SCION packet parser and cryptographic validation circuitry did not - We started with a design for the Intel Tofino since this would likely result in - the most + fit in the FPGA at the same time due to inefficient workarounds - significant performance increase (see sec. 3.1). A downside of implementing the + that had to be taken to handle SCION’s non-standard header layout. - SIG in P4 is that we must create all the functionality from scratch since there - is no + Nevertheless, the project led to improvements to SCION’s header - user space implementation running in parallel as there is with the eBPF designs. - In + layout making it more suitable for high-speed processing. - retrospect, a hybrid design might even be possible; we discuss this in sec. 8.1. + A first implementation of SCION for Tofino 1 was presented by - In order to create the prototype, we started with a design experiment for the - first + de Ruiter et al. [7] being capable of processing packets at 100 Gbit/s - requirement. The experiment was to isolate a specific part of the packet payload. + line rate. However, as Tofino does not support cryptographic opera- - With isolation, we mean removing parts of the front and back of the packet’s payload + tions in hardware, the AES-CMAC hop field validation in de Ruiter’s - resulting in a specific piece of the payload. This behaviour is required for the - SIG to + approach relies on a pre-populated table of valid hop fields. This - decapsulate framed IP packets. An example of this requirement would be isolating + simplification works as current SCION deployments change valida- - packet P1 in fig. 2.6 since that frame contains the beginning of packetP2. Therefore, + tion keys infrequently. An unfortunate consequence of this design - removing the beginning part of packetP2 from the frame is necessary to successfully + is that the SCION router is no longer stateless and instead has to - decapsulate packet P1. + communicate with the path discovery and registration services of - We successfully isolated specific parts of the packet payload. However, the range + the AS to obtain valid hop fields. Furthermore, the lookup-table - (number of bytes we could remove) of the operation was limited, resulting in that - we + solution also prevents the deployment of the SCION extensions - could not isolate small packets in the middle of the payload of a SIG frame. We + EPIC [ - concluded that the hardware-based P4 platform does not provide the featureset - we + 11] and Colibri [ 9] which rely on MACs that do not just - need to implement the SIG framing protocol since we were not able to perform the + change per-path, but per-packet. Nevertheless, the P4 code pub- - fragmentation and reassembly operations. This mismatch resulted in us stopping + lished by de Ruiter et al. inspired our work and is incorporated in - with the OPDP SIG prototype implementation in P4, and we further focused on an + our implementation. - eBPF-based implementation. In sec. 8.1, we discuss the mismatch more thoroughly. + Chen has shown that it is possible to implement an AES encryp- - 5.3 Kernel-based Implementation using XDP + tion in a Tofino 1 switch using so called scrambled lookup tables [4]. - Since XDP is the lowest level eBPF networking kernel hook, we start by making + Their implementation was limited to an encryption throughput of - an XDP-based implementation. We give an overview of the architecture in fig. 5.1, + 10.92 Gbit/s due to limited recirculation capacity. - which clearly illustrates the fast path. Another thing to notice in the figure - is that the + Our work addresses the issues encountered by Součková and de - XDP program runs parallel to the user space SIG. The parallel deployment has the + Ruiter et al. We implement the SCION packet parsing and validation - advantage of not having to cover all edge cases since we can pass packets from + logic separately in different pipelines of a Tofino 2 switch in order - the unsupported cases to the user space SIG. The parallel operation enables us - to + to bridge the gap between SCION’s requirements and achieving + + line-rate throughput. We furthermore develop an approach to AES + + in P4 that takes full advantage of the resources provided by Tofino 2 + + realizing the first 400G line-rate packet validator for SCION. + + 18 ' - - 'Book excerpt (Green Networking with SCION, Section 16.2.1-16.2.1.1) presenting - green routing design. Explains CO2 emission calculation for inter-domain paths - using top-down and bottom-up models. Top-down model uses AS-wide CO2 emission - and interface distance. Bottom-up model sums CO2 emissions of individual devices, - including per-bit, per-packet, and idle power. Introduces CEPB (CO2 emission per - bit). + - 'Book excerpt providing an overview of LightningFilter operation. It keeps AS-level + aggregates and stores long-term traffic profiles for traffic shaping. Describes + a process for rate-limiting based on these, and prediction to account for recent + traffic. Emphasizes prevention of source address spoofing and replay attacks using + DRKey(§3.2) , SPAO(§3.3), and replay suppression modules. Differentiates authenticated + traffic vs. best-effort approach pipelines. Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022. book - 420 + 229 - 16 Green Networking with SCION + 9.2 High-Speed Traffic Filtering with LightningFilter - 16.2.1 Green Routing Design + 9.2.1.2 Design Goals - To forward traffic on the lowest-emitting path, ASes should provide their end + LightningFilter is designed to achieve the following objectives: - hosts with the sets of paths emitting the lowest amount of CO 2 for forwarding + • Guaranteed access for legitimate users within traffic profile: The - traffic. To discover such paths between all ASes, ASes (1) need to estimate + system must ensure that a client in a non-compromised domain (i.e., a - their intra-domain paths’ CO 2 emissions, (2) disseminate this information to + domain without an adversary) has a guarantee to reach a target domain - other ASes, (3) make beaconing decisions based on this information to con- + even in the presence of adversaries in other domains. We define a traffic - struct green path segments, and (4) end hosts use this information to construct + profile as a sequence of measurements over a specific period of time - the greenest end-to-end paths. + (profiling window) on a per-flow basis (flow count). As long as the traffic - 16.2.1.1 Calculating CO 2 Emissions of Internet Paths by ASes + of a flow is within such a traffic profile, its packets are guaranteed to be - We propose a model that allows ASes to calculate the CO 2 emissions of Inter- + processed.4 - net paths. In general, researchers use either top-down or bottom-up models for + • Enabling traditional firewalls to filter packets using metadata: The - network energy consumption and CO 2 emission [ 140]. A top-down model di- + system should enable traditional firewalls to employ meaningful rule- - vides the energy a network or a part of it consumes over a certain time interval + based packet filtering using packet metadata (such as the 5-tuple in the - by the traffic volume it carries over the same interval. By contrast, a bottom- + packet header). Without LightningFilter, these filtering rules can be cir- - up model uses the energy consumption of every single device in a network. + cumvented by spoofing attacks due to the lack of authentication. - We propose one top-down and one bottom-up model to estimate inter-domain + • Elimination of collateral damage across domains: The system should - paths’ CO 2 emissions. In both models, we calculate the CO 2 emission per + guarantee that compromised domains cannot introduce collateral dam- - bit of data ( CEPB) on an inter-domain path as the sum of CEPBs of all its + age on non-compromised domains by consuming all available resources. - intra-domain path segments. + Legitimate clients within a compromised domain, however, may be af- - Top-Down Model. In the top-down model, ASes estimate the CEPB of an + fected by an adversary consuming excessive resources at a target domain. - intra-domain path between a pair of ingress and egress interfaces using the + This provides an incentive for domain owners to eliminate attack traffic - CO2 emission of the whole AS over a certain time interval—which can be + sent by their end hosts. - derived using their electricity consumption over that interval and their electric- + • Non-goal: Guaranteed traffic delivery to the domain is not a goal of this - ity contracts—and the distance between the ingress and the egress interfaces. + system, but can be achieved by a complementary system in SCION. - This is justified since the longer the distance between a pair of interfaces is, + 9.2.2 Overview of LightningFilter - the more energy is consumed to transmit packets between them, and thus more + Considering our threat model, the adversary’s goal is to consume all available - CO2 is emitted. + processing resources to prevent legitimate clients from reaching a target ser- - We model this relation between the distance and the energy consumption for + vice, e.g., by sending an excessive number of requests. To prevent a single en- - forwarding a packet on the path using a constant function for short distances + tity from achieving this goal, the available processing resources should be sub- - and a linear function for long distances. The constant for short distances is + divided and distributed among all clients. However, allocating an equal share - equal to the average CO 2 emission of the AS per bit of data it has carried over + of resources to each entity inhibits high utilization and potentially punishes - the last interval. The slope of the linear function for long distances is equal + benign traffic. As a consequence, researchers have suggested the use of more - to the average CO 2 emission per bit of data the AS has carried over the past + dynamic approaches, such as history-based filtering [ 213, 407] or binning of - interval per kilometer between all its interface pairs. + requests [ 470]. The potentially huge number of clients poses a challenge to - Bottom-Up Model. The bottom-up model is more precise but requires + the former approaches, as storing a traffic history (e.g., packet counters) per - more detailed knowledge about an AS’s network. Each AS estimates the CEPB + client is impractical. Instead, we propose to aggregate and store traffic profiles - of its AS entry included in an inter-domain path as the sum of the expected + at the level of domains, i.e., ASes. These traffic profiles denote a sequence - CEPBs of all network devices on the intra-domain path between the ingress + 4The replay-suppression system causes a negligible number of packets to be dropped + due to - and the egress interface of the AS. The expected CEPB of each networking + false positives; however, end hosts must be able to handle packet loss anyway. - 400 + 209 ' - - 'Document titled "Access and Host Configuration" describing requirements for using - SCION applications and accessing different SCION networks (production, SCIONLab, - local development). Explains setting the SCION_DAEMON_ADDRESS environment variable. - Outlines installation and configuration steps for the SCION endhost stack using - the SCION orchestrator or bootstrapper. Provides alternative instructions for - Linux, macOS, and Windows. + - "Technical document on SCION CP-PKI trust model and terminology specification.\ + \ Defines terms like base TRC, TRC signing ceremony, TRC update (regular/sensitive),\ + \ voting ASes, voting quorum, grace period, trust reset. Explains SCION's trust\ + \ model with Isolation Domains addressing limitations of monopoly/oligopoly PKI\ + \ models. Mentions trust agility/resilience, multilateral governance, policy versioning,\ + \ and lack of IP prefix origin validation by design in contrast to RPKI.\n\ + \ https://www.ietf.org/archive/id/draft-dekater-scion-pki-08.txt \n\ + \ specification \n\nde Kater, et al. Expires 3 July\ + \ 2025 [Page 5]\n\f\nInternet-Draft SCION CP-PKI\ + \ December 2024\n\n\n *Authoritative AS*: Authoritative ASes\ + \ are those ASes in an ISD that\n always have the latest TRCs of the ISD. As\ + \ a consequence,\n authoritative ASes also start the announcement of a TRC update.\n\ + \n *Base TRC*: A base TRC is a trust root configuration (TRC) that other\n \ + \ parties trust axiomatically. In other words, trust for a base TRC is\n assumed,\ + \ not derived from another cryptographic object. Each ISD\n MUST create and\ + \ sign a base TRC when the ISD is established. A base\n TRC is either the first\ + \ TRC of the ISD or the result of a trust\n reset.\n\n *TRC Signing Ceremony*:\ + \ The ceremony during which the very first base\n TRC of an ISD, called the\ + \ initial TRC, is signed. The initial TRC is\n a special case of the base TRC\ + \ where the number of the ISD is\n assigned.\n\n *TRC Update*: A _regular_\ + \ TRC update is a periodic re-issuance of the\n TRC where the entities and policies\ + \ listed in the TRC remain\n unchanged. A _sensitive_ TRC update is an update\ + \ that modifies\n critical aspects of the TRC, such as the set of core ASes.\ + \ In both\n cases, the base TRC remains unchanged.\n\n *Voting ASes*: Those\ + \ ASes within an ISD that may sign TRC updates.\n The process of appending a\ + \ signature to a new TRC is called \"casting\n a vote\".\n\n *Voting Quorum*:\ + \ The voting quorum is a trust root configuration\n (TRC) field that indicates\ + \ the number of votes (signatures) needed on\n a successor TRC for it to be\ + \ verifiable. A voting quorum greater\n than one will thus prevent a single\ + \ entity from creating a malicious\n TRC update.\n\n *Grace Period*: The grace\ + \ period is an interval during which the\n previous version of a trust root\ + \ configuration (TRC) is still\n considered active after a new version has been\ + \ published.\n\n *Trust Reset*: A trust reset is the action of announcing a\ + \ new base\n TRC for an existing ISD. A trust reset SHOULD only be triggered\n\ + \ after a catastrophic event involving the loss or compromise of\n several\ + \ important private keys.\n\n1.2. Conventions and Definitions\n\n The key words\ + \ \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\",\n \"SHOULD\"\ + , \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\", \"MAY\", and\n \"OPTIONAL\"\ + \ in this document are to be interpreted as described in\n BCP 14 [RFC2119]\ + \ [RFC8174] when, and only when, they appear in all\n capitals, as shown here.de\ + \ Kater, et al. Expires 3 July 2025 [Page 6]\n\f\n\ + Internet-Draft SCION CP-PKI December 2024\n\n\n\ + 1.3. Trust Model\n\n Given the diverse nature of the constituents in the current\ + \ Internet,\n an important challenge is how to scale authentication of network\n\ + \ elements (such as AS ownership, hop-by-hop routing information, name\n servers\ + \ for DNS, and domains for TLS) to the global environment. The\n roots of trust\ + \ of currently prevalent public key infrastructure (PKI)\n models do not scale\ + \ well to a global environment because (1) mutually\n distrustful parties cannot\ + \ agree on a single trust root (monopoly\n model), and because (2) the security\ + \ of a plethora of roots of trust\n is only as strong as its weakest link (oligopoly\ + \ model) - see also\n [BARRERA17].\n\n The monopoly model suffers from two\ + \ main drawbacks: First, all\n parties must agree on a single root of trust.\ + \ Secondly, the single\n root of trust represents a single point of failure,\ + \ the misuse of\n which enables the forging of certificates. Its revocation\ + \ can also\n result in a kill switch for all the entities it certifies.\n\n\ + \ The oligopoly model relies on several roots of trust, all equally and\n \ + \ completely trusted. However, this is not automatically better:\n whereas\ + \ the monopoly model has a single point of failure, the\n oligopoly model has\ + \ the drawback of exposing more than one point of\n failure.\n\n Thus, there\ + \ is a need for a trust architecture that supports\n meaningful trust roots\ + \ in a global environment with inherently\n distrustful parties. This new trust\ + \ architecture should provide the\n following properties:\n\n * Trust agility\ + \ (see further below);\n\n * Resilience to single root of trust compromise;\n\ + \n * Multilateral governance; and\n\n * Support for policy versioning and\ + \ updates.\n\n Ideally, the trust architecture allows parties that mutually\ + \ trust\n each other to form their own trust \"union\" or \"domain\", and to\ + \ freely\n decide whether to trust other trust unions (domains) outside their\n\ + \ own trust bubble.\n" +- source_sentence: What are the challenges of deploying INT on multi-operator networks + like the Internet + sentences: + - 'Book chapter excerpt, ("SBAS," Section "Secure Route Redistribution"). Details + SBAS''s internal full-mesh topology among PoPs using SCION and encrypted iBGP + sessions. Introduces three address categories: secure (customer/SBAS-owned), internal + (PoP communication), and global (other routable addresses). - https://docs.scion.org/projects/scion-applications/en/latest/applications/access.html - + Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles + to Formal Verification*. Springer International Publishing AG, 2022. + + book - documentation + 368 - # Access and Host Configuration + 13 Deployment and Operation + tural abstraction of the underlying infrastructure and provide an interface to - # Access and Host Configuration + customers. + End-to-End Security. In the context of mediating customers’ IP endpoints - To use any SCION application, you must have access to a SCION network and have - the SCION endhost stack installed on your host. + via a secure backbone, the end-to-end communication path can be segmented - Depending on the SCION network you are targeting, refer to the corresponding section - below. + into an external (insecure) segment, which is comprised of the Internet links + between an IP endpoint and the SBAS ingress/egress point, and an internal - For the following instructions, we assume that the SCION daemon runs on the default - address. + segment between an arbitrary ingress and egress pair of the secure routing - If it does not, specify the address of the SCION daemon to which you want to attach - the application by setting the SCION_DAEMON_ADDRESS environment variable, e.g.: + infrastructure. Therefore, to ensure end-to-end secure routing, the follow- + ing conditions must hold: (1) Customers must be able to select trusted in- - ``` + gress/egress points and securely exchange packets with hijack resilience; and - export SCION_DAEMON_ADDRESS=127.0.0.1:30255 + (2) the secure backbone must deliver the security properties it promised to any - ``` + pairs of ingress/egress points even in the presence of internal adversaries. + Routing Priority. To enable customers to route traffic from/to the Internet - ## SCION production network + through a secure backbone, SBAS must disseminate the customers’ prefix an- + nouncements to all other customers and external entities. Prefixes will then be - The SCION production network is a global real-wordl network that provides secure - and reliable communication. + announced via SBAS and the Internet, resulting in competing announcements. + To maximize the ability to route securely, SBAS must be able to convince the - In order to access the SCION production network, your network provider must provide - SCION connectivity for your host, e.g.: + entities receiving the announcements to prioritize routing paths through the + secure backbone over the insecure Internet paths. - - You are a customer of an ISP that provides SCION connectivity. + 13.5.3.2 Secure Route Redistribution - - Your university or reasearch institution is part of the SCIERA ISD (see SCIERA - docs) or another SCION ISD. + The internal structure of SBAS can be abstracted to a full-mesh topology be- + tween the PoPs, which communicate over SCION. Over these connections, - ### Setting up the SCION endhost stack + the PoPs redistribute announcements from SBAS customers as well as the In- + ternet, akin to the operation of iBGP in a regular AS. To prevent tampering by - You can install and configure the SCION endhost stack for Linux, macOS, or Windows - using the SCION orchastrator for endhosts. + non-PoP members, the iBGP sessions run over an encrypted and authenticated + connection (such as a VPN tunnel). - Alternatively, you can use the SCION endhost bootstrapper to fetch the SCION configuration. + SBAS offers a high degree of flexibility to its customers through support for - On Debian systems, the bootstrapper will also install the SCION endhost stack - for you. + dynamic route redistribution. Contrary to a traditional AS, which is controlled - For other platforms, you will need to manually install the SCION endhost stack. - Please refer to the following sections for more information. + by a single entity, the redistribution scheme to be used in SBAS must support + its federated structure and remain secure in the presence of malicious mem- - Note + bers. In the following, we describe the design and security aspects of the route + redistribution mechanism. - Both tools require your network provider to enable a SCION bootstrapper service. + The system distinguishes between three categories of addresses: - If it is not available, follow the alternative host installation instructions - below. + • Secure addresses: This includes prefixes announced by SBAS cus- + tomers and SBAS-owned address spaces, which are assigned to cus- - Warning + tomers. Secure address spaces are announced publicly at egress points + via BGP. - The SCION endhost stack is not officially supported on Windows, but it can be - built and run with some limitations. + • Internal addresses: In order to provide an internal addressing scheme - Mainly, the dispatcher is not supported on Windows, but you can run SCION applications - in environments that do not require the dispatcher. + among PoPs, e.g., to set up iBGP sessions between PoP routers, the PoPs - This is applicable if your network provider runs SCION version > 0.11.0, available - from the Releases. + 348 + ' + - 'Research paper titled "ID-INT: Secure Inter-Domain In-Band Telemetry" proposing + ID-INT, a SCION extension for secure, authenticated in-band telemetry. Leverages + SCION''s PKI and DRKey for data plane authentication, enabling applications like + intra-AS path tracing, congestion control, and carbon-aware routing. Implemented + in the SCION stack with an AS-hosted telemetry collector. Evaluation shows minimal + performance impact on routers with authentication-only mode and up to a 13% throughput + decrease with encryption. + + Lars-Christian Schulz et al.. "ID-INT: Secure Inter-Domain In-Band + Telemetry." *2024 20th International Conference on Network and Service Management + (CNSM)*, 2024. - ### Alternative Linux Host Installation + research paper + 1 - If your network provider does not provide a SCION bootstrapper service, you can - manually install the Debian packages (see SCION Installation). + - Otherwise, you can also follow the instructions to build the SCION endhost stack - from source (see SCION Build). + ID-INT: Secure Inter-Domain In-Band Telemetry + Lars-Christian Schulz - Additionally, you will require a valid configuration file from your network provider - located at /etc/scion/topology.json. + OVGU Magdeburg - Depending on the applications you want to use, you may also need the TRC files - under /etc/scion/certs/. + Magdeburg, Germany + lschulz@ovgu.de - ### Alternative macOS Host Installation + David Hausheer + OVGU Magdeburg - Note + Magdeburg, Germany + hausheer@ovgu.de - Homebrew support will be available soon. + Abstract—In-band network telemetry (INT) is a powerful tool + for gathering status information from network components in - For now, you can build the SCION endhost stack from source (see SCION Build). + a distributed and timely way. Until now, INT has mostly been - Depending on where you compile the binaries, you may need to specify GOOS=darwin - and GOARCH=amd64 (or your target architecture). + deployed in data center environments or single operator W ANs, + because it lacks mechanisms for authentication and is not widely - ### Alternative Windows Host Installation + standardized. SCION is a novel, path-based Internet architecture + providing strong resilience and security properties. In this paper, - You can build the SCION endhost stack from source (see SCION Build). + we propose Inter-domain In-band Network Telemetry (ID-INT) - Depending on where you compile the binaries, you may need to specify GOOS=windows - and GOARCH=amd64 (or your target architecture). + as a protocol extension for SCION. ID-INT leverages SCION’s + public key infrastructure to authenticate telemetry data while - ## SCIONLab network + augmenting SCION’s end host path control with real-time + network information. Promising applications of ID-INT include - The SCIONLab network is a global testbed (not production) that runs as SCION as - an overlay network protocol. + intra-AS path tracing, congestion control, SLA verification, and - It is used for experimental purposes, altough one can deploy real applications - on it. + carbon-aware routing. We implement ID-INT in the open-source - It is free to use and open to everyone, but one cannot expect the same level of - reliability, performance and security as the SCION production network. + SCION stack and provide a proof of concept for an AS-hosted + telemetry collection service. We show that cryptographically - In order to access the SCIONLab network, you must have a SCIONLab account and - have set up a SCIONLab node (see https://docs.scionlab.org/). + authenticated ID-INT can be fully implemented in the SCION + router’s fast-path with no measurable impact on router per- - The SCIONLab node already comes with a SCION endhost stack, meaning that you can - run SCION applications directly on the node. + formance. If optional encryption is employed in addition to - Otherwise, you can follow the previous instructions to install the SCION endhost - stack on your host and connect to the SCIONLab node. + authentication, router throughput drops by no more than 13% + even if every packet carries telemetry. - ## Local SCION network for development + Index Terms—In-band Network Telemetry, SCION, W AN + I. I NTRODUCTION - To set up a local SCION network for development, you must have a development environment - set up (see https://docs.scion.org/en/latest/dev/setup.html). + Network monitoring and measurement is an integral part of + any network operator’s toolkit. In order to meet the demands - If you have a running development environment, you can run the SCION applications - on your host. + of modern real-time applications, constant monitoring of the - You need to specify the address of the SCION daemon to which you want to attach - the application to, using the SCION_DAEMON_ADDRESS environment variable. + network’s status and performance is required. Traditionally, - The SCION daemon addresses for the diferent ASes can be found in their corresponding - sd.toml configuration files in the gen/ASx directories. + networks have been monitored through active measurements + using probe packets, e.g., using the well-known ping and + traceroute commands, or through passive traffic monitoring - ' -- source_sentence: Why all other paths compute loss with same potential traffic on - synchronization? - sentences: - - 'Master''s thesis "Leveraging Application Layer Path-Awareness with SCION" outlining - the structure of WebRTC calls (setup and in-progress). Describes the signaling - process for call bootstrapping and states assumptions that peers are directly - addressable without NAT. Mentions the signaling server and the lack of a mandated - signaling protocol in WebRTC. + at routers. Passive monitoring is usually employing sampling - Jonas Gessner. *Leveraging Application Layer Path-Awareness with SCION*. - Master''s thesis, ETH Zurich, 2021. + techniques as observing every single packet is costly. - research paper + With the advent of SDN, programmable data planes, and - 23 + P4, a new network monitoring paradigm emerged in the form - + of push-based network telemetry. Telemetry-enabled devices + + push network measurements to a central controller, instead + + of waiting for the controller to poll monitoring data. Fully + + programmable network devices like Intel’s Tofino [1] enable + + to push telemetry one step further by offloading the collection + + of telemetry metadata entirely to the data plane. Noticeably, + + the INT specification [2] was developed as a standardized way + + to exchange telemetry information between network entities. + + The INT framework is related to a number of earlier systems + + all based around the idea of embedding telemetry instructions + + and is some cases metadata as well in packet headers [3], + + [4]. INT has in turn inspired research on advanced in-band + + telemetry protocols like ML-INT for optical networks [5] + + and probabilistic approaches like PINT [6]. All these systems + + have in common that they can only be deployed in networks + + under shared administrative control. Additionally, security and + + privacy aspects have largely been ignored, precluding Internet- + + wide deployment. + + The SCION Internet architecture [7] has been developed - 2B a c k g r o u n d + to address the lack of security-by-design in today’s Internet - • End-to-end encryption via Datagram Transport Layer Security (DTLS) and + based on the Border Gateway Protocol (BGP). BGP’s design - Secure Real-time Transport Protocol (SRTP). + limitations have caused numerous outages. SCION provides - This section presents the structure and lifetime of a simple WebRTC call between + a public key infrastructure for authenticating network entities - two peers in two parts: The call setup phase and in-progress calls. Termination - of + and allows multiple roots of trust to coexist. Another core - calls is not covered. + feature of SCION is that it is a path-based routing protocol. - The focus of the presented background is on mechanisms relevant to this thesis - and + End hosts include the AS-level forwarding path in packet - underlying protocols used to establish and maintain calls. + headers to eliminate uncertainties in traditional routing. The - 2.2.1 Call Setup + same property also allows end hosts to send traffic to a specific - The first step to establishing a call is signaling of the intent to start a call - from the + destination over multiple parallel paths to increase reliability - caller to the callee. The acknowledgement by the callee and the establishment - of + and aggregate bandwidth. SCION has been successfully de- - one or more direct connections between the peers follow. The details of how a - call is + ployed in both research [8] and commercial networks [9] and - bootstrapped are presented in this section. + already reaches hundreds of thousands devices. A challenge - For the context of this thesis, it is sufficient to assume that both peers are addressable + of the end host routing approach is to provide sufficient - directly via a public IP/SCION address without the traversal of routers that perform + information for making routing decisions to hosts. Current - network address translation (NAT). The involvement of NAT makes call setups + solutions (cf. [10]–[12]) are based on control plane messages - significantly more complex. The presence or absence of NAT is orthogonal to the + and cannot provide real-time feedback from routers to hosts. - work presented in this thesis and a simple NAT-free setup is therefore chosen. + Therefore, SCION path selection is mostly based on end-to- - Signaling + end measurements, which become challenging as the number - Communication during the call setup phase is not handled by WebRTC itself and + of available paths grows with the number of SCION ASes. - instead needs to involve asignaling server, with which both peers are in constant + In order to address the absence of real-time telemetry in - contact. Signaling can come in various forms and may include security mechanisms + SCION and INT’s lack of an authentication infrastructure and - to achieve properties like authentication of the caller and callee. Dedicated - pro- + inter-operator compatibility, we introduce Inter-Domain In- - tocols for signaling exist, such as Jingle, but WebRTC does not mandate the use + band Network Telemetry (ID-INT). ID-INT relies on SCION’s - of any particular signaling protocol [10]. This work uses a simple unencrypted, + Dynamically Recreatable Key (DRKey) system to provide - unauthenticated signaling service. + efficient message authentication in the data plane and in turn - Session Description Protocol + allows SCION end host to make informed routing decisions. - To initiate a call (also calledsession), the caller uses the Session Description - Protocol + This work is structured as follows: We continue with a - (SDP) to create an SDP offer, which specifies their configuration for the session. - The + brief description of SCION in section II and provide an - SDP offer includes a listing of media tracks (e.g. video, audio, data) and further + overview of related work in and outside the SCION ecosystem - information: + in section III. ID-INT’s design is presented in section IV. - 14 + section V provides details on our prototype implementation + + which we evaluate for throughput and overhead in section VI, + + before we discuss potential extensions to the protocol in + + section VII. Finally, section VIII gives an outlook on a wide + + range of applications, while section IX concludes this paper. + + 2024 20th International Conference on Network and Service Management (CNSM) + + 978-3-903176-66-9 ©2024 IFIP ' - - 'Master''s thesis excerpt illustrating the effect of randomization in path switching - for SCION, preventing cyclic behavior even when applications start simultaneously. - Highlights that applications split and distribute across paths over time due to - randomized delays, addressing synchronization issues in the ''active'' mechanism. + - 'Master''s thesis excerpt detailing scoring functions for "passive" and "active" + path selection mechanisms in SCION. "Passive" mechanism modifies QoE function + (Equation 4.4), with increased loss penalty: `5000 * loss` (if loss < 0.05). Describes + "passive" mechanism behavior: initial path selection by lowest latency with increasing + sending rate, switching when significant loss occurs. Pascal Marc Suter. *Traffic Engineering in SCION: The impact of end host QoS mechanisms on network performance*. Master''s thesis, ETH Zurich, 2023. @@ -487,1372 +747,1327 @@ widget: research paper - 65 + 44 - 6. S imulator experiments + 5.2. Implementation details + + Table 5.1: Sending rates considered by other works and chosen bitrates in Mbps. + + Title Low Medium High + + Can you see me now?: a measurement + + study of Zoom, Webex, and Meet [54] + + 0.5 - 1 2.5 - 2.6 + + Zoom Session Quality: A Network- + + Level View [55] + + 1 - 1.5 3 - 6 + + Measuring the performance and net- + + work utilization of popular video con- + + ferencing applications [21] - Figure 6.19: Detailed results of a run with 600 applications using the ’active’ - mechanism not + 0.8 - 1.9 - having any measures to desynchronize the applications and starting at the same - time. + Chosen bitrates 0.7 1.5 5 - the large amount of probes and predict a loss, the probe agents for all other + The scoring functions differ between the mechanisms. For the ’naive’ and - paths will see the same probes and compute the loss with the same poten- + ’shortest path’ mechanisms, the application will select the path at the begin- - tial traffic. While this makes all paths less attractive, it does not change the + ning. ’Naive’ chooses uniformly at random from all available paths while - chosen path and therefore does not prevent the applications from choosing + ’shortest path’ chooses uniformly at random from the subset of the shortest - the same path. + paths, i.e.,the paths with the fewest hops or fewest ASes in it. Shortest path - This proves the need for some randomness when selecting new paths. Ran- + does not necessarily mean paths with the lowest latency but paths with the - domness in the path selection itself would prove most effective, but it would + fewest hops. The selected path gets a high score and all others a low score. - also decrease the quality of experience as the mechanisms would choose + The score is set to low score when the sending rate is higher or equal than - paths that have worse properties. Instead, the time at which the paths are + previously and there was loss previously except for low sending rates. This - switched were randomized. Some applications will therefore remain on the + gives them the behavior of starting at a low sending rate, increasing when - congested path long enough to notice that no congestion occurs anymore + no loss is detected and decreasing when it is, mirroring the functionality of - and will remain on the same path, splitting the applications apart. + ABR. These two mechanisms do not require any probing. - A run with again 600 applications with the ’active’ mechanism and this + The ’passive’ mechanism uses latency only probing. The core of its scoring - randomization implemented but still starting at the same time is shown in + function is the score function defined in Equation 4.4. That function scores - Figure 6.20. It is clearly visible that a group of applications remain on the + the QoE for VCAs and as the mechanisms are supposed to optimize the - paths and the applications split nicely over time. Because they still start at + quality, it is a good starting point. However, early testing showed that this - the same time, the probing happens at the same time again, which does lead + is too accepting of loss, only changing paths or sending rate after 10% of - to renewed congestion for a short time. It would be possible to avoid this + loss occurs. After 10% the score drops significantly and to avoid that, the - by having the probing intervals also randomized. For this implementation, + scoring function used internally by the mechanisms has a lower threshold. - the start times were distributed over time as in the experiments discussed + The internal score function is given by replacing Equation 4.2 with - above. This comes from the fact that all the applications starting at the exact + penalty loss = - same time is unrealistic. + ( - 58 + 5000 ∗ loss if loss < 0.05 + + 104 ∗ loss else (5.2) + + It punishes loss more; this is to get a tradeoff between optimizing for QoE + + and limiting congestion. + + There are some more modifications for the implementation. The loss on + + a path is only known when traffic was sent, otherwise it will be assumed + + zero. Additionally, the ’passive’ mechanism also performs a sending rate + + selection similar to ’naive’ and ’shortest path’. When sending over a new + + path, i.e., a path that was not sent over since the last probing and for which + + 37 ' - - "Specification document of SCION's Dynamically Recreatable Key (DRKey) infrastructure.\ - \ Outlines key derivation hierarchy (Level 0-3: Secret Value, AS-AS, host-AS/AS-host,\ - \ host-host) and schemes (protocol-specific, generic). Defines notation, key derivation\ - \ functions (KDF, PRF), validity times (epoch, grace, prefetching), and key establishment\ - \ protocols (control/application plane). Provides detailed protobuf message formats\ - \ of DRKey Requests/Responses. Assigns protocol identifiers.\n https://docs.scion.org/en/latest/cryptography/drkey.html\ - \ \n documentation \n\n# Dynamically Recreatable Key\ - \ (DRKey) Infrastructure\n\n# Dynamically Recreatable Key (DRKey) Infrastructure\n\ - \nThis document describes the Dynamically Recreatable Key (DRKey)\ninfrastructure.\n\ - \n## Overview\n\nThe DRKey protocol enables routers and end hosts to derive cryptographic\n\ - symmetric keys on the fly from a single local secret.\n\nDRKey is used for the\ - \ following systems:\n\n- SCION Packet Authenticator Option (SPAO)\n- COLIBRI\n\ - - EPIC\n\nIn the DRKey system, the key establishment is offloaded to the Control\ - \ Service\n(CS).\nControl services exchange top-level keys that will be used afterwards\n\ - to derive lower level keys locally.\nThe DRKey system leverages efficient key\ - \ derivation and pseudorandom functions\nto derive keys in the hierarchy from\ - \ top to bottom.\n\nThe first secret in the hierarchy (\\(SV_A\\)) is derived\ - \ from a long-term master_secret,\nusing a key derivation function.\nFor the rest\ - \ of the derivations, DRKey utilizes pseudorandom functions, which are more efficient.\n\ - Informally, key derivation functions output a cryptographic key indistinguishable\ - \ from\na random key if the secret is unknown for the attacker.\nIn contrast,\ - \ the security of pseudorandom functions relies on the input being a uniformly\n\ - random secret.\n\n## Notation\n\n| Notation | Description |\n| --- | --- |\n|\ - \ \\(KDF_{K}(X)\\) | key derivation function using key K and taking X as an input\ - \ |\n| \\(PRF_K (X)\\) | pseudorandom function using key K and taking X as an\ - \ input |\n| \\(A\\) | Autonomous system (identified by the pair ISD and AS number)\ - \ |\n| \\(H_A\\) | end host (identified by its address) |\n| \\(CS_A\\) | Control\ - \ service located in AS A |\n| \\(SV_A\\) | AS A’s local secret value |\n\n##\ - \ Derivation scheme\n\nWe define two types of derivation: the Protocol-specific\ - \ derivation derivation and\nthe Generic-protocol derivation. Both of them leverage\ - \ the 4-level derivation scheme.\n\n### 4-level derivation\n\nSecret value (Level\ - \ 0)\n\nEach AS locally derives one \\(SV_A^{protocol}\\) per protocol and epoch.\ - \ This secret value\nis renewed at every epoch and it is only shared with trustworthy\ - \ entities that require\nto derive keys on the fly for the specified protocol.\n\ - \nAS-AS (Level 1)\n\nThe AS-AS key is derived locally in the AS \\(A\\) CS (\\\ - (CS_A\\)) and exchanged\nwith remote CS. More specifically \\(CS_A\\) shares \\\ - (K_{A,B}\\) with\n\\(CS_B\\).\n\nhost-AS (Level 2)\n\nThe host-AS key is derived\ - \ using the Level 1 symmetric key.\nIt is intended to be used as an intermediate\ - \ derivation allowing the node holding this\nkey to derive Level 3 keys locally.\n\ - Therefore, the key \\(K_{A:H_A,B}\\) is only available to \\(A:H_A\\) and trusted\n\ - infrastructure.\n\nAS-host (Level 2)\n\nThe AS-host key is also derived using\ - \ the Level 1 symmetric key,\nhowever this key is intended to be used for communication.\n\ - In this case, the key \\(K_{A,B:H_B}\\) is shared between \\(AS_A\\) trusted nodes\n\ - and \\(B:H_B\\).\n\nhost-host (Level 3)\n\nThe host-host key is derived in \\\ - (H_A\\) and \\(CS_B\\) using the host-AS key. This key\nis available to both hosts\ - \ \\(H_A\\) and \\(H_B\\).\n\n### Protocol-specific derivation\n\n| Identifier\ - \ | Derivation | Name |\n| --- | --- | --- |\n| \\(SV_A^{protocol}\\) | \\(KDF(input)\\\ - ) | Secret value (Level 0) |\n| \\(K_{A,B}^{protocol}\\) | \\(PRF_{SV_A^{protocol}}(type||B)\\\ - ) | AS-AS key (Level 1) |\n| \\(K_{A,B:H_B}^{protocol}\\) | \\(PRF_{K_{A,B}^{protocol}}(type||len/type(H_B)||H_B)\\\ - ) | AS-host key (Level 2) |\n| \\(K_{A:H_A,B}^{protocol}\\) | \\(PRF_{K_{A,B}^{protocol}}(type||len/type(H_A)||H_A)\\\ - ) | host-AS key (Level 2) |\n| \\(K_{A:H_A,B:H_B}^{protocol}\\) | \\(PRF_{K_{A:H_A,B}^{protocol}}(type||len/type(H_B)||H_B)\\\ - ) | host-host key (Level 3) |\n\nThe SV computation is local, thus the AS is free\ - \ to compute it as desired as long as\nit outputs a cryptographic key indistinguishable\ - \ from a random key for an attacker.\nWe suggest to use the PBKDF2 as KDF function\ - \ and set input to:\ninput = \"len(master_secret) || master_secret || protocol\ - \ || epoch_begin || epoch_end\".\n\nThe key notation states for which entity the\ - \ key derivation must be efficient.\nThe term in the left identifies the key issuer\ - \ (the fast side in the derivation),\nwhereas the right term identifies the key\ - \ subject (the slow side in the derivation).\nFor example, \\(K_{A,B:H_B}\\) can\ - \ be used in both communication directions,\nbut it is directly derivable by \\\ - (AS_A\\), whereas the \\(AS_B\\) requires to contact\n\\(CS_A\\) to fetch the\ - \ intermediate Level 1 key.\n\n### Generic-protocol derivation\n\n| Identifier\ - \ | Derivation | Name |\n| --- | --- | --- |\n| \\(SV_A\\) | \\(KDF(input)\\)\ - \ | Secret value (Level 0) |\n| \\(K_{A,B}\\) | \\(PRF_{SV_A}(type||B)\\) | AS-AS\ - \ key (Level 1) |\n| \\(K_{A,B:H_B}^{protocol}\\) | \\(PRF_{K_{A,B}}(type||protocol||len/type(H_B)||H_B)\\\ - ) | AS-host key (Level 2) |\n| \\(K_{A:H_A,B}^{protocol}\\) | \\(PRF_{K_{A,B}}(type||protocol||len/type(H_A)||H_A)\\\ - ) | host-AS key (Level 2) |\n| \\(K_{A:H_A,B:H_B}^{protocol}\\) | \\(PRF_{K_{A:H_A,B}^{protocol}}(type||len/type(H_B)||H_B)\\\ - ) | host-host key (Level 3) |\n\nThis derivation scheme allows applications to\ - \ define “niche” protocols. By including\nthe protocol in the Level 2 derivation\ - \ input.\n\n### PRF derivation specification\n\n1 byte field identifying the derivation\ - \ type (AS-AS, AS-host,\nhost-AS and host-host). This enables domain separation\ - \ among computed\nkeys. For instance, it outputs (with high probability)\n\\(K_{A:H_A,B}\ - \ ≠ K_{A,B:H_B}\\) when \\(H_A==H_B\\).\n\n2 byte field used in the PRF derivation\ - \ for Lvl2 generic-protocol derivations\nto identify the concrete protocol.\n\n\ - This field is present in Lvl1 derivations and follows the format in\nSCION Address\ - \ Header.\n\nThis field is present in Lvl2/3 derivations and follows the format\ - \ for the DT/DL\nfield in SCION Common Header.\n\nThis field is present in Lvl2/3\ - \ derivations and follows the format in\nSCION Address Header.\n\nDRKey uses AES-CBC\ - \ MAC as PRF. The MAC is computed over the following fields:\n\n- type (1 byte)\n\ - - protocol in Lvl2 generic-protocol derivations (2 bytes)\n- ISD-AS address in\ - \ Lvl1 derivations (8 bytes)\n- Host type/length in Lvl2/3 derivations (4-bit,\ - \ padded to 1 byte)\n- Host address in Lvl2/3 derivations (variable size).\n\n\ - The derivation using CBC MAC is safe since all fields are of a fixed size,\nexcept\ - \ for the host address whose length is prepended.\n\n## Key Validity time\n\n\ - ### Epochs\n\nAn epoch is an interval between a starting and ending point in time.\ - \ The epoch\nlength can be chosen by a given AS and can change over time, however,\ - \ epochs\nmust not overlap. Thus, a secret value is associated with exactly one\ - \ epoch.\n\nEvery AS can define different epoch lengths for each protocol-specific\n\ - 0th level key.\n\nDefining a reasonable lower bound for the epoch length used\ - \ in DRKey\nis necessary to avoid nonsensical scenarios. This value is\nglobally\ - \ set to 6 minutes.\n\nThe upper bound for the epoch length is defined to 3 days,\ - \ looking for a trade-off\nbetween efficiency and security.\n\nNote\n\nThese bounds\ - \ might be changed in the future in case a more suitable\nvalues are found.\n\n\ - ### Grace period\n\nWe define a short overlapping period in which the protocol\ - \ accepts packets with the key\nfor the previous epoch i-1 and also for the current\ - \ one i. This period should be\nideally as short as possible, although long enough\ - \ to allow using the same key for\nsingle packet request/response use cases (e.g.\ - \ a few seconds). Thus, we set\nGRACE_PERIOD = 5 seconds.\n\n### Prefetching period\n\ - \nASes will be allowed to prefetch keys some time before the key for the current\ - \ epoch expires.\nThis period must be long enough to allow every remote AS to\ - \ attempt the key prefetching\nenough times to be successful even in the presence\ - \ of failures. However, this period\nshould not be too long, since the issuer\ - \ AS is not assumed to carry out any changes\nonce it has issued keys for a given\ - \ epoch (e.g. modifying SV epoch duration,\nrotating the master secret, etc.).\n\ - \nWe suggest globally setting PREFETCHING_PERIOD = 30 minutes.\n\nNote\n\nWhether\ - \ ASes are allowed to request/serve keys for past epochs is up for discussion.\n\ - \n## Key establishment\n\n### Level 1 key establishment\n\nThe Level 1 key establishment\ - \ occurs between CSes located in different ASes.\nThe subject-AS on the slow side\ - \ (i.e. the AS requesting the key) will establish a TLS secure connection with\n\ - the issuer-AS on the fast side (i.e. the AS serving the key). Both parties identify\ - \ each other by using\nthe CP-PKI infrastructure.\n\nThe Level 1 key request message\ - \ contains the validTime that specifies for what time the requested\nkey must\ - \ be valid (it implicitly specifies the epoch for which the key will be valid)\n\ - and the protocol_id.\nThe Level 1 key response includes the symmetric key along\ - \ with the epoch\nfor which this key will be valid.\n\nThe protocol_id is either\ - \ set to GENERIC = 0 to request Lvl1 keys that will be derived according to\n\ - the generic-protocol hierarchy or to the protocol number for the protocol-specific\ - \ derivation.\n\n### Level 0/2/3 key establishment\n\nEven though Level 0/2/3\ - \ key exchange happens within the same AS (i.e. intra-AS communication),\nthe\ - \ protocol should establish a secure channel.\nThis would avoid that hosts in\ - \ the AS can eavesdrop on symmetric keys that are not\nintended for them.\n\n\ - The CS will only respond to the specific request if the requesting host\nis authorized\ - \ to receive the requested key.\nThis is especially important in the Level 0 key\ - \ case since only trustworthy nodes should\nbe authorized to receive this key.\n\ - \nThe Level 0 key request contains the validTime and the specific protocol_id.\n\ - The CS responds with the SV and the epoch for which this key will be valid.\n\n\ - The Level 2/3 key request includes the validTime and the necessary host and AS\n\ - information (depending on the key type).\nThe server responds with the symmetric\ - \ key and the epoch.\n\nThe protocol_id in Lvl2/3 requests is always set to the\ - \ final protocol identifier.\nThe key service will choose between the protocol-specific\ - \ derivation, if it exists, or\nthe generic-protocol derivation, otherwise.\n\n\ - ## Spreading Level 1 key requests\n\nShared symmetric keys are short-lived to\ - \ avoid explicit key revocation. In order\nto avoid peaks in the requests for\ - \ Level 1 keys derived from a given SV, every requesting\nCS (i.e. the CS on the\ - \ slow side) SHOULD wait a random time before trying to prefetch\nthe Level 1\ - \ key. This time t is u.r.d. in the interval [0, 15] minutes.\n\nIn this manner,\ - \ the CS on the slow side SHOULD NOT request a Level 1 key before\nepoch_end -\ - \ (PREFETCHING_PERIOD - t) instant in time (the PREFETCHING_PERIOD\nis defined\ - \ in Prefetching period).\n\n## DRKey Messages Format\n\nThe DRKey messages format\ - \ is specified in terms of their protobuf definitions.\n\n### Protocol Enum\n\n\ - DRKeys are protocol-specific. The following enum defines the valid protocol IDs.\n\ - \n```\nenum Protocol {\n // Generic (unspecified protocol)\n GENERIC = 0;\n\ - \ // SCION Control Message Protocol (SCMP)\n SCMP = 1;\n reserved 65536 to\ - \ max; // only 16-bit values allowed\n}\n```\n\n### Control Plane Messages\n\n\ - Control plane messages are used to establish level 0 and level 1 keys. They are\ - \ always between SCION\ncontrol plane entities, e.g., between two CSes in two\ - \ different ASes (level 1) or between an CS and\na router within the same AS (level\ - \ 0).\n\n```\n// SVRequest is used to request a secret value (level 0 key) for\ - \ a given\n// epoch and protocol. The secret value can then further be used to\n\ - // locally derive higher-level keys.\nmessage SVRequest{\n // Point in time when\ - \ the requested key is valid.\n Timestamp val_time = 1;\n // Protocol value.\n\ - \ Protocol protocol_id = 2;\n}\n\n// SVResponse contains the secret value (level\ - \ 0 key) and the epoch for which\n// it is valid.\nmessage SVResponse{\n // Begin\ - \ of the SV validity period.\n Timestamp epoch_begin = 1;\n // End of the SV\ - \ validity period.\n Timestamp epoch_end = 2;\n // SV key.\n bytes key = 3;\n\ - }\n\n// Lvl1Request is used to request a level 1 key for a given epoch and protocol.\n\ - message Lvl1Request{\n // Point in time when the requested key is valid.\n Timestamp\ - \ val_time = 1;\n // Protocol value.\n Protocol protocol_id = 2;\n}\n\n// Lvl1Response\ - \ contains the level 1 key and the epoch for which it is valid.\nmessage Lvl1Response{\n\ - \ // Begin of validity period.\n Timestamp epoch_begin = 1;\n // End of validity\ - \ period.\n Timestamp epoch_end = 2;\n // Lvl1 key.\n bytes key = 3;\n}\n```\n\ - \n### Application Level Messages\n\nApplication level messages are used by SCION\ - \ applications or SCION daemons to request and establish\nlevel 2 and level 3\ - \ keys from a CS in their AS. These messages constitute the API for applications\n\ - to use DRKeys.\n\n```\n// HostASRequest is used to request a Host-AS (level 2)\ - \ key for a given epoch and protocol.\nmessage HostASRequest{\n // Point in time\ - \ where requested key is valid.\n Timestamp val_time = 1;\n // Protocol value.\n\ - \ Protocol protocol_id = 2;\n // Src ISD-AS of the requested DRKey.\n uint64\ - \ src_ia = 3;\n // Dst ISD-AS of the requested DRKey.\n uint64 dst_ia = 4;\n\ - \ // Src Host of the request DRKey.\n string src_host = 5;\n}\n\n// HostASResponse\ - \ contains the Host-AS (level 2) key and the epoch for which it is valid.\nmessage\ - \ HostASResponse{\n // Begin of validity period of DRKey.\n Timestamp epoch_begin\ - \ = 1;\n // End of validity period of DRKey.\n Timestamp epoch_end = 2;\n //\ - \ Lvl2 key.\n bytes key = 3;\n}\n\n// ASHostRequest is used to request an AS-Host\ - \ (level 2) key for a given epoch and protocol.\nmessage ASHostRequest{\n //\ - \ Point in time where requested key is valid.\n Timestamp val_time = 1;\n //\ - \ Protocol value.\n Protocol protocol_id = 2;\n // Src ISD-AS of the requested\ - \ DRKey.\n uint64 src_ia = 3;\n // Dst ISD-AS of the requested DRKey.\n uint64\ - \ dst_ia = 4;\n // Dst Host of the request DRKey.\n string dst_host = 5;\n}\n\ - \n// ASHostResponse contains the AS-Host (level 2) key and the epoch for which\ - \ it is valid.\nmessage ASHostResponse{\n // Begin of validity period of DRKey.\n\ - \ Timestamp epoch_begin = 1;\n // End of validity period of DRKey.\n Timestamp\ - \ epoch_end = 2;\n // Lvl2 key.\n bytes key = 3;\n}\n\n// HostHostRequest is\ - \ used to request a Host-Host (level 3) key for a given epoch and protocol.\n\ - message HostHostRequest{\n // Point in time where requested key is valid.\n \ - \ Timestamp val_time = 1;\n // Protocol value.\n Protocol protocol_id = 2;\n\ - \ // Src ISD-AS of the requested DRKey.\n uint64 src_ia = 3;\n // Dst ISD-AS\ - \ of the requested DRKey.\n uint64 dst_ia = 4;\n // Src Host of the request\ - \ DRKey.\n string src_host = 5;\n // Dst Host of the request DRKey.\n string\ - \ dst_host = 6;\n}\n\n// HostHostResponse contains the Host-Host (level 3) key\ - \ and the epoch for which it is valid.\nmessage HostHostResponse{\n // Begin\ - \ of validity period of DRKey.\n Timestamp epoch_begin = 1;\n // End of validity\ - \ period of DRKey.\n Timestamp epoch_end = 2;\n // Lvl2 key.\n bytes key =\ - \ 3;\n}\n```\n\n## Assigned Protocol Identifiers\n\nThe following protocol identifiers\ - \ are assigned:\n\n| Decimal | Identifier | Description | Reference |\n| --- |\ - \ --- | --- | --- |\n| 0 | Generic | Identifier for Level 1 key in Generic-protocol\ - \ derivation | Generic-protocol derivation |\n| 1 | SCMP | Authentication of SCMP\ - \ messages | SCMP Specification |\n\n\n" -- source_sentence: What is the default behavior regarding checking the certificate's - validity period +- source_sentence: What is the default output of the `scion-pki key public` command sentences: - - 'Research paper providing background on BGP and SCION architectures. Explains - BGP''s path-vector routing, security issues (hijacking), and example topology. - Introduces SCION''s ISD concept, path finding (beaconing), and routing mechanisms. + - "Research paper section on a Security Analysis of PILA. Addresses potential MitM\ + \ attacks, downgrade attacks, and key compromises. Describes how PILA prevents\ + \ or mitigates these attacks, local responder-side attackers, Responder-Side NAT\ + \ attackers, and details how key compromises can be detected and their impact\ + \ is limited.\n Cyrill Krähenbühl et al.. \"Ubiquitous Secure Communication\ + \ in a Future Internet Architecture.\" SN Computer Science, vol. 3, no. 5, 2022,\ + \ pp. . \n research paper \n 9 \n\n\ + SN Computer Science (2022) 3:350 \n Page 9 of 13 350 \nSN Computer\ + \ Science\nresponder can query either the certificate service or the local \n\ + NAT, see “NAT Devices”, and check for duplicate certifi-\ncates for its identifiers.\n\ + Responder-Side NAT or AS Attacker. A malicious AS \nor a malicious NAT device\ + \ on the responder side cannot \nimmediately be detected. They do, however, create\ + \ irrefuta-\nble cryptographic proof of misbehavior in the form of con-\nflicting\ + \ end-host certificates valid at the same point in time. \nThese certificates\ + \ can be stored locally or published on an \nappend-only log server and later\ + \ be compared through an \nout-of-band channel or audited by another entity.\n\ + Other Attackers. Other entities, such as a malicious AS \nor NAT device on the\ + \ initiator’s side or an attacker in the \ninitiator’s local network, cannot perform\ + \ an MitM attack, \nsince they cannot forge valid responder certificates.\nDowngrade\ + \ Attacks\nIn this section, we analyze the three downgrade prevention \napproaches\ + \ explained in Downgrade Prevention. In a down-\ngrade attack, an attacker attempts\ + \ to convince the initiator \nconnecting to an unknown responder that the responder’s\ + \ \nAS does not support PILA or that the responder does not \nallow the desired\ + \ PILA-supported protocol. However, care \nmust be taken that the downgrade prevention\ + \ approaches do \nnot introduce an additional DoS vector where a non-PILA-\nenabled\ + \ end-host is prevented from communicating with a \nPILA-enabled end-host.\nSignature-Based\ + \ and Log-Based Approaches. Both \nthe signature-based (“Signature-based Approach\ + \ ”) and \nlog-based (“Log-based Approach”) approaches prevent \ndowngrade attacks,\ + \ since an attacker is not able to forge \nvalid signatures for bogus statements\ + \ which claim that a \nPILA-enabled end-host does not support PILA. Replaying\ + \ \na (potentially different) out-of-date statement is prevented \nby the time\ + \ stamps within the statements and due to the \nassumption of time synchronization\ + \ (see 3 ). For the same \nreason, an attacker cannot use an out-of-date statement\ + \ \nwhich claims that a non-PILA-enabled host supports PILA \nas a DoS vector,\ + \ since this statement will be rejected by the \nrelying end-host.\nSelf-verifiable\ + \ Approaches. We separate between the \ntwo self-verifiable address approaches\ + \ explained in Self-\nVerifiable Approach: address range reservation and IPv6\ + \ \naddress encoding.\nIf an AS reserves an IP address range for PILA-enabled\ + \ \ntraffic, then an attacker can neither downgrade (since the \nrelying end-host\ + \ can locally check whether the remote end-\nhost is within the IP address range)\ + \ nor use it as a DoS vector \n(since only PILA-enabled end-hosts are assigned\ + \ to this IP \naddress range).\nFor the self-verifiable IPv6 address encoding\ + \ approach, \nan attacker cannot perform a downgrade attack since the two \ncommunicating\ + \ end hosts will perform the same determinis-\ntic computation to verify whether\ + \ the end-host has encoded \nPILA support in the IP address. Regarding a potential\ + \ DoS \nvector, we consider two attackers: an on-path attacker which \ncan and\ + \ an on-path attacker which cannot influence the net-\nwork prefix of the IPv6\ + \ address of an end-host. We assume \nthe worst case, where the attacker can predict\ + \ the device \naddress that will be chosen by the end-host. The attacker’s \n\ + goal is to make the non-PILA-enabled end-host choose an \nIPv6 address that indicates\ + \ PILA support.\n• If the attacker cannot influence the network prefix and \n\ + thus cannot impact the final IPv6 address chosen by the \nnon-PILA-enabled end-host,\ + \ the probability of a DoS for \nthe non-PILA-enabled end host remains unchanged\ + \ from \nthe case without any attacker ( 2−32).\n• If the attacker can influence\ + \ the network prefix and pre-\ndict the device address, then the attacker could\ + \ poten-\ntially fabricate a network prefix, such that there is a hash \ncollision\ + \ on the leftmost 32 bit of the device address. \nThis would prevent the non-PILA-enabled\ + \ end-host from \ncommunicating with a PILA-enabled end-host. However, \nit is\ + \ very likely that an attacker with the capability of \ncontrolling the routing\ + \ within the AS can simply drop \nunwanted traffic, which is in comparison a much\ + \ stronger \nand more effective attack.\nPrivate Key Compromise\nThe severity\ + \ of a compromised private key depends on the \nentity and the lifetime of the\ + \ certificate belonging to this key.\nKey compromises of entities in the SCION\ + \ control-plane \ndelegation chain are relatively easy to detect if abused, since\ + \ \nthere would be ASes with multiple valid certificates for an \nISD and AS number\ + \ with different public keys. AS key com-\npromises are similarly easy to detect\ + \ but only allow forging \nsigned PILA messages within the compromised AS. End-\n\ + host key compromises are less severe, as end-host certifi-\ncates are short-lived.\ + \ In RPKI-based PILA, a compromised \ntrust root impacts the authenticity of all\ + \ end hosts. In com-\nparison, a compromised (ISD) trust root in SCION-based \n\ + PILA only impacts the authenticity of end-hosts within this \nISD. Additionally,\ + \ a single (or a few) compromised control-\nplane CAs can be removed from the\ + \ set of trusted CAs by \nupdating the trust root configuration (TRC) which specifies\ + \ \nall control-plane CAs.\nAttacking AS Trust\nAttackers might attempt to reduce\ + \ the trustworthiness of an \nAS. Slander, i.e., accusing a benign, uncompromised\ + \ AS \nof having issued incorrect certificates, is not possible in \n" + - "Documentation document for the scion-pki key private command, which generates\ + \ a PEM-encoded private key with selectable elliptic curve (P-256, P-384, P-521).\ + \ Defaults to P-256. The --force option controls overwriting the keyfile.\n\ + \ https://docs.scion.org/en/latest/command/scion-pki/scion-pki_key_public.html\ + \ \n documentation \n\n# scion-pki key public\n\n\ + # scion-pki key public\n\nGenerate public key for the provided private key\n\n\ + ## Synopsis\n\n‘public’ generates a PEM encoded public key.\n\nBy default, the\ + \ public key is written to standard out.\n\n```\nscion-pki key public [flags]\ + \ \n```\n\n## Examples\n\n```\nscion-pki key public cp-as.key\n\ + scion-pki key public cp-as.key --out cp-as.pub\n```\n\n## Options\n\n```\n--force\ + \ Force overwritting existing public key\n-h, --help help for public\n\ + \ --kms string The uri to configure a Cloud KMS or an HSM.\n --out string\ + \ Path to write public key\n```\n\n## SEE ALSO\n\n- scion-pki key - Manage\ + \ private and public keys\n\n\n" + - 'Book excerpt ("Bootstrapping Steps, Discovery Mechanisms") detailing the steps + of the end-host bootstrapper daemon using DHCP, DNS and mDNS and configuration + file download. Explanations focus on operation of discovery mechanisms in environments + with managed DHCP servers or DNS infrastructure. - Dennis Eijkel. "Anycast in the SCION Internet Architecture." 2022. - + Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles + to Formal Verification*. Springer International Publishing AG, 2022. - research paper + book - 9 + 348 - Chapter 2 + 13 Deployment and Operation + + the bootstrapper daemon and starts the SCION Daemon once the bootstrapper + + daemon finishes successfully. + + Bootstrapping Steps. The end host bootstrapper daemon performs the fol- - Background + lowing steps: - SCION is an emerging internet architecture that aims to provide more trust and - route control + 1. Probe the local network for hints about a bootstrapping server address us- - than the current internet powered by BGP provides. In this chapter we will introduce - BGP + ing the available discovery mechanisms (i.e., DHCP, DNS, and mDNS). - and SCION and explain their differences. We will also go into how anycast works - in BGP. The + 2. Wait for hints from the discoverers. - contents of this chapter are based on the Research Topics report that is the precursor - to this + 3. Once a hint is received, try to download the TRCs and the topology - Master Thesis report [7]. + of the AS from the bootstrapping server. While there is no maximum - 2.1 BGP + amount of TRCs to be served, the bootstrapping server must provide at - The current internet is a collection of interconnected autonomous systems, often - also referred + least the TRC of the ISD in which the AS is located. - to as a network of networks. An autonomous system can be seen as a network that - is operated + a) On success, prepare the SD’s files and exit successfully; the SD is - by a single organization. Intradomain routing refers to routing of packets within - an AS and + then automatically started by the orchestrator. - the protocol that is used for that is up to the operator. Interdomain routing - refers to routing + b) On failure, go back to step 2. - between ASes and a common protocol is needed to be able to communicate between - individual + If no hint is received after a certain period, the bootstrapper daemon times - networks. + out and exits with a non-zero value. - ASes can peer with other ASes, which means that they have a direct connection - to each + Note that the TRCs retrieval is a transition solution to ease adoption; ideally - other. An example of how a topology would look in BGP is given in Figure 2.1. - This type of + they are installed on a device out-of-band, before the device gets connected to - topology is not necessarily unique to BGP, but is used to make it easier to show - the differences + a network (more details are given in the security considerations on page 331). - in network topology and structure between BGP and SCION later on. + 13.2.3 Discovery Mechanisms - 8 + A bootstrapper can leverage DHCP, DNS or mDNS in order to find the IP + + address of the bootstrapping server. We describe each case, where we assume + + that + + • the end host is located in the example.comdomain; and + + • the IP address of the bootstrapping server is 192.168.1.1. + + DHCP. The DHCP mechanism relies on the presence of an existing DHCP + + server in the network. This mechanism is advantageous in environments where + + there is a managed DHCP server, but no dedicated DNS infrastructure is oper- + + ated for the local network. + + The DHCP server has to be configured to announce the address of the dis- + + covery services using one of the DHCP options. One natural choice is to use + + the option field with ID 72 “Default WWW server”, given that HTTP, the same + + application-level protocol as used in the WWW, is used to retrieve the config- + + uration files. In our example, we would set the option value to 192.168.1.1. + + 328 ' - - "Documentation document for the scion-pki certificate validate command, used to\ - \ validate SCION certificates based on their type. Describes type options (any,\ - \ chain, cp-as, cp-ca, cp-root, regular-voting, sensitive-voting) and the optional\ - \ --check-time flag for validating against the current time using a --current-time\ - \ parameter.\n https://docs.scion.org/en/latest/command/scion-pki/scion-pki_certificate_validate.html\ - \ \n documentation \n\n# scion-pki certificate validate\n\ - \n# scion-pki certificate validate\n\nValidate a SCION cert according to its type\n\ - \n## Synopsis\n\n‘validate’ checks if the certificate is valid and of the specified\ - \ type.\n\nIn case the ‘any’ type is specified, this command attempts to identify\ - \ what type\na certificate is and validates it accordingly. The identified type\ - \ is stated in\nthe output.\n\nBy default, the command does not check that the\ - \ certificate is in its validity\nperiod. This can be enabled by specifying the\ - \ --check-time flag.\n\n```\nscion-pki certificate validate [flags]\n```\n\n##\ - \ Examples\n\n```\nscion-pki certificate validate --type cp-root /tmp/certs/cp-root.crt\n\ - scion-pki certificate validate --type any /tmp/certs/cp-root.crt\n```\n\n## Options\n\ - \n```\n--check-time Check that the certificate covers the current time.\n\ - \ --current-time time The time that needs to be covered by the certificate.\n\ - \ Can either be a timestamp or an offset.\n\n \ - \ If the value is a timestamp, it is expected to either be an\ - \ RFC 3339 formatted\n timestamp or a unix timestamp.\ - \ If the value is a duration, it is used as the\n offset\ - \ from the current time. (default 0s)\n-h, --help help for validate\n\ - \ --type string type of cert (any|chain|cp-as|cp-ca|cp-root|regular-voting|sensitive-voting)\ - \ (required)\n```\n\n## SEE ALSO\n\n- scion-pki certificate - Manage certificates\ - \ for the SCION control plane PKI.\n\n\n" - - "Research paper explaining the implementation of a modular SCION border router\ - \ on a Tofino 2 switch. Details on the operations of the different pipes. Presents\ - \ in Section 5.1 two configuration options: 1BR+2AES using three pipelines (Figure\ - \ 4) and 2BR+2AES using two pipelines, with details about port usage and total\ - \ bandwidth (table 1), the AES implementation is splited between pipe 1 and 2.\ - \ Describes the use of \"folded pipes\" and internal loopback ports to maximize\ - \ resource utilization.\n Lars-Christian Schulz et al.. \"Cryptographic\ - \ Path Validation for SCION in P4.\" *Proceedings of the 6th on European P4 Workshop*,\ - \ 2023. \n research paper \n 4 \n\n\ - EuroP4 ’23, December 8, 2023, Paris, France Lars-Christian Schulz, Robin Wehner,\ - \ and David Hausheer\n+\nKey Table\nT-Tables +\nKey Tablex3\nEgress ParserT-Tables\ - \ +\nKey Tablex3\n0\nEgr. Deparser\nIng. Deparser\nIngress Parser\nT-Tables +\n\ - Key Tablex3\nEgr. Deparser\nEgress Parser\nSubBytes \nShiftRows +\nKey Table\n\ - Ing. Deparser\nIngress Parser\nIng. Deparser\nIngress Parser\nSCION \nBorder Router\n\ - Egress Ports\n1\n2\nIngress Ports\nHidden Ports\nPipe Ingress EgressTraffic Mgr.\n\ - Egr. Deparser\nEgress Parser\nSCION \nBorder Router\nFigure 4: 1BR+2AES configuration.\ - \ SCION router imple-\nmented by 3 Tofino 2 pipelines. Packets pass through all\n\ - three pipelines in order, but no packet is recirculated in the\nsame pipeline,\ - \ thus the overall switch has the same band-\nwidth as one of the pipelines.\n\ - 5 IMPLEMENTATION ON TOFINO 2\nWe implement our design1 in a quad-pipeline Intel\ - \ Tofino Switch\n(Edgecore DCS810 using the Tofino BFN-T20-128Q ASIC). Each\n\ - of the four pipelines is connected to eight of the total 32x 400G\nfront-panel\ - \ Ethernet ports [\n1]. The pipelines can be loaded with\nindependent programs,\ - \ effectively splitting one P4-programmable\nswitch into four. Additionally, any\ - \ port of the switch can be con-\nfigured as a loopback port. Loopback ports become\ - \ unavailable\nfor connecting external devices, hosts etc. but can facilitate\ - \ pass-\ning packets from pipeline to pipeline. By configuring all ports of a\n\ - pipeline as loopback and directing the flow of packets appropriately,\nwe can\ - \ “fold” the pipelines to create a longer pipeline with more\nresources available.\n\ - 5.1 Folded Pipe\nOur router supports different pipeline configurations depending\n\ - on the number of available pipelines, desired usable port count and\ntotal bandwidth.\ - \ The configuration1BR+2AES uses three of the four\navailable pipelines. Figure\ - \ 4 sketches the layout of operations in\nthe switch. A Packet enters the router\ - \ in Pipe 0 where the packet\nprocessing and forwarding part of the border router\ - \ is located. The\nborder router processes the packet and creates the bridge header\n\ - containing the input for MAC calculation as well as the expected\nMACs. The packet\ - \ is directed to Pipe 1 next, where it first encoun-\nters the egress processing\ - \ of that pipe. While it may seem unusual\nthat the egress pipe is executed first,\ - \ this is a consequence of the\nswitching happening in between ingress and egress.\ - \ Once egress\nprocessing has finished, the packet begins ingress processing in\ - \ the\nsame pipe, as all ports of this pipe have been configured as loop-\nback/recirculation\ - \ ports. In the same way, the packet is directed to\nPipe 2. Pipe 1 and 2 implement\ - \ the AES-CMAC validation. If the\nCMAC is valid, the packet is next forwarded\ - \ to one of the ports\nin the original border router pipeline 0. Pipe 0’s ports\ - \ operate in\nregular mode, thus the packet now leaves the router. If the MAC\ - \ is\nnot valid, the packet is dropped by Pipe 2.\n1https://github.com/netsys-lab/scion-p4\n\ - +\nKey Table\nT-Tables +\nKey Tablex3\nEgress ParserT-Tables +\nKey Tablex3\n\ - 0\nEgr. Deparser\nIng. Deparser\nIngress Parser\nIng. Deparser\nIngress Parser\n\ - SCION \nBorder Router\nEgress Ports\n1\nIngress Ports\nPipe Ingress EgressTraffic\ - \ Mgr.\nEgr. Deparser\nEgress Parser\nSCION \nBorder Router\n+\nKey Table\nT-Tables\ - \ +\nKey Tablex3\nEgress ParserT-Tables +\nKey Tablex3\n2\nEgr. Deparser\nIng.\ - \ Deparser\nIngress Parser\nIng. Deparser\nIngress Parser\nSCION \nBorder Router\n\ - Egress Ports\n3\nIngress Ports\nEgr. Deparser\nEgress Parser\nSCION \nBorder Router\n\ - Figure 5: 2BR+2AES configuration. Two instances of the\nSCION router implemented\ - \ by 2 Tofino 2 pipelines each.\nPackets are recirculated once in pipe 1 and 3.\ - \ Pipe 0-1 and\npipe 2-3 can operate as two independent border routers or as\n\ - a single router with twice the number of ports.\nBy folding the pipelines as described,\ - \ we lose the front-panel\nports of pipe 1 and 2, but we gain enough resources\ - \ per pass through\nthe switch that no additional recirculation in the same pipeline\ - \ is\nrequired, thus fitting the complete fast-path of a SCION router in a\nTofino\ - \ 2 switch without impacting the per-port throughput.\nNot all Tofino 2 switches\ - \ have the full four pipelines, models\nwith two pipelines are available as well.\ - \ In order to fit our border\nrouter to a two pipeline Tofino, we can recirculate\ - \ the packet once\nin the pipeline implementing AES, giving rise to the second\ - \ imple-\nmentation variant 1BR+1AES. Doing so exactly halves the available\n\ - bandwidth to a theoretical maximum of 1.6 Tbit/s, but as we leave\npipe 0 unchanged,\ - \ the number of ports available for connections to\nother switches stays the same.\ - \ As oversubscribing ports can also\nbe useful on quad-pipeline switches, it can\ - \ also be desirable to in-\nstantiate two copies of the 2 pipe variant on a quad-pipeline\ - \ switch\nas shown in Figure 5. We refer to this configuration as 2BR+2AES.\n\ - An overview of the available ports and bandwidth in each con-\nfiguration is given\ - \ in Table 1. Note that the number of usable ports\ngiven for 1BR+2AES, 1BR+1AES,\ - \ and 2BR+2AES stays the same\nfor switches that do not connect all pipelines\ - \ to externally accessi-\nble ports, making them particularly well suited as SCION\ - \ border\nrouters.\nIn the next sections we detail the operation of the different\ - \ pipes.\nConfiguration Pipes Ports Bandwidth\nBR w/o AES 4/4 32/32 12.8 Tbit/s\n\ - 1 BR + 2 AES 3/4 8/32 3.2 Tbit/s\n1 BR + 1 AES 2/4 8/32 1.6 Tbit/s\n2 BR + 2 AES\ - \ 4/4 16/32 3.2 Tbit/s\nTable 1: Usable 400 Gbit/s ports and total available bandwidth\n\ - taking recirculation into account for different configurations\nof the border\ - \ router.\n20\n" -- source_sentence: What are the role of 12 functions that rely on simple, unproved - lemmas? +- source_sentence: How might operators of large replicated services manage their own + ISD sentences: - - "Research paper evaluating SCIONLab's data-plane performance, focusing on latency\ - \ stretch compared to direct Internet connections. Measures RTT using SCMP-based\ - \ echo application. Shows latency improvements, discusses path stretch, and shows\ - \ examples of AWS path selection and network latency.\n Jonghoon Kwon\ - \ et al.. \"SCIONLab: A Next-Generation Internet Testbed.\" *Proceedings of the\ - \ IEEE International Conference on Network Protocols (ICNP)*, 2020. \n\ - research paper \n 8 \n\n 0\n 0.2\n 0.4\n 0.6\n\ - \ 0.8\n 1\n-150 -100 -50 0 50 100\nC\n\0\n\x01\nR \x02 \x02\n d\x03 \x04\x05\ - \ \x06 \a \b \t\n\v \b \n \x04\x05 \x06 \a \b \t\n (ms)\nMulti-hop\nOne-hop\n\ - -100\n-10\n0\n10\n100\n1000\n 0 50 100 150 200 250 300 350\nR\n\0\n\0\n\ - \ \no\n\x01\n\x02\n\x03\n\x04\n\x02\n\x05\n\x06\n (%)\n\a\b \b \t\n\v \f t \r\ - \ \v I\x0E t \v \f \x0E\v t (\x0F \x10 \x11\nMulti-hop\nOne-hop\nFigure 5: RTT\ - \ deflation/inflation for all pairs of infrastructure ASes on S CION LAB\n(RTTSCMP\ - \ −RTTICMP).\n 0\n 0.2\n 0.4\n 0.6\n 0.8\n 1\n 0 1 2 3 4 5\nCDF\nPath stretch\ - \ (da/ds)\nFigure 6: CDF curves of path stretch for\nall direct links.\nfrequency\ - \ of once every 5 seconds is an aggressive approach\nand a value of PT near 3600\ - \ seconds would start being\nreasonable. We conclude that only a small amount\ - \ of resources\nis expended by the core path server in most cases. For example,\n\ - the CPU consumption is bounded below 29 % of a single core\nfor RT = 15. The memory\ - \ consumption ranges 22 ∼39 MB.\nPath resolution may cause a serious resource\ - \ exhaustion on\nthe core path servers, which are responsible for all the path\n\ - requests within the corresponding ISD. Therefore, caching\npath segments in local\ - \ path servers is essential to reduce the\nheavy load on the core path server,\ - \ achieving the path-service\nscalability. Recall that each path server caches\ - \ requested path\nsegments and reuses them upon receiving the same requests\n\ - until they expire; only the cache-missed requests are recur-\nsively forwarded\ - \ to the core path server. To evaluate this, we\nassess the actual path requests\ - \ collected from the S CION LAB\npath servers during a hackathon event on October\ - \ 12, 2019 [9].\nFrom the results, we make the following observations: 1)\nThe\ - \ number of path requests observed at the core path server\ndoes not reflect the\ - \ total number of path requests within\nthe ISD. 2) From the local path servers,\ - \ only a few path\nrequests (27 % of cache-misses) are forwarded to their core.\n\ - 3) With multiple core path servers, the load of path requests\ncan be distributed.\ - \ The observations suggest that the load\nbalancing (i.e., the caching and distributed\ - \ services) is the key\nto minimizing the overhead of path resolution, achieving\ - \ path-\nservice scalability.\nC. Data-Plane Performance\nWe now measure the latency\ - \ stretch, compared to a direct\nInternet connection. Interestingly, S CION LAB\ - \ forwarding can\nachieve lower latency than the Internet, thanks to the possibil-\n\ - ity to optimize the path in a path-aware network architecture.\nNetwork Latency\ - \ in S CION LAB. We start by measur-\ning the round-trip time (RTT) between all\ - \ the S CION LAB\nnode pairs—in total of 496 pairs for 32 ASes under our\nadministration—using\ - \ the SCION Control Message Protocol\n(SCMP)–based echo application, which is\ - \ similar to ICMP\necho for the IP network; we then compare it with the RTTs\n\ - using the current Internet. Figure 5 plots the RTT differences\nbetween S CION\ - \ LAB and the current Internet, i.e., RTTdiff =\nRTTSCMP −RTTICMP. If the RTTdiff\ - \ is negative, it means\nthat S CION LAB provides better latency than the IP network\n\ - for the particular node pair. Note that the results do not\ncontain RTTdiff for\ - \ all node pairs as nine institutions hosting\nSCION LAB nodes filter ICMP packets\ - \ for “security reasons”.\nNonetheless, the number of the institution pairs that\ - \ filter\nICMP from both sides is low (36 out of 496 pairs) and we\nconsider the\ - \ missing results to be negligible and not affecting\nthe overall result.\nSince\ - \ the majority of links in the current S CION LAB\ntopology are overlay connections,\ - \ it can be expected that\nmost values of RTTdiff are positive, as there is an\ - \ additional\noverhead such as queuing delay and processing delay taken\nby the\ - \ software-defined S CION LAB applications. As we can\nsee in Figure 5 (left),\ - \ RTTdiff is almost always positive\nbetween node pairs with a one-hop distance,\ - \ because of this\nadditional overhead, although over 83 % of node pairs show\n\ - a RTTdiff with a tolerable RTTdiff ≤ 5 ms. The negative\nRTTdiff for one-hop measurements\ - \ is observed between the\nbackbone ASes due to the ICMP deprioritization on AWS.\n\ - With multi-hop communication, S CION LAB achieves better\nnetwork latency for\ - \ almost one third of the node pairs. This\nprompts the question: “ How are these\ - \ improvements even\npossible despite the additional delays inone-hop communi-\n\ - cation?” The improvement is possible by taking advantage\nof the path-aware networking\ - \ provided by S CION LAB. For\nexample, consider end-to-end communication where\ - \ one end-\nhost is in Europe and another is in East Asia. In the current\nInternet,\ - \ the packets typically travel over North America,\nwhich is a serious detour,\ - \ but there is no other option the\nend-host can take because it does not control\ - \ routing. Re-\ncall that BGP does not always select the latency-optimized\npath\ - \ [49]. In contrast, S CION LAB provides various possible\nforwarding path candidates\ - \ to users, allowing them to choose\na desired path and forward their packets\ - \ according to their\nown criteria, achieving a better forwarding path minimizing\n\ - latency. Figure 5 (right) shows that SCION LAB achieves better\nlatency for a\ - \ majority of node pairs with high ICMP latency\n(RTTICMP ≥200 ms). There are\ - \ 94 pairs with a negative\nRTTdiff and RTTICMP ≥200 ms, and out of them 54 do\ - \ not\nhave an AS from the backbone ISD in their forwarding path.\nThis implies\ - \ that the improvement on the better latency comes\nfrom path-awareness in most\ - \ cases.\nTwo thirds of the cases score RTTdiff ≥0 ms; one third\nincurs more than\ - \ 25 ms of additional delay and 8 % of node\npairs have RTTdiff ≥ 50 ms. The additional\ - \ delays are\nmostly caused by inevitable detours in the current S CION LAB\n\ - " - - 'Research paper abstract on G-SINC, a Byzantine fault-tolerant global clock synchronization - system for SCION. G-SINC leverages SCION''s resilience and security for constructing - a backward-compatible system that doesn''t trust any single entity, tolerating - faulty nodes. The abstract notes that over 94% of time servers minimize offset - with up to 20% malicious nodes, and servers remain synchronized within 2ms after - a year of reference clock outage. Mentions a two-tier structure (global top-level - and local) based on strong security. - - Marc Frei et al.. "G-SINC: Global Synchronization Infrastructure for - Network Clocks." *Proceedings of the Symposium on Reliable Distributed Systems - (SRDS)*, 2022. + - 'Research paper on PISKES providing background on source address validation limitations + (SAV/BCP 38), cookie-based systems, and client certificates. Discusses limitations + of key-distribution systems like Passport and extends on prior work, DRKey, to + form the new PISKES design. + + Benjamin Rothenberger et al.. "PISKES: Pragmatic Internet-Scale Key-Establishment + System." *Proceedings of the ACM Asia Conference on Computer and Communications + Security (ASIACCS)*, 2020. research paper - 1 + 3 - G-SINC: Global Synchronization Infrastructure for + section. Here we focus on several representative and well-known - Network Clocks + systems—an exhaustive overview of related work is provided in §8. - Marc Frei∗, Jonghoon Kwon∗, Seyedali Tabaeiaghdaei∗, Marc Wyss∗, Christoph Lenzen†, - and Adrian Perrig∗ + 3.1 Authentication Systems - ∗Network Security Group, Department of Computer Science, ETH Zurich, Switzerland + 3.1.1 Source Address Validation. Source address validation (SAV), - Email: {marc.frei, jong.kwon, seyedali.tabaeiaghdaei, marc.wyss, adrian.perrig}@inf.ethz.ch + also known as best current practice (BCP) 38 [ 24], is not an au- - †CISP A Helmholtz Center for Information Security, Germany + thentication system in the strict sense but is still often considered - Email: lenzen@cispa.de + a solution to source-address spoofing in the Internet. With SAV, - Abstract—Many critical computing applications rely on secure + ASes monitor traffic originating from their own hosts and filter - and dependable time which is reliably synchronized across large + out packets with a source address outside their own address space. - distributed systems. Today’s time synchronization architectures + However, due to incentive misalignments,2 the adoption of SAV - are commonly based on global navigation satellite systems at the + has been slow and a recent study found that many ASes still do - considerable risk of being exposed to outages, malfunction, or + not employ it in their networks [46]. Furthermore, it is impossible - attacks against availability and accuracy. This paper describes a + to determine from the outside if a particular AS employs SAV or if - practical instantiation of a new global, Byzantine fault-tolerant + a particular packet originated from an AS that employs SAV as it - clock synchronization approach that does not place trust in + does not carry any proof of authenticity. For an external service it is - any single entity and is able to tolerate a fraction of faulty + therefore impossible to filter traffic based on whether it originated - entities while still maintaining synchronization on a global scale + from an AS employing SAV. Even with a full deployment of SAV - among otherwise sovereign network topologies. Leveraging strong + in the Internet, on-path adversaries would still be able to spoof - resilience and security properties provided by the path-aware + the source of packets and SAV thus provides very weak security - SCION networking architecture, the presented design can be + properties. There exists a wide range of other filtering techniques - implemented as a backward compatible active standby solution + with similarly limited properties [4, 21, 34, 43, 56]. - for existing time synchronization deployments. Through extensive + 3.1.2 Cookies. Several protocols, including TLS [63], IKEv2 [38], - evaluation, we demonstrate that over 94% of time servers reliably + and DNS [22] define a cookie mechanism to provide a weak form - minimize the offset of their local clocks to real-time in the + of source authentication. The basic mechanism for these systems is - presence of up to 20% malicious nodes, and all time servers + similar: Upon receiving a request, the server replies to the sender - remain synchronized with a skew of only 2 ms even after one + with a cookie that encodes the request parameters without allo- - year of reference clock outage. + cating state or processing the request. Only after receiving this - Index T erms—Byzantine fault tolerance; clock synchroniza- + cookie back from the source, the request is processed. Compared - tion; multipath communication + to SAV, cookies have the advantage that they can be enforced by - I. I NTRODUCTION + services without relying on Internet service providers (ISPs) to + + perform filtering. However, cookies introduce additional latency + + of one round-trip time (RTT) and are still susceptible to spoofed - Secure and dependable time synchronization is an essential + packets by on-path adversaries. - prerequisite for many industries with applications in finance, + 3.1.3 Client Certificates. Strong authentication properties can be - telecommunication, electric power production and distribution, + achieved through asymmetric cryptography and client certificates. - or environmental monitoring. + These are supported, for example, by TLS [63] and DTLS [64]. How- - Current best practice to achieve large-scale time synchro- + ever, authentication using client certificates requires expensive - nization relies on Coordinated Universal Time (UTC) as a + asymmetric cryptography in violation of our efficiency require- - global time standard which is distributed within multiple, + ments (§2.1.2). Furthermore, these systems cannot authenticate the - hierarchical synchronization networks from a set of primary + first packet and are vulnerable to signature-flooding attacks. - time servers to every end host in the system. The Network + 3.2 Key-Distribution Systems - Time Protocol (NTP) [43] is a commonly used protocol for + 3.2.1 Passport. Passport [44] provides mechanisms to establish - this purpose. Global Navigation Satellite Systems (GNSSes) + shared keys between any pair of ASes based on a DH key exchange - are the most practical and cost effective sources of UTC as a + piggybacked on BGP messages. It relies on a secure routing system - reference time in this architecture. + to ensure the authenticity of the shared keys, which can subse- - Alternatives to GNSSes as reference clocks for UTC exist, + quently be used to authenticate the source of packets at the network - but these more specialized methods are primarily used in + layer. For our purposes (see §2), Passport by itself is inadequate for - purpose-built solutions with very specific use-cases: + several reasons: (i) it only enables authentication at the AS level, - • Multi-Source Common-View Disciplined Clock + (ii) it requires authenticating systems to keep a store of symmetric - (MSCVDC) is a recent design to support critical + keys for all ASes (currently approximately 68 000 [6]), (iii) it has - infrastructure systems that require fault-tolerant clock + 2The costs of deploying SAV are paid by an AS itself while its benefits are experienced - synchronization. In its current stage of development, + by the rest of the Internet. - MSCVDC makes use of GNSSes (and a central cloud + Table 1: Notation used in this paper. - service). Conceptually it would be feasible to augment + ∥ bitstring concatenation - the implementation with additional time sources, possibly + 𝐴,𝐵 autonomous systems (ASes) identified by AS number (ASN) - even based on terrestrial transmitters. But it remains + 𝐻𝐴, 𝐻𝐵 end hosts identified by IP address - to be explored in how far the strict dependency on + 𝐾𝑆𝐴, 𝐾𝑆𝐵 key servers located in a specific AS - GNSSes could be removed for deployments beyond + 𝑆𝑉𝐴 AS 𝐴’s local secret value - geographically restricted areas [52], [40]. + 𝑆𝑉𝑝 - • Two-Way Satellite Time and Frequency Transfer (TW- + 𝐴 AS 𝐴’s local secret value for protocol 𝑝 - STFT) provides significantly better synchronization qual- + ˜𝐾𝑝 - ity than one-way communication with GNSSes at much + • symmetric key derived (indirectly) from 𝑆𝑉𝑝 - higher complexity and cost [65]. Like GNSSes, TW- + 𝐾𝐴→𝐵 symmetric key between ASes 𝐴and 𝐵, derived from 𝑆𝑉𝐴 - STFT relies on satellite infrastructure which represents + 𝐾𝑝 - a potential source of disruption. The system also poses + 𝐴→𝐵 symmetric key between ASes 𝐴and 𝐵for protocol 𝑝 - considerable unsolved scalability challenges to support + 𝐾𝑝 - more than a few tens of clients [53]. + 𝐴→𝐵:𝐻𝐵 - • Time distribution over dedicated fiber optic links does not + symmetric key between AS 𝐴and end host 𝐻𝐵 in AS 𝐵for pro- - come with a dependency on satellites. At the same time + tocol 𝑝 - this technology is not flexible enough to synchronize a + 𝐾𝑝 - potentially large and evolving set of primary time servers + 𝐴:𝐻𝐴→𝐵:𝐻𝐵 - around the globe [11], [27]. + symmetric key between end host 𝐻𝐴 in AS 𝐴and end host 𝐻𝐵 - • Physical transport of high-accuracy clocks can be a viable + in AS 𝐵for protocol 𝑝 - synchronization method but it is even more limited in its + H(·) non-cryptographic hash operation - application than dedicated fiber optic links [22]. + MAC𝐾(·) message authentication code using key 𝐾 - We also note that installation of atomic clocks at every site + PRF𝐾(·) pseudorandom function using key 𝐾 - to be synchronized is not sufficient to avoid dependencies + {𝑋}𝑃𝐾𝐴 public-key encryption of 𝑋 using AS 𝐴’s public key - on GNSSes. Atomic clocks can only serve as accurate and + {𝑋}𝑃𝐾− - highly stable oscillators. As so-called frequency standards they + 𝐴 public-key signature over 𝑋 using AS 𝐴’s private key - cannot provide UTC by themselves but have to be continu- + no mechanism to delegate keys to certain services. Other systems, - ously synchronized with external time sources [39]. Ongoing + such as Kerberos [54], are reviewed in §8. - synchronization is required to compensate for nonidentical + 3.2.2 DRKey. Dynamically Recreatable Keys (DRKeys) have been - frequency drifts among separate clocks. Moreover, due to + proposed to efficiently derive and distribute symmetric shared keys - occasional (positive or negative) leap second insertions, UTC + between routers and end hosts in the context of Origin and Path - is not a fixed time scale that can be computed locally without + Trace (OPT) [41], a system providing path validation. The system - external coordination. + has later been generalized and embedded in the SCION Internet - Based on this short survey we conclude that there currently + architecture [58]. DRKey’s fundamental idea is that each AS 𝐴 - exists no practical alternative to GNSSes to receive UTC as a + can efficiently derive a key hierarchy starting from a secret value - global reference time. In the context of critical infrastructure + 𝑆𝑉𝐴, providing keys shared with other ASes, 𝐾𝐴→𝐵, and end hosts, - this means a significant risk since GNSSes exhibit a num- + 𝐾𝐴→𝐵:𝐻𝐵. By periodically exchanging the keys 𝐾𝐴→𝐵 between - ber of potentially severe vulnerabilities such as equipment + ASes, from which host-level keys can be derived, DRKey enables - failure [25], misconfiguration, malicious manipulation by at- + an efficient global distribution of symmetric keys. - tackers [51], and due to more localized spoofing or jamming + DRKey fulfills most of our requirements to a key-distribution - attacks [69], [26]. Natural disasters like, for example, solar + system and thus provides the basis of PISKES. However, PISKES - superstorms could also hit and impact GNSSes [30]. + refines and extends the existing DRKey system [58] in several sig- - 133 + nificant ways: (i) PISKES modifies DRKey to make it applicable to - 2022 41st International Symposium on Reliable Distributed Systems (SRDS) + the current Internet in addition to SCION; (ii) it adds efficient mech- - 2575-8462/22/$31.00 ©2022 IEEE + anisms to delegate specific keys to services in an AS; (iii) it specifies - DOI 10.1109/SRDS55811.2022.00021 + many of its important practical aspects in further detail; and (iv) it + + fixes recently discovered vulnerabilities of DRKey’s key-exchange + + mechanisms due to an inadequate application of signatures [33]. + + 4 KEY DERIVATION AND DISTRIBUTION + + In this section, we present the key-derivation and -distribution + + mechanisms used for PISKES. This is based on the DRKey sys- + + tem [58], but we significantly extend it with additional delegation + + mechanisms and other optimizations, see also §3.2.2. Furthermore, + + we also formally model and verify security properties of this key- + + distribution system, see §7.1. + + We first provide a high-level overview to convey an intuition + + of the operation of our system. Figure 1 shows the basic use case + + of PISKES, where a host 𝐻𝐴 in AS 𝐴desires to communicate with + + a server 𝑆𝐵 in AS 𝐵, and 𝑆𝐵 wants to authenticate the network ' - - 'Research paper "Protocols to Code: Formal Verification of a Next-Generation Internet - Router" summarizing main results and effort. Protocol verification: 16,100 LoC - in Isabelle/HOL, extending prior work, 2-3 person-years. Implementation verification: - 4,700 LoC Go, 13,400 LoC annotations, 2.8 annotation/code ratio, 2.5 person-years. - Reports bugs found (5 protocol, 13 implementation), stronger loop freedom property. - Includes fixes and confirms bug reports. + - 'Book chapter on SCION Control Plane explaining path exploration (beaconing). + Describes PCB initiation and propagation by beacon servers. Covers intra-ISD beaconing + (up/down segments) and core beaconing (core segments). Details initial PCB creation + with initial ASE containing hop field (HF0) with empty ingress interface and specified + egress interface. Mentions use of one-hop paths and service addresses for beacon + dissemination. - João C. Pereira et al.. "Protocols to Code: Formal Verification of - a Next-Generation Internet Router." 2024. + Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles + to Formal Verification*. Springer International Publishing AG, 2022. - research paper + book - 10 + 90 - library gopacket. We achieved our goal of verifying the de- - - ployed, performance-optimized implementation as is, except + 4 Control Plane - for three small changes to work around limitations of Gobra. + 4.2.1 Initiating Beaconing - First, we rewrote one type declaration that uses a specific + Each core AS, through its beacon service, periodically initiates the path explo- - combination of Go’s interfaces and Go’s delegation mecha- + ration process by creating an initial PCB and propagating it. The PCB is either - nism that is not supported by Gobra. Second, we split some + sent to a child AS (in the case of intra-ISD beaconing) or to other core ASes - compound expressions, which allows us to add necessary + (in the case of core beaconing). The beacon service inserts (among other infor- - annotations about intermediate results. Third, we rewrote + mation) the initial AS entry ASE0 in the PCB. In the intra-ISD case, the initial - some range-loops into regular for-loops, which in some + PCB can optionally contain peer entries to non-core ASes. The hop entry HE - cases simplifies permission-based reasoning. + inside ASE0 includes an initial hop field with the ingress interface identifier + set - Altogether, we fully verified 332 functions across 12 pack- + to ‚ (which indicates an empty value): - ages. Of these, 12 functions rely on simple, unproved lemmas + HF0 “ x FlagsHF } ExpTime } ‚ } ConsEgress } HFAuthy. (4.9) - relating the representation of packets as bytestrings and their + The initial hop field denotes the extremity of a path segment and authenti- - logical counterpart. An additional 12 functions are verified + cates a forwarding decision for every packet that - except for a few paths (related to error handling) due to + • enters the AS through the interface ConsEgress and terminates in the - two implementation errors that we detected and reported, + AS; - but that were fixed too late for us to verify the fix. Another + • originates from the AS and exits through the interface ConsEgress; or - three functions are verified partially because of performance + • switches to another path segment at this AS (using one of the possible - problems of Gobra. We are currently closing this small gap. + path-segment combinations, as described in § 5.5). - In total, we added 13,400 lines of specifications and an- + The beacon service then signs the PCB and sends it to a border router (which - notations, including 900 for the I/O specification and the + corresponds to the ConsEgress identifier as specified in the hop field). - definitions it depends on. We wrote another 2,400 lines of + PCBs are disseminated within packets addressed to the beacon service using - trusted specifications for the Go standard library and third- + the corresponding service address (see § 4.6). Furthermore, the special one- - party libraries. The overhead of 2.8 lines of annotation per + hop path is used to initiate the communication to a neighboring beacon service - line of code is typical for SMT-based deductive verification + (see § 5.4.1). This is necessary because there may not be a full forwarding - and would be substantially higher for verification using an + path available for beaconing. Indeed, the discovery of such paths in turn relies - interactive theorem prover. Annotating and verifying the + on beaconing. The purpose of one-hop paths is thus to break this circular - code took roughly 2.5 person years; + dependency. - running Gobra on the implementation takes three hours + During core beaconing, the neighboring AS that receives the PCB can be - on a commodity laptop. + in the same or in a different ISD. The ISD identifier included in the PCB’s - Our specifications express essential safety and security + signature metadata describes only the ISD of the PCB’s originator. - properties of the router implementation. As such, we expect + 4.2.2 Propagating PCBs - them to greatly facilitate the evolution of the code base be- + After beaconing is initiated, each PCB is propagated in the following way: - cause Gobra can check automatically whether any changes + The ingress border router of the next AS in the beaconing path receives the - to the implementation still satisfy the existing specification. + PCB, detects that the destination is a SCION service address, and sends it - 6.2 Improvements of protocol and implementation + to the AS’s beacon service. The beacon service verifies the structure and all - Our work discovered numerous bugs and led to improve- + signatures on the PCB. The PCB contains the version numbers of the TRC(s) 3 - ments of both the protocol and the implementation. We + and certificate(s) that must be used to verify the signatures. This enables the - provide additional detail in Appendix A. + 3Even within a single ISD, there can be multiple valid TRCs at the same time, + see § 3.1.6. - Discovered protocol attacks. We found five attacks, in- + 70 - cluding a critical attack that allowed a malicious sender to + ' + - 'Research paper describing the "Multiple Advertisements" approach for Anycast + in SCION. Proposes advertising the same AS number from multiple locations, leveraging + SCION''s path servers. Discusses addressing limitations (single ISD) and potential + workarounds. - fabricate arbitrary forwarding paths, thus violating all three + Dennis Eijkel. "Anycast in the SCION Internet Architecture." 2022. + - security properties. All vulnerabilities were resolved, except + research paper - a minor one currently under discussion. + 20 - Strengthened properties. Our formalization led us to dis- + - cover an additional check that routers could perform, which + Addressing - allowed us to prove a stronger loop freedom property. In the + In the multiple advertisements solution, the same AS number is advertised from + different points - original protocol, we could prove that a loop can exist only + in the network, thus making the AS replicated and therefore also the services + that reside inside - if there is some compromised on-loop AS. With our improve- + of it. A SCION address is a triple of (ISD, AS, address) and does not allow for + multiple ISD - ment, loops can exist only if all on-loop ASes are compro- + or AS identifiers in a single address. Therefore to have a single address for + all of the different - mised. The developers implemented our recommendation. + replicas that make up the service, all of the replicas must be put in the same + AS that resides in - Discovered implementation bugs. We reported thirteen + a single ISD. A way to work around this limitation would be to extend the addressing + format of - previously unknown issues in the router implementation, all + SCION, either by allowing multiple ISD identifiers in the same address or a wildcard + instead of - of which have been confirmed by the SCION developers. So + the ISD identifier. - far, seven of them were fixed and three have pending fixes + Putting a wildcard in the address in the place of the ISD identifier would make + that the - under discussion. The remaining three issues indicate latent + address does not have the hijacking protection through isolation that regular + SCION addresses - bugs that do not currently affect the forwarding logic, but + have, thus possibly allowing for hijacking of routes. This means that traffic + for that wildcard - might in the future as the code evolves. The detected bugs + address can route to any ISD that hosts that AS number in their network, the rightful + owner of - affect the safety, functional correctness, and the I/O behav- + the AS number has no control over which ISDs the traffic intended for their network + would end - ior of the router. While verifying safety, we found missing + up. - bounds checks, a nil-pointer dereference, + Putting multiple ISD identifiers in a single address would mean that we would + get practically - and data races. Verification of functional correctness un- + the same system as the naming solution described in Section 3.3, where instead + of through the - covered missing checks after decoding SCION paths, incor- + naming system, alternate replicas are given in a single address. - rect error handling, and the incorrect accumulation of met- + The conclusion is that both of these workarounds are not favorable. - rics. Finally, verifying the I/O behavior detected a critical + ISD considerations - bug where the router did not reject packets simultaneously + Considering the issues that exist around the addressing described before, replicated + AS would - originating from and destined to the internal network. This + be part of a (single) regular ISD that might also have ASes that are not replicated. + But it is also - behavior is explicitly ruled out by the SCION protocol and + possible to have dedicated ISD(s) for replicated services. These could come in + multiple different - our models, but was allowed by the implementation. These + forms. - findings demonstrate that all major steps of the code verifi- + Operators of big replicated services might want to run their own ISD. These ISDs + would - cation were effective in uncovering bugs. Remarkably, all of + then only have core ASes or only a limited number of non-core ASes. The core ASes + would - these bugs escaped the extensive code reviews, testing, and + then have many peerings with other ISD cores at different geographical locations. + Replicated - fuzzing that are continuously performed on the code base, + service operators are probably not interested in providing transit for traffic + through their ISD, - in parallel with formal verification. + thus they would not propagate beacons that would lead to paths that travel through + their ISD - 7 Lessons learned + being created. - In this section, we reflect on our project and draw lessons + Another scenario could be that there are third parties that operate an anycast + ISD and - learned for future large-scale verification efforts. + provide transit service to customers that want to operate a replicated service. + The anycast ISD - 7.1 Overall methodology + operator would operate the ISD core ASes and peer those with many other cores. + Customers - One of the most fundamental design decisions of our project + can then peer at multiple locations with (some of) the anycast core(s). - was to follow the Igloo methodology [49], which separates + 19 - the protocol verification from the code verification and soundly + ' +- source_sentence: How is the concept of configurable rates in Z-Lane intended to + accommodate varying traffic demands + sentences: + - 'Research paper setup description section detailing the specific SCIONLab configuration, + including AS creation, attachment to ETHZ-AP, and VM setup. Lists and describes + SCION applications crucial the experiments: ''scion address'', ''scion showpaths'', + ''scion ping'', ''scion traceroute'', and ''scion-bwtestclient'', including their + options and parameters(like packet size, bandwidth target) for performance evaluation + on the network. + + Antonio Battipaglia et al.. "Evaluation of SCION for User-driven Path + Control: a Usability Study." *Proceedings of the SC ''23 Workshops of The International + Conference on High Performance Computing, Network, Storage, and Analysis*, 2023. + - integrates the two parts to provide overall guarantees. This + research paper - methodology worked extremely well in our project. First, it + 3 - allowed us to work on the protocol and code verification in + - parallel, which greatly reduced the overall time required for + Evaluation of SCION for User-driven Path Control: a Usability Study SC-W 2023, + November 12–17, 2023, Denver, CO, USA - the project. Igloo links the most-refined protocol model to + Figure 1: SCIONLab Topology: in light orange there are Core ASes; Non-Core ASes + are white colored; Attachment Points are - the implementation via the I/O specification. The develop- + green; our AS is blue. - ment of all other, more-abstract protocol models as well as + help us run specific experiments we will discuss in later sections. - the verification of all other code properties (safety, functional + Once this configuration phase was completed, SCIONLab web inter- - correctness, finite processing) are independent of each other. + face provided a unique ASN for our AS, along with cryptographic - Second, Igloo enables using different verification techniques + keys and public-key certificates. Subsequently, a Vagrant file for - and tools for the protocol and code verification, respectively. + our AS was generated to instruct the configuration of a Virtual - This freedom allowed us to use an expressive interactive + Machine (VM) that represents our AS. This file made the setup - theorem prover to verify global properties of a system of + process lightweight by automating the installation of SCIONLAB - unbounded size and and a separation logic based program + services, relevant packages, and necessary configurations. Finally - verifier to reason about the intricacies of a performance- + we were ready to use a fully configured VM belonging to the global - optimized Go implementation. Performing both verification + SCIONLab topology. - tasks within one framework would have been infeasible. + 3.3 Available Applications - The Igloo methodology requires that the most-refined + The VM configuration process also installs a predefined set of - protocol model and the implementation agree on the I/O + SCION applications. The SCION apps that we used in our experi- - operations performed by a system, which are determined + ments are: - by the I/O library used in the implementation. Aligning our + • scion address : this command returns the relevant SCION - 10 + address information for the local host, that is, our AS where - ' -- source_sentence: In the evaluation, which method (native SCION or SIG) showed better - performance in terms of CPU and memory utilization - sentences: - - "Research paper \"DMTP: Deadline-aware Multipath Transport Protocol\" covering\ - \ SCION network visualization, the goals of DMTP, and an overview of its technologies.\ - \ Describes DMTP as a user-space protocol utilizing SCION-UDP, incorporating optimal\ - \ path combination selection using linear programming (or heuristics, or PANAPI)\ - \ and heuristics, smart packet retransmission, and adaptive FEC (Reed-Solomon\ - \ coding). Presents DMTP's high-level architecture, including the Sender and Receiver\ - \ components with modules like Splitter, Encoder, Reassembler, Scheduler, Send/Receive/UnACK\ - \ Queues and Path Selection Optimizer. Explains the interaction and functions\ - \ between the modules.\n Tony John et al.. \"DMTP: Deadline-aware Multipath\ - \ Transport Protocol.\" *Proceedings of IFIP Networking*, 2023. \n\ - research paper \n 4 \n\nD\nZ1\n Z2\nZ3\nC\n\ - F\nH\nJ\nG\nI\nISD\nCore\nISD\nCore\nISD\nCore\nISD\nCore\nISD 1 ISD 3 ISD 4\n\ - ISD 2\nAS\nCore link\nPeering link\nParent - Child link-\nFig. 1. SCION network\ - \ with four ISDs showing two of the possible end-to-\nend paths between ASes C\ - \ and G\nresearch and running experiments on a SCION network,\nSCIONLab provides\ - \ a global SCION testbed where users can\ncreate personal ASes [25].\nV. D EADLINE\ - \ -AWARE MULTIPATH TRANSPORT PROTOCOL\nThe goal of our Deadline-Aware Multipath\ - \ Protocol is\nto deliver data from one host to another within a speci-\nfied\ - \ deadline with minimum overhead and minimum cost.\nThroughout the rest of the\ - \ paper, the term protocol refers to the\nDeadline-Aware Multipath Transport Protocol.\ - \ Our protocol\nruns in the user space and uses the path-aware networking\nof\ - \ SCION Internet Architecture for communication. As UDP\nis the defacto transmission\ - \ protocol upon which most real-\ntime and latency-sensitive protocols are built,\ - \ we are using the\nSCION version of UDP, SCION-UDP as our base transmission\n\ - protocol.\nTo fulfill the deadline and reliability requirements, we in-\ncorporate\ - \ the following technologies into a transport protocol:\n• Optimal path combination\ - \ selection\n• Smart packet retransmission\n• Adaptive FEC\nChuat et al. [18]\ - \ describe the optimal path selection for\ndeadline-sensitive data as an optimization\ - \ problem. They have\nproposed to use linear programming (LP) to select the optimal\n\ - paths and the proportion of bandwidth to assign to each path\nwhile maximizing\ - \ communication quality or minimizing cost.\nWe are adopting this strategy in\ - \ our protocol. The heuristics-\nbased approach requires less computation compared\ - \ to solv-\ning the LP problem, making it more suitable for scenarios\nwith limited\ - \ computational resources or in highly dynamic\nnetworks where path selection\ - \ needs to be run at a higher\nfrequency. However, the heuristics-based approach\ - \ might not\nalways find the optimal solution, as it relies on approximations,\n\ - while the LP-based approach guarantees optimality under\ncertain conditions. Thus,\ - \ depending on the specific network\nrequirements and constraints, either the\ - \ heuristic algorithm\nalone may be sufficient, or a combination of LP and heuristics\n\ - may be needed for optimal path selection. Alternatively, the\nPath-Aware Networking\ - \ Application Programming Interface\n(PANAPI) [26] may also be used for optimal\ - \ path selection.\nSmart packet retransmission ensures that retransmission\nhappens\ - \ only if the retransmitted packet can reach the re-\nceiver within the required\ - \ deadline and retransmission happens\nthrough one of the fastest paths available.\n\ - FEC works by generating and sending redundancy packets\nalong with data packets\ - \ to recreate packets lost in transmission.\nIt utilizes additional bandwidth\ - \ to avoid retransmission. We\nhave opted to use Reed-Solomon coding [27] as our\ - \ FEC\nmethod as it supports multiple loss recovery. Our protocol\nadjusts the\ - \ coding rate according to the observed loss on each\npath used.\nA. Protocol\ - \ Architecture\nSender \nReceiver \nSplitter\nEncoder\nReassembler\nReceive\n\ - Queue\nReceive\nMemory\nFragment \nSize\nCoding \nRate\nRequirements\nRetransmit\ - \ \nThreshold\nManager\nPath Selection\nOptimizer Path \nMetrics\nScheduler\n\ - Send Queue\nUnACK\nQueue\nPAN\nConfig\nCoding rate \nin pakcet header\nDecoder\n\ - Joiner\nPAN\nData streams IN\nData Streams OUT\nACK\nSignal\nData\nSCION Multipath\n\ - SCION\nFig. 2. Protocol Architecture\nFigure 2 shows the high-level architecture\ - \ of our protocol.\nThe two nodes communicating with each other will have a\n\ - sender and receiver component. In the figure, only one sender\nand receiver are\ - \ shown for simplicity. The sender takes in\nmultiple streams of data and sends\ - \ it to the receiver over\n" - - 'Book excerpt on Path Revocation - Challenges & Principles discussing challenges - with path revocation. Describes tradeoffs with revocation time granularity, the - importance of scalability to resist attacks, and critical security properties - like authenticity and replay protection. Defines principles like applications - independent for path failure, strictly better improvements using revocation. + we launch commands from. - Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles - to Formal Verification*. Springer International Publishing AG, 2022. + • scion showpaths : it lists available paths between the local - book + and the specified AS. By default, the list is set to display 10 - 141 + paths only, it can be extended using the-moption. Moreover, - + a really useful feature for this work, is the—extendedoption, - 5.7 Path Revocation + which provides additional information for each path (e.g. - 5.7.1 Challenges + MTU, Path Status, Latency info). - There are complex challenges and potential corner cases related to revocations, + • scion ping : it tests connectivity to a remote SCION host - which we will discuss in the following. + using SCMP echo packets[4]. When the —countoption is en- - Time Granularity. The duration for which paths are revoked is a crucial pa- + abled, the ping command sends a specific number of SCMP - rameter for the efficiency of the system with a fundamental trade-off: Increas- + echo packets and provides a report with corresponding statis- - ing the duration of revocations (or even permanently removing path segments + tics. Furthermore, the real innovation is the —interactive - from caches) reduces the number of revocations that need to be processed; + mode option, which displays all the available paths for the - however, this can also cause unnecessarily long nonuse of certain links in case + specified destination allowing the user to select the desired - of short-term or intermittent failures and cause other overhead as it requires + traffic route. - re-registering paths. + • scion traceroute : it traces the SCION path to a remote - Scalability. To ensure scalability and also to prevent denial-of-service + AS using SCMP traceroute packets. It is particularly useful - (DoS) attacks by malicious entities in the network infrastructure, it is critical + to test how the latency is affected by each link. Even this - to achieve low computational, storage, and bandwidth overhead. Thus, a + command makes interactive mode available. - revocation must not require involved network elements to keep an excessive + • scion-bwtestclient: it is the only application presented - amount of state or to generate a large number of additional messages within + in this work that is not installed by default in the VM. - the network. Additionally, a revocation must be efficiently verifiable to prevent + Bwtestclientis part of a bigger bandwidth testing applica- - overwhelming verifiers through many (possibly forged) revocations. Finally, + tion named bwtesterwhich allows a variety of bandwidth - revocations should be short, to minimize communication overhead. + tests on the SCION network. The application enables speci- - Security. Path revocation directly affects the paths used by end hosts. There- + fication of the test duration (up to 10 seconds), the packet - fore, the system needs to prevent unauthorized or malicious parties from revok- + size to be used (at least 4 bytes), the total number of packets - ing path segments. The system must thus ensure that revocations are authentic, + that will be sent, and the target bandwidth. For example, - i.e., only the operator of an interface should be able to revoke that interface. + 5,100,?,150Mbps specifies that the packet size is 100 bytes, - It must also be impossible to replay a recorded revocation with the effect of + sent over 5 seconds, resulting in a bandwidth of 150Mbps. - removing a valid path segment (resistance against replay attacks). + The question mark ? character can be used as wildcard for - 5.7.2 Principles + any of these parameters, in this case the number of packets - As any revocation system is necessarily imperfect and (short) delays are un- + sent. Its value is then computed according to the other pa- - avoidable, SCION is designed such that it remains functional even in the face + rameters. The parameters for the test in the client-to-server - of failures without a dedicated revocation system. Even with a revocation sys- + direction are specified with -cs, and the server-to-client - tem in place, applications should not rely on the system and should continue to + direction with -sc. - function without it. Specifically, applications should have state machines that + We will analyze further these scion commands and how we used - switch from a broken path even if no revocation was received on that path (e.g., + them in the next section. - by relying on transport-layer acknowledgments). + 4 SOFTWARE DESIGN - Most fundamentally, a SCION network with revocations should work + We now present our software to test SCION features of path aware- - strictly better than without the system. If a revocation feature does not bring + ness and path selection. We will also test network performances - a strict improvement (e.g., improves certain cases but deteriorates others), it + such as: latency, bandwidth and packet loss in order to provide - should not be implemented. + UPIN users with paths that fulfill requirements on these properties. - 121 + 787 ' - - 'Research paper (page 6) concluding S3MP''s contributions and outlining future - work. Reinforces SCION''s security benefits for smart metering. Notes native SCION - implementation''s superior performance. Future work includes SCION-Linux kernel - integration and optimization for resource-constrained devices. Lists multiple - references. + - 'Research paper (PERFORMANCE ''20) on "Incentivizing Stable Path Selection." Continues + the game-theoretic analysis. Defines the oscillation model, building upon the + Wardrop model, focusing on parallel-path systems, defining terms such key terms + oscillation-prone system, oscillation and stability. Introduces system parameters, + describes the temporal component, and defines formalizes definitions for oscillation + and stability at equilibrium. - Tony John et al.. "S3MP: A SCION based Secure Smart Metering Platform." - *2021 IFIP/IEEE International Symposium on Integrated Network Management (IM)*, - 2021. + Simon Scherrer et al.. "Incentivizing Stable Path Selection in Future + Internet Architectures." *Proceedings of the International Symposium on Computer + Performance, Modeling, Measurements and Evaluation (PERFORMANCE)*, 2020. research paper - 6 + 2 - 0% + IFIP Performance, November 2–6, 2020, Milano, Italy Simon Scherrer, Markus Legner, + Adrian Perrig, and Stefan Schmid + + an inter-domain context cannot be achieved by relying only on end- + + point path selection. Instead, network operators have to incentivize + + end-hosts to adopt one of the well-known convergent path-selection + + strategies with stabilization mechanisms . These mechanisms have + + to be incentive-compatible, i.e., the mechanisms must create an in- + + centive structure such that it is in an end-host’s self-interest to + + adopt a non-oscillatory path-selection strategy. In this work, we + + present two such stabilization mechanisms, FLOSS and CROSS, and + + formally prove their incentive compatibility. These mechanisms + + employ different techniques to disincentivize oscillatory switching + + between paths, namely limiting the migration rate between paths + + (FLOSS) and imposing a cost on switching between paths (CROSS). + + To complement our mainly theoretical work, we also discuss how + + our findings could be practically applied. + + 1.1 Contribution + + This paper revisits the theoretical study of the dynamic effects of + + end-point path selection, for the first time focusing the analysis + + on inter-domain networks where the end-points are selfish and + + uncontrolled. We present a game-theoretic model that allows us + + to investigate which path-selection strategies will be adopted by - 10% + selfish end-hosts. In particular, we introduce the notion of equi- - 20% + libria to path-selection strategies (PSS equilibria). Moreover, we - 30% + formally show that the non-oscillatory path-selection strategies - 40% + proposed in the existing literature do not form such PSS equilibria. - 50% + Thus, we provide evidence towards the hypothesis that stability in - 60% + load-adaptive routing over multiple domains cannot be achieved by - 70% + exclusively relying on end-hosts’ path-selection behavior. To rem- - 80% + edy this problem, we leverage insights from mechanism design to - 90% + devise two incentive-compatible stabilization mechanisms enforced - 100% + by network operators. While these mechanisms build on existing - 0.00 50.00 100.00 + insights from intra-domain traffic engineering, their methods of - Probability + incentivization represent a novel approach to achieve stability in - Reading Delay (milliseconds) + inter-domain networks with load-adaptive routing. We formally - SCION vs SIG + prove the incentive compatibility of both mechanisms and discuss - SIG Na ve SCIONti + their practical application. - Fig. 8. Reading delay: Native SCION vs SIG + 2 OSCILLATION MODEL - access control and hidden paths. Moreover, failure recovery + 2.1 Parallel-Path Systems - and high availability is achieved through multi-path commu- + In order to study oscillation in network architectures with end-host - nication. To use these properties, we have developed a SCION- + path selection, we build on the well-established Wardrop model [37], - based smart metering infrastructure as described in Section 3. + which is the standard model for studying the interactions of selfish - Our implementation includes a SCION jDLMS library which + agents in computer networks [28, 32, 33]. In the Wardrop model, + + an infinite number of end-hosts, each controlling an infinitesimal + + traffic share, select one path 𝜋 among multiple paths Π between + + two network nodes. Every path 𝜋 has a load-dependent cost, where + + the path-cost function 𝑐𝜋 is typically interpreted as latency. The + + end-hosts’ path-selection decisions form a congestion game, where + + the path-selection decisions of end-hosts both determine and follow + + the load 𝑓𝜋 on every path 𝜋 [5, 19, 30]. + + In this work, we analyze congestion games with a temporal com- + + ponent, i.e., end-hosts take path-selection decisions over time based + + on currently available information. More precisely, an end-host + + performs an average of 𝑟 > 0 re-evaluations per unit of time. The + + aggregate re-evaluation behavior is uniform over time, i.e., when + + dividing time into intervals of length 𝜖 ∈(0,1], 𝑟𝜖 re-evaluations + + are performed in any interval + + Whenever an end-host performs a re-evaluation, it chooses one + + path 𝜋to its destination according to a freely chosen path-selection + + strategy 𝜎. We thus formalize the environment of congestion games + + as parallel-path systems : + + Definition 1. A parallel-path system 𝑂 := (Π,𝑟,𝑝,𝑇,𝐴 0,𝑣) + + is a tuple, where a total demand normalized to 1 is distributed over + + parallel paths 𝜋 ∈Π among which end-hosts can select; 𝑟 > 0 is + + the average number of re-evaluations per end-host and unit of time; + + 𝑝 ≥ 1 is the steepness of the path cost as a function of the load + + (i.e., 𝑐𝜋 = (𝑓𝜋)𝑝); 𝑇 ≥0 is the average time that it takes for cost + + information to reach the agents; A0 ∈ [0,1]|Π| is the initial load + + matrix, where the entry A0𝜋 = 𝑓𝜋(0); and 𝑣 is the strategy profile, + + defining for every available path-selection strategy 𝜎 the share 𝑣(𝜎) + + of end-hosts that permanently apply strategy 𝜎. + + Every congestion game possesses at least one Wardrop equilib- + + rium, consisting of a traffic distribution where no single agent can + + reduce its cost by selecting an alternative path [30]. If the agents + + take path-selection decisions based on up-to-date cost information + + of paths (𝑇 = 0), convergence to Wardrop equilibria is guaranteed + + and persistent oscillations can thus not arise [12, 13, 34]. However, + + in practice, the cost information possessed by agents isstale (𝑇 > 0), + + i.e., the information describes an older state of the network. If such + + stale information is present, undesirable oscillations can arise [14]. + + Therefore, parallel-path systems can be oscillation-prone: + + Definition 2. A parallel-path system 𝑂 is oscillation-prone if + + and only if 𝑇 > 0. + + In this work, we study oscillation-prone systems with two paths + + 𝛼 and 𝛽 (i.e., |Π|= 2), but our insights directly generalize to more + + paths. Due to total demand normalization, it holds that 𝑓𝛽(𝑡)= + + 1 −𝑓𝛼(𝑡)for all 𝑡 ≥0. Thus, the unique Wardrop equilibrium in + + a two-path oscillation-prone system is given by 𝑓𝛼 = 𝑓𝛽 = 1/2. + + Moreover, we assume w.l.o.g. that the initial imbalance𝐴0 exists + + with the higher load on path 𝛼: 𝑓𝛼(0)= 𝐴0 = A0𝛼 > 1/2. For this + + system of two parallel paths, ˜𝜋 denotes the respective other path, + + i.e., ˜𝛼 = 𝛽 and ˜𝛽 = 𝛼. + + Having introduced the concept of oscillation-prone systems, we + + next define notions of oscillation and stability. First, an oscillation- + + prone system experiences oscillation if the traffic distribution does + + not eventually become static: + + Definition 3. An oscillation-prone system 𝑂experiences oscilla- + + tion if there exists no limit Δ∗of the function Δ(𝑡)= |𝑓𝛼(𝑡)− 𝑓𝛽(𝑡)| + + for 𝑡 →∞. + + Conversely, we understand stability simply as the absence of + + oscillation, i.e., stability is given if a limit Δ∗exists. However, to + + ensure optimal network utilization, the desirable state of the net- + + work is not only stability, but stability at equal load as given by the + + Wardrop equilibrium: + + Definition 4. An oscillation-prone system 𝑂 is stable at equal + + load if Δ∗:= lim𝑡→∞Δ(𝑡)= 0. + + 2 + + ' + - 'Research paper section providing a Z-lane system description. Introduces AS/ISD-level + bandwidth isolation and configurable rates using SCION''s ISDs. Explains how ASes + can overuse allocated bandwidth and send traffic at guaranteed rates. + + Marc Wyss et al.. "Zero-setup Intermediate-rate Communication Guarantees + in a Global Internet." *Proceedings of the USENIX Security Symposium*, 2024. + + research paper + + 5 + + - uses DRKey for authentication instead of fixed keys. + Z-Lane. The decision how to configure the rates is ultimately - 2. Implementation of a SCION based smart metering proto- + up to the network operator and, importantly, does not require - type: Section 4 describes the prototypical implementation of + any inter-domain coordination. Due to the aggregation of - the SCION smart metering infrastructure. The implementation + ASes into ISDs, configurations remain manageable even if - includes a DLMS application which is based on our SCION + the Internet grows to hundreds of thousands of ASes. - jDLMS library. The hardware of the prototype was realized + End Host Guarantees. Z-Lane lets end hosts, more specifi- - using off the shelf components and Raspberry Pi single-board + cally their applications, define what traffic should be sent with - computers. + forwarding guarantees, and what traffic should be forwarded - 3. Evaluation of different methods based on the implemented + over best-effort. Still, to protect against malicious end hosts, - prototype: We evaluated and compared two methods of using + their AS has the ultimate authority in this matter and can re- - SCION in a smart metering infrastructure: a) through SIG + classify traffic to be sent as best-effort only. This protection - and b) by using SCION natively. As discussed in Section 5, + is implemented through a Z-Lane gateway, which schedules - the native SCION implementation required more development + end host traffic and authenticates it towards on-path routers - effort, but it showed better performance in the evaluation. + using a secret key not known to the end hosts. How traffic is - A native SCION implementation is required to take full + scheduled is up to the AS operator; configurations can range - advantage of SCION’s security features. + from fair sharing to prioritizing certain traffic from critical AS - A. Future Work + services like routing or time synchronization. We emphasize - Currently, the SCION jDLMS library uses a Java binding + that, to avoid any setup overhead (R3), neither ISDs, nor ASes - to the SCION appnet package to enable Java to communicate + or end hosts explicitly learn their configured rate; instead, end - with SCION. In a very resource-constrained device, this can + hosts implicitly discover their allowed rate through existing - lead to crashes. Development efforts are ongoing to integrate + mechanisms like congestion control. - SCION into the Linux kernel. When completed, this will + Compatibility with Other Systems. Bandwidth reserva- - remove the aforementioned additional overhead. + tion systems cannot provide zero-setup communication guar- - The SCION smart metering prototype presented in this pa- + antees and are therefore not suitable to protect short-lived - per runs on a Raspberry Pi Zero. The Smart meters available in + intermediate-rate communication (Section 8). Still, we design - the market today have less powerful processors and resources. + Z-Lane to seamlessly coexist with them, as they complement - Additional development and testing efforts are required to + our work by effectively protecting non-setup-critical, high- - optimize the library to run on these resource-constrained + volume communication such as from video conferencing. We - devices. + choose COLIBRI [27] as a reservation system instantiation, - ACKNOWLEDGMENT + but other systems could be deployed as well. To prevent at- - We would like to extend our sincere gratitude and apprecia- + tacks targeting DRKey’s AS-level key exchange, which is a - tion for all the help provided by our colleagues in the SCION + fundamental requirement for EPIC, our design also ensures - IoT team. + compatibility with the DoCile system [74], which leverages - REFERENCES + dedicated channels between neighboring ASes to successfully - [1] “IoT Market Size Will More Than Double — Bain & Company.” + bootstrap the key exchange even under DDoS. - https://www.bain.com/about/media-center/press-releases/2018/bain- + We therefore consider the following four types of inter- - predicts-the-iot-market-will-more-than-double-by-2021/ (accessed Jan. + domain traffic: COLIBRI reservation traffic, DoCile’s - 20, 2021). + neighbor-based communication, authenticated traffic from - [2] Wang, Yi, et al. ”Review of smart meter data analytics: Applications, + EPIC, and unauthenticated SCION traffic. - methodologies, and challenges.” IEEE Transactions on Smart Grid 10.3 + 4.2 Source Authentication - (2018): 3125-3148. + Z-Lane employs EPIC for authenticating traffic sources to - [3] Beckel, Christian, et al. ”Revealing household characteristics from smart + border routers, allowing every border router to verify the au- - meter data.” Energy 78 (2014): 397-410. + thenticity of every received packet. An important insight in the - [4] Molina-Markham, Andr ´es, et al. ”Private memoirs of a smart meter.” + design of Z-Lane is that efficient and reliable source authen- - Proceedings of the 2nd ACM workshop on embedded sensing systems + tication as provided by EPIC allows for meaningful source- - for energy-efficiency in building. 2010. + based traffic control at border routers. The realization of this - [5] “Trump Declares National Emergency As For- + idea has not been possible so far because previous source - eign Hackers Threaten U.S. Power Grid.” + authentication mechanisms would cause excessive commu- - https://www.forbes.com/sites/daveywinder/2020/05/02/trump-declares- + nication or computation overhead and therefore impede de- - national-emergency-as-foreign-hackers-threaten-us-power-grid/ + ployment, or were based on heuristics or probabilities, and - (accessed Dec. 07, 2020). + would thus fail to reliably distinguish between authentic and - [6] Goldberg, Sharon, et al. ”How secure are secure interdomain routing + spoofed addresses (Appendix H). Z-Lane is the first system - protocols.” ACM SIGCOMM Computer Communication Review 40.4 + to explore the use of comprehensive source authentication to - (2010): 87-98. + protect the availability of short-lived intermediate-rate Inter- - [7] Zhang, Xin, et al. ”SCION: Scalability, control, and isolation on next- + net traffic – with EPIC’s security rooted in AS-level secret - generation networks.” 2011 IEEE Symposium on Security and Privacy. + keys, it integrates seamlessly into Z-Lane. - IEEE, 2011. + We want to highlight that EPIC together with a fairness - [8] Kumar, Pardeep, et al. ”Smart grid metering networks: A survey on + mechanism provided by some congestion control algorithm, - security, privacy and open research issues.” IEEE Communications + i.e., without any guaranteed rates, would not be enough in - Surveys Tutorials 21.3 (2019): 2886-2927. + our threat model, as an attacker would just not respect the - [9] “Smart electricity meters can be dangerously insecure, + algorithm’s feedback and instead keep sending traffic at high - warns expert — Smart homes — The Guardian.” + rates, or leverage a botnet to create many low-volume flows. - https://www.theguardian.com/technology/2016/dec/29/smart-electricity- + 4.3 End Host Traffic Generation - meters-dangerously-insecure-hackers (accessed Jan. 01, 2021). + End hosts, i.e., their applications, can choose among several - [10] “The Dark Side of the Smart Grid.” https://www.powermag.com/the- + mechanisms on how their traffic is forwarded (Figure 1). For - dark-side-of-the-smart-grid/ (accessed Jan. 01, 2021). + long-term traffic they request a bandwidth reservation and - [11] “Specification — dlms.” https://www.dlms.com/dlms-cosem (accessed + use it by sending their COLIBRI traffic class packets through - Jan. 01, 2021). + the COLIBRI gateway. While the overhead for requesting - [12] “Security in DLMS A White Paper by the DLMS User Association,” + a reservation is significant, the result is a fixed amount of - 2019. + bandwidth that is exclusively reserved along the communi- - [13] “jDLMS Overview – DLMS/COSEM – OpenMUC.” + cation path. In a similar way, applications send short-lived - https://www.openmuc.org/dlms-cosem/ (accessed Jan. 01, 2021). + intermediate-rate traffic using the EPIC traffic class over the - [14] Perrig, Adrian, et al. SCION: a secure Internet architecture. Springer, + Z-Lane gateway, where traffic is forwarded immediately with- - 2017. + out any delay (requirement R3), but without the applications - [15] “Dynamically Recreatable Key (DRKey) In- + knowing the concrete rates. In both cases traffic is protected - frastructure — SCION documentation.” + against congestion on the communication path. The default - https://scion.docs.anapaya.net/en/latest/cryptography/DRKeyInfra.html + option is for end hosts to send their traffic using the EPIC - (accessed Jan. 01, 2021). + traffic class directly to a border router of their AS, where they - [16] Kwon, Jonghoon, et al. “SCIONLab: A next-generation internet testbed.” + are forwarded along the path using best-effort. This option - IEEE ICNP. 2020. + is useful for non-latency-critical communication such as file - [17] “14,000 Incidents: A 2017 Routing Security Year in Review — Internet + downloads, or for long-term traffic for which no reservation - Society.” https://www.internetsociety.org/blog/2018/01/14000-incidents- + is available, which can for example happen if the end host has - 2017-routing-security-year-review/ (accessed Jan. 01, 2021). + already created a large number of reservations and gets denied - [18] Cloudflare, “What Is BGP? BGP Routing Explained — Cloud- + from creating even more. Z-Lane envisages unauthenticated - flare,” 2017. https://www.cloudflare.com/learning/security/glossary/bgp- + SCION traffic to be sent only in scenarios where it is not - hijacking/ (accessed Jan. 01, 2021). + otherwise possible, e.g., if an AS needs to request shared keys - [19] “What Is a Distributed Denial-of-Service (DDoS) Attack? — Cloud- + using DRKey from another AS for the first time. - flare.” https://www.cloudflare.com/learning/ddos/what-is-a-ddos-attack/ + 4.4 Z-Lane Gateway - (accessed Jan. 01, 2021). + ASes use the gateway to control the traffic volumes that their - [20] Labovitz, Craig, et al. ”Delayed Internet routing convergence.” ACM + end hosts (incl. AS infrastructure services) are allowed to send - SIGCOMM Computer Communication Review 30.4 (2000): 175-187. + using Z-Lane, which serves the primary purpose of protecting - [21] “GitHub - scionproto/scion: This repository represents the main SCION + benign from malicious or compromised end hosts. - version.” https://github.com/scionproto/scion (accessed Jan. 01, 2021). + For end host traffic complying with the allowed rate, the - [22] “GitHub - sridharv/gojava: GoJava - Java bindings for Go packages.” + gateway sets a QoS flag in the EPIC header, which indicates - https://github.com/sridharv/gojava (accessed Jan. 01, 2021). + to on-path routers that the corresponding packets should be - [23] Shuaib, Khaled, et al. ”Resiliency of Smart Power Meters to Common + forwarded using the AS’ guaranteed rate. If an end host’s - Security Attacks.” ANT/SEIT. 2015. + packet exceeds the allowed rate at the gateway, then either (i) - [24] “OR-WE-514 Single-phase meter 100A with port RS-485.” Accessed: + the QoS flag is not set (or removed, if it was already set by the - Jan. 01, 2021. [Online]. Available: www.orno.pl + end host), meaning that those packets will be treated as best- - [25] “Configuration - SCIONLab Tutorials.” + effort, or (ii) the packets are dropped, depending on the AS’ - https://docs.scionlab.org/content/config/ (accessed Jan. 01, 2021). + policy. In contrast to best-effort EPIC packets generated at - [26] ”S3MP Demo Video.” https://youtu.be/YvT-otHCpA8 + 5 ' pipeline_tag: sentence-similarity @@ -1884,49 +2099,49 @@ model-index: type: val-ir-eval metrics: - type: cosine_accuracy@1 - value: 0.7389162561576355 + value: 0.7254901960784313 name: Cosine Accuracy@1 - type: cosine_accuracy@3 - value: 0.9113300492610837 + value: 0.9019607843137255 name: Cosine Accuracy@3 - type: cosine_accuracy@5 - value: 0.9261083743842364 + value: 0.9313725490196079 name: Cosine Accuracy@5 - type: cosine_accuracy@10 - value: 0.9556650246305419 + value: 0.9607843137254902 name: Cosine Accuracy@10 - type: cosine_precision@1 - value: 0.7389162561576355 + value: 0.7254901960784313 name: Cosine Precision@1 - type: cosine_precision@3 - value: 0.30377668308702793 + value: 0.3006535947712418 name: Cosine Precision@3 - type: cosine_precision@5 - value: 0.18522167487684726 + value: 0.18627450980392155 name: Cosine Precision@5 - type: cosine_precision@10 - value: 0.09556650246305418 + value: 0.09607843137254901 name: Cosine Precision@10 - type: cosine_recall@1 - value: 0.7389162561576355 + value: 0.7254901960784313 name: Cosine Recall@1 - type: cosine_recall@3 - value: 0.9113300492610837 + value: 0.9019607843137255 name: Cosine Recall@3 - type: cosine_recall@5 - value: 0.9261083743842364 + value: 0.9313725490196079 name: Cosine Recall@5 - type: cosine_recall@10 - value: 0.9556650246305419 + value: 0.9607843137254902 name: Cosine Recall@10 - type: cosine_ndcg@10 - value: 0.85826952408338 + value: 0.8542256235274797 name: Cosine Ndcg@10 - type: cosine_mrr@10 - value: 0.8259715380405037 + value: 0.8187908496732025 name: Cosine Mrr@10 - type: cosine_map@100 - value: 0.8286137115728134 + value: 0.8212133545466878 name: Cosine Map@100 --- @@ -1980,9 +2195,9 @@ from sentence_transformers import SentenceTransformer model = SentenceTransformer("tjohn327/scion-snowflake-arctic-embed-s-v2") # Run inference sentences = [ - 'In the evaluation, which method (native SCION or SIG) showed better performance in terms of CPU and memory utilization', - 'Research paper (page 6) concluding S3MP\'s contributions and outlining future work. Reinforces SCION\'s security benefits for smart metering. Notes native SCION implementation\'s superior performance. Future work includes SCION-Linux kernel integration and optimization for resource-constrained devices. Lists multiple references.\n Tony John et al.. "S3MP: A SCION based Secure Smart Metering Platform." *2021 IFIP/IEEE International Symposium on Integrated Network Management (IM)*, 2021. \n research paper \n 6 \n\n0%\n10%\n20%\n30%\n40%\n50%\n60%\n70%\n80%\n90%\n100%\n0.00 50.00 100.00\nProbability\nReading Delay (milliseconds)\nSCION vs SIG\nSIG Na ve SCIONti\nFig. 8. Reading delay: Native SCION vs SIG\naccess control and hidden paths. Moreover, failure recovery\nand high availability is achieved through multi-path commu-\nnication. To use these properties, we have developed a SCION-\nbased smart metering infrastructure as described in Section 3.\nOur implementation includes a SCION jDLMS library which\nuses DRKey for authentication instead of fixed keys.\n2. Implementation of a SCION based smart metering proto-\ntype: Section 4 describes the prototypical implementation of\nthe SCION smart metering infrastructure. The implementation\nincludes a DLMS application which is based on our SCION\njDLMS library. The hardware of the prototype was realized\nusing off the shelf components and Raspberry Pi single-board\ncomputers.\n3. Evaluation of different methods based on the implemented\nprototype: We evaluated and compared two methods of using\nSCION in a smart metering infrastructure: a) through SIG\nand b) by using SCION natively. As discussed in Section 5,\nthe native SCION implementation required more development\neffort, but it showed better performance in the evaluation.\nA native SCION implementation is required to take full\nadvantage of SCION’s security features.\nA. Future Work\nCurrently, the SCION jDLMS library uses a Java binding\nto the SCION appnet package to enable Java to communicate\nwith SCION. In a very resource-constrained device, this can\nlead to crashes. Development efforts are ongoing to integrate\nSCION into the Linux kernel. When completed, this will\nremove the aforementioned additional overhead.\nThe SCION smart metering prototype presented in this pa-\nper runs on a Raspberry Pi Zero. The Smart meters available in\nthe market today have less powerful processors and resources.\nAdditional development and testing efforts are required to\noptimize the library to run on these resource-constrained\ndevices.\nACKNOWLEDGMENT\nWe would like to extend our sincere gratitude and apprecia-\ntion for all the help provided by our colleagues in the SCION\nIoT team.\nREFERENCES\n[1] “IoT Market Size Will More Than Double — Bain & Company.”\nhttps://www.bain.com/about/media-center/press-releases/2018/bain-\npredicts-the-iot-market-will-more-than-double-by-2021/ (accessed Jan.\n20, 2021).\n[2] Wang, Yi, et al. ”Review of smart meter data analytics: Applications,\nmethodologies, and challenges.” IEEE Transactions on Smart Grid 10.3\n(2018): 3125-3148.\n[3] Beckel, Christian, et al. ”Revealing household characteristics from smart\nmeter data.” Energy 78 (2014): 397-410.\n[4] Molina-Markham, Andr ´es, et al. ”Private memoirs of a smart meter.”\nProceedings of the 2nd ACM workshop on embedded sensing systems\nfor energy-efficiency in building. 2010.\n[5] “Trump Declares National Emergency As For-\neign Hackers Threaten U.S. Power Grid.”\nhttps://www.forbes.com/sites/daveywinder/2020/05/02/trump-declares-\nnational-emergency-as-foreign-hackers-threaten-us-power-grid/\n(accessed Dec. 07, 2020).\n[6] Goldberg, Sharon, et al. ”How secure are secure interdomain routing\nprotocols.” ACM SIGCOMM Computer Communication Review 40.4\n(2010): 87-98.\n[7] Zhang, Xin, et al. ”SCION: Scalability, control, and isolation on next-\ngeneration networks.” 2011 IEEE Symposium on Security and Privacy.\nIEEE, 2011.\n[8] Kumar, Pardeep, et al. ”Smart grid metering networks: A survey on\nsecurity, privacy and open research issues.” IEEE Communications\nSurveys Tutorials 21.3 (2019): 2886-2927.\n[9] “Smart electricity meters can be dangerously insecure,\nwarns expert — Smart homes — The Guardian.”\nhttps://www.theguardian.com/technology/2016/dec/29/smart-electricity-\nmeters-dangerously-insecure-hackers (accessed Jan. 01, 2021).\n[10] “The Dark Side of the Smart Grid.” https://www.powermag.com/the-\ndark-side-of-the-smart-grid/ (accessed Jan. 01, 2021).\n[11] “Specification — dlms.” https://www.dlms.com/dlms-cosem (accessed\nJan. 01, 2021).\n[12] “Security in DLMS A White Paper by the DLMS User Association,”\n2019.\n[13] “jDLMS Overview – DLMS/COSEM – OpenMUC.”\nhttps://www.openmuc.org/dlms-cosem/ (accessed Jan. 01, 2021).\n[14] Perrig, Adrian, et al. SCION: a secure Internet architecture. Springer,\n2017.\n[15] “Dynamically Recreatable Key (DRKey) In-\nfrastructure — SCION documentation.”\nhttps://scion.docs.anapaya.net/en/latest/cryptography/DRKeyInfra.html\n(accessed Jan. 01, 2021).\n[16] Kwon, Jonghoon, et al. “SCIONLab: A next-generation internet testbed.”\nIEEE ICNP. 2020.\n[17] “14,000 Incidents: A 2017 Routing Security Year in Review — Internet\nSociety.” https://www.internetsociety.org/blog/2018/01/14000-incidents-\n2017-routing-security-year-review/ (accessed Jan. 01, 2021).\n[18] Cloudflare, “What Is BGP? BGP Routing Explained — Cloud-\nflare,” 2017. https://www.cloudflare.com/learning/security/glossary/bgp-\nhijacking/ (accessed Jan. 01, 2021).\n[19] “What Is a Distributed Denial-of-Service (DDoS) Attack? — Cloud-\nflare.” https://www.cloudflare.com/learning/ddos/what-is-a-ddos-attack/\n(accessed Jan. 01, 2021).\n[20] Labovitz, Craig, et al. ”Delayed Internet routing convergence.” ACM\nSIGCOMM Computer Communication Review 30.4 (2000): 175-187.\n[21] “GitHub - scionproto/scion: This repository represents the main SCION\nversion.” https://github.com/scionproto/scion (accessed Jan. 01, 2021).\n[22] “GitHub - sridharv/gojava: GoJava - Java bindings for Go packages.”\nhttps://github.com/sridharv/gojava (accessed Jan. 01, 2021).\n[23] Shuaib, Khaled, et al. ”Resiliency of Smart Power Meters to Common\nSecurity Attacks.” ANT/SEIT. 2015.\n[24] “OR-WE-514 Single-phase meter 100A with port RS-485.” Accessed:\nJan. 01, 2021. [Online]. Available: www.orno.pl\n[25] “Configuration - SCIONLab Tutorials.”\nhttps://docs.scionlab.org/content/config/ (accessed Jan. 01, 2021).\n[26] ”S3MP Demo Video.” https://youtu.be/YvT-otHCpA8\n', - 'Research paper "DMTP: Deadline-aware Multipath Transport Protocol" covering SCION network visualization, the goals of DMTP, and an overview of its technologies. Describes DMTP as a user-space protocol utilizing SCION-UDP, incorporating optimal path combination selection using linear programming (or heuristics, or PANAPI) and heuristics, smart packet retransmission, and adaptive FEC (Reed-Solomon coding). Presents DMTP\'s high-level architecture, including the Sender and Receiver components with modules like Splitter, Encoder, Reassembler, Scheduler, Send/Receive/UnACK Queues and Path Selection Optimizer. Explains the interaction and functions between the modules.\n Tony John et al.. "DMTP: Deadline-aware Multipath Transport Protocol." *Proceedings of IFIP Networking*, 2023. \n research paper \n 4 \n\nD\nZ1\n Z2\nZ3\nC\nF\nH\nJ\nG\nI\nISD\nCore\nISD\nCore\nISD\nCore\nISD\nCore\nISD 1 ISD 3 ISD 4\nISD 2\nAS\nCore link\nPeering link\nParent - Child link-\nFig. 1. SCION network with four ISDs showing two of the possible end-to-\nend paths between ASes C and G\nresearch and running experiments on a SCION network,\nSCIONLab provides a global SCION testbed where users can\ncreate personal ASes [25].\nV. D EADLINE -AWARE MULTIPATH TRANSPORT PROTOCOL\nThe goal of our Deadline-Aware Multipath Protocol is\nto deliver data from one host to another within a speci-\nfied deadline with minimum overhead and minimum cost.\nThroughout the rest of the paper, the term protocol refers to the\nDeadline-Aware Multipath Transport Protocol. Our protocol\nruns in the user space and uses the path-aware networking\nof SCION Internet Architecture for communication. As UDP\nis the defacto transmission protocol upon which most real-\ntime and latency-sensitive protocols are built, we are using the\nSCION version of UDP, SCION-UDP as our base transmission\nprotocol.\nTo fulfill the deadline and reliability requirements, we in-\ncorporate the following technologies into a transport protocol:\n• Optimal path combination selection\n• Smart packet retransmission\n• Adaptive FEC\nChuat et al. [18] describe the optimal path selection for\ndeadline-sensitive data as an optimization problem. They have\nproposed to use linear programming (LP) to select the optimal\npaths and the proportion of bandwidth to assign to each path\nwhile maximizing communication quality or minimizing cost.\nWe are adopting this strategy in our protocol. The heuristics-\nbased approach requires less computation compared to solv-\ning the LP problem, making it more suitable for scenarios\nwith limited computational resources or in highly dynamic\nnetworks where path selection needs to be run at a higher\nfrequency. However, the heuristics-based approach might not\nalways find the optimal solution, as it relies on approximations,\nwhile the LP-based approach guarantees optimality under\ncertain conditions. Thus, depending on the specific network\nrequirements and constraints, either the heuristic algorithm\nalone may be sufficient, or a combination of LP and heuristics\nmay be needed for optimal path selection. Alternatively, the\nPath-Aware Networking Application Programming Interface\n(PANAPI) [26] may also be used for optimal path selection.\nSmart packet retransmission ensures that retransmission\nhappens only if the retransmitted packet can reach the re-\nceiver within the required deadline and retransmission happens\nthrough one of the fastest paths available.\nFEC works by generating and sending redundancy packets\nalong with data packets to recreate packets lost in transmission.\nIt utilizes additional bandwidth to avoid retransmission. We\nhave opted to use Reed-Solomon coding [27] as our FEC\nmethod as it supports multiple loss recovery. Our protocol\nadjusts the coding rate according to the observed loss on each\npath used.\nA. Protocol Architecture\nSender \nReceiver \nSplitter\nEncoder\nReassembler\nReceive\nQueue\nReceive\nMemory\nFragment \nSize\nCoding \nRate\nRequirements\nRetransmit \nThreshold\nManager\nPath Selection\nOptimizer Path \nMetrics\nScheduler\nSend Queue\nUnACK\nQueue\nPAN\nConfig\nCoding rate \nin pakcet header\nDecoder\nJoiner\nPAN\nData streams IN\nData Streams OUT\nACK\nSignal\nData\nSCION Multipath\nSCION\nFig. 2. Protocol Architecture\nFigure 2 shows the high-level architecture of our protocol.\nThe two nodes communicating with each other will have a\nsender and receiver component. In the figure, only one sender\nand receiver are shown for simplicity. The sender takes in\nmultiple streams of data and sends it to the receiver over\n', + 'How is the concept of configurable rates in Z-Lane intended to accommodate varying traffic demands', + 'Research paper section providing a Z-lane system description. Introduces AS/ISD-level bandwidth isolation and configurable rates using SCION\'s ISDs. Explains how ASes can overuse allocated bandwidth and send traffic at guaranteed rates.\n Marc Wyss et al.. "Zero-setup Intermediate-rate Communication Guarantees in a Global Internet." *Proceedings of the USENIX Security Symposium*, 2024. \n research paper \n 5 \n\nZ-Lane. The decision how to configure the rates is ultimately\nup to the network operator and, importantly, does not require\nany inter-domain coordination. Due to the aggregation of\nASes into ISDs, configurations remain manageable even if\nthe Internet grows to hundreds of thousands of ASes.\nEnd Host Guarantees. Z-Lane lets end hosts, more specifi-\ncally their applications, define what traffic should be sent with\nforwarding guarantees, and what traffic should be forwarded\nover best-effort. Still, to protect against malicious end hosts,\ntheir AS has the ultimate authority in this matter and can re-\nclassify traffic to be sent as best-effort only. This protection\nis implemented through a Z-Lane gateway, which schedules\nend host traffic and authenticates it towards on-path routers\nusing a secret key not known to the end hosts. How traffic is\nscheduled is up to the AS operator; configurations can range\nfrom fair sharing to prioritizing certain traffic from critical AS\nservices like routing or time synchronization. We emphasize\nthat, to avoid any setup overhead (R3), neither ISDs, nor ASes\nor end hosts explicitly learn their configured rate; instead, end\nhosts implicitly discover their allowed rate through existing\nmechanisms like congestion control.\nCompatibility with Other Systems. Bandwidth reserva-\ntion systems cannot provide zero-setup communication guar-\nantees and are therefore not suitable to protect short-lived\nintermediate-rate communication (Section 8). Still, we design\nZ-Lane to seamlessly coexist with them, as they complement\nour work by effectively protecting non-setup-critical, high-\nvolume communication such as from video conferencing. We\nchoose COLIBRI [27] as a reservation system instantiation,\nbut other systems could be deployed as well. To prevent at-\ntacks targeting DRKey’s AS-level key exchange, which is a\nfundamental requirement for EPIC, our design also ensures\ncompatibility with the DoCile system [74], which leverages\ndedicated channels between neighboring ASes to successfully\nbootstrap the key exchange even under DDoS.\nWe therefore consider the following four types of inter-\ndomain traffic: COLIBRI reservation traffic, DoCile’s\nneighbor-based communication, authenticated traffic from\nEPIC, and unauthenticated SCION traffic.\n4.2 Source Authentication\nZ-Lane employs EPIC for authenticating traffic sources to\nborder routers, allowing every border router to verify the au-\nthenticity of every received packet. An important insight in the\ndesign of Z-Lane is that efficient and reliable source authen-\ntication as provided by EPIC allows for meaningful source-\nbased traffic control at border routers. The realization of this\nidea has not been possible so far because previous source\nauthentication mechanisms would cause excessive commu-\nnication or computation overhead and therefore impede de-\nployment, or were based on heuristics or probabilities, and\nwould thus fail to reliably distinguish between authentic and\nspoofed addresses (Appendix H). Z-Lane is the first system\nto explore the use of comprehensive source authentication to\nprotect the availability of short-lived intermediate-rate Inter-\nnet traffic – with EPIC’s security rooted in AS-level secret\nkeys, it integrates seamlessly into Z-Lane.\nWe want to highlight that EPIC together with a fairness\nmechanism provided by some congestion control algorithm,\ni.e., without any guaranteed rates, would not be enough in\nour threat model, as an attacker would just not respect the\nalgorithm’s feedback and instead keep sending traffic at high\nrates, or leverage a botnet to create many low-volume flows.\n4.3 End Host Traffic Generation\nEnd hosts, i.e., their applications, can choose among several\nmechanisms on how their traffic is forwarded (Figure 1). For\nlong-term traffic they request a bandwidth reservation and\nuse it by sending their COLIBRI traffic class packets through\nthe COLIBRI gateway. While the overhead for requesting\na reservation is significant, the result is a fixed amount of\nbandwidth that is exclusively reserved along the communi-\ncation path. In a similar way, applications send short-lived\nintermediate-rate traffic using the EPIC traffic class over the\nZ-Lane gateway, where traffic is forwarded immediately with-\nout any delay (requirement R3), but without the applications\nknowing the concrete rates. In both cases traffic is protected\nagainst congestion on the communication path. The default\noption is for end hosts to send their traffic using the EPIC\ntraffic class directly to a border router of their AS, where they\nare forwarded along the path using best-effort. This option\nis useful for non-latency-critical communication such as file\ndownloads, or for long-term traffic for which no reservation\nis available, which can for example happen if the end host has\nalready created a large number of reservations and gets denied\nfrom creating even more. Z-Lane envisages unauthenticated\nSCION traffic to be sent only in scenarios where it is not\notherwise possible, e.g., if an AS needs to request shared keys\nusing DRKey from another AS for the first time.\n4.4 Z-Lane Gateway\nASes use the gateway to control the traffic volumes that their\nend hosts (incl. AS infrastructure services) are allowed to send\nusing Z-Lane, which serves the primary purpose of protecting\nbenign from malicious or compromised end hosts.\nFor end host traffic complying with the allowed rate, the\ngateway sets a QoS flag in the EPIC header, which indicates\nto on-path routers that the corresponding packets should be\nforwarded using the AS’ guaranteed rate. If an end host’s\npacket exceeds the allowed rate at the gateway, then either (i)\nthe QoS flag is not set (or removed, if it was already set by the\nend host), meaning that those packets will be treated as best-\neffort, or (ii) the packets are dropped, depending on the AS’\npolicy. In contrast to best-effort EPIC packets generated at\n5\n', + 'Research paper setup description section detailing the specific SCIONLab configuration, including AS creation, attachment to ETHZ-AP, and VM setup. Lists and describes SCION applications crucial the experiments: \'scion address\', \'scion showpaths\', \'scion ping\', \'scion traceroute\', and \'scion-bwtestclient\', including their options and parameters(like packet size, bandwidth target) for performance evaluation on the network.\n Antonio Battipaglia et al.. "Evaluation of SCION for User-driven Path Control: a Usability Study." *Proceedings of the SC \'23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis*, 2023. \n research paper \n 3 \n\nEvaluation of SCION for User-driven Path Control: a Usability Study SC-W 2023, November 12–17, 2023, Denver, CO, USA\nFigure 1: SCIONLab Topology: in light orange there are Core ASes; Non-Core ASes are white colored; Attachment Points are\ngreen; our AS is blue.\nhelp us run specific experiments we will discuss in later sections.\nOnce this configuration phase was completed, SCIONLab web inter-\nface provided a unique ASN for our AS, along with cryptographic\nkeys and public-key certificates. Subsequently, a Vagrant file for\nour AS was generated to instruct the configuration of a Virtual\nMachine (VM) that represents our AS. This file made the setup\nprocess lightweight by automating the installation of SCIONLAB\nservices, relevant packages, and necessary configurations. Finally\nwe were ready to use a fully configured VM belonging to the global\nSCIONLab topology.\n3.3 Available Applications\nThe VM configuration process also installs a predefined set of\nSCION applications. The SCION apps that we used in our experi-\nments are:\n• scion address : this command returns the relevant SCION\naddress information for the local host, that is, our AS where\nwe launch commands from.\n• scion showpaths : it lists available paths between the local\nand the specified AS. By default, the list is set to display 10\npaths only, it can be extended using the-moption. Moreover,\na really useful feature for this work, is the—extendedoption,\nwhich provides additional information for each path (e.g.\nMTU, Path Status, Latency info).\n• scion ping : it tests connectivity to a remote SCION host\nusing SCMP echo packets[4]. When the —countoption is en-\nabled, the ping command sends a specific number of SCMP\necho packets and provides a report with corresponding statis-\ntics. Furthermore, the real innovation is the —interactive\nmode option, which displays all the available paths for the\nspecified destination allowing the user to select the desired\ntraffic route.\n• scion traceroute : it traces the SCION path to a remote\nAS using SCMP traceroute packets. It is particularly useful\nto test how the latency is affected by each link. Even this\ncommand makes interactive mode available.\n• scion-bwtestclient: it is the only application presented\nin this work that is not installed by default in the VM.\nBwtestclientis part of a bigger bandwidth testing applica-\ntion named bwtesterwhich allows a variety of bandwidth\ntests on the SCION network. The application enables speci-\nfication of the test duration (up to 10 seconds), the packet\nsize to be used (at least 4 bytes), the total number of packets\nthat will be sent, and the target bandwidth. For example,\n5,100,?,150Mbps specifies that the packet size is 100 bytes,\nsent over 5 seconds, resulting in a bandwidth of 150Mbps.\nThe question mark ? character can be used as wildcard for\nany of these parameters, in this case the number of packets\nsent. Its value is then computed according to the other pa-\nrameters. The parameters for the test in the client-to-server\ndirection are specified with -cs, and the server-to-client\ndirection with -sc.\nWe will analyze further these scion commands and how we used\nthem in the next section.\n4 SOFTWARE DESIGN\nWe now present our software to test SCION features of path aware-\nness and path selection. We will also test network performances\nsuch as: latency, bandwidth and packet loss in order to provide\nUPIN users with paths that fulfill requirements on these properties.\n787\n', ] embeddings = model.encode(sentences) print(embeddings.shape) @@ -2029,21 +2244,21 @@ You can finetune this model on your own dataset. | Metric | Value | |:--------------------|:-----------| -| cosine_accuracy@1 | 0.7389 | -| cosine_accuracy@3 | 0.9113 | -| cosine_accuracy@5 | 0.9261 | -| cosine_accuracy@10 | 0.9557 | -| cosine_precision@1 | 0.7389 | -| cosine_precision@3 | 0.3038 | -| cosine_precision@5 | 0.1852 | -| cosine_precision@10 | 0.0956 | -| cosine_recall@1 | 0.7389 | -| cosine_recall@3 | 0.9113 | -| cosine_recall@5 | 0.9261 | -| cosine_recall@10 | 0.9557 | -| **cosine_ndcg@10** | **0.8583** | -| cosine_mrr@10 | 0.826 | -| cosine_map@100 | 0.8286 | +| cosine_accuracy@1 | 0.7255 | +| cosine_accuracy@3 | 0.902 | +| cosine_accuracy@5 | 0.9314 | +| cosine_accuracy@10 | 0.9608 | +| cosine_precision@1 | 0.7255 | +| cosine_precision@3 | 0.3007 | +| cosine_precision@5 | 0.1863 | +| cosine_precision@10 | 0.0961 | +| cosine_recall@1 | 0.7255 | +| cosine_recall@3 | 0.902 | +| cosine_recall@5 | 0.9314 | +| cosine_recall@10 | 0.9608 | +| **cosine_ndcg@10** | **0.8542** | +| cosine_mrr@10 | 0.8188 | +| cosine_map@100 | 0.8212 |