--- tags: - sentence-transformers - sentence-similarity - feature-extraction - generated_from_trainer - dataset_size:4321 - loss:MultipleNegativesRankingLoss base_model: Snowflake/snowflake-arctic-embed-s widget: - source_sentence: What are "Authoritative ASes" and their roles relate to TRC? sentences: - '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 2 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. The first attempt at a hardware implementation of SCION was made by Součková, targeting a NetFPGA SUME development board programmable in P4 [16]. The full 10 Gbit/s line rate of the devel- opment platform has been achieved in experiments. However, the SCION packet parser and cryptographic validation circuitry did not fit in the FPGA at the same time due to inefficient workarounds that had to be taken to handle SCION’s non-standard header layout. Nevertheless, the project led to improvements to SCION’s header layout making it more suitable for high-speed processing. A first implementation of SCION for Tofino 1 was presented by de Ruiter et al. [7] being capable of processing packets at 100 Gbit/s line rate. However, as Tofino does not support cryptographic opera- tions in hardware, the AES-CMAC hop field validation in de Ruiter’s approach relies on a pre-populated table of valid hop fields. This simplification works as current SCION deployments change valida- tion keys infrequently. An unfortunate consequence of this design is that the SCION router is no longer stateless and instead has to communicate with the path discovery and registration services of the AS to obtain valid hop fields. Furthermore, the lookup-table solution also prevents the deployment of the SCION extensions EPIC [ 11] and Colibri [ 9] which rely on MACs that do not just change per-path, but per-packet. Nevertheless, the P4 code pub- lished by de Ruiter et al. inspired our work and is incorporated in our implementation. Chen has shown that it is possible to implement an AES encryp- tion in a Tofino 1 switch using so called scrambled lookup tables [4]. Their implementation was limited to an encryption throughput of 10.92 Gbit/s due to limited recirculation capacity. Our work addresses the issues encountered by Součková and de Ruiter et al. We implement the SCION packet parsing and validation logic separately in different pipelines of a Tofino 2 switch in order 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 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 229 9.2 High-Speed Traffic Filtering with LightningFilter 9.2.1.2 Design Goals LightningFilter is designed to achieve the following objectives: • Guaranteed access for legitimate users within traffic profile: The system must ensure that a client in a non-compromised domain (i.e., a domain without an adversary) has a guarantee to reach a target domain even in the presence of adversaries in other domains. We define a traffic profile as a sequence of measurements over a specific period of time (profiling window) on a per-flow basis (flow count). As long as the traffic of a flow is within such a traffic profile, its packets are guaranteed to be processed.4 • Enabling traditional firewalls to filter packets using metadata: The system should enable traditional firewalls to employ meaningful rule- based packet filtering using packet metadata (such as the 5-tuple in the packet header). Without LightningFilter, these filtering rules can be cir- cumvented by spoofing attacks due to the lack of authentication. • Elimination of collateral damage across domains: The system should guarantee that compromised domains cannot introduce collateral dam- age on non-compromised domains by consuming all available resources. Legitimate clients within a compromised domain, however, may be af- fected by an adversary consuming excessive resources at a target domain. This provides an incentive for domain owners to eliminate attack traffic sent by their end hosts. • Non-goal: Guaranteed traffic delivery to the domain is not a goal of this system, but can be achieved by a complementary system in SCION. 9.2.2 Overview of LightningFilter Considering our threat model, the adversary’s goal is to consume all available processing resources to prevent legitimate clients from reaching a target ser- vice, e.g., by sending an excessive number of requests. To prevent a single en- tity from achieving this goal, the available processing resources should be sub- divided and distributed among all clients. However, allocating an equal share of resources to each entity inhibits high utilization and potentially punishes benign traffic. As a consequence, researchers have suggested the use of more dynamic approaches, such as history-based filtering [ 213, 407] or binning of requests [ 470]. The potentially huge number of clients poses a challenge to the former approaches, as storing a traffic history (e.g., packet counters) per client is impractical. Instead, we propose to aggregate and store traffic profiles at the level of domains, i.e., ASes. These traffic profiles denote a sequence 4The replay-suppression system causes a negligible number of packets to be dropped due to false positives; however, end hosts must be able to handle packet loss anyway. 209 ' - "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). Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022. book 368 13 Deployment and Operation tural abstraction of the underlying infrastructure and provide an interface to customers. End-to-End Security. In the context of mediating customers’ IP endpoints via a secure backbone, the end-to-end communication path can be segmented 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 segment between an arbitrary ingress and egress pair of the secure routing 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 (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 through a secure backbone, SBAS must disseminate the customers’ prefix an- nouncements to all other customers and external entities. Prefixes will then be announced via SBAS and the Internet, resulting in competing announcements. To maximize the ability to route securely, SBAS must be able to convince the entities receiving the announcements to prioritize routing paths through the secure backbone over the insecure Internet paths. 13.5.3.2 Secure Route Redistribution The internal structure of SBAS can be abstracted to a full-mesh topology be- tween the PoPs, which communicate over SCION. Over these connections, 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 non-PoP members, the iBGP sessions run over an encrypted and authenticated connection (such as a VPN tunnel). SBAS offers a high degree of flexibility to its customers through support for dynamic route redistribution. Contrary to a traditional AS, which is controlled 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- bers. In the following, we describe the design and security aspects of the route redistribution mechanism. The system distinguishes between three categories of addresses: • Secure addresses: This includes prefixes announced by SBAS cus- tomers and SBAS-owned address spaces, which are assigned to cus- tomers. Secure address spaces are announced publicly at egress points via BGP. • Internal addresses: In order to provide an internal addressing scheme among PoPs, e.g., to set up iBGP sessions between PoP routers, the PoPs 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. research paper 1 ID-INT: Secure Inter-Domain In-Band Telemetry Lars-Christian Schulz OVGU Magdeburg Magdeburg, Germany lschulz@ovgu.de David Hausheer OVGU Magdeburg Magdeburg, Germany hausheer@ovgu.de Abstract—In-band network telemetry (INT) is a powerful tool for gathering status information from network components in a distributed and timely way. Until now, INT has mostly been deployed in data center environments or single operator W ANs, because it lacks mechanisms for authentication and is not widely standardized. SCION is a novel, path-based Internet architecture providing strong resilience and security properties. In this paper, we propose Inter-domain In-band Network Telemetry (ID-INT) as a protocol extension for SCION. ID-INT leverages SCION’s public key infrastructure to authenticate telemetry data while augmenting SCION’s end host path control with real-time network information. Promising applications of ID-INT include intra-AS path tracing, congestion control, SLA verification, and carbon-aware routing. We implement ID-INT in the open-source SCION stack and provide a proof of concept for an AS-hosted telemetry collection service. We show that cryptographically authenticated ID-INT can be fully implemented in the SCION router’s fast-path with no measurable impact on router per- formance. If optional encryption is employed in addition to authentication, router throughput drops by no more than 13% even if every packet carries telemetry. Index Terms—In-band Network Telemetry, SCION, W AN I. I NTRODUCTION Network monitoring and measurement is an integral part of any network operator’s toolkit. In order to meet the demands of modern real-time applications, constant monitoring of the network’s status and performance is required. Traditionally, 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 at routers. Passive monitoring is usually employing sampling techniques as observing every single packet is costly. With the advent of SDN, programmable data planes, and 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 to address the lack of security-by-design in today’s Internet based on the Border Gateway Protocol (BGP). BGP’s design limitations have caused numerous outages. SCION provides a public key infrastructure for authenticating network entities and allows multiple roots of trust to coexist. Another core feature of SCION is that it is a path-based routing protocol. End hosts include the AS-level forwarding path in packet headers to eliminate uncertainties in traditional routing. The same property also allows end hosts to send traffic to a specific destination over multiple parallel paths to increase reliability and aggregate bandwidth. SCION has been successfully de- ployed in both research [8] and commercial networks [9] and already reaches hundreds of thousands devices. A challenge of the end host routing approach is to provide sufficient information for making routing decisions to hosts. Current solutions (cf. [10]–[12]) are based on control plane messages and cannot provide real-time feedback from routers to hosts. Therefore, SCION path selection is mostly based on end-to- end measurements, which become challenging as the number of available paths grows with the number of SCION ASes. In order to address the absence of real-time telemetry in SCION and INT’s lack of an authentication infrastructure and inter-operator compatibility, we introduce Inter-Domain In- band Network Telemetry (ID-INT). ID-INT relies on SCION’s Dynamically Recreatable Key (DRKey) system to provide efficient message authentication in the data plane and in turn allows SCION end host to make informed routing decisions. This work is structured as follows: We continue with a brief description of SCION in section II and provide an overview of related work in and outside the SCION ecosystem in section III. ID-INT’s design is presented in section IV. 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 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. research paper 44 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] 0.8 - 1.9 Chosen bitrates 0.7 1.5 5 The scoring functions differ between the mechanisms. For the ’naive’ and ’shortest path’ mechanisms, the application will select the path at the begin- ning. ’Naive’ chooses uniformly at random from all available paths while ’shortest path’ chooses uniformly at random from the subset of the shortest paths, i.e.,the paths with the fewest hops or fewest ASes in it. Shortest path does not necessarily mean paths with the lowest latency but paths with the fewest hops. The selected path gets a high score and all others a low score. The score is set to low score when the sending rate is higher or equal than previously and there was loss previously except for low sending rates. This gives them the behavior of starting at a low sending rate, increasing when no loss is detected and decreasing when it is, mirroring the functionality of ABR. These two mechanisms do not require any probing. The ’passive’ mechanism uses latency only probing. The core of its scoring function is the score function defined in Equation 4.4. That function scores the QoE for VCAs and as the mechanisms are supposed to optimize the quality, it is a good starting point. However, early testing showed that this is too accepting of loss, only changing paths or sending rate after 10% of loss occurs. After 10% the score drops significantly and to avoid that, the scoring function used internally by the mechanisms has a lower threshold. The internal score function is given by replacing Equation 4.2 with penalty loss = ( 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 ' - source_sentence: What is the default output of the `scion-pki key public` command sentences: - "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. Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022. book 348 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- lowing steps: 1. Probe the local network for hints about a bootstrapping server address us- ing the available discovery mechanisms (i.e., DHCP, DNS, and mDNS). 2. Wait for hints from the discoverers. 3. Once a hint is received, try to download the TRCs and the topology of the AS from the bootstrapping server. While there is no maximum amount of TRCs to be served, the bootstrapping server must provide at least the TRC of the ISD in which the AS is located. a) On success, prepare the SD’s files and exit successfully; the SD is then automatically started by the orchestrator. b) On failure, go back to step 2. If no hint is received after a certain period, the bootstrapper daemon times out and exits with a non-zero value. Note that the TRCs retrieval is a transition solution to ease adoption; ideally they are installed on a device out-of-band, before the device gets connected to a network (more details are given in the security considerations on page 331). 13.2.3 Discovery Mechanisms 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 ' - source_sentence: How might operators of large replicated services manage their own ISD sentences: - '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 3 section. Here we focus on several representative and well-known systems—an exhaustive overview of related work is provided in §8. 3.1 Authentication Systems 3.1.1 Source Address Validation. Source address validation (SAV), also known as best current practice (BCP) 38 [ 24], is not an au- thentication system in the strict sense but is still often considered a solution to source-address spoofing in the Internet. With SAV, ASes monitor traffic originating from their own hosts and filter out packets with a source address outside their own address space. However, due to incentive misalignments,2 the adoption of SAV has been slow and a recent study found that many ASes still do not employ it in their networks [46]. Furthermore, it is impossible to determine from the outside if a particular AS employs SAV or if a particular packet originated from an AS that employs SAV as it does not carry any proof of authenticity. For an external service it is therefore impossible to filter traffic based on whether it originated from an AS employing SAV. Even with a full deployment of SAV in the Internet, on-path adversaries would still be able to spoof the source of packets and SAV thus provides very weak security properties. There exists a wide range of other filtering techniques with similarly limited properties [4, 21, 34, 43, 56]. 3.1.2 Cookies. Several protocols, including TLS [63], IKEv2 [38], and DNS [22] define a cookie mechanism to provide a weak form of source authentication. The basic mechanism for these systems is similar: Upon receiving a request, the server replies to the sender with a cookie that encodes the request parameters without allo- cating state or processing the request. Only after receiving this cookie back from the source, the request is processed. Compared to SAV, cookies have the advantage that they can be enforced by 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 packets by on-path adversaries. 3.1.3 Client Certificates. Strong authentication properties can be achieved through asymmetric cryptography and client certificates. These are supported, for example, by TLS [63] and DTLS [64]. How- ever, authentication using client certificates requires expensive asymmetric cryptography in violation of our efficiency require- ments (§2.1.2). Furthermore, these systems cannot authenticate the first packet and are vulnerable to signature-flooding attacks. 3.2 Key-Distribution Systems 3.2.1 Passport. Passport [44] provides mechanisms to establish shared keys between any pair of ASes based on a DH key exchange piggybacked on BGP messages. It relies on a secure routing system to ensure the authenticity of the shared keys, which can subse- quently be used to authenticate the source of packets at the network layer. For our purposes (see §2), Passport by itself is inadequate for several reasons: (i) it only enables authentication at the AS level, (ii) it requires authenticating systems to keep a store of symmetric keys for all ASes (currently approximately 68 000 [6]), (iii) it has 2The costs of deploying SAV are paid by an AS itself while its benefits are experienced by the rest of the Internet. Table 1: Notation used in this paper. ∥ bitstring concatenation 𝐴,𝐵 autonomous systems (ASes) identified by AS number (ASN) 𝐻𝐴, 𝐻𝐵 end hosts identified by IP address 𝐾𝑆𝐴, 𝐾𝑆𝐵 key servers located in a specific AS 𝑆𝑉𝐴 AS 𝐴’s local secret value 𝑆𝑉𝑝 𝐴 AS 𝐴’s local secret value for protocol 𝑝 ˜𝐾𝑝 • symmetric key derived (indirectly) from 𝑆𝑉𝑝 𝐾𝐴→𝐵 symmetric key between ASes 𝐴and 𝐵, derived from 𝑆𝑉𝐴 𝐾𝑝 𝐴→𝐵 symmetric key between ASes 𝐴and 𝐵for protocol 𝑝 𝐾𝑝 𝐴→𝐵:𝐻𝐵 symmetric key between AS 𝐴and end host 𝐻𝐵 in AS 𝐵for pro- tocol 𝑝 𝐾𝑝 𝐴:𝐻𝐴→𝐵:𝐻𝐵 symmetric key between end host 𝐻𝐴 in AS 𝐴and end host 𝐻𝐵 in AS 𝐵for protocol 𝑝 H(·) non-cryptographic hash operation MAC𝐾(·) message authentication code using key 𝐾 PRF𝐾(·) pseudorandom function using key 𝐾 {𝑋}𝑃𝐾𝐴 public-key encryption of 𝑋 using AS 𝐴’s public key {𝑋}𝑃𝐾− 𝐴 public-key signature over 𝑋 using AS 𝐴’s private key no mechanism to delegate keys to certain services. Other systems, such as Kerberos [54], are reviewed in §8. 3.2.2 DRKey. Dynamically Recreatable Keys (DRKeys) have been proposed to efficiently derive and distribute symmetric shared keys between routers and end hosts in the context of Origin and Path Trace (OPT) [41], a system providing path validation. The system has later been generalized and embedded in the SCION Internet architecture [58]. DRKey’s fundamental idea is that each AS 𝐴 can efficiently derive a key hierarchy starting from a secret value 𝑆𝑉𝐴, providing keys shared with other ASes, 𝐾𝐴→𝐵, and end hosts, 𝐾𝐴→𝐵:𝐻𝐵. By periodically exchanging the keys 𝐾𝐴→𝐵 between ASes, from which host-level keys can be derived, DRKey enables an efficient global distribution of symmetric keys. DRKey fulfills most of our requirements to a key-distribution system and thus provides the basis of PISKES. However, PISKES refines and extends the existing DRKey system [58] in several sig- nificant ways: (i) PISKES modifies DRKey to make it applicable to the current Internet in addition to SCION; (ii) it adds efficient mech- anisms to delegate specific keys to services in an AS; (iii) it specifies 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 ' - '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. Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022. book 90 4 Control Plane 4.2.1 Initiating Beaconing Each core AS, through its beacon service, periodically initiates the path explo- ration process by creating an initial PCB and propagating it. The PCB is either sent to a child AS (in the case of intra-ISD beaconing) or to other core ASes (in the case of core beaconing). The beacon service inserts (among other infor- mation) the initial AS entry ASE0 in the PCB. In the intra-ISD case, the initial PCB can optionally contain peer entries to non-core ASes. The hop entry HE inside ASE0 includes an initial hop field with the ingress interface identifier set to ‚ (which indicates an empty value): HF0 “ x FlagsHF } ExpTime } ‚ } ConsEgress } HFAuthy. (4.9) The initial hop field denotes the extremity of a path segment and authenti- cates a forwarding decision for every packet that • enters the AS through the interface ConsEgress and terminates in the AS; • originates from the AS and exits through the interface ConsEgress; or • switches to another path segment at this AS (using one of the possible path-segment combinations, as described in § 5.5). The beacon service then signs the PCB and sends it to a border router (which corresponds to the ConsEgress identifier as specified in the hop field). PCBs are disseminated within packets addressed to the beacon service using the corresponding service address (see § 4.6). Furthermore, the special one- hop path is used to initiate the communication to a neighboring beacon service (see § 5.4.1). This is necessary because there may not be a full forwarding path available for beaconing. Indeed, the discovery of such paths in turn relies on beaconing. The purpose of one-hop paths is thus to break this circular dependency. During core beaconing, the neighboring AS that receives the PCB can be in the same or in a different ISD. The ISD identifier included in the PCB’s signature metadata describes only the ISD of the PCB’s originator. 4.2.2 Propagating PCBs After beaconing is initiated, each PCB is propagated in the following way: The ingress border router of the next AS in the beaconing path receives the PCB, detects that the destination is a SCION service address, and sends it to the AS’s beacon service. The beacon service verifies the structure and all signatures on the PCB. The PCB contains the version numbers of the TRC(s) 3 and certificate(s) that must be used to verify the signatures. This enables the 3Even within a single ISD, there can be multiple valid TRCs at the same time, see § 3.1.6. 70 ' - '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. Dennis Eijkel. "Anycast in the SCION Internet Architecture." 2022. research paper 20 Addressing In the multiple advertisements solution, the same AS number is advertised from different points in the network, thus making the AS replicated and therefore also the services that reside inside of it. A SCION address is a triple of (ISD, AS, address) and does not allow for multiple ISD or AS identifiers in a single address. Therefore to have a single address for all of the different replicas that make up the service, all of the replicas must be put in the same AS that resides in a single ISD. A way to work around this limitation would be to extend the addressing format of SCION, either by allowing multiple ISD identifiers in the same address or a wildcard instead of the ISD identifier. Putting a wildcard in the address in the place of the ISD identifier would make that the address does not have the hijacking protection through isolation that regular SCION addresses have, thus possibly allowing for hijacking of routes. This means that traffic for that wildcard address can route to any ISD that hosts that AS number in their network, the rightful owner of the AS number has no control over which ISDs the traffic intended for their network would end up. Putting multiple ISD identifiers in a single address would mean that we would get practically the same system as the naming solution described in Section 3.3, where instead of through the naming system, alternate replicas are given in a single address. The conclusion is that both of these workarounds are not favorable. ISD considerations Considering the issues that exist around the addressing described before, replicated AS would be part of a (single) regular ISD that might also have ASes that are not replicated. But it is also possible to have dedicated ISD(s) for replicated services. These could come in multiple different forms. Operators of big replicated services might want to run their own ISD. These ISDs would then only have core ASes or only a limited number of non-core ASes. The core ASes would then have many peerings with other ISD cores at different geographical locations. Replicated service operators are probably not interested in providing transit for traffic through their ISD, thus they would not propagate beacons that would lead to paths that travel through their ISD being created. Another scenario could be that there are third parties that operate an anycast ISD and provide transit service to customers that want to operate a replicated service. The anycast ISD operator would operate the ISD core ASes and peer those with many other cores. Customers can then peer at multiple locations with (some of) the anycast core(s). 19 ' - 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. research paper 3 Evaluation of SCION for User-driven Path Control: a Usability Study SC-W 2023, November 12–17, 2023, Denver, CO, USA Figure 1: SCIONLab Topology: in light orange there are Core ASes; Non-Core ASes are white colored; Attachment Points are green; our AS is blue. help us run specific experiments we will discuss in later sections. Once this configuration phase was completed, SCIONLab web inter- face provided a unique ASN for our AS, along with cryptographic keys and public-key certificates. Subsequently, a Vagrant file for our AS was generated to instruct the configuration of a Virtual Machine (VM) that represents our AS. This file made the setup process lightweight by automating the installation of SCIONLAB services, relevant packages, and necessary configurations. Finally we were ready to use a fully configured VM belonging to the global SCIONLab topology. 3.3 Available Applications The VM configuration process also installs a predefined set of SCION applications. The SCION apps that we used in our experi- ments are: • scion address : this command returns the relevant SCION address information for the local host, that is, our AS where we launch commands from. • scion showpaths : it lists available paths between the local and the specified AS. By default, the list is set to display 10 paths only, it can be extended using the-moption. Moreover, a really useful feature for this work, is the—extendedoption, which provides additional information for each path (e.g. MTU, Path Status, Latency info). • scion ping : it tests connectivity to a remote SCION host using SCMP echo packets[4]. When the —countoption is en- abled, the ping command sends a specific number of SCMP echo packets and provides a report with corresponding statis- tics. Furthermore, the real innovation is the —interactive mode option, which displays all the available paths for the specified destination allowing the user to select the desired traffic route. • scion traceroute : it traces the SCION path to a remote AS using SCMP traceroute packets. It is particularly useful to test how the latency is affected by each link. Even this command makes interactive mode available. • scion-bwtestclient: it is the only application presented in this work that is not installed by default in the VM. Bwtestclientis part of a bigger bandwidth testing applica- tion named bwtesterwhich allows a variety of bandwidth tests on the SCION network. The application enables speci- fication of the test duration (up to 10 seconds), the packet size to be used (at least 4 bytes), the total number of packets that will be sent, and the target bandwidth. For example, 5,100,?,150Mbps specifies that the packet size is 100 bytes, sent over 5 seconds, resulting in a bandwidth of 150Mbps. The question mark ? character can be used as wildcard for any of these parameters, in this case the number of packets sent. Its value is then computed according to the other pa- rameters. The parameters for the test in the client-to-server direction are specified with -cs, and the server-to-client direction with -sc. We will analyze further these scion commands and how we used them in the next section. 4 SOFTWARE DESIGN We now present our software to test SCION features of path aware- ness and path selection. We will also test network performances such as: latency, bandwidth and packet loss in order to provide UPIN users with paths that fulfill requirements on these properties. 787 ' - '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. 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 2 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 selfish end-hosts. In particular, we introduce the notion of equi- libria to path-selection strategies (PSS equilibria). Moreover, we formally show that the non-oscillatory path-selection strategies proposed in the existing literature do not form such PSS equilibria. Thus, we provide evidence towards the hypothesis that stability in load-adaptive routing over multiple domains cannot be achieved by exclusively relying on end-hosts’ path-selection behavior. To rem- edy this problem, we leverage insights from mechanism design to devise two incentive-compatible stabilization mechanisms enforced by network operators. While these mechanisms build on existing insights from intra-domain traffic engineering, their methods of incentivization represent a novel approach to achieve stability in inter-domain networks with load-adaptive routing. We formally prove the incentive compatibility of both mechanisms and discuss their practical application. 2 OSCILLATION MODEL 2.1 Parallel-Path Systems In order to study oscillation in network architectures with end-host path selection, we build on the well-established Wardrop model [37], which is the standard model for studying the interactions of selfish 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 Z-Lane. The decision how to configure the rates is ultimately up to the network operator and, importantly, does not require any inter-domain coordination. Due to the aggregation of ASes into ISDs, configurations remain manageable even if the Internet grows to hundreds of thousands of ASes. End Host Guarantees. Z-Lane lets end hosts, more specifi- cally their applications, define what traffic should be sent with forwarding guarantees, and what traffic should be forwarded over best-effort. Still, to protect against malicious end hosts, their AS has the ultimate authority in this matter and can re- classify traffic to be sent as best-effort only. This protection is implemented through a Z-Lane gateway, which schedules end host traffic and authenticates it towards on-path routers using a secret key not known to the end hosts. How traffic is scheduled is up to the AS operator; configurations can range from fair sharing to prioritizing certain traffic from critical AS services like routing or time synchronization. We emphasize that, to avoid any setup overhead (R3), neither ISDs, nor ASes or end hosts explicitly learn their configured rate; instead, end hosts implicitly discover their allowed rate through existing mechanisms like congestion control. Compatibility with Other Systems. Bandwidth reserva- tion systems cannot provide zero-setup communication guar- antees and are therefore not suitable to protect short-lived intermediate-rate communication (Section 8). Still, we design Z-Lane to seamlessly coexist with them, as they complement our work by effectively protecting non-setup-critical, high- volume communication such as from video conferencing. We choose COLIBRI [27] as a reservation system instantiation, but other systems could be deployed as well. To prevent at- tacks targeting DRKey’s AS-level key exchange, which is a fundamental requirement for EPIC, our design also ensures compatibility with the DoCile system [74], which leverages dedicated channels between neighboring ASes to successfully bootstrap the key exchange even under DDoS. We therefore consider the following four types of inter- domain traffic: COLIBRI reservation traffic, DoCile’s neighbor-based communication, authenticated traffic from EPIC, and unauthenticated SCION traffic. 4.2 Source Authentication Z-Lane employs EPIC for authenticating traffic sources to border routers, allowing every border router to verify the au- thenticity of every received packet. An important insight in the design of Z-Lane is that efficient and reliable source authen- tication as provided by EPIC allows for meaningful source- based traffic control at border routers. The realization of this idea has not been possible so far because previous source authentication mechanisms would cause excessive commu- nication or computation overhead and therefore impede de- ployment, or were based on heuristics or probabilities, and would thus fail to reliably distinguish between authentic and spoofed addresses (Appendix H). Z-Lane is the first system to explore the use of comprehensive source authentication to protect the availability of short-lived intermediate-rate Inter- net traffic – with EPIC’s security rooted in AS-level secret keys, it integrates seamlessly into Z-Lane. We want to highlight that EPIC together with a fairness mechanism provided by some congestion control algorithm, i.e., without any guaranteed rates, would not be enough in our threat model, as an attacker would just not respect the algorithm’s feedback and instead keep sending traffic at high rates, or leverage a botnet to create many low-volume flows. 4.3 End Host Traffic Generation End hosts, i.e., their applications, can choose among several mechanisms on how their traffic is forwarded (Figure 1). For long-term traffic they request a bandwidth reservation and use it by sending their COLIBRI traffic class packets through the COLIBRI gateway. While the overhead for requesting a reservation is significant, the result is a fixed amount of bandwidth that is exclusively reserved along the communi- cation path. In a similar way, applications send short-lived intermediate-rate traffic using the EPIC traffic class over the Z-Lane gateway, where traffic is forwarded immediately with- out any delay (requirement R3), but without the applications knowing the concrete rates. In both cases traffic is protected against congestion on the communication path. The default option is for end hosts to send their traffic using the EPIC traffic class directly to a border router of their AS, where they are forwarded along the path using best-effort. This option is useful for non-latency-critical communication such as file downloads, or for long-term traffic for which no reservation is available, which can for example happen if the end host has already created a large number of reservations and gets denied from creating even more. Z-Lane envisages unauthenticated SCION traffic to be sent only in scenarios where it is not otherwise possible, e.g., if an AS needs to request shared keys using DRKey from another AS for the first time. 4.4 Z-Lane Gateway ASes use the gateway to control the traffic volumes that their end hosts (incl. AS infrastructure services) are allowed to send using Z-Lane, which serves the primary purpose of protecting benign from malicious or compromised end hosts. For end host traffic complying with the allowed rate, the gateway sets a QoS flag in the EPIC header, which indicates to on-path routers that the corresponding packets should be forwarded using the AS’ guaranteed rate. If an end host’s packet exceeds the allowed rate at the gateway, then either (i) the QoS flag is not set (or removed, if it was already set by the end host), meaning that those packets will be treated as best- effort, or (ii) the packets are dropped, depending on the AS’ policy. In contrast to best-effort EPIC packets generated at 5 ' pipeline_tag: sentence-similarity library_name: sentence-transformers metrics: - cosine_accuracy@1 - cosine_accuracy@3 - cosine_accuracy@5 - cosine_accuracy@10 - cosine_precision@1 - cosine_precision@3 - cosine_precision@5 - cosine_precision@10 - cosine_recall@1 - cosine_recall@3 - cosine_recall@5 - cosine_recall@10 - cosine_ndcg@10 - cosine_mrr@10 - cosine_map@100 model-index: - name: SentenceTransformer based on Snowflake/snowflake-arctic-embed-s results: - task: type: information-retrieval name: Information Retrieval dataset: name: val ir eval type: val-ir-eval metrics: - type: cosine_accuracy@1 value: 0.7254901960784313 name: Cosine Accuracy@1 - type: cosine_accuracy@3 value: 0.9019607843137255 name: Cosine Accuracy@3 - type: cosine_accuracy@5 value: 0.9313725490196079 name: Cosine Accuracy@5 - type: cosine_accuracy@10 value: 0.9607843137254902 name: Cosine Accuracy@10 - type: cosine_precision@1 value: 0.7254901960784313 name: Cosine Precision@1 - type: cosine_precision@3 value: 0.3006535947712418 name: Cosine Precision@3 - type: cosine_precision@5 value: 0.18627450980392155 name: Cosine Precision@5 - type: cosine_precision@10 value: 0.09607843137254901 name: Cosine Precision@10 - type: cosine_recall@1 value: 0.7254901960784313 name: Cosine Recall@1 - type: cosine_recall@3 value: 0.9019607843137255 name: Cosine Recall@3 - type: cosine_recall@5 value: 0.9313725490196079 name: Cosine Recall@5 - type: cosine_recall@10 value: 0.9607843137254902 name: Cosine Recall@10 - type: cosine_ndcg@10 value: 0.8542256235274797 name: Cosine Ndcg@10 - type: cosine_mrr@10 value: 0.8187908496732025 name: Cosine Mrr@10 - type: cosine_map@100 value: 0.8212133545466878 name: Cosine Map@100 --- # SentenceTransformer based on Snowflake/snowflake-arctic-embed-s This is a [sentence-transformers](https://www.SBERT.net) model finetuned from [Snowflake/snowflake-arctic-embed-s](https://huggingface.co/Snowflake/snowflake-arctic-embed-s). It maps sentences & paragraphs to a 384-dimensional dense vector space and can be used for semantic textual similarity, semantic search, paraphrase mining, text classification, clustering, and more. ## Model Details ### Model Description - **Model Type:** Sentence Transformer - **Base model:** [Snowflake/snowflake-arctic-embed-s](https://huggingface.co/Snowflake/snowflake-arctic-embed-s) - **Maximum Sequence Length:** 512 tokens - **Output Dimensionality:** 384 dimensions - **Similarity Function:** Cosine Similarity ### Model Sources - **Documentation:** [Sentence Transformers Documentation](https://sbert.net) - **Repository:** [Sentence Transformers on GitHub](https://github.com/UKPLab/sentence-transformers) - **Hugging Face:** [Sentence Transformers on Hugging Face](https://huggingface.co/models?library=sentence-transformers) ### Full Model Architecture ``` SentenceTransformer( (0): Transformer({'max_seq_length': 512, 'do_lower_case': False}) with Transformer model: BertModel (1): Pooling({'word_embedding_dimension': 384, 'pooling_mode_cls_token': True, 'pooling_mode_mean_tokens': False, 'pooling_mode_max_tokens': False, 'pooling_mode_mean_sqrt_len_tokens': False, 'pooling_mode_weightedmean_tokens': False, 'pooling_mode_lasttoken': False, 'include_prompt': True}) (2): Normalize() ) ``` ## Usage ### Direct Usage (Sentence Transformers) First install the Sentence Transformers library: ```bash pip install -U sentence-transformers ``` Then you can load this model and run inference. ```python from sentence_transformers import SentenceTransformer # Download from the 🤗 Hub model = SentenceTransformer("tjohn327/scion-snowflake-arctic-embed-s-v2") # Run inference sentences = [ '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) # [3, 384] # Get the similarity scores for the embeddings similarities = model.similarity(embeddings, embeddings) print(similarities.shape) # [3, 3] ``` ## Evaluation ### Metrics #### Information Retrieval * Dataset: `val-ir-eval` * Evaluated with [InformationRetrievalEvaluator](https://sbert.net/docs/package_reference/sentence_transformer/evaluation.html#sentence_transformers.evaluation.InformationRetrievalEvaluator) | Metric | Value | |:--------------------|:-----------| | 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 | ## Training Details ### Training Dataset #### Unnamed Dataset * Size: 4,321 training samples * Columns: sentence_0 and sentence_1 * Approximate statistics based on the first 1000 samples: | | sentence_0 | sentence_1 | |:--------|:----------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------| | type | string | string | | details | | | * Samples: | sentence_0 | sentence_1 | |:-------------------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | What are the two scenarios for LightningFilter deployment depending on the level of trust with the AS | Book chapter detailing SCION LightningFilter's packet authentication using DRKey. Describes key derivation using PRF with AS-level (KLF_A->B) and host-level (KLF_A:HA->B:HB) keys. Explains two deployment scenarios: trusted entity with direct access to SVLF_A and less-trusted entity fetching second-level keys. Covers header and payload authentication using SPAO, MAC computation with symmetric key (tag = MAC{KLF_A:HA->B:HB}(hdr)), and payload hash (h = H(pld)).
Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022.
book
233

