sentence-transformers How to use tjohn327/scion-snowflake-arctic-embed-s-v2 with sentence-transformers:
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("tjohn327/scion-snowflake-arctic-embed-s-v2")
sentences = [
"What are \"Authoritative ASes\" and their roles relate to TRC?",
"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.\n<citation> Lars-Christian Schulz et al.. \"Cryptographic Path Validation for SCION in P4.\" *Proceedings of the 6th on European P4 Workshop*, 2023. </citation>\n<type> research paper </type>\n<page> 2 </page>\n<content>\nEuroP4 ’23, December 8, 2023, Paris, France Lars-Christian Schulz, Robin Wehner, and David Hausheer\ncompare it to other existing implementations. Finally, we conclude\nthis paper and give a brief outlook on future work.\n2 BACKGROUND\nIn this section, we briefly describe the architecture of the SCION\nInternet and the Intel Tofino 2 switch.\n2.1 SCION\nSCION is a path-aware Internet protocol. It introduces Isolation\nDomains (ISDs) as groups of ASes sharing a common jurisdiction.\nSCION is path-aware, i.e., end hosts can choose from available\nforwarding paths and encode the desired one in the SCION header\nas what is known as packet-carried forwarding state (PCFS). Hence,\nthe SCION data plane does not rely on longest prefix matching to\ndetermine the next hop router. Instead, SCION routers examine\nthe hop fields (HF) in the SCION header which directly encode the\nAS-level path by means of interface IDs (IFIDs).\nEach AS can uniquely map its IFIDs to a neighbor and even a cer-\ntain link in case there are multiple links to this neighbor. Together\nwith the source AS, the chain of ingress and egress IFIDs uniquely\ndescribes a SCION path. The hop fields are cryptographically signed\nby the AS corresponding to the hop with an AES-CMAC truncated\nto 6 bytes. To avoid forgery of HFs, SCION border routers must\ncheck the CMAC of every HF they use to make a forwarding deci-\nsion. Packets with invalid HFs should be dropped. In most cases, a\nHF corresponds to a specific border router, requiring each of them\nto only validate a single HF. Hop fields are grouped into segments\nresulting in a special case where a border router has to check two\nHFs when the path switches from one segment to another and the\nAS ingress and egress router happen to be the same device.\nThe AES-CMAC is calculated over a 128 bit pseudo-header. As\nthis matches up with the block size of the AES cipher, a single round\nof AES encryption is sufficient to generate the authentication tag,\nexcluding the subkey derivation AES-CMAC calls for. A precise de-\nscription of the AES-CMAC algorithm is available in the correspond-\ning RFC [15]. AES-128 is widely supported in commodity server\nhardware, making HF checks much faster than lookups in Internet-\nscale IP routing tables [3]. However, the switching ASICs used in\nhardware routers designed over decades to efficiently forward IP\ntraffic do not include AES in their forwarding logic. Fortunately, re-\ncent P4-programmable switches have sufficient match-action stages\nto implement AES in standard P4 [4].\nFor more information on SCION we refer to the corresponding\nliterature [3, 5, 19].\n2.2 Tofino Architecture\nWe develop our SCION border router for Intel Tofino 2 switches.\nThe P4 programmable Tofino architecture is an embodiment of the\nProtocol Independent Switching Architecture (PISA) data plane\nmodel. PISA switches contain three major types of programmable\ncomponents: parsers, deparsers, and match-action units (MAUs). In\nthe Tofino architecture, switch pipes consist of an in- and an egress\npipeline each containing its own parser, MAUs and deparser [18].\nEach switch pipe is hardwired to a set of, in case of Tofino 2, 8x\n400G Ethernet ports [1].\nThe number of operations that can be performed per pipeline\nis limited. If a program exhausts the resources of one pipeline, the\nprogrammer can recirculate packets in order to process them itera-\ntively. If a packet is diverted to a different pipeline and recirculated\nthere, there is the option to process the same packet sequentially\nwith different P4 programs as each pipeline can be programmed\nindependently. This is the key to fit the SCION border router in a\nTofino 2 switch as described in Section 5.1.\n3 RELATED WORK\nThe SCION reference border router is implemented in Go [2] and\nuses regular IP/UDP sockets for packet I/O. Although being multi-\nthreaded, the reference border router is not suitable for high traffic\nvolume. Schulz et al. have proposed a BPF implementation of SCION\npacket forwarding [14] which achieves a throughput of 0.676 Mpps\nper core within a virtual machine test environment. However, the\nBPF data path has not been integrated in the reference border router\nyet. A commercial DPDK-based SCION router software is available\nfrom Anapaya Systems [17], but to our knowledge no production-\nready SCION routers exist in hardware.\nThe first attempt at a hardware implementation of SCION was\nmade by Součková, targeting a NetFPGA SUME development board\nprogrammable in P4 [16]. The full 10 Gbit/s line rate of the devel-\nopment platform has been achieved in experiments. However, the\nSCION packet parser and cryptographic validation circuitry did not\nfit in the FPGA at the same time due to inefficient workarounds\nthat had to be taken to handle SCION’s non-standard header layout.\nNevertheless, the project led to improvements to SCION’s header\nlayout making it more suitable for high-speed processing.\nA first implementation of SCION for Tofino 1 was presented by\nde Ruiter et al. [7] being capable of processing packets at 100 Gbit/s\nline rate. However, as Tofino does not support cryptographic opera-\ntions in hardware, the AES-CMAC hop field validation in de Ruiter’s\napproach relies on a pre-populated table of valid hop fields. This\nsimplification works as current SCION deployments change valida-\ntion keys infrequently. An unfortunate consequence of this design\nis that the SCION router is no longer stateless and instead has to\ncommunicate with the path discovery and registration services of\nthe AS to obtain valid hop fields. Furthermore, the lookup-table\nsolution also prevents the deployment of the SCION extensions\nEPIC [\n11] and Colibri [ 9] which rely on MACs that do not just\nchange per-path, but per-packet. Nevertheless, the P4 code pub-\nlished by de Ruiter et al. inspired our work and is incorporated in\nour implementation.\nChen has shown that it is possible to implement an AES encryp-\ntion in a Tofino 1 switch using so called scrambled lookup tables [4].\nTheir implementation was limited to an encryption throughput of\n10.92 Gbit/s due to limited recirculation capacity.\nOur work addresses the issues encountered by Součková and de\nRuiter et al. We implement the SCION packet parsing and validation\nlogic separately in different pipelines of a Tofino 2 switch in order\nto bridge the gap between SCION’s requirements and achieving\nline-rate throughput. We furthermore develop an approach to AES\nin P4 that takes full advantage of the resources provided by Tofino 2\nrealizing the first 400G line-rate packet validator for SCION.\n18\n</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.\n<citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022. </citation>\n<type> book </type>\n<page> 229 </page>\n<content>\n9.2 High-Speed Traffic Filtering with LightningFilter\n9.2.1.2 Design Goals\nLightningFilter is designed to achieve the following objectives:\n• Guaranteed access for legitimate users within traffic profile: The\nsystem must ensure that a client in a non-compromised domain (i.e., a\ndomain without an adversary) has a guarantee to reach a target domain\neven in the presence of adversaries in other domains. We define a traffic\nprofile as a sequence of measurements over a specific period of time\n(profiling window) on a per-flow basis (flow count). As long as the traffic\nof a flow is within such a traffic profile, its packets are guaranteed to be\nprocessed.4\n• Enabling traditional firewalls to filter packets using metadata: The\nsystem should enable traditional firewalls to employ meaningful rule-\nbased packet filtering using packet metadata (such as the 5-tuple in the\npacket header). Without LightningFilter, these filtering rules can be cir-\ncumvented by spoofing attacks due to the lack of authentication.\n• Elimination of collateral damage across domains: The system should\nguarantee that compromised domains cannot introduce collateral dam-\nage on non-compromised domains by consuming all available resources.\nLegitimate clients within a compromised domain, however, may be af-\nfected by an adversary consuming excessive resources at a target domain.\nThis provides an incentive for domain owners to eliminate attack traffic\nsent by their end hosts.\n• Non-goal: Guaranteed traffic delivery to the domain is not a goal of this\nsystem, but can be achieved by a complementary system in SCION.\n9.2.2 Overview of LightningFilter\nConsidering our threat model, the adversary’s goal is to consume all available\nprocessing resources to prevent legitimate clients from reaching a target ser-\nvice, e.g., by sending an excessive number of requests. To prevent a single en-\ntity from achieving this goal, the available processing resources should be sub-\ndivided and distributed among all clients. However, allocating an equal share\nof resources to each entity inhibits high utilization and potentially punishes\nbenign traffic. As a consequence, researchers have suggested the use of more\ndynamic approaches, such as history-based filtering [ 213, 407] or binning of\nrequests [ 470]. The potentially huge number of clients poses a challenge to\nthe former approaches, as storing a traffic history (e.g., packet counters) per\nclient is impractical. Instead, we propose to aggregate and store traffic profiles\nat the level of domains, i.e., ASes. These traffic profiles denote a sequence\n4The replay-suppression system causes a negligible number of packets to be dropped due to\nfalse positives; however, end hosts must be able to handle packet loss anyway.\n209\n</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\nInternet-Draft SCION CP-PKI December 2024\n\n\n1.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>"
]
embeddings = model.encode(sentences)
similarities = model.similarity(embeddings, embeddings)
print(similarities.shape)
# [4, 4] 
