README.md

---
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.

    <citation> Lars-Christian Schulz et al.. "Cryptographic Path Validation for SCION
    in P4." *Proceedings of the 6th on European P4 Workshop*, 2023. </citation>

    <type> research paper </type>

    <page> 2 </page>

    <content>

    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

    </content>'
  - '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.

    <citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles
    to Formal Verification*. Springer International Publishing AG, 2022. </citation>

    <type> book </type>

    <page> 229 </page>

    <content>

    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

    </content>'
  - "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<url>\
    \ https://www.ietf.org/archive/id/draft-dekater-scion-pki-08.txt </url>\n<type>\
    \ specification </type>\n<content>\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</content>"
- 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).

    <citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles
    to Formal Verification*. Springer International Publishing AG, 2022. </citation>

    <type> book </type>

    <page> 368 </page>

    <content>

    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

    </content>'
  - '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.

    <citation> Lars-Christian Schulz et al.. "ID-INT: Secure Inter-Domain In-Band
    Telemetry." *2024 20th International Conference on Network and Service Management
    (CNSM)*, 2024. </citation>

    <type> research paper </type>

    <page> 1 </page>

    <content>

    ID-INT: Secure Inter-Domain In-Band Telemetry

    Lars-Christian Schulz

    OVGU Magdeburg

    Magdeburg, Germany

    [email protected]

    David Hausheer

    OVGU Magdeburg

    Magdeburg, Germany

    [email protected]

    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

    </content>'
  - '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.

    <citation> Pascal Marc Suter. *Traffic Engineering in SCION: The impact of end
    host QoS mechanisms on network performance*. Master''s thesis, ETH Zurich, 2023.
    </citation>

    <type> research paper </type>

    <page> 44 </page>

    <content>

    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

    </content>'
- 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<citation> Cyrill Krähenbühl et al.. \"Ubiquitous Secure Communication\
    \ in a Future Internet Architecture.\" SN Computer Science, vol. 3, no. 5, 2022,\
    \ pp. . </citation>\n<type> research paper </type>\n<page> 9 </page>\n<content>\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</content>"
  - "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<url>\
    \ https://docs.scion.org/en/latest/command/scion-pki/scion-pki_key_public.html\
    \ </url>\n<type> documentation </type>\n<content>\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]\
    \ <private-key-file>\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</content>"
  - '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.

    <citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles
    to Formal Verification*. Springer International Publishing AG, 2022. </citation>

    <type> book </type>

    <page> 348 </page>

    <content>

    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

    </content>'
- 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.

    <citation> Benjamin Rothenberger et al.. "PISKES: Pragmatic Internet-Scale Key-Establishment
    System." *Proceedings of the ACM Asia Conference on Computer and Communications
    Security (ASIACCS)*, 2020. </citation>

    <type> research paper </type>

    <page> 3 </page>

    <content>

    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

    </content>'
  - '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.

    <citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles
    to Formal Verification*. Springer International Publishing AG, 2022. </citation>

    <type> book </type>

    <page> 90 </page>

    <content>

    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

    </content>'
  - '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.

    <citation> Dennis Eijkel. "Anycast in the SCION Internet Architecture." 2022.
    </citation>

    <type> research paper </type>

    <page> 20 </page>

    <content>

    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

    </content>'
- 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.

    <citation> 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.
    </citation>

    <type> research paper </type>

    <page> 3 </page>

    <content>

    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

    </content>'
  - '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.

    <citation> 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. </citation>

    <type> research paper </type>

    <page> 2 </page>

    <content>

    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

    </content>'
  - '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.

    <citation> Marc Wyss et al.. "Zero-setup Intermediate-rate Communication Guarantees
    in a Global Internet." *Proceedings of the USENIX Security Symposium*, 2024. </citation>

    <type> research paper </type>

    <page> 5 </page>

    <content>

    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

    </content>'
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) <!-- at revision e596f507467533e48a2e17c007f0e1dacc837b33 -->
- **Maximum Sequence Length:** 512 tokens
- **Output Dimensionality:** 384 dimensions
- **Similarity Function:** Cosine Similarity
<!-- - **Training Dataset:** Unknown -->
<!-- - **Language:** Unknown -->
<!-- - **License:** Unknown -->

