diff --git "a/README.md" "b/README.md" --- "a/README.md" +++ "b/README.md" @@ -4,106 +4,2527 @@ tags: - sentence-similarity - feature-extraction - generated_from_trainer -- dataset_size:4205 +- dataset_size:4229 - loss:MultipleNegativesRankingLoss base_model: Snowflake/snowflake-arctic-embed-s widget: -- source_sentence: What are the two essential properties that path-aware networks - provide for a resource-reservation architecture? +- source_sentence: Why is it advisable to rebase your branch before creating a pull + request? sentences: - - Technical document presenting gRPC API definitions for the SCION Control Service, - specifically for the Signed ASEntry representation. Defines Protobuf message formats - for SignatureAlgorithm, HeaderAndBodyInternal, Header, ASEntrySignedBody, and - VerificationKeyID. Includes details on signature algorithm, verification key ID, - timestamp, and associated data length, along TRC base and serial numbers within - VerificationKeyID. - - Master's thesis "Leveraging Application Layer Path-Awareness with SCION" continuing - the WebRTC call setup description. Details the Session Description Protocol (SDP) - offer/answer exchange, including media information, codecs, and transmission policies. - Introduces Interactive Connectivity Establishment (ICE) protocol to bootstrap - peer-to-peer connections. Mentions ICE candidates exchange for NAT-free endpoint, - and STUN/TURN are not covered. - - 'Research paper section explaining Colibri building on SCION, leveraging its hierarchical - AS decomposition (ISDs, core/non-core ASes), and segment types: up/down/core. - Details how path segments and shortcuts are built. DRKey is used to achieve secure - authentication.' -- source_sentence: Describe Phase 2 of the TRC signing ceremony., What is the overall - security model of the TRC signing ceremony? + - 'Documentation guide for using Git and GitHub in contributing to the SCION project. + Explains the process of forking the repository, setting up SSH key authentication, + cloning, and keeping the fork synchronized with the main repository. Details pull + request workflow and emphasizes best practices such as rebasing, squashing commits, + writing good commit messages and code reviews. + + https://docs.scion.org/en/latest/dev/git.html + + documentation + + + + # How to Use Git and GitHub + + + # How to Use Git and GitHub + + + ## Getting started + + + If you’ve never used Git and/or GitHub before, GitHub assembled an awesome list + of + + recommendations to get you started. + + + Below, you can find some additional guidelines on how to work with Git when + + contributing to the SCION project. If you have never used Git before, we strongly + + recommend reading it. + + + Even if you are experienced with Git, we recommend at least skimming it because + + it includes some additional information on how to write good commit messages + + and how the code review process works. + + + ### Forking the repository + + + The first step is to make your own personal fork of the main repository. You can + + do this by going to the SCION repo, and + + clicking the ‘Fork’ button on the top right, and then choosing your own personal + + repository. + + + This gives you a complete copy of the main scion repo in which you are free to + + make changes without affecting anyone else. The only downside is that you have + a + + little extra work to do to keep it up to date with the main repo. + + This is covered below. + + + ### Setting up github auth + + + Interacting with GitHub using Git will require you to authenticate every time. + + To make your life easier, we strongly suggest setting up automated + + authentication using an SSH-key. GitHub has a nice doc on how to set it + + up. + + + ### Cloning the repository + + + Now that you have your own fork, follow the steps in the + + Setting up the Development Environment section to set up + + your workspace. When you get to the point of cloning the repository, use the + + directory indicated in the README, but clone your own fork into it instead: + + + ``` + + cd "" + + git clone git@github.com:/scion + + ``` + + + (If you have authentication setup correctly, you won’t be prompted for a password.) + + + This will initialize a Git repository on your local machine and pull everything + + from your forked personal repository. + + + ### Keeping your personal fork up to date + + + To keep your personal fork in sync with the main repository, you need + + to add the main repo as new remote repository in your local clone. GitHub’s guide + + for this is + + pretty straightforward and can be summarised as follows: + + + ``` + + git remote add upstream git@github.com:scionproto/scion.git + + ``` + + + Now that you have this setup, the procedure for syncing is pretty + + straight-forward: + + + 1. Fetch the changes from the main repo: git fetch upstream + + 2. Switch to your master branch: git checkout master + + 3. Merge the upstream changes into your main branch: git merge --ff-only upstream/master + + 4. Push the changes to your GitHub fork: git push + + + ## Submitting a pull request + + + Pull Requests are a powerful tool provided by GitHub mainly used to review code + + before it is merged into the main branch. + + + ### Preparing your pull request + + + Before you create your pull request (PR), make sure your code passes the unit + testing and linting checks. + + + To run the tests, use the following command: + + + ``` + + make test + + ``` + + + The above command runs only the unit tests. As soon as you open your PR, some + additional tests + + will run automatically. + + + To lint the code, run: + + + ``` + + make lint + + ``` + + + #### Good commit messages + + + We adhere to the rules in the Go Contribution + + Guide. + + + Here is an example of a good commit message: + + + ``` + + sciond: do not panic on shutdown + + + SCIOND runs a tcp-messenger in client mode. There was a superfluous + + deferred `CloseServer` call that panicked on shutdown. + + + Changes: + + - Remove deferred `CloseServer` call on tcp-messenger in client mode + + - Don''t panic when calling `CloseServer` on a tcp-messenger with nil listener + + - Move deferred `CloseServer` call in CS to the appropriate place + + + Fixes #3766 + + ``` + + + - Starts with + + - Uses lowercase letters for subject line + + - There is always a reference number to an issue + + + ### Submitting your pull request + + + To submit a pull request, you need to push your branch containing the + + new code to the GitHub repository (as explained above). This new branch will now + + appear in the web interface (under ‘branches’ on the main repository page). + + From there, you can click on ‘New pull request’ to add a description + + and check what’s included in the pull request. + + + You can then assign the pull request to one or more reviewers who will be + + notified to perform a code review. + + + ### Code reviews + + + GitHub’s code review interface is fairly basic and lacks some key features. To + compensate for this, we use an external review system, + + reviewable.io. It integrates with the GitHub PR and keeps + + track of addressed or unresolved comments. When all issues pointed out + + by your reviewer are fixed, your code is likely ready to be merged. + + + ### Best practices + + + - Keep your development branch(es) rebased on the master branch. + + - Squash your contributions into a single commit before sending a PR. + + - Incremental updates to a PR should be separate commits to allow reviewers to + see the change. + + - Each PR should be self-contained as much as possible. It should have a description + + that covers all the changes and leave the codebase in a working + + state. + + - If you encounter any Git problems, ping someone on the Slack channel for help. + + Don’t struggle alone :) + + + ### Final comments + + + Git is a very powerful tool, and this tutorial only scratches the surface. It + presents the most common use case to get you started. Please explore the vast + amount of excellent Git and github resources available on the web.. + + + + ' + - "Description document of how Path Metadata is integrated into SCION Path Construction\ + \ Beacons (PCBs) using the StaticInfoExtension. Defines static vs. dynamic path\ + \ properties and symmetry requirements. Explains ASEntry representation for inter/intra-AS\ + \ hops, conflict resolution (most conservative value), and metadata types (latency,\ + \ bandwidth, geographic information, link type, internal hops, note). Details\ + \ wire format of HopMetadata.\n https://docs.scion.org/en/latest/beacon-metadata.html\ + \ \n documentation \n\n# Path Metadata in Beacons\n\ + \n# Path Metadata in Beacons\n\n## Introduction\n\nWhen selecting end-to-end SCION\ + \ paths, it is useful to have information\nabout the properties of the available\ + \ paths, such as information about the\nexpected latency or the “type” of the\ + \ traversed links.\n\nThis document describes how metadata can be included in\ + \ an optional extension\nof the Path Construction Beacons (PCBs), called StaticInfoExtension,\ + \ so\nthat it can be used by applications on the end hosts in the path selection\n\ + process.\n\n### Static properties\n\nWe distinguish between static and dynamic\ + \ properties of a path. Static\nproperties remain valid over the course of its\ + \ announced lifetime. The lifetime\nof a path typically is on the order of minutes\ + \ to hours. Properties that can\nvary more quickly are considered dynamic.\n\n\ + As an example, the maximum possible bandwidth on each link of a path is\nstatic,\ + \ as it will not change unless the underlying network infrastructure is\nmodified.\ + \ On the other hand, the bandwidth available to an application over\nthis path\ + \ is dynamic, as it depends on the current load on the network\ninfrastructure\ + \ along the path.\n\nIn the PCBs, we can naturally only include information about\ + \ the static\nproperties of a path.\n\n### Symmetry\n\nSCION paths and path segments\ + \ are reversible. The system described here does\nnot allow representing values\ + \ differing depending on the usage direction.\nInstead, we require that all metadata\ + \ items represent quantities that are\nsymmetric. If a path hop has e.g. different\ + \ latency in the two directions we\ncan just pick the more conservative estimate.\n\ + \n## Path Segments with Metadata\n\nSCION end-to-end paths are obtained by combining\ + \ up to three (up, core and down)\npath segments which correspond directly to\ + \ a PCB. A path segment consists\nof a series of ASEntrys, one for each AS. An\ + \ ASEntry describes the\ntraversal of an AS for a specific pair of “ingress” and\ + \ “egress” interfaces\n(where ingress/egress refer to the dissemination direction\ + \ of the beacon).\n\nTo describe the properties of all hops of a path, we will\ + \ have to include\ninformation about the links between the ASes (inter-AS hops),\ + \ and also for\nthe hops from the ingress to the egress inside an AS (intra-AS\ + \ hops). For\nthe intra-AS hops, it is however not enough to include only information\ + \ about\nthe hop between the beacon ingress and egress interfaces – where two\ + \ path\nsegments can be “joined” together, we have to ensure that the information\ + \ about\nthe resulting intra-AS hop is contained in (at least) one of the ASEntrys.\n\ + \nThe figures below illustrate the various ways in which segments can be combined\n\ + to form end-to-end paths:\n\nCombination of path segments to paths: the blue circles\ + \ represent the end\nhosts; the shaded gray circles represent core ASes, possibly\ + \ in different\nISDs; blue lines without arrow heads denote hops of created forwarding\n\ + paths; the dashed blue line denotes a peering link (labeled “p”); orange\nlines\ + \ with arrows stand for PCBs and indicate their dissemination direction;\ndashed\ + \ orange lines represent core beacons exchanged over core links\n(labeled “c”).\ + \ All created forwarding paths in cases 1a-1e traverse the ISD\ncore(s), whereas\ + \ the paths in cases 2-4 do not enter the ISD core.\n\n### Representation in StaticInfoExtension\n\ + \nWe use the following scheme, to ensure that each hop is described by (at least)\ + \ one ASEntry.\nWe rely on symmetry and avoid some redundancy.\nEach ASEntry includes\ + \ information about:\n\n- the inter-AS hop at the egress interface\n- the intra-AS\ + \ hop between egress and any (other) CHILD-link interface\nwith ID smaller than\ + \ the egress interface, for shortcuts.\n- the intra-AS hop between egress and\ + \ any (other) CORE-link interface,\nfor up-core or core-down segment cross-over\n\ + - the intra-AS hop between egress and any PEER-link interface, and\nthe inter-AS\ + \ hop at any PEER-interface\n\n| Path from 111 to 211, through core.\nCase 1a,\ + \ above. | Path from 111 to 211, via peering link.\nCase 2, above. |\n| --- |\ + \ --- |\n| Path from 111 to 211, through core.\nCase 1a, above. | Path from 111\ + \ to 211, via peering link.\nCase 2, above. |\n| Path from 111 to 112, with shortcut\ + \ at 110.\nCase 3, above. | |\n\n#### Wire format\n\nIn the PCBs, the per-hop\ + \ information is represented using the following\nstructure (extracted from proto/control_plane/v1/seg_extensions.proto):\n\ + This is the generalized Protocol Buffers-like description for a per-link\nmetadata\ + \ item of type T (but Protocol Buffers does not actually have a\ntemplates).\n\ + \n```\nmessage HopMetadata {\n // Information about the hop between construction-egress\ + \ interface and the relevant other\n // interfaces. These are:\n // - construction-ingress\ + \ interface (if any)\n // - sibling child interfaces,\n // - core interfaces,\ + \ at start or end of a segment\n // - peer interfaces\n // The key is the\ + \ interface identifier of the other interface.\n map intra = 1;\n\ + \ // Information about the hop between the local interface and the interface\ + \ in the neighbor AS\n // for the relevant links. These are:\n // - link\ + \ at construction-egress interface (if any)\n // - peer links\n // The key\ + \ is the interface identifier of the local interface associated\n // with the\ + \ link.\n map inter = 2;\n}\n```\n\nNote that some of the metadata\ + \ types discussed below do not describe per-hop\ninformation but e.g. per-AS notes.\ + \ These are much simpler to represent in the\nPCBs and don’t need to be discussed\ + \ here.\n\n### Conflicts\n\nWhen combining the information from all the path segments,\ + \ information may be\navailable from more than one ASEntry. Therefore, it is possible\ + \ to have\nconflicting information, which must be considered when combining path\ + \ segments.\n\nThe conflicts are resolved by selecting the most conservative value.\n\ + \nThis conflict resolution procedure allows an AS to announce a more conservative\n\ + value for the metadata of inter-AS links if it disagrees with the value\nannounced\ + \ by the upstream AS.\n\n### Authenticity, Integrity and Accuracy\n\nThe responsibility\ + \ for providing all of this metadata lies with the individual\nASes. There is\ + \ no mechanism to enforce that this information is complete or\naccurate.\n\n\ + The beacon extensions are signed/verified based on the control plane PKI. This\n\ + provides integrity and accountability for the provided metadata.\n\n- No AS can\ + \ tamper with the metadata included in a beacon\n- The source of the metadata\ + \ is visible and non-repudiable. Thus, if an AS was\ndetected to be including\ + \ false information, it can be held accountable by\ne.g. being added to a block\ + \ list.\n\n## Metadata types\n\n### Latency\n\nLatency describes the propagation\ + \ delay between any two hops on the path.\nThe advertised information describes\ + \ the latency for an ideal idle state of the\nnetwork infrastructure, i.e. it\ + \ does not account for any variable delay due to\nqueuing or processing.\n\nUse\ + \ cases of such information include:\n\n- Augment path selection policy in order\ + \ to obtain low latency paths.\n\n### Bandwidth\n\nBandwidth describes the maximum\ + \ bandwidth between any two hops on the path.\nThe advertised information describes\ + \ the bandwidth for an ideal idle state of\nthe network infrastructure, i.e. it\ + \ does not account for congestion.\n\nUse cases of such information include:\n\ + \n- Augment path selection policy, such that unsuitable paths can be excluded\ + \ a\npriori.\n- Avoid connections that are prone to congestion due to a low-bandwidth\n\ + bottleneck somewhere.\n\n### Geographic information\n\nThis describes the geographic\ + \ position of each router on the path. The position\nis described as a GPS coordinate\ + \ (latitude/longitude pair, in the WGS 84 datum)\nas well as an optional free-form\ + \ civic address.\n\nUse cases of such information include:\n\n- Can be used to\ + \ augment path selection policies in order to ensure\npaths do not leave a particular\ + \ area, or alternatively ascertain that\nthey never cross territory that is considered\ + \ “undesirable” by the\nuser.\n- Can be used to provide users with information\ + \ about the location of\nthe entity they are communicating with (i.e. the endpoint\ + \ on the\nother side of the path).\n- Informing network admins about router locations.\n\ + - Cross-check or enhance latency information\n\n### Link Type\n\nLink Type information\ + \ gives a broad classification of the different\nunderlying infrastructure used\ + \ by inter-AS links.\n\nFor now it distinguishes three different types of links:\n\ + \n- DIRECT: direct physical connection\n- MULTI_HOP: connection with local routing/switching\n\ + - OPEN_NET: connection overlayed over publicly routed Internet\n\nUse cases of\ + \ such information include:\n\n- Mitigating security concerns.\n- Allowing users\ + \ to select paths that e.g. avoid the open Internet.\n\n### Internal Hops\n\n\ + The Number of AS-internal hops counts the internal hops (e.g. internal IP\nrouters)\ + \ between the ingress and egress routers of any AS on the path.\n\nUse cases of\ + \ such information include:\n\n- Can be used to exclude undesirable paths from\ + \ the selection.\n- Obtain a selection of efficient, low latency paths (especially\ + \ when\ncombined with Latency Information).\n\n### Note\n\nA Note is simply a\ + \ bit of plain text. Use cases of such information\ninclude:\n\n- Tool for network\ + \ engineers to communicate interesting/important\ninformation to their peers as\ + \ well as users.\n\n## Application Programming Interface\n\nApplications will\ + \ typically not interact with the raw information in the\nStaticInfoExtension\ + \ in the ASEntrys.\nThe path combinator (go/lib/infra/modules/combinator) is used\ + \ to\nextract (only) the relevant information from the individual ASEntrys\nwhen\ + \ combining path segments to a path.\n\nThe snet.PathMetadata struct contains\ + \ the resulting path metadata.\n\n## Command Line Interface\n\nscion showpaths\ + \ displays the available extended path metadata if the\n--extended/-e flag is\ + \ provided.\nThe following values will be displayed in human readable form, provided\ + \ they\nare available:\n\n| Name | Description |\n| --- | --- |\n| Latency | Total\ + \ latency |\n| Bandwidth | Bottleneck bandwidth |\n| Geo | Sequence of geographical\ + \ coordinates of routers along path, separated by > |\n| LinkType | The link type\ + \ of each inter-AS connection along the path |\n| InternalHops | Number of internal\ + \ hops, per AS, in order of appearance on the path |\n| Notes | The notes for\ + \ each AS on the path |\n\n## Example Configuration\n\nLet us look at an AS with\ + \ three interfaces with IDs 1, 2, 3 and 5 which\nlooks like the diagram below.\ + \ The values attached to the connections\nrepresent the latency in milliseconds\ + \ between interfaces.\n\nThe staticInfoConfig.json configuration file for this\ + \ AS could then look like this:\n\n```\n{\n \"Latency\": {\n \"1\":{\n \ + \ \"Inter\": \"30ms\",\n \"Intra\": {\n \"2\": \"10ms\",\n \ + \ \"3\": \"20ms\",\n \"5\": \"30ms\"\n }\n },\n \"2\":{\n\ + \ \"Inter\": \"40ms\",\n \"Intra\": {\n \"1\": \"10ms\",\n \ + \ \"3\": \"70ms\",\n \"5\": \"50ms\"\n }\n },\n \"3\":{\n\ + \ \"Inter\": \"80ms\",\n \"Intra\": {\n \"1\": \"20ms\",\n \ + \ \"2\": \"70ms\",\n \"5\": \"60ms\"\n }\n },\n \"5\":{\n\ + \ \"Inter\": \"90ms\",\n \"Intra\": {\n \"1\": \"30ms\",\n \ + \ \"2\": \"50ms\",\n \"3\": \"60ms\"\n }\n }\n },\n \"Bandwidth\"\ + : {\n \"1\":{\n \"Inter\": 400000000,\n \"Intra\": {\n \"\ + 2\": 100000000,\n \"3\": 200000000,\n \"5\": 300000000\n }\n\ + \ },\n \"2\":{\n \"Inter\": 4000000000,\n \"Intra\": {\n \ + \ \"1\": 5044444,\n \"3\": 6555555550,\n \"5\": 75555550\n \ + \ }\n },\n \"3\":{\n \"Inter\": 80,\n \"Intra\": {\n \ + \ \"1\": 9333330,\n \"2\": 10444440,\n \"5\": 133333310\n }\n\ + \ },\n \"5\":{\n \"Inter\": 120,\n \"Intra\": {\n \"1\"\ + : 1333330,\n \"2\": 155555540,\n \"3\": 15666660\n }\n }\n\ + \ },\n \"Linktype\": {\n \"1\":\"direct\",\n \"2\":\"opennet\",\n \"\ + 3\":\"multihop\",\n \"5\":\"direct\"\n },\n \"Geo\": {\n \"1\":{\n \ + \ \"Latitude\": 48.858222,\n \"Longitude\": 2.2945,\n \"Address\"\ + : \"Eiffel Tower\\n7th arrondissement\\nParis\\nFrance\"\n },\n \"2\": {\n\ + \ \"Latitude\": 48.8738,\n \"Longitude\": 2.295,\n \"Address\"\ + : \"Place Charles de Gaulle\\n8th arrondissement\\nParis\\nFrance\"\n },\n\ + \ \"3\":{\n \"Latitude\": 47.22,\n \"Longitude\": 42.23,\n },\n\ + \ \"5\":{\n \"Latitude\": 48.2,\n \"Longitude\": 46.2,\n }\n \ + \ },\n \"Hops\": {\n \"1\":{\n \"Intra\": {\n \"2\": 2,\n \ + \ \"3\": 3,\n \"5\": 0\n }\n },\n \"2\":{\n \"Intra\"\ + : {\n \"1\": 2,\n \"3\": 3,\n \"5\": 1\n }\n },\n\ + \ \"3\":{\n \"Intra\": {\n \"1\": 4,\n \"2\": 6,\n \ + \ \"5\": 3\n }\n },\n \"5\":{\n \"Intra\": {\n \"1\"\ + : 2,\n \"2\": 3,\n \"3\": 4\n }\n }\n },\n \"Note\": \"\ + GNU Terry Pratchett\"\n}\n```\n\n\n" + - 'Research paper section presenting data-plane evaluation of Colibri measuring + gateway and border router forwarding performance showing scalability of the system. + Also shows evaluation againts Dataplane protection scenarios including best-effort + cross-traffic, unauthentic Colibri packets and authentic Colibri packets at unintended + rates. + + Giacomo Giuliari et al.. "Colibri: A Cooperative Lightweight Inter-domain + Bandwidth-Reservation Infrastructure." *International Conference on emerging Networking + EXperiments and Technologies (CoNEXT ’21)*, 2021. + + research paper + + 11 + + + + Colibri: A Cooperative Lightweight Inter-domain Bandwidth-Reservation Infrastructure + CoNEXT ’21, December 7–10, 2021, Virtual Event, Germany + + 1 2 4 8 160 + + 5 + + 10 + + 15 + + 20 + + 25 + + 30 + + 35 + + Number of cores + + Performance [Mpps] + + BR GW,𝑟 = 20 + + GW,𝑟 = 210 GW,𝑟 = 215 + + GW,𝑟 = 217 GW,𝑟 = 220 + + Figure 6: Forwarding performance of the gateway (GW) and + + border router (BR) as a function of the number of used cores. + + The gateway is evaluated for paths consisting of four ASes + + and various numbers of existing reservations ( 𝑟). + + Table 2: Measurement results in Gbps for different phases. + + Reservations 1 and 2 have bandwidth guarantees of 0.4 Gbps + + and 0.8 Gbps, respectively. + + Inputs + + Traffic class 1 2 3 Output + + phase 1 + + Reservation 1 0.400 — — 0.400 + + Reservation 2 — 0.800 — 0.800 + + Best effort — 39.200 40.000 38.669 + + phase 2 + + Reservation 1 0.400 — — 0.400 + + Reservation 2 — 0.800 — 0.800 + + Best effort — 39.200 20.000 38.643 + + Colibri unauth. — — 20.000 — + + phase 3 + + Reservation 1 40.000 — — 0.400 + + Reservation 2 — 0.800 — 0.800 + + Best effort — 39.200 20.000 38.608 + + Colibri unauth. — — 20.000 — + + gateway with worst-case inputs—for realistic traffic patterns the + + performance would therefore further increase. + + Figure 6 shows the scalability of the border router and the gate- + + way. We observe that for both components, the performance is + + almost perfectly linear in the number of cores dedicated to packet + + processing. For realistic parameters such as paths consisting of four + + ASes3 and around 32 000 existing reservations, the gateway can + + forward 18.7 Mpps using 16 CPU cores. For packets with a payload + + of 1000 B, this corresponds to a throughput of170 Gbps. The border + + router achieves even higher rates of34.4 Mpps with 16 cores, which + + corresponds to 312 Gbps when using 1000 B packet payloads. + + Data-Plane Protection. Through three phases, we show that + + the border router is able to effectively protect the Colibri reserva- + + tions from best-effort cross traffic (phase 1), unauthentic Colibri + + attacks (phase 2), and overuse of the provided bandwidth guaran- + + tees (phase 3), see Table 2. + + Phase 1 shows that congestion in the best-effort traffic does not + + impact the Colibri bandwidth due to the implemented traffic pri- + + oritization. Phase 2 demonstrates that unauthentic Colibri traffic + + is filtered effectively due to the cryptographic checks. In phase 3, + + we simulate a state where reservations 1 and 2 were flagged by the + + probabilistic flow monitor as suspicious (see §4.8) and are being + + deterministically monitored by means of the token-bucket algo- + + rithm. The overusing reservation 1 is limited to the guaranteed + + bandwidth of 0.8 Gbps without impacting the well-behaved reser- + + vation 2. Overall, the border router is able to process 120 Gbps of + + input (the maximum of our hardware) to fill the 40 Gbps output + + link under adversarial conditions without impacting the provided + + bandwidth guarantees of honest flows. + + 8 Related Work + + Resource Allocation. Multiple queuing protocols [37, 47] aim + + to approximate the fair bandwidth allocation at each router. They + + rely on the flow identifiers being reported correctly by the end hosts + + and routers. The PCE architecture [57, 58] aims to provide inter-AS + + support and allows resource allocations in GMPLS networks. Un- + + fortunately, all on-path ASes must cooperate and trust each other. + + RCS [14] is a mechanism to calculate fair traffic shares without + + congestion control. DiffServ [8] enables traffic prioritization based + + on multiple traffic classes but it does not provide any guarantees, + + and its application is restricted to intra-domain settings. All of these + + mechanisms lack security mechanisms and are thus not applicable + + to the global Internet. Route Bazaar [16] uses a decentralized public + + ledger to automate the negotiation of trustworthy SLOs on a path- + + aware Internet. This architecture, however, does not specify how + + such SLOs are created and enforced, as it is focused on their dissem- + + ination, billing, and the detection of misbehavior. Colibri’s highly + + secure SLOs are then complementary to Route Bazaar’s flexible + + SLO negotiation framework. + + RSVP. RSVP [13, 72] is a protocol to signal bandwidth reserva- + + tions. As it was designed without any security considerations, reser- + + vations may not be protected during DDoS attacks. RSVP forces + + routers, even with aggregation [19], to keep a large amount of state + + in the fast path. + + Capability-Based Mechanisms. Many systems [3, 9, 22, 30, 31, + + 34, 38, 66, 69] try to isolate legitimate flows from illegitimate and + + malicious flows by issuing network capabilities, i.e., access tokens + + for on-path entities. Privileged channels—similar to Colibri’sEERs— + + may only be used in case the packet carries the token. These + + schemes require defense mechanisms to protect against DoC at- + + tacks [7] and against collusion attacks [ 26, 53]. GLWP [65] also + + achieves inter-domain reservations, but only provides a small, in- + + flexible amount of bandwidth to each AS. + + Comparison with SIBRA. The Scalable Internet Bandwidth Re- + + servation Architecture (SIBRA) [9] is an ancestor of Colibri, and + + they are both designed to operate on top of SCION. Therefore, they + + share many design principles. However, Colibri makes numerous + + substantial improvements. + + Regarding security and performance, the major difference be- + + tween the two systems is in the authentication mechanisms. SIBRA’s + + hop-field authenticators are at the same time more complex (e.g., + + because of chaining) and provide weaker security guarantees: they + + do not allow an on-path AS to conclusively attribute a packet to the + + source, and cannot prevent the replay of authenticators. In Colibri, + + this problem is solved by the two-step calculation of HVFs (Eq. (6)). + + Further, monitoring is more efficient in Colibri, as it uses a single + + traffic monitor to track all bandwidth classes simultaneously and, + + thanks to source authentication, policing is much simpler than in + + SIBRA. Then, the lack of management scalability in SIBRA, where + + core reservations are static contracts, is addressed in Colibri by + + supporting the renegotiation of core reservations. + + ' +- source_sentence: How did the project adapt to changes of SCION implementations sentences: - - Book excerpt discussing related work in Future Internet Architectures, focusing - on Plutarch, HLP, and Information-Centric Networking (ICN/CCN). Compares SCION's - approach to Plutarch's context-based communication and HLP's hybrid link-state/path-vector - algorithm. Details ICN/CCN projects (NDN, CCNx, PSIRP), highlighting their limitations - for point-to-point, ephemeral, or customized content. Mentions Bloom filter use - in PSIRP. - - 'Documentation document on the TRC (Trust Root Configuration) signing ceremony, - outlining procedures for creating and updating TRCs in a SCION Isolation Domain - (ISD). Details two ceremony types: base TRC (for initial creation or disaster - recovery) and non-base TRC (for updates). Describes participant roles (Ceremony - Administrator, Voting AS Representatives, Witnesses). Explains that voters use - sensitive and regular voting private keys. Describes pre-ceremony policy agreement - (validity, grace period, quorum, Core/Authoritative ASes, CP Root Certificates).' - - Master's thesis "Leveraging Application Layer Path-Awareness with SCION" discussing - user involvement in SCION automated path selection. Mentions using implicit/explicit - user feedback and interaction states. Lists path-selection related limitations, - including knowing the quality of only full paths. -- source_sentence: What are SIG(0)s? + - 'Book chapter section that continues about the deployment, and focuses on name + resolution for SCION. Explains how to transition resolution of SCION address via + DNS, and integration between RHINE and SCION components. Suggest the TXT type + of DNS resource record as the most suitable option, as it holds arbitrary data + that allows application-specific parsing. + + Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles + to Formal Verification*. Springer International Publishing AG, 2022. + + book + + 478 + + + + 19 RHINE: Secure and Reliable Internet Naming Service + + From an operational perspective, RHINE will come with a set of software + + equivalents of DNS and modern EE-PKI. + + • A full-fledged RHINE server that can be configured as a forwarder, re- + + solver, or authoritative nameserver, performing operations specified by + + RHINE protocols. + + • A client-side RHINE library exposes the same resolution APIs as stan- + + dard DNS stub resolvers (e.g., systemd-resolved) to userspace appli- + + cations, and handles mandatory validation of assertions. + + • A CLI tool rdigis also provided as a replacement of the familiar dig. + + • A RHINE manager consolidating offline functions, including secure del- + + egation, zone signing and publication, etc. + + • A set of ACME-style tools for automated issuance and management of + + RCerts. + + • An extension to the public logging infrastructure to implement addi- + + tional security checks for RCerts. + + DNS entities can migrate to RHINE by substituting legacy software with + + their RHINE counterparts. Zone authorities should additionally communicate + + with the EE-PKI and manage RCerts with the new toolset. A remarkable ex- + + ception is that the operation of the root zone, which is complicated and requires + + extreme prudence, remains unaffected. This significantly reduces the friction + + of adopting and deploying RHINE. + + It may be useful to introduce a Happy Eyeballs [ 541] approach to facilitate + + the co-operation of RHINE and DNS. This allows clients to send queries to + + both systems and prefer authenticated answers from RHINE. One caveat here + + is that potential downgrade attacks may disrupt the delivery of RHINE mes- + + sages and force clients to always fall back to the untrusted DNS. This risk can + + be mitigated by deploying COLIBRI to RHINE for guaranteed low-latency + + transmission of name queries and responses. + + 19.7.2 Name Resolution for SCION + + While there are multiple ways for legacy Internet hosts to benefit from SCION + + (see Chapter 13), the resolution of native SCION addresses is necessary for + + many applications. We describe a transition solution that enables the lookup + + of SCION addresses via DNS and the integration between RHINE and SCION. + + 458 + + ' + - 'Book excerpt discussing verification of concurrent Go programs using Gobra. It + explains how incorrect programs containing data races are rejected due to permission + errors. + + Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles + to Formal Verification*. Springer International Publishing AG, 2022. + + book + + 559 + + + + 23.3 Verification of Go Programs + + Figure 23.16: Verification fails for programs containing data races. + + bra rejects programs that may suffer from race conditions. As an example, + + Figure 23.16 shows a program spawning two goroutines that each execute the + + function worker concurrently. These goroutines cause a potential data race + + because they update the same heap location without synchronization. This + + program legitimately fails to verify due to a permission error: Each worker + + requires the permission to the heap location referenced by parameter ptr in + + order to modify its content. The function main declares a local-variable i, + + obtaining the permission to write to this location. It then transfers this permis- + + sion to the first worker on line 11. Afterwards, main has no permissions left + + for this heap location. Therefore, spawning the second goroutine fails with an + + insufficient permission error as shown in the error message. + + Permission transfers from the launched function back to the caller (or any + + other function execution) need to be encoded via suitable synchronization op- + + erations. Go offers common synchronization primitives such as mutexes and + + waitgroups, but goroutines idiomatically synchronize via channels. In general, + + Gobra enables verification of concurrent programs by associating Go’s syn- + + chronization primitives with invariants, which not only express properties of + + data but also express how permissions to shared memory get transferred be- + + tween threads. For instance, mutex invariants may include properties as well + + 539 + + ' + - 'Research paper "Protocols to Code: Formal Verification of a Next-Generation Internet + Router" providing details about the implemented solution for addressing the performance + issues encountered: outline statements, pre-processing, fine-grained control. + Discusses related works: network configuration verification vs protocol implementation + and comparisons to other system verification efforts. + + João C. Pereira et al.. "Protocols to Code: Formal Verification of + a Next-Generation Internet Router." 2024. + + research paper + + 12 + + + + function depends mostly on the size of the function and the + + complexity of the properties to be verified. + + The SCION router implementation contains several large + + functions (e.g., function Run has 96 LoC and prepareSCMP + + has 101 LoC) for which verification was too slow. Since + + we did not want to restructure the code or compromise on + + the verified properties, we designed a new code annotation + + (called outline statement ) that effectively extracts a code seg- + + ment into a separate function, similar to a code refactoring + + but only for verification purposes. Analogously to functions, + + outline statements have pre- and postconditions and are ver- + + ified separately, such that they split functions into smaller + + logical parts without actually changing the implementation. + + Even with modular verification, declarations in the input + + program give rise to global declarations and (quantified) ax- + + ioms in the proof obligations. For implementations of the size + + targeted here, these declarations and axioms may overwhelm + + the SMT solver as there are too many ways to instantiate + + quantifiers. To address this, we developed a pre-processing + + step for Gobra that transforms the proof obligations in two + + ways before they are handed to the SMT solver. First, it + + splits queries into smaller sub-queries. Second, it removes + + irrelevant assumptions based on a conservative dependency + + analysis. These transformations do not affect soundness. + + Finally, we modified Gobra to give users more fine-grained + + control to select or fine-tune the used verification algorithms + + on a per-function basis. As a result, it was possible, for exam- + + ple, to use faster but less complete algorithms for reasoning + + about the heap by default, but fall back to slower but more + + precise algorithms where needed. + + All three features have been added to Gobra and can now + + also be applied in other verification projects. + + 8 Related work + + We first discuss networking-related verification efforts and + + then other work on verifying complex systems. + + Networking-related verification. As mentioned in the + + introduction, we build on an existing protocol verification + + of a simplified version of SCION [ 24, 26]. We adopt their + + refinement-based approach, but extended the models to in- + + clude realistic paths and proved additional security proper- + + ties, namely valley freedom and loop freedom. Independently, + + Chen et al. [13] model SCION in a Prolog-style declarative + + language for specifying networking protocols, and verify + + both route authenticity (control plane) and data path authen- + + ticity (data plane). The latter is weaker than path authoriza- + + tion, as it considers each hop separately instead of relating + + successively traversed hops. Consequently, path splicing at- + + tacks are not ruled out. Zhang et al. [54] prove additional se- + + curity properties provided by a SCION extension called OPT, + + but they do not verify the security of SCION itself. Moreover, + + the soundness of the logic they use is questionable [15]. + + Arnaud et al. [4, 5] model routing protocols in a process + + calculus and propose two decision procedures for their anal- + + ysis. The first one analyzes a protocol for any topology and + + the second one works for a given topology. They analyze + + two ad-hoc routing protocols from the literature. All of these + + works are limited to protocol verification, whereas we also + + provide guarantees for the actual implementation. + + As mentioned in the introduction, our work on verifying a + + protocol and its implementation fundamentally differs from + + verifying network configurations, e.g., [7, 27, 34, 50]. + + Verified security protocols. The Everest project has suc- + + cessfully verified several security protocols, including TLS [9, + + 16] and QUIC [17] at the code level. They implement the TLS + + and QUIC protocols in F# [ 9] and F∗[16, 17], respectively, + + and use the associated refinement type checker (F7 and F∗, re- + + spectively) to perform the cryptographic security proofs. As + + they use a cryptographic attacker model, their proofs yield + + stronger security guarantees than are possible in a Dolev-Yao + + model. The resulting protocol implementations, written in + + F# or in OCaml extracted from F∗, are reference implemen- + + tations, which were designed for verification and achieve a + + significantly lower performance than OpenSSL. The authors + + also provide more efficient implementations written in lan- + + guage fragments that can be compiled to C (e.g., the Low∗ + + fragment of F∗[42]), which achieve a performance similar + + to an optimized implementation in some cases, but require + + an additional proof of equivalence with the reference imple- + + mentation [16, 17]. In contrast, we verified a pre-existing, + + optimized protocol implementation and soundly connect it + + to a protocol model via the Igloo methodology. + + Both DY* [8] and work by Arquint et al. [6] verify security + + protocols at the code level by establishing invariants over + + the possible protocol traces and proving that these invariants + + entail the desired security properties. Our refinement-based + + approach increases modularity, which is crucial for verifying + + systems of the size and complexity of SCION. + + Distributed system verification. IronFleet [21], Verdi [51, + + 53], and Velisarios [43] respectively verify the Paxos, Raft, + + and PBFT consensus protocols. Chapar [32] is a framework to + + prove the causal consistency of key-value stores. In IronFleet, + + both models and implementation are written in Dafny [30] + + and verified using an SMT solver. The other algorithms are + + modeled and proven correct in Coq. These works all use code + + extraction (from either Dafny or Coq), which is unsuitable + + for the verification of existing implementations written in + + commonly-used programming languages. + + Verified centralized systems. The seL4 operating sys- + + tem [23] was verified in Isabelle/HOL using three abstraction + + levels (Isabelle, Haskell and C, the latter two imported into Is- + + abelle) that are related by refinement proofs. The seL4 design + + tries to largely avoid concurrency to simplify the verifica- + + tion. CertiKOS [20] is a general-purpose OS kernel using + + 12 + + ' +- source_sentence: What parts of a packet must be authenticated and why? sentences: - - Research paper (PERFORMANCE '20) on "Incentivizing Stable Path Selection." Defines - and explains Nash equilibria on path-selection strategies (PSS equilibria). Formally - defines the cost of a strategy (equations 7, 8, 9, 10) in an oscillation-prone - system, considering factors like usage cost, strategy cost, and expected strategy - cost over specific time spans. - - Research paper section contrasting PILA with TOFU, certificate-based & anonymity-based - protocols. Mentions HTTPS/Web PKI, DANE. Highlights PISKES' limitations (symmetric - keys only, no third-party AS accountability) vs. PILA's trust amplification. Cites - TCPCrypt, SSH, SMKEX, DoubleCheck, and Plug-and-Play IP Security as belonging - to different categories. - - Research paper introduction to Anycast in the SCION Internet Architecture. Compares - BGP and SCION as solutions for inter-domain routing. Highlights BGP's limitations - (authentication, hijacking) and introduces SCION as a future internet architecture. - Defines project goals related to supporting globally replicated services in SCION. -- source_sentence: Which protocol number is assigned to SCMP? + - 'Research paper evaluating PISKES with DNS, comparing latency overhead to legacy + DNS over UDP, TCP, and TLS. Shows minimal overhead of PISKES compared to TLS-based + solutions. + + Benjamin Rothenberger et al.. "PISKES: Pragmatic Internet-Scale Key-Establishment + System." *Proceedings of the ACM Asia Conference on Computer and Communications + Security (ASIACCS)*, 2020. + + research paper + + 9 + + + + 64 B 128 B + + 0 + + 2 + + 4 + + 6 + + 8 + + 10 + + 12 + + 14 + + 16Throughput (Mpps) + + 99.6% + + 99.9% + + 9.9 Gbps + + 10.0 Gbps + + Baseline + + Key Derivation + + Performance + + Figure 5: Key derivation performance of our key server pro- + + totype connected using a 10GbE link. + + 64 B 128 B + + 0 + + 2 + + 4 + + 6 + + 8 + + 10 + + 12 + + 14 + + 16Throughput (Mpps) + + 85.3% + + 99.8% + + 8.5 Gbps + + 9.9 Gbps + + Baseline + + Packet Verification + + Performance + + Figure 6: Packet verification performance for an end host + + connected using a 10GbE link. + + 9.08 million 117 B packets. Micro-benchmarking the key-derivation + + operation showed that each key derivation takes around 8.40 ns + + (64 B), or 17.5 ns (117 B). + + 6.2.4 End-to-End Experiments. As end-to-end experiments we eval- + + uate the packet-verification performance at the receiving end host. + + The receiver first derives from a corresponding (cached) first-level + + key and then recalculates and compares the MAC; we assume that + + only the header is authenticated. In Figure 6, the performance of + + PISKES is compared to the base case without key derivation and au- + + thentication. While our implementation introduces some overhead + + for small packets (64 B), it is able to saturate line rate for packets + + of frame size of 128 B and larger. Processing a single packet takes + + 78.0 ns for a 64 B packet and 83.6 ns for a 128 B packet. + + 6.2.5 PISKES with DNS. To evaluate PISKES as a mechanism to + + provide source authentication to DNS, we compare the latency + + overhead introduced by PISKES to legacy DNS for three different + + transport modes: DNS over UDP [49], DNS over TCP [19], and DNS + + over TLS (DoT) [ 32]. For each transport mode, we evaluate the + + overhead of adding the PISKES EDNS(0) extension (including MAC + + computation), and then measure the impact of key derivation. We + + distinguish between only MAC verification without key derivation + + (i.e., the server has the second-level key cached), additional second- + + level key derivation (i.e., the server has the corresponding first- + + level key), and both first- and second-level key derivation (i.e., + + the server derives the key from the protocol-specific secret value + + 𝑆𝑉DNS). In our experiments, we measure the processing time (using + + microbenchmarks) on the DNS server and exclude any network + + time. Additionally, the measurements for TCP and TLS do not + + include the handshake in the beginning of the protocol. + + udp tcp tcp-tls + + 0 + + 20 + + 40 + + 60 + + 80 + + 100 + + 120 + + 140 + + 160 + + 180 + + 200 + + 220 + + 240 + + 260 + + 280 + + 300 + + 320 + + 340 + + 360 + + 380 + + Latency (us) + + base + + mac + + mac+l2 + + mac+l2+l1 + + Figure 7: Latency of DNS requests between client and server + + for DNS over UDP, TCP, and TLS. “base” refers to DNS with- + + out PISKES, “mac” denotes the overhead of adding the EDNS + + extension and MAC computation, “mac+l2” and “mac+l2+l1” + + additionally performs key derivation of the second-level re- + + spectively first-level key. + + Figure 7 depicts the results of our experiments. PISKES intro- + + duces only marginal overhead (3–5 %) compared to a baseline of + + legacy DNS, which is significantly lower than the overhead due to + + TLS. The significantly higher baseline for all evaluated transports + + compared to the previous experiments (on the order of hundreds of + + microseconds) can be attributed to the overhead of the implemen- + + tation in Golang, which includes the Linux network stack, and is in + + line with other evaluations of DNS [10]. + + A recent evaluation of the DNS over HTTPS (DoH) ecosystem + + by Bottger et al. [10] shows that DoH increases the DNS resolution + + latency even more compared to DNS via UDP or TLS. Additionally, + + the authors show that delayed queries have a significant impact + + on TLS and DoH with HTTP/1.1 due to the serialization of the + + connection (head-of-line-blocking), whereas DNS via UDP remains + + unaffected. This shows that a system based on UDP as a transport + + layer is better suited for DNS. + + 7 ANALYSIS AND DISCUSSION + + 7.1 Formal Security Analysis + + To show how PISKES prevents attacks that undermine source au- + + thenticity, we have formally modeled the key-exchange system + + and verified its security properties using the Tamarin prover [48]. + + Tamarin is a state-of-the-art security protocol-verification tool that + + supports both falsification and unbounded verification of symbolic + + models. Using the Tamarin prover tool, we show (i) the secrecy of + + key-exchange messages assuming that an agents’ private key is + + not compromised; (ii) entity authentication as defined in Lowe’s + + hierarchy of authentication specifications [45]; (iii) key uniqueness; + + and (iv) key agreement between hosts. For entity authentication, + + we show non-injective agreement using timestamps as time indica- + + tors and injective agreement using nonces. All models and gener- + + ated proofs can be found at https://github.com/benrothen/piskes- + + verification. + + We have shown that the adversary has no way of obtaining a + + first-level key or second-level key, except by compromising an AS + + or host involved in the key exchange. Given that second-level keys + + are host-specific, the adversary is effectively prevented from issuing + + a packet that evades our source-authentication system. Assuming + + ' + - 'Book excerpt introducing LightningFilter, a high-speed traffic filtering mechanism + in SCION. Explains shortcomings of current intrusion-detection systems and firewalls + that LightningFilter addresses. It combats spoofing and rate-limits based on source + AS using DRKey. Explains an open-source prototype of the software solution can + filter traffic up to 160 Gbps on commodity hardware. + + Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles + to Formal Verification*. Springer International Publishing AG, 2022. + + book + + 227 + + + + 9.2 High-Speed Traffic Filtering with LightningFilter + + 9.1.5 Prerequisites for Replay Suppression + + In summary, any protocol that should be protected by our replay-suppression + + system must provide the following in each packet: + + 1. A timestamp with a precision of at least 100 ms (and a corresponding + + global time synchronization) to filter out long-outdated packets and limit + + the monitoring period; + + 2. A unique packet ID to be able to distinguish any two packets; and + + 3. Authentication of at least the timestamp and the unique packet ID. + + The hash used to insert the packet into the Bloom filter can be either the unique + + packet ID or the MAC with which the packet is authenticated: Given suffi- + + ciently long MACs, collisions—while in principle possible—are highly un- + + likely. The false-positive rate caused by these collisions is much lower than + + that of the Bloom filters themselves. + + 9.2 High-Speed Traffic Filtering with + + LightningFilter + + Intrusion-detection systems and firewalls have become indispensable for de- + + tecting and preventing a range of attacks in today’s Internet. Unfortunately, + + far from being a panacea, these defense systems suffer from several short- + + comings: First, traffic filtering is hindered by the ever more ubiquitous use + + of end-to-end encryption. Indeed, deep packet inspection is impossible with- + + out terminating encryption (and thus breaking end-to-end secrecy). Therefore, + + firewalls are often demoted to filtering based on header attributes and packet + + metadata. As these attributes are typically not authenticated, adversaries can + + spoof their IP address and thus render filters ineffective in many cases. When + + a firewall also incorporates VPN functionality, spoofed IP packets can have + + significant impact, as VPNs have been shown to be extremely susceptible to + + stateless flooding attacks [ 494]. Second, the complex filtering rules of modern + + firewalls are computationally expensive to enforce. As a result, enterprise- + + grade firewalls with a throughput beyond 100 Gbps can cost several hundred + + thousand USD [ 40]. Furthermore, the advertised performance of firewalls is + + often much lower if an adversary sends worst-case traffic in a denial-of-service + + (DoS) attack [ 144]. Finally, despite the computational effort spent per packet, + + firewalls and intrusion-detection systems suffer from substantial false-positive + + and false-negative rates. + + To remedy these issues, we developed LightningFilter, a high-speed traffic- + + filtering mechanism that leverages DRKey to enable authenticated traffic shap- + + ing based on the AS number of the source host. This provides the basis for + + 207 + + ' + - 'Research paper section explaining Z-Lane appendices. Describes EPIC per-packet + authentication using DRKey-derived symmetric keys (HVF). Also covers Z-Lane gateway + authorization with AS-level keys, and presents an optimized rate limiter, which + improves memory-efficiency. + + Marc Wyss et al.. "Zero-setup Intermediate-rate Communication Guarantees + in a Global Internet." *Proceedings of the USENIX Security Symposium*, 2024. + + research paper + + 17 + + + + B EPIC + + EPIC [42] utilizes DRKey’s efficient key derivation to enable + + per-packet source authentication in SCION. To authenticate + + itself to on-path border routers, an endpoint HS in AS A0 + + computes a per-packet hop validation field (HVF) for each + + AS Ai (1 ≤ i ≤ n) on the selected path. These HVFs are + + included in the SCION packet header. + + Ki := KAi→HS (5) + + Vi := MACKi (tsPkt,A0,HS,σi) [0:ℓval] (6) + + In this context, the function MACK generates a message au- + + thentication code using the key K, and tsPkt is a unique high- + + precision timestamp added to the packet header for every + + packet sent by the source end host. The last input to the MAC, + + σi, is an authenticator included by EPIC to achieve a property + + called path authorization, which protects the routing deci- + + sion of ASes from malicious end hosts. The notation X[a:b] + + denotes the substring of X from byte a (inclusive) to byte b + + (exclusive), and the HVF is defined as the first ℓval bytes of + + the MAC output. To verify a packet’s source, a border router + + recomputes the HVF of its AS and compares it to the HVF + + contained in the packet header. A duplicate-suppression sys- + + tem further allows ASes to filter replayed packets. EPIC also + + provides assurance to source hosts that their traffic indeed + + followed the selected path. Path validation is achieved by + + letting border routers replace the HVFs in the packet with + + the next ℓval bytes of the MAC output, i.e., [ℓval:2ℓval]. This + + serves as proof that the packet indeed traversed the ASes on + + the selected path. To communicate this information to HS, + + the destination endpoint HD returns a packet that contains the + + updated HVFs and tsPkt of the original packet. + + C Z-Lane Gateway Authorization + + Based on DRKey and EPIC, the Z-Lane gateway marks au- + + thorized packets such that other ASes’ routers can later dis- + + tinguish them from standard EPIC traffic that did not pass the + + gateway. This is achieved by replacing the packets HVFs with + + AS-level authenticated HVFs: + + fKi := KAi→A0 (7) + + fVi := MACKi (Vi) (8) + + Here, Vi is the arriving packet’s HVF (Eq. 6).10 Apart from + + the HVF (and the QoS flag), the gateway does not change any + + field in the packet header. Overwriting the HVF at the gateway + + does not break EPIC’s path validation feature, because the + + border router later still updates the HVF to Vi[ℓval:2ℓval], i.e., + + based on the original HVF computed by the end host; thus the + + destination will still see the original EPIC MACs. Computing + + fVi in addition to Vi increases the overhead at border routers. + + 10We use an additional, not explicitly mentioned input to the MACs in Equa- + + tions (4) and (8) to enforce domain separation. + + However, this increase is minimal, as only a single additional + + AES operation is needed; the key fKi is already derived and + + AES-expanded in the computation of Ki (Eq. 4). We choose + + this approach of computing fVi as a new MAC with input + + Vi instead of just recomputing Vi according to Equation (6) + + but with KA→B, as otherwise an end host would need to also + + communicate each σi to the gateway. + + D Memory-Efficient Rate Limiting + + In standard literature, the token-bucket rate limiter is either + + implemented using a counter and a timer or using a counter + + and a timestamp [49] (plus the configured rate and burst size). + + The first approach does not scale because for every flow (or + + every source AS or ISD, in the case of Z-Lane) a separate + + timer is needed. Also, timers are often not suitable for high- + + performance applications. The second approach is computa- + + tionally very efficient but typically not optimized for a low + + memory footprint: state-of-the-art implementations often re- + + quire at least 20 B [26]—some even more than 60 B [29]—of + + memory per token bucket.11In this section, we present a data + + structure that requires only 8 B per token bucket, thus im- + + proving Z-Lane’s memory-efficiency. Concretely, we do the + + following optimizations: (i) Configure the same burst size for + + every token bucket. This means that this value only needs to + + be stored once. (ii) Store the burst size in 2 B. This allows + + to define values up to 65535 B. (iii) Reduce the size of the + + counter to 2 B. This is possible, because the counter cannot + + exceed the burst size, on which we put an upper bound in + + the previous step. (iv) Decrease the size of the rate field to + + 2 B. With a granularity of 100 kbps, this still allows to con- + + figure values up to 6.5 Gbps. (v) Only track short intervals. + + Instead of storing an 8 B Unix timestamp that measures the + + time elapsed since 1970, we use 4 B tracking an interval of + + only 1.3 s. The timestamp still stores time values at nanosec- + + ond precision. When monitoring α ASes and υ ISDs, this + + data structure thus requires only 2B + (α + υ) ·8B instead + + of (α + υ) ·20B. In case the configured rates are the same + + for all monitored ASes and ISDs, they can be replaced by + + a single globally defined rate, thereby further reducing the + + per-token-bucket memory overhead by 2 B. + + Monitoring Accuracy. Using timestamps to only track + + 1.3 s intervals can lead to false negatives, where the rate + + limiter wrongly considers a packet to cause an overuse of + + the configured rate. However, this situation can only arise + + if (i) a packet is sent a multiple of 1.3 s after the previous + + packet and (ii) the previous packet depleted the token bucket. + + More precisely, this is the case if a packet arrives at a time + + t ∈ ]λ·1.3s, λ·1.3s + ℓ + + rate ] for λ ∈ N≥1, where ℓ denotes the + + packet’s length. Therefore, if an AS stops sending any traffic + + for a random period of at least 1.3 s, then the probability of + + the next packet being illegitimately dropped is ℓ + + rate·1.3s . For + + 11Typical field sizes: 8 B for timestamp, 4 B for counter, burst, and rate. + + 17 + + ' +- source_sentence: What are the two possible configurations for the forwarding hardware + and the validator (accelerator) sentences: - - Documentation document listing assigned SCION protocol numbers, mirroring IANA - assignments where possible. Details the SCION-specific protocol number range (starting - at 200) to avoid conflicts. Specifies protocol numbers for TCP/SCION (6), UDP/SCION - (17), SCION Hop-by-Hop Options (200), SCION End-to-End Options (201), SCMP (202), - and BFD/SCION (203). - - Research paper (PERFORMANCE '20) on "Incentivizing Stable Path Selection in Future - Internet Architectures." Introduces the problem of oscillations in path-aware - networks with end-host path control and lack of incentive compatibility in existing - stability-inducing policies. Proposes a game-theoretic model to analyse end-host - path selection and introduces the concept of PSS (Path-Selection Strategy) equilibria. - The paper's main contribution is a formal analysis proving incentive incompatibility - of existing strategies and presenting two novel, incentive-compatible mechanisms. - - 'Research paper "Protocols to Code: Formal Verification of a Next-Generation Internet - Router" presenting background on the SCION architecture and an overview of the - verification approach. Explains ASes, hierarchical links (CustProv, ProvCust, - Core), border routers, control plane (path discovery, dissemination), and data - plane (packet forwarding). Describes segment construction, authorization (nested - MACs), combination rules (valley avoidance), and simplified inter-domain forwarding. - Presents an overview of the verification framework.' -- source_sentence: What observations supported that, had a path switch occurred when - the penalty was issued, the high bitrate video quality degradation could have - been avoided? , Why is expected to see QoE degradation the high bitrate video - when bandwidth is limited to 1 Mb/s? + - 'Research paper discussing limitations and further, automated improvements of + the DNS analysis framework, and expanding on future study goals. Details the ethics + of responsible notification to DNS developers and operators of found vulnerabilities. + + Si Liu* et al.. "A Formal Framework for End-to-End DNS Resolution." + *Proceedings of ACM SIGCOMM*, 2023. + + research paper + + 12 + + + + ACM SIGCOMM ’23, September 10–14, 2023, New York, NY, USA Si Liu, Huayi Duan, + Lukas Heimes, Marco Bearzi, Jodok Vieli, David Basin, and Adrian Perrig + + in two resolver implementations. Unbound suffers from much larger + + amplification than BIND when QMIN is enabled. This is because + + Unbound has a higher limit for QMIN iterations, which outweighs + + its slightly lower limit for cname. + + These amplification vulnerabilities can be exploited by attackers + + to launch highly effective DoS attacks at low costs. We anticipate + + that DNS developers and operators can leverage our framework to + + proactively discover and fix such security vulnerabilities. + + 6.4 Discussion + + Improving Automation. While our approach produces zones and + + queries that exhibit undesirable system behavior, some manual + + work is still necessary to triage and classify the results. We have + + seen that discovering certain attacks requires changing the focus + + of the zone generation to, e.g., specific record types. + + Moreover, the generated zones mainly expose problematic in- + + teractions of DNS features, whereas constructing realistic attack + + scenarios would be even more helpful. For example, our tool easily + + discovers that large delegations to non-existent nameservers intro- + + duce a large amplification, which is, however, not yet directed at + + a specific victim. We would like to improve our tool to automate + + the simulation of real-world attacks, e.g., automatically placing + + the non-existent nameservers under a victim zone to maximize + + amplification as in a full-fledged NXNS attack. + + Reducing the Attack Search Space. While we have demonstrated + + that random zone generation with a heuristic coverage of the query + + space is quite effective in discovering problematic interactions of + + DNS features, an exhaustive (albeit still bounded) exploration of + + the search space would be preferable. GRoot’s ECs provide a good + + starting point, but they are unsound with respect to our more + + realistic semantic model, i.e., two queries in the same EC can cause + + a resolver to behave differently. + + As future work, we plan to refine the definition of ECs for the + + specific analysis of amplification attacks. GRoot does not place + + multiple queries for different existing names in the same equiv- + + alence class; only non-existent names may be collapsed into one + + EC. However, different existing names in a zone are often resolved + + in exactly the same way, e.g., the resolution of a type a query for + + ns1.example.com and ns2.example.com are likely identical, apart + + from the contents of the final response. Similarly, query rewriting + + at the nameserver is irrelevant for amplification (assuming the re- + + solver does not validate the cname chain). A promising direction + + would therefore be to define a “resolver-centric” notion of query + + equivalence, where two queries are considered equivalent if they + + lead to the same actions at the resolver. + + 7 RELATED WORK + + Formalizing DNS Semantics. GRoot [26] provides the first for- + + malization of a subset of DNS semantics. We have already discussed + + its limitations in Section 1. Relying on parts of the GRoot seman- + + tics, the authors also develop SCALE [27], a test case generator to + + find RFC compliance errors in nameserver implementations. While + + SCALE identifies implementation bugs, it focuses solely on the + + local processing logic at authoritative nameservers and does not + + consider the complete name resolution process with a recursive + + resolver. RHINE is a DNS-based naming system co-designed with a + + formal model [20], which, unlike our formal semantics, focuses on + + an end-to-end authentication architecture that is agnostic to the + + detailed resolution process. + + Verification of DNS Implementations. Son et al. [44] formal- + + ize the cache implementations of popular open-source resolvers, + + modeling aspects such as data credibility requirements and baili- + + wick rules. In comparison, our model is more comprehensive as it + + specifies the complete resolver algorithm at the design level. + + Ironsides [14] is an authoritative nameserver implementation + + that is formally verified to be free of dataflow errors, runtime excep- + + tions, and similar problems. While being provably secure against + + single-packet DoS attacks, it may still be vulnerable to application- + + layer attacks at the DNS protocol level, which are the focus of our + + automated attack analysis. In addition, the use of formal methods + + in Ironsides is unrelated to the DNS semantics, which means that it + + cannot serve as a formalization of the specification. + + Formal Analysis of DoS Attacks. Formal analysis of a system’s + + availability aspects is generally less mature in comparison to confi- + + dentiality or integrity properties. This is mainly due to the inherent + + quantitative nature of DoS attacks and the fact that the common + + Dolev-Yao intruder model [19], often used for cryptographic proto- + + col analysis, is too strong for this purpose. Meadows [34] introducs + + a cost-based framework for the analysis of DoS attacks where an + + attacker’s power can be metered and limited. Urquiza et al. [ 48] + + refine this intruder model by explicitly considering timing aspects, + + which can capture more sophisticated attacks such as slow DoS + + and attacks targeting computational resources or memory. Our + + framework offers the same capabilities. + + Amplification attacks have been analyzed by Shankesi et al. [43], + + where they leverage model checking to automate the search for DoS + + attacks on the VoIP session initiation protocol. Our framework also + + provides a built-in model checker. For DNS in particular, Deshpande + + et al. [18] model the classic bandwidth amplification attack as a + + continuous-time Markov chain to analyze different countermea- + + sures. However, their model is abstract and cannot capture more + + sophisticated DoS attacks. + + 8 CONCLUSION AND FUTURE WORK + + A formal framework is a necessary approach to achieve the desirable + + goal of a DNS infrastructure with strong security properties, espe- + + cially given the intrinsic complexity of today’s DNS specifications + + and configurations. Establishing a mathematically rigorous seman- + + tics can help identify and resolve ambiguities as well as provide a + + basis for tools to automatically discover known and new attacks. + + In addition to pursuing the research directions highlighted in Sec- + + tion 6.4, we also plan to extend our framework to cover DNSSEC + + and DoH/DoT, and support multiple zones at a single nameserver. + + Ethics. We have followed common practices for responsible dis- + + closure of the discovered DoS vulnerabilities. The affected entities + + have acknowledged the validity of our reported vulnerabilities, and + + are investigating their potential impact and mitigation. + + ACKNOWLEDGMENTS + + We thank the anonymous reviewers for their valuable feedback. We + + gratefully acknowledge support from ETH Zürich, ZISC, and from + + SNSF for project RHINE (200021_215318). + + ' + - "Research paper describing the modular SCION border router structure. Focuses\ + \ on separating cryptography and forwarding. Outlines the bridge header design\ + \ for communicating with an external accelerator. Illustrate two possible accelerator\ + \ configruations: look-aside (Figure 1, validator outside forwarding hardware),\ + \ and inline (Figure 2, validator before/after forwarding hardware). Mentions\ + \ support for one or two hop field validations and EPIC protocol extension in\ + \ the bridge header.\n Lars-Christian Schulz et al.. \"Cryptographic\ + \ Path Validation for SCION in P4.\" *Proceedings of the 6th on European P4 Workshop*,\ + \ 2023. \n research paper \n 3 \n\n\ + Cryptographic Path Validation for SCION in P4 EuroP4 ’23, December 8, 2023, Paris,\ + \ France\n4 THE MODULAR SCION BORDER ROUTER\nConceptually, a SCION border router\ + \ located at the edge of an AS\nhas to perform the following steps for every packet:\n\ + (1) Check that the port the packet was received on matches the\none specified\ + \ inside the hop field.\n(2) Check that the HF is not expired. Each HF has a timestamp\n\ + and a lifetime to prevent replay attacks on the network.\n(3) Recalculate the\ + \ CMAC over the current HF and check its\nauthenticity. This ensures that the\ + \ HF itself was not manipulated\n(i.e. hijacked).\n(4) Forward the packet on the\ + \ port specified in the hop field, or\nperform AS-internal routing to reach the\ + \ egress router or destina-\ntion host.\n4.1 System Architecture\nIn order to\ + \ allow a distributed hardware implementation of a SCION\nborder router we split\ + \ its functionality into a cryptography part that\nonly performs the CMAC validation\ + \ (e. g. FPGA or another switch\npipe as in this work) and a forwarding part (e.\ + \ g. our P4 border\nrouter) that does everything else. Considering that one of\ + \ the major\nproblems with SCION in NetFPGA was its complex packet header\ncontaining\ + \ the PCFS, we decided that the forwarding hardware\nshould prepend a newly designed\ + \ bridge header to the packet. This\ncan be parsed directly by the accelerator\ + \ performing the crypto-\ngraphic validation, removing all complexity from its\ + \ parser.\nAs a result, there are two different configurations of the forward-\n\ + ing hardware and the validator.\nForwarding Hardware\nStart processing\nthe packet,\n\ + Add bridge header\nRemove bridge\nheader, \n(Continue processing\nthe packet)\n\ + Validator\nValidate MAC\nValidator\nValidate MAC\nIngress port\nEgress port\n\ + Figure 1: Look-aside configuration with the SCION forward-\ning hardware encompassing\ + \ the accelerator.\nThe first possibility is alook-aside accelerator. The resulting\ + \ work-\nflow for packet processing is depicted in Figure 1. Every packet is\n\ + received first by the forwarding hardware which parses the packet\nand at least\ + \ creates the bridge header in front of the packet. After-\nwards it forwards\ + \ the packet to the cryptographic accelerator that\nparses the bridge header and\ + \ validates the CMAC. When the packet\nis returned, the forwarding hardware removes\ + \ the bridge header\nagain from the packet and transmits it via the egress port.\ + \ In this\ncase, the forwarding logic can be applied during one of the two\nruns\ + \ through the hardware or even be split between both. However,\nhalf of the ports\ + \ of the forwarding hardware are occupied by the\nexternal accelerator(s).\nThe\ + \ other option is an inline accelerator as sketched in Figure 2.\nPackets are\ + \ first received by the validator and passed directly to the\nforwarding hardware,\ + \ which parses and processes the packet. The\nswitch assembles the bridge header\ + \ and passes the packet back to\nValidator\nForwarding Hardware\nStart processing\n\ + the packet,\nAdd bridge header\nValidate MAC, Remove\nbridge header\nValidatorIngress\ + \ port\nEgress port\nValidate MAC, Remove\nbridge header Egress port\nFigure 2:\ + \ Inline configuration with only one pass through\nSCION forwarding hardware and\ + \ the accelerator.\nthe accelerator for validation. In the accelerator the bridge\ + \ header\nis removed and the packet forwarded to the next hop if it passes\nvalidation\ + \ or dropped otherwise.\nNote that we have to forward the entire packet between\ + \ Tofino\nand validator, because switches lack the memory for buffering\npackets\ + \ during the external MAC validation.\n4.2 Bridge Header\nAs we do not require\ + \ the external accelerator to be capable of\nparsing the SCION header, we prepend\ + \ a bridge header to the packet.\nTo be able to detect the presence of the bridge\ + \ header, an additional\nEthernet header is inserted at the beginning of the packet\ + \ with\nEtherType set to 0x9999.\nFlags Reserved Switch Data\n0 1 2 3 4 5 6 7\ + \ 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n0 1 2 3\nValidate First Hop\ + \ Field\nValidate Second Hop Field\nReserved\nReserved\nHop Field 1 is valid\n\ + Hop Field 2 is valid\nReserved\nReserved\n0\n1\n2\n3\n4\n5\n6\n7\nInstruction\ + \ Flags\nStatus Flags\nFigure 3: Layout of the bridge main header.\nThe bridge\ + \ header’s main part is always present and given in\nFigure 3. It includes instruction\ + \ flags to signal to the accelerator\nwhich CMACs to validate. These flags also\ + \ define the remaining\nbridge header’s structure. The accelerator may usestatus\ + \ flags to no-\ntify the switch whether validation was successful. The forwarding\n\ + hardware can store metadata in switch data to be passed through\nunchanged for\ + \ use in a look-aside configuration.\nFor every hop field to be validated, there\ + \ is a header section\nincluding the 16-byte pseudo header which the CMAC is calculated\n\ + over as well as the MAC from the original hop field for checking.\nThe full layout\ + \ of the hop field header can be found in Appendix A.\nWe support the validation\ + \ of one or two hop fields simultaneously,\nwhich covers all possible cases in\ + \ the protocol (see Section 2.1).\nFurthermore, the header can be extended to\ + \ include data for other\ncryptographic operations, i.e. for the EPIC protocol\ + \ extension of\nSCION.\n19\n" + - "Book excerpt presenting experimental results for the N-Tube statistical analysis.\ + \ Discusses impact of increasing malicious power (total demand, number of attackers,\ + \ reservations per attacker). Analyzes how attackers occupy bandwidth using the\ + \ statistical model checking.\n Laurent Chuat et al.. *The Complete\ + \ Guide to SCION. From Design Principles to Formal Verification*. Springer International\ + \ Publishing AG, 2022. \n book \n 536 \n\ + \n22 Design-Level Verification\n 0\n 20\n 40\n 60\n 80\n 100\n0 40 80\ + \ 120 160 200 240 280 320\n% of Bandwidth Allocation\nTotal Malicious Demand (Gbps)\n\ + Benign\nMalic.\nExp. (a)\n 0\n 20\n 40\n 60\n 80\n 100\n0 2 4 6 8 10 12 14 16\n\ + # Attackers\nBenign\nMalic.\nExp. (b)\n 0\n 20\n 40\n 60\n 80\n 100\n0 1 2 3 4\ + \ 5 6 7 8 9\n% of Bandwidth Allocation\n# Reservations per Attacker\nBenign\n\ + Malic.\nExp. (c)\n 0\n 20\n 40\n 60\n 80\n 100\nExp. (a) Exp. (b) Exp. (c)\n%\ + \ of Malicious Demands\nBefore f-line\nImmed. after f-line\nAfter stab.\nExp.\ + \ (d)\nFigure 22.12: Measuring the impact of increasing malicious power.\nlocations\ + \ in the entire network converge and stabilize; the total allocations are\nalways\ + \ bounded by D’s adjusted capacity (dashed line), and distributed propor-\ntionally\ + \ to the demands after stabilization as expected (§ 10.2.5). Hence, from\nthe\ + \ quantitative perspective, these results further demonstrate stability and fair-\n\ + ness, in particular for the worst-case scenarios (Figures 10.8–10.10) where\n\ + attacks are mounted directly on an honest path.\nExperiment 3: Impact of Increasing\ + \ Malicious Power. To analyze\nthe influence on bandwidth allocation of increasing\ + \ malicious power, we ran-\ndomly positioned the attackers in the network (not\ + \ necessarily neighbors of the\ntargeted path), and picked a relatively small\ + \ number of destinations (5 out of\n100 ASes) for the reservations so that all\ + \ demands, including malicious ones,\nconverge to these destinations . We then\ + \ randomly selected one destination and\none of its egress interfaces, and reported\ + \ the associated aggregate allocations\nfor the benign sources and attackers,\ + \ respectively.\nExperiments (a)–(c) in Figure 22.12 show the allocation percentage\ + \ as a\nfunction of attacker capability, represented by total demanded bandwidth\ + \ , num-\nber of attackers , and number of issued reservations per attacker ,\ + \ respectively.\nWith increasing malicious power, the attackers tend to occupy\ + \ more bandwidth\nuntil the entire allocation stabilizes (starting from 160 Gbps,\ + \ 10 attackers, and\n7 reservations per attacker, respectively); thereafter their\ + \ demands are adjusted,\nand thus limited by the links’ capacities and scaling\ + \ factors. These results fur-\n516\n" +- source_sentence: How does multipath communication in SCION compare to protocols + like multipath TCP and QUIC? sentences: - - Book section on Absence of Kill Switches contrasting SCION's trust architecture - with the monopolistic trust root architectures of DNSSEC and RPKI/BGPsec, which - enable kill switches. Details SCIONs kill switches, stating that in SCION, ISDs - manage their own trust roots, granting autonomy. Describes local ISD Kill Switches, - and how they differ. - - Master's thesis "Leveraging Application Layer Path-Awareness with SCION" abstract. - Introduces path-awareness in SCION and its potential to improve networking. Presents - the concept of "path processor" for application-layer path selection strategies. - Describes a SCION application library and a path-aware video calling app (iOS/macOS) - using call-specific metrics and redundant transmission. Mentions experiments confirming - positive impacts on Quality of Experience (QoE). - - Master's thesis "Leveraging Application Layer Path-Awareness with SCION" displaying - results (figure 6.8) of high bitrate video transmission with restricted bandwidth, - showing QoE degradation (freezes, resolution drops). Discusses correlation between - bitrate, bandwidth limits, and the timing of potential path penalties. + - 'Research paper comparing BGP and SCION, highlighting differences in hierarchy, + security, and routing mechanisms. Contrasts BGP''s path-vector approach with SCION''s + path-aware, packet-carried forwarding state. Emphasizes SCION''s multipath capabilities + and embedded cryptography. + + Dennis Eijkel. "Anycast in the SCION Internet Architecture." 2022. + + + research paper + + 16 + + + + 2.3 Comparison between BGP and SCION + + Since SCION is a clean-slate design, there are many differences between SCION + and BGP. This + + section will elaborate on some of those differences. + + SCION has a clear hierarchy and isolation in the isolation domains. Each ISD has + a config- + + uration which is managed by the group of core ASes in that ISD. These core ASes + thus have a + + managerial task within the ISD which regular ASes do not have. BGP in theory does + not have + + such a clear hierarchy. However, it is common in BGP for ASes to be customers + to higher tier + + ISPs, where the only connectivity that the customer ASes have to the internet + is through that + + ISP. So where BGP has hierarchy to some extent, it is not as clear as the ISDs + in SCION. + + The isolation principle in SCION plays a big part in the security benefits it + has over BGP. + + In SCION, an address is made up by the tuple (ISD, AS, address) where the first + two parts + + identify the ISD and AS inside that ISD. The information in the beaconing process + is signed + + by keys that are part of a public key infrastructure (PKI), with a root key that + is managed + + by the core ASes of the ISD. The fact that cryptographic authentication and verification + are + + an integral part of SCION makes it resilient to attempts by malicious actors to + interfere with + + the beaconing process. Plain BGP does not have this level of security, thus allowing + for route + + hijacking. Extensions such as RPKI [2] and BGPSec [3] could alleviate most of + these problems, + + but require every AS operator to run them. + + The SCION authors refer to SCION as being path aware networking and having a packet- + + carried forwarding state. SCION also has some resemblance to source routing, and + link-state + + routing. In source routing protocols, senders have to specify the path that the + packet travels + + through the network in the packet header. In SCION this is partially the case, + the sender specifies + + the path that a SCION packet travels over. However, the client does not need knowledge + of the + + entire topology of the internet, which would be the case in pure source routing. + Link-state + + routing is a class of protocols where routers disseminate information about the + connections that + + they have with other routers. Each router can then build a network topology graph + and routing + + table based on that information. During the beaconing phase of SCION, the beaconing + servers + + share this type of information with neighboring networks. + + In contrast, BGP is a path-vector routing algorithm as mentioned before. Border + routers + + speaking BGP regularly exchange information about their routing tables with each + other: which + + IP prefixes they can reach and what the path is that packets destined to an address + in that prefix + + would (most likely) take. When a border router receives a packet to forward, it + will perform a + + lookup in its routing table and determine where the packet should go next. + + In SCION, end hosts construct end-to-end paths through a graph that they construct + from + + the path segments that they receive from their path lookup query. Therefore end + hosts can + + construct disjoint end-to-end paths. Using these disjoint paths allows for improved + resilience + + against path failures. There exist protocols in the current internet, such as + multipath TCP [10] + + and QUIC [11], that can do some limited form of multipath communication. But those + are + + generally limited to the first hop, after which there is no way to guarantee that + the end-to-end + + paths are disjoint. End hosts in a BGP-based internet can not dictate the path + that individual + + packets must take, whereas end hosts in SCION can. Multipath TCP and QUIC therefore + can + + not provide multipath routing to the extent that SCION can, which can construct + completely + + disjoint paths if the topology allows that. + + 2.4 Anycast + + The basic concept behind anycast, as described in RFC 1546 [6], is that there + can be an internet + + service replicated over multiple different (geographical) locations. All of these + replicas would + + 15 + + ' + - 'Research paper related to data-plane energy efficiency, discussing prior work + and future research directions. Divides existing Internet energy analysis into + top-down, bottom-up, and model-based categories; categorizes Baliga, Vishwanath + and Chen''s previous research, and mentions a prior work estimating power consumption + of Content-Centric Networking (CCN) and a comparison between power consumption + of SCION and Named Data Networking (NDN). Outlines a method to analyze SCION''s + data plane power consumption and proposes future research on considering the internet''s + transition to edge computing and MPLS deployment. + + Seyedali Tabaeiaghdaei, Adrian Perrig. "Data-Plane Energy Efficiency + of a Next-Generation Internet Architecture." *IEEE Symposium on Computers and + Communications (ISCC)*, 2022. + + research paper + + 7 + + + + 2) Bottom-up approaches: researchers generalize the en- + + ergy intensity values they have obtained from case studies + + through direct measurement or observation. For example, + + Coroama et al. [38] present a pure bottom-up assessment of the + + energy intensity of a video conference between Switzerland + + and Japan. Their study achieves high accuracy , as they knew + + the exact path and all the network devices between the end + + domains. However, the generalization to the whole Internet + + may lead to considerable error. + + 3) Model-based approaches: researchers model parts of the + + Internet based on network design principles and then apply + + vendor-provided energy consumption of each device in that + + part of the Internet to their model to determine the total energy + + consumption of that part. In one of the earliest studies in this + + area, Baliga et al. [39] propose a model for core routers’ and + + WDM links’ energy consumption as a function of the number + + of Internet subscribers and their access rate. In their later + + work [40] they propose models for the energy consumption of + + core, metro/edge, and access networks. V ishwanath et al. [41] + + propose a model for power consumption of high-capacity + + switches and routers in metro and edge networks taking both + + idle and dynamic power into account, and verify their model + + with direct measurements. In another work [42], they predict + + the future trends in the power consumption of different parts + + of the Internet with and without considering the improvement + + in devices’ energy efficiencies. + + In the context of next-generation Internet architectures, Lee + + et al. [43] estimate the power consumption of Content-Centric + + Networking (CCN). Chen et al. [44] compare power consump- + + tion of SCION with Named Data Networking (NDN [45]), + + but they only analyze SCION’s impact on the dynamic power + + consumption of core routers’ forwarding engine, ignoring the + + impact of SCION on idle power consumption, on other parts + + of a core router, and on other network components. + + VII. C O N C L U S I O N A N D FU T U R E WO R K + + In this work, we propose a method to analyze the power + + consumption of the SCION next-generation Internet architec- + + ture’s data plane and its QoS extension based on the models + + for the power consumption of communication networks. A + + major advantage of this method is its generality that makes it + + applicable to different power consumption models of different + + parts of the communication networks. + + However, the accuracy of the final results derived by the + + proposed method depends on the accuracy of the underlying + + power consumption models. T o the best of our knowledge, + + the power consumption models we use are the currently latest + + and most reliable. Nonetheless, not all changes in the Internet + + infrastructure in recent years are reflected, which could have + + an impact on the power consumption models of the Internet. In + + particular, two changes should be considered in future work: + + • the transition from the conventional hierarchy of the + + Internet in which most of the Internet traffic used to + + carried by carrier ISPs towards a more flat model due + + to the deployment of edge computing, direct peerings at + + IXPs, and intra- and inter-datacenter communications, + + • the deployment of multi-protocol label switching (MPLS) + + in core networks, which reduces their power consumption + + considerably as the longest-prefix matching is only per- + + formed once per ISP at the (core) border router and all + + other (core) routers within the ISP only perform label + + matching which is more energy efficient than longest- + + prefix matching. The available models do not differentiate + + between IP and MPLS core routers for modeling their + + power consumption. + + As the Internet continues to evolve, it is clear that the power + + consumption models of the Internet require continuous up- + + dates. Nevertheless, our analysis based on the method we pro- + + pose and using the best available power consumption models, + + indicates that a secure Internet architecture like SCION could + + reduce the power consumption of the Internet while providing + + strong security guarantees. Interestingly , our analysis suggests + + that a QoS extension can decrease the power consumption of + + an Internet architecture. Our results indicate SCION with its + + QoS extension can decrease the power consumption of the + + Internet (excluding data centers) by up to 9.4%. + + These results open up exciting research directions to study + + next-generation architectures’ energy consumption. An open + + problem in this context is the question of how to construct + + an Internet architecture to minimize power consumption. W e + + hope that this paper provides an early indication about the + + energy reduction potential of architectural mechanisms, and + + encourages further research on this important topic. + + VIII. A C K N OW L E D G M E N T S + + W e are grateful to Daniel Bertolo, Claude H ¨ahni, Fabian + + Mauchle, and Dave Oran for stimulating discussions and + + inputs on the power consumption of network devices. W e + + gratefully acknowledge support from ETH Zurich, and from + + the Zurich Information Security and Privacy Center (ZISC). + + RE F E R E N C E S + + [1] A. Andrae, “New perspectives on internet electricity use in 2030, ” + + Engineering and Applied Science Letters , vol. 3, pp. 19–31, 06 2020. + + [2] International Energy Agency (IEA). (2020) Data and Statistics. [Online]. + + A vailable: https://perma.cc/72QW - 26D9 + + [3] A. Andrae, L. Hu, L. Liu, J. Spear, and K. Rubel, “Delivering T angible + + Carbon Emission and Cost Reduction through the ICT Supply Chain, ” + + International Journal of Green T echnology, vol. 3, pp. 1–10, Nov 2017. + + [4] A. Andrae, “Projecting the Chiaroscuro of the Electricity Use of + + Communication and Computing from 2018 to 2030, ” Feb 2019. + + [5] J. Lorincz, A. Capone, and J. Wu, “Greener, Energy-Efficient and + + Sustainable Networks: State-Of-The-Art and New Trends, ” Sensors, + + vol. 19, p. 4864, Nov 2019. + + [6] A. Andrae and T . Edler, “On Global Electricity Usage of Communication + + T echnology: Trends to 2030, ” Challenges, vol. 6, no. 1, pp. 117–157, + + 2015. [Online]. A vailable: https://www .mdpi.com/2078- 1547/6/1/117 + + [7] J. Baliga, R. A yre, K. Hinton, W . V . Sorin, and R. S. Tucker, “Energy + + consumption in optical ip networks, ” Journal of Lightwave T echnology , + + vol. 27, no. 13, pp. 2391–2403, 2009. + + [8] H. Pihkola, M. Hongisto, O. Apilo, and M. Lasanen, “Evaluating + + the Energy Consumption of Mobile Data Transfer—From T echnology + + Development to Consumer Behaviour and Life Cycle Thinking, ”Sus- + + tainability, vol. 10, p. 2494, 07 2018. + + [9] K. Hinton, J. Baliga, M. Feng, R. A yre, and R. S. Tucker, “Power + + consumption and energy efficiency in the Internet, ” IEEE Network , + + vol. 25, no. 2, pp. 6–12, 2011. + + ' + - 'Master''s thesis excerpt proposing a probe agent service within each AS for loss + estimation in SCION. Details how probes interact with agents in each AS to retrieve + expected loss rates, bypassing performance limitations of individual routers, + for a SCION path. Illustrates the concept with diagrams showing probe propagation + and agent responses. + + Pascal Marc Suter. *Traffic Engineering in SCION: The impact of end + host QoS mechanisms on network performance*. Master''s thesis, ETH Zurich, 2023. + + + research paper + + 20 + + + + 3.3. Loss estimation + + Figure 3.2: Example topology with 4 ASes for illustrations. + + using the application’s actual data as the probing traffic, which would also + + mean no additional traffic is created. But that would make the connection + + unstable during that time as all the paths are tried out. Overall, estimating + + the packet loss by the host alone is infeasible. + + To get the expected loss rates without needing large amount of traffic is by + + getting the actual loss rates from the routers. This does require support + + from the routers in the AS. A probe would contain the amount of traffic + + the application plans to send and when it passes through a link, the router + + would generate a response with the expected loss if that additional traffic + + is sent. However, as routers are very performance optimized, this would + + create a significant overhead. Instead, there could be an agent in each AS + + which handles the responding to probes. The AS knows which internal links + + will be taken and can track or estimate the throughput and loss on its links. + + Some related works have looked at how the gathering of such information + + could be implemented, see section 2.1. + + The simplest form of this agent would be a server that gets data about the + + link states for the AS and then handles the loss computation and responses + + to the probes. When talking about the probe agent, it is meant to include all + + the infrastructure to provide this service, including the implementation of + + AS for the probe agent to get the link states, which is also important when + + considering the costs. It is most likely that a different infrastructure would + + be preferred by the ASes in terms of costs, resilience, load balancing, etc. + + This thesis does not focus on how such a service would be best implemented, + + but what this service can provide for hosts, how they can benefit from it, and + + what the impact on the resulting traffic will be. + + Consider the topology shown in Figure 3.2 with the corresponding internal + + topology of AS1 as shown in Figure 3.3. Now, assume a host in AS0 wants + + to estimate the loss for the lower path passing through AS1 to AS3. The case + + where only latency probing is used is depicted in Figure 3.4. The latency + + probe traverses the path normally and its response will be used to estimate + + the latency. The case with both latency and loss probing in is depicted + + in Figure 3.5. Additionally to the latency probe, one probe is sent to the + + probe agent in each AS, which returns the expected loss between arriving + + at that AS’ border router and arriving at the next AS. In this example, the + + 13 + + ' pipeline_tag: sentence-similarity library_name: sentence-transformers metrics: @@ -133,49 +2554,49 @@ model-index: type: val-ir-eval metrics: - type: cosine_accuracy@1 - value: 0.725 + value: 0.7857142857142857 name: Cosine Accuracy@1 - type: cosine_accuracy@3 - value: 0.9 + value: 0.9285714285714286 name: Cosine Accuracy@3 - type: cosine_accuracy@5 - value: 0.925 + value: 0.9523809523809523 name: Cosine Accuracy@5 - type: cosine_accuracy@10 - value: 0.95 + value: 0.9761904761904762 name: Cosine Accuracy@10 - type: cosine_precision@1 - value: 0.725 + value: 0.7857142857142857 name: Cosine Precision@1 - type: cosine_precision@3 - value: 0.3 + value: 0.30952380952380953 name: Cosine Precision@3 - type: cosine_precision@5 - value: 0.185 + value: 0.19047619047619047 name: Cosine Precision@5 - type: cosine_precision@10 - value: 0.095 + value: 0.0976190476190476 name: Cosine Precision@10 - type: cosine_recall@1 - value: 0.725 + value: 0.7857142857142857 name: Cosine Recall@1 - type: cosine_recall@3 - value: 0.9 + value: 0.9285714285714286 name: Cosine Recall@3 - type: cosine_recall@5 - value: 0.925 + value: 0.9523809523809523 name: Cosine Recall@5 - type: cosine_recall@10 - value: 0.95 + value: 0.9761904761904762 name: Cosine Recall@10 - type: cosine_ndcg@10 - value: 0.8485383128259677 + value: 0.8929838072814293 name: Cosine Ndcg@10 - type: cosine_mrr@10 - value: 0.8145833333333334 + value: 0.8654761904761905 name: Cosine Mrr@10 - type: cosine_map@100 - value: 0.8169407894736842 + value: 0.866326530612245 name: Cosine Map@100 --- @@ -229,9 +2650,9 @@ from sentence_transformers import SentenceTransformer model = SentenceTransformer("tjohn327/scion-snowflake-arctic-embed-s-v2") # Run inference sentences = [ - 'What observations supported that, had a path switch occurred when the penalty was issued, the high bitrate video quality degradation could have been avoided? , Why is expected to see QoE degradation the high bitrate video when bandwidth is limited to 1 Mb/s?', - 'Master\'s thesis "Leveraging Application Layer Path-Awareness with SCION" displaying results (figure 6.8) of high bitrate video transmission with restricted bandwidth, showing QoE degradation (freezes, resolution drops). Discusses correlation between bitrate, bandwidth limits, and the timing of potential path penalties.', - 'Master\'s thesis "Leveraging Application Layer Path-Awareness with SCION" abstract. Introduces path-awareness in SCION and its potential to improve networking. Presents the concept of "path processor" for application-layer path selection strategies. Describes a SCION application library and a path-aware video calling app (iOS/macOS) using call-specific metrics and redundant transmission. Mentions experiments confirming positive impacts on Quality of Experience (QoE).', + 'How does multipath communication in SCION compare to protocols like multipath TCP and QUIC?', + 'Research paper comparing BGP and SCION, highlighting differences in hierarchy, security, and routing mechanisms. Contrasts BGP\'s path-vector approach with SCION\'s path-aware, packet-carried forwarding state. Emphasizes SCION\'s multipath capabilities and embedded cryptography.\n Dennis Eijkel. "Anycast in the SCION Internet Architecture." 2022. \n research paper \n 16 \n\n2.3 Comparison between BGP and SCION\nSince SCION is a clean-slate design, there are many differences between SCION and BGP. This\nsection will elaborate on some of those differences.\nSCION has a clear hierarchy and isolation in the isolation domains. Each ISD has a config-\nuration which is managed by the group of core ASes in that ISD. These core ASes thus have a\nmanagerial task within the ISD which regular ASes do not have. BGP in theory does not have\nsuch a clear hierarchy. However, it is common in BGP for ASes to be customers to higher tier\nISPs, where the only connectivity that the customer ASes have to the internet is through that\nISP. So where BGP has hierarchy to some extent, it is not as clear as the ISDs in SCION.\nThe isolation principle in SCION plays a big part in the security benefits it has over BGP.\nIn SCION, an address is made up by the tuple (ISD, AS, address) where the first two parts\nidentify the ISD and AS inside that ISD. The information in the beaconing process is signed\nby keys that are part of a public key infrastructure (PKI), with a root key that is managed\nby the core ASes of the ISD. The fact that cryptographic authentication and verification are\nan integral part of SCION makes it resilient to attempts by malicious actors to interfere with\nthe beaconing process. Plain BGP does not have this level of security, thus allowing for route\nhijacking. Extensions such as RPKI [2] and BGPSec [3] could alleviate most of these problems,\nbut require every AS operator to run them.\nThe SCION authors refer to SCION as being path aware networking and having a packet-\ncarried forwarding state. SCION also has some resemblance to source routing, and link-state\nrouting. In source routing protocols, senders have to specify the path that the packet travels\nthrough the network in the packet header. In SCION this is partially the case, the sender specifies\nthe path that a SCION packet travels over. However, the client does not need knowledge of the\nentire topology of the internet, which would be the case in pure source routing. Link-state\nrouting is a class of protocols where routers disseminate information about the connections that\nthey have with other routers. Each router can then build a network topology graph and routing\ntable based on that information. During the beaconing phase of SCION, the beaconing servers\nshare this type of information with neighboring networks.\nIn contrast, BGP is a path-vector routing algorithm as mentioned before. Border routers\nspeaking BGP regularly exchange information about their routing tables with each other: which\nIP prefixes they can reach and what the path is that packets destined to an address in that prefix\nwould (most likely) take. When a border router receives a packet to forward, it will perform a\nlookup in its routing table and determine where the packet should go next.\nIn SCION, end hosts construct end-to-end paths through a graph that they construct from\nthe path segments that they receive from their path lookup query. Therefore end hosts can\nconstruct disjoint end-to-end paths. Using these disjoint paths allows for improved resilience\nagainst path failures. There exist protocols in the current internet, such as multipath TCP [10]\nand QUIC [11], that can do some limited form of multipath communication. But those are\ngenerally limited to the first hop, after which there is no way to guarantee that the end-to-end\npaths are disjoint. End hosts in a BGP-based internet can not dictate the path that individual\npackets must take, whereas end hosts in SCION can. Multipath TCP and QUIC therefore can\nnot provide multipath routing to the extent that SCION can, which can construct completely\ndisjoint paths if the topology allows that.\n2.4 Anycast\nThe basic concept behind anycast, as described in RFC 1546 [6], is that there can be an internet\nservice replicated over multiple different (geographical) locations. All of these replicas would\n15\n', + "Master's thesis excerpt proposing a probe agent service within each AS for loss estimation in SCION. Details how probes interact with agents in each AS to retrieve expected loss rates, bypassing performance limitations of individual routers, for a SCION path. Illustrates the concept with diagrams showing probe propagation and agent responses.\n Pascal Marc Suter. *Traffic Engineering in SCION: The impact of end host QoS mechanisms on network performance*. Master's thesis, ETH Zurich, 2023. \n research paper \n 20 \n\n3.3. Loss estimation\nFigure 3.2: Example topology with 4 ASes for illustrations.\nusing the application’s actual data as the probing traffic, which would also\nmean no additional traffic is created. But that would make the connection\nunstable during that time as all the paths are tried out. Overall, estimating\nthe packet loss by the host alone is infeasible.\nTo get the expected loss rates without needing large amount of traffic is by\ngetting the actual loss rates from the routers. This does require support\nfrom the routers in the AS. A probe would contain the amount of traffic\nthe application plans to send and when it passes through a link, the router\nwould generate a response with the expected loss if that additional traffic\nis sent. However, as routers are very performance optimized, this would\ncreate a significant overhead. Instead, there could be an agent in each AS\nwhich handles the responding to probes. The AS knows which internal links\nwill be taken and can track or estimate the throughput and loss on its links.\nSome related works have looked at how the gathering of such information\ncould be implemented, see section 2.1.\nThe simplest form of this agent would be a server that gets data about the\nlink states for the AS and then handles the loss computation and responses\nto the probes. When talking about the probe agent, it is meant to include all\nthe infrastructure to provide this service, including the implementation of\nAS for the probe agent to get the link states, which is also important when\nconsidering the costs. It is most likely that a different infrastructure would\nbe preferred by the ASes in terms of costs, resilience, load balancing, etc.\nThis thesis does not focus on how such a service would be best implemented,\nbut what this service can provide for hosts, how they can benefit from it, and\nwhat the impact on the resulting traffic will be.\nConsider the topology shown in Figure 3.2 with the corresponding internal\ntopology of AS1 as shown in Figure 3.3. Now, assume a host in AS0 wants\nto estimate the loss for the lower path passing through AS1 to AS3. The case\nwhere only latency probing is used is depicted in Figure 3.4. The latency\nprobe traverses the path normally and its response will be used to estimate\nthe latency. The case with both latency and loss probing in is depicted\nin Figure 3.5. Additionally to the latency probe, one probe is sent to the\nprobe agent in each AS, which returns the expected loss between arriving\nat that AS’ border router and arriving at the next AS. In this example, the\n13\n", ] embeddings = model.encode(sentences) print(embeddings.shape) @@ -276,23 +2697,23 @@ You can finetune this model on your own dataset. * Dataset: `val-ir-eval` * Evaluated with [InformationRetrievalEvaluator](https://sbert.net/docs/package_reference/sentence_transformer/evaluation.html#sentence_transformers.evaluation.InformationRetrievalEvaluator) -| Metric | Value | -|:--------------------|:-----------| -| cosine_accuracy@1 | 0.725 | -| cosine_accuracy@3 | 0.9 | -| cosine_accuracy@5 | 0.925 | -| cosine_accuracy@10 | 0.95 | -| cosine_precision@1 | 0.725 | -| cosine_precision@3 | 0.3 | -| cosine_precision@5 | 0.185 | -| cosine_precision@10 | 0.095 | -| cosine_recall@1 | 0.725 | -| cosine_recall@3 | 0.9 | -| cosine_recall@5 | 0.925 | -| cosine_recall@10 | 0.95 | -| **cosine_ndcg@10** | **0.8485** | -| cosine_mrr@10 | 0.8146 | -| cosine_map@100 | 0.8169 | +| Metric | Value | +|:--------------------|:----------| +| cosine_accuracy@1 | 0.7857 | +| cosine_accuracy@3 | 0.9286 | +| cosine_accuracy@5 | 0.9524 | +| cosine_accuracy@10 | 0.9762 | +| cosine_precision@1 | 0.7857 | +| cosine_precision@3 | 0.3095 | +| cosine_precision@5 | 0.1905 | +| cosine_precision@10 | 0.0976 | +| cosine_recall@1 | 0.7857 | +| cosine_recall@3 | 0.9286 | +| cosine_recall@5 | 0.9524 | +| cosine_recall@10 | 0.9762 | +| **cosine_ndcg@10** | **0.893** | +| cosine_mrr@10 | 0.8655 | +| cosine_map@100 | 0.8663 |