9.2 High-Speed Traffic Filtering with LightningFilter
in the number of hosts, the computation overhead is significant and thus not
suited for a per-packet usage. On the other hand, using symmetric cryptog-
raphy would traditionally require the filtering service to store a key for each
packet source. To avoid per-host stat... | | How do preferences, such as customer, peering link, or transit provider, are expressed in BGP? | Book excerpt on Approaches to Implementing Path Policies and Gao–Rexford Model describing how ASes add path policy information to PCBs, specifying usage restrictions. Highlights accountability for violating AS, explain the need of a default, arbitrary path. Explains the "preference policy" for economics and "export policy" for stability.
Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022.
book
159

6.2 SCION Path Policy
When the path is only used against the explicit path policy but not regis-
tered, detection is more challenging. To detect such misuse, an AS can
monitor hop fields (HFs) used in traffic and, in the case of HFs that were
not registered by any of the downstream ASes, it can verify whether the
source or destination AS is allowed to use the path. Furthermore, viola-
tion by an intermediate AS can be detected by tracing the ... | | What is the structure of a complete SCION address? ,How is intra-domain forwarding handled at the destination AS? | Technical document describing inter- and intra-domain forwarding in SCION. Explains the separation of inter-domain (SCION-based) and intra-domain (AS-specific, often IP-based) forwarding. SCION routers forward based on Hop Fields and need not inspect destination IP address. Includes advantages like path control and simplified processing.
https://www.ietf.org/archive/id/draft-dekater-scion-dataplane-04.txt
specification