### 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<citation> Marc Wyss et al.. "Zero-setup Intermediate-rate Communication Guarantees in a Global Internet." *Proceedings of the USENIX Security Symposium*, 2024. </citation>\n<type> research paper </type>\n<page> 5 </page>\n<content>\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</content>',
    '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<citation> 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. </citation>\n<type> research paper </type>\n<page> 3 </page>\n<content>\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</content>',
]
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]
```

<!--
### Direct Usage (Transformers)

<details><summary>Click to see the direct usage in Transformers</summary>

</details>
-->

<!--
### Downstream Usage (Sentence Transformers)

You can finetune this model on your own dataset.

<details><summary>Click to expand</summary>

</details>
-->

<!--
### Out-of-Scope Use

*List how the model may foreseeably be misused and address what users ought not to do with the model.*
-->

## Evaluation

### Metrics

#### Information Retrieval

* Dataset: `val-ir-eval`
* Evaluated with [<code>InformationRetrievalEvaluator</code>](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     |

<!--
## Bias, Risks and Limitations

*What are the known or foreseeable issues stemming from this model? You could also flag here known failure cases or weaknesses of the model.*
-->

<!--
### Recommendations

*What are recommendations with respect to the foreseeable issues? For example, filtering explicit content.*
-->

## Training Details

### Training Dataset

#### Unnamed Dataset

* Size: 4,321 training samples
* Columns: <code>sentence_0</code> and <code>sentence_1</code>
* Approximate statistics based on the first 1000 samples:
  |         | sentence_0                                                                        | sentence_1                                                                            |
  |:--------|:----------------------------------------------------------------------------------|:--------------------------------------------------------------------------------------|
  | type    | string                                                                            | string                                                                                |
  | details | <ul><li>min: 5 tokens</li><li>mean: 19.23 tokens</li><li>max: 66 tokens</li></ul> | <ul><li>min: 238 tokens</li><li>mean: 507.97 tokens</li><li>max: 512 tokens</li></ul> |
* Samples:
  | sentence_0                                                                                                                     | sentence_1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
  |:-------------------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
  | <code>What are the two scenarios for LightningFilter deployment depending on the level of trust with the AS</code>             | <code>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)).<br><citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022. </citation><br><type> book </type><br><page> 233 </page><br><content><br>9.2 High-Speed Traffic Filtering with LightningFilter<br>in the number of hosts, the computation overhead is significant and thus not<br>suited for a per-packet usage. On the other hand, using symmetric cryptog-<br>raphy would traditionally require the filtering service to store a key for each<br>packet source. To avoid per-host stat...</code>                            |
  | <code>How do preferences, such as customer, peering link, or transit provider, are expressed in BGP?</code>                    | <code>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.<br><citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022. </citation><br><type> book </type><br><page> 159 </page><br><content><br>6.2 SCION Path Policy<br>When the path is only used against the explicit path policy but not regis-<br>tered, detection is more challenging. To detect such misuse, an AS can<br>monitor hop fields (HFs) used in traffic and, in the case of HFs that were<br>not registered by any of the downstream ASes, it can verify whether the<br>source or destination AS is allowed to use the path. Furthermore, viola-<br>tion by an intermediate AS can be detected by tracing the ...</code>                      |
  | <code>What is the structure of a complete SCION address? ,How is intra-domain forwarding handled at the destination AS?</code> | <code>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.<br><url> https://www.ietf.org/archive/id/draft-dekater-scion-dataplane-04.txt </url><br><type> specification </type><br><content><br><br>de Kater, et al.          Expires 27 June 2025                  [Page 8]<br>  <br>Internet-Draft                  SCION DP                   December 2024<br><br><br>   *  It simplifies the packet processing at routers.  Instead of having<br>      to perform longest prefix matching on IP addresses which requires<br>      expensive hardware and substantial amounts of energy, a router can<br>      simply access the next hop from the packet header after having<br>      verified the authenticity of the Hop Field's MAC.<br><br>1.3.1.  Inter- and Intra-Domain Forwarding<br><br>...</code> |
* Loss: [<code>MultipleNegativesRankingLoss</code>](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
<details><summary>Click to expand</summary>

- `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

</details>

### 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}
}
```

<!--
## Glossary

*Clearly define terms in order to be accessible across audiences.*
-->

<!--
## Model Card Authors

*Lists the people who create the model card, providing recognition and accountability for the detailed work that goes into its construction.*
-->

<!--
## Model Card Contact

*Provides a way for people who have updates to the Model Card, suggestions, or questions, to contact the Model Card authors.*
-->