de Kater, et al. Expires 27 June 2025 [Page 8]

Internet-Draft SCION DP December 2024


* It simplifies the packet processing at routers. Instead of having
to perform longest prefix matching on IP addresses which requires
expensive hardware and substantial amounts of energy, a router can
simply access the next hop from the packet header after having
verified the authenticity of the Hop Field's MAC.

1.3.1. Inter- and Intra-Domain Forwarding

... | * Loss: [MultipleNegativesRankingLoss](https://sbert.net/docs/package_reference/sentence_transformer/losses.html#multiplenegativesrankingloss) with these parameters: ```json { "scale": 20.0, "similarity_fct": "cos_sim" } ``` ### Training Hyperparameters #### Non-Default Hyperparameters - `eval_strategy`: steps - `per_device_train_batch_size`: 50 - `per_device_eval_batch_size`: 50 - `num_train_epochs`: 5 - `multi_dataset_batch_sampler`: round_robin #### All Hyperparameters
Click to expand - `overwrite_output_dir`: False - `do_predict`: False - `eval_strategy`: steps - `prediction_loss_only`: True - `per_device_train_batch_size`: 50 - `per_device_eval_batch_size`: 50 - `per_gpu_train_batch_size`: None - `per_gpu_eval_batch_size`: None - `gradient_accumulation_steps`: 1 - `eval_accumulation_steps`: None - `torch_empty_cache_steps`: None - `learning_rate`: 5e-05 - `weight_decay`: 0.0 - `adam_beta1`: 0.9 - `adam_beta2`: 0.999 - `adam_epsilon`: 1e-08 - `max_grad_norm`: 1 - `num_train_epochs`: 5 - `max_steps`: -1 - `lr_scheduler_type`: linear - `lr_scheduler_kwargs`: {} - `warmup_ratio`: 0.0 - `warmup_steps`: 0 - `log_level`: passive - `log_level_replica`: warning - `log_on_each_node`: True - `logging_nan_inf_filter`: True - `save_safetensors`: True - `save_on_each_node`: False - `save_only_model`: False - `restore_callback_states_from_checkpoint`: False - `no_cuda`: False - `use_cpu`: False - `use_mps_device`: False - `seed`: 42 - `data_seed`: None - `jit_mode_eval`: False - `use_ipex`: False - `bf16`: False - `fp16`: False - `fp16_opt_level`: O1 - `half_precision_backend`: auto - `bf16_full_eval`: False - `fp16_full_eval`: False - `tf32`: None - `local_rank`: 0 - `ddp_backend`: None - `tpu_num_cores`: None - `tpu_metrics_debug`: False - `debug`: [] - `dataloader_drop_last`: False - `dataloader_num_workers`: 0 - `dataloader_prefetch_factor`: None - `past_index`: -1 - `disable_tqdm`: False - `remove_unused_columns`: True - `label_names`: None - `load_best_model_at_end`: False - `ignore_data_skip`: False - `fsdp`: [] - `fsdp_min_num_params`: 0 - `fsdp_config`: {'min_num_params': 0, 'xla': False, 'xla_fsdp_v2': False, 'xla_fsdp_grad_ckpt': False} - `fsdp_transformer_layer_cls_to_wrap`: None - `accelerator_config`: {'split_batches': False, 'dispatch_batches': None, 'even_batches': True, 'use_seedable_sampler': True, 'non_blocking': False, 'gradient_accumulation_kwargs': None} - `deepspeed`: None - `label_smoothing_factor`: 0.0 - `optim`: adamw_torch - `optim_args`: None - `adafactor`: False - `group_by_length`: False - `length_column_name`: length - `ddp_find_unused_parameters`: None - `ddp_bucket_cap_mb`: None - `ddp_broadcast_buffers`: False - `dataloader_pin_memory`: True - `dataloader_persistent_workers`: False - `skip_memory_metrics`: True - `use_legacy_prediction_loop`: False - `push_to_hub`: False - `resume_from_checkpoint`: None - `hub_model_id`: None - `hub_strategy`: every_save - `hub_private_repo`: None - `hub_always_push`: False - `gradient_checkpointing`: False - `gradient_checkpointing_kwargs`: None - `include_inputs_for_metrics`: False - `include_for_metrics`: [] - `eval_do_concat_batches`: True - `fp16_backend`: auto - `push_to_hub_model_id`: None - `push_to_hub_organization`: None - `mp_parameters`: - `auto_find_batch_size`: False - `full_determinism`: False - `torchdynamo`: None - `ray_scope`: last - `ddp_timeout`: 1800 - `torch_compile`: False - `torch_compile_backend`: None - `torch_compile_mode`: None - `dispatch_batches`: None - `split_batches`: None - `include_tokens_per_second`: False - `include_num_input_tokens_seen`: False - `neftune_noise_alpha`: None - `optim_target_modules`: None - `batch_eval_metrics`: False - `eval_on_start`: False - `use_liger_kernel`: False - `eval_use_gather_object`: False - `average_tokens_across_devices`: False - `prompts`: None - `batch_sampler`: batch_sampler - `multi_dataset_batch_sampler`: round_robin
### Training Logs | Epoch | Step | val-ir-eval_cosine_ndcg@10 | |:-----:|:----:|:--------------------------:| | 1.0 | 44 | 0.7533 | | 2.0 | 88 | 0.8088 | | 3.0 | 132 | 0.8296 | | 4.0 | 176 | 0.8326 | | 5.0 | 220 | 0.8542 | ### Framework Versions - Python: 3.12.3 - Sentence Transformers: 3.4.1 - Transformers: 4.49.0 - PyTorch: 2.6.0+cu124 - Accelerate: 1.4.0 - Datasets: 3.3.2 - Tokenizers: 0.21.0 ## Citation ### BibTeX #### Sentence Transformers ```bibtex @inproceedings{reimers-2019-sentence-bert, title = "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks", author = "Reimers, Nils and Gurevych, Iryna", booktitle = "Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing", month = "11", year = "2019", publisher = "Association for Computational Linguistics", url = "https://arxiv.org/abs/1908.10084", } ``` #### MultipleNegativesRankingLoss ```bibtex @misc{henderson2017efficient, title={Efficient Natural Language Response Suggestion for Smart Reply}, author={Matthew Henderson and Rami Al-Rfou and Brian Strope and Yun-hsuan Sung and Laszlo Lukacs and Ruiqi Guo and Sanjiv Kumar and Balint Miklos and Ray Kurzweil}, year={2017}, eprint={1705.00652}, archivePrefix={arXiv}, primaryClass={cs.CL} } ```