SCION can be incrementally deployed at ISPs, who can make use of SCION's features to route traffic through the backbone of the Internet. This is done by (transparently to end-users) encapsulating SCION packets inside IP packets. At the edges, encapsulation is removed and packets are routed as usual. If a SCION path exists between two or more ISPs, encapsulation is not needed.

Absolutely. In fact, packet processing in SCION requires fewer processing cycles than traditional IP routing since there are no table lookups. SCION may breathe new life into your ancient networking equipment.

Please use the SCION checker on our home page, it may be that your ISP is already offering SCION connectivity. If that is the case, you can already get started by using the network, check out our applications page. If your ISP does not yet offer SCION, you can join the network by running your own SCION AS in SCIONLab. Check out the SCIONLab code repository on Github.
We currently support three main ways to run SCION:

1. Run SCION locally using processes managed by supervisord.
2. Run a host and use the SCION network.
3. Connect your domain to the SCION network.

An ISP can offer new services to its customers, for example:

1. High availability through multi-path communication.
2. Secure paths that cannot be hijacked.
3. Client path control, ensuring that a packet will only traverse ASes that were specified in the forwarding path. This can help with communication compliance, that sensitive traffic did not leave a jurisdiction.
4. Guaranteed communication despite DDoS attacks.

We find that the early use cases will encompass corporations that want to secure a point-to-point connection (where they control both end points) with properties similar to a leased line, but without the costs and time delays associated with setting up and running a leased line. In this context, here are a few concrete use cases:

1. Highly available communication. Many aspects of SCION provide higher availability, especially when multi-path communication is used. You become immune to current BGP-level attacks, such as prefix hijacking.
2. Client path control, for example for compliance purposes. SCION can guarantee what path each packet takes; in particular, which ISPs are NOT traversed.
3. Secret paths that can only be used by selected communication partners. The cryptographic path protection enables path hiding even if an attacker knows the network topology, thus, making the path impossible to DDoS.
4. VPN link protection. A VPN link can be provided by the SCION network, providing all the properties listed above for the end-to-end VPN tunnel.

If you are in Switzerland, you can achieve the benefits of a native SCION deployment if you are a customer of an ISP such as Swisscom, Sunrise, SWITCH — in essence, you can communicate without any reliance on BGP (thus none of the BGP vulnerabilities or weaknesses can affect you!). As additional ISPs deploy SCION, these properties will become available to customers of those ISPs as well. Anapaya is the biggest solution provider for SCION, visit their website to find out more about getting your business connected to the SCION network.

By connecting to SCIERA (SCION Education, Research and Academic Network), your institute can join a growing network of universities and national research organizations, fostering international collaboration and knowledge exchange. A SCION connection for your research institute would provide access to the cutting-edge Internet architecture, enabling you to join the development of innovative applications that take advantage of SCION's unique features. The ScienceDMZ concept, when implemented with SCION, addresses the common issue of firewalls bottlenecking network throughput in research environments. By utilizing SCION's Lightning Filter, institutes can protect their networks against unauthenticated traffic while maintaining high performance. SCION's Hercules tool facilitates rapid transfer of large datasets, which is crucial for data-intensive research collaborations. This capability can dramatically reduce the time required to exchange information between research partners.

The properties that SCION achieves are weaker if some of the traffic traverses the current Internet, however, major benefits can still be achieved. As our simulations (and independent research by Peter et al. "One tunnel is (often) enough" published at SIGCOMM 2014) show, paths composed by shorter tunnels are much more resilient to BGP hijacking attacks than the longer end-to-end paths. Another major benefit is that SCION’s source-based path selection and multi-path routing enables relatively fine-grained selection of paths. For instance, for traffic from Switzerland to Australia, the sender can select paths that go eastwards via Singapore or westwards via the US. Many of the properties continue to hold, however, in weakened forms depending on the deployment density and network topology. With steadily increasing deployment density, the properties will continue to strengthen as well, further increasing deployment incentives.

The SCION protocol currently requires ports 30041 and 50000 to be open for UDP packets.

SCION runs on Debian and derivatives (x86-64, arm64, x86-32, arm), as well as MacOS and NixOS.

We're currently looking into the best way to partition the Internet into ISDs, so using countries as ISDs is only one possible option. Countries have the advantage of providing a uniform legal environment, allowing misbehavior in an ISD to be handled according to the legal framework of that ISD. As ISDs can overlap, stronger isolation properties can be achieved by letting ASes join more than one ISD.

Even in SCION, the Internet remains globally connected — entities anywhere in the world should still be able to communicate with one another using SCION. ISDs provide isolation guarantees with respect to this communication, such that if two entities in the same ISD communicate, no traffic between them will ever exit the ISD. Additionally, ISDs guarantee that their internal routing decisions for external destinations cannot affect the rest of the Internet, which would prevent an ISP in Pakistan from globally hijacking traffic to YouTube.

Source routing does not scale to the size of the Internet, because the source would need to know the entire network topology to determine paths. Source routing would not allow the receiver to control the path, nor does it enable ISPs' path control. SCION, in contrast, enables ISPs, sources, and destinations to control the end-to-end path. Sources do not need to know the network topology, they simply have the choice of several paths to combine, so sources do not compute an end-to-end path based on a topology, but they merely select from a set of given paths.

No, SCION routers do not have any per-flow state. Senders can simply place hop fields from a path in a packet header and send the packet to the destination without any required setup.

Configuration errors can affect the control plane or the data plane. In the control plane of today's Internet, a misconfiguration of BGP can result in a route hijack, and traffic not intended for the misconfigured AS takes a detour and is sent to that AS. SCION's secure routing architecture prevents such misconfigurations to be believed by other ASes, they simply reject incorrect announcements due to the absence of correct cryptographic authenticators. Another misconfiguration in today's Internet is an incorrect BGP route filter, which can result in the hijack of the internal IP address space. SCION's control plane structure also makes such misconfigurations impossible.
In the data plane of today's Internet, a misconfiguration can result in incorrect forwarding tables. In SCION, ASes require correct hop fields to forward traffic, which contain a cryptographic token that each AS verifies. So without the correct hop fields, a packet cannot traverse the network and is dropped when it enters the network. Since both the ingress point into the ISP and the egress point out are contained in the hop field and are verified, packets can by design not be forwarded along an incorrect path.

ASes in SCION can decide which links they want to announce to which downstream customers. However, SCION does provide more information about connectivity of an AS than BGP is currently exposing. Nothing about an AS's internal connectivity is revealed in SCION; and even in today's Internet, analysis of BGP messages over a time period reveals how an AS is connected to its neighbors.

Indeed, there is an RTT delay for each lost packet, but the SCION socket will quickly determine a failed path and re-direct traffic to working paths.

A customer of a SCION-supporting ISP would not need a public IP address, as it can communicate with other SCION ASes via SCION paths. At the current stage of SCION deployment, however, an AS without a SCION-supporting provider ISP, needs to have a public IP address in order to connect to other SCION ASes using the current Internet as an underlay network.

Yes.

SCION is used for inter-domain communication. For intra-domain routing, each domain can use any protocol, such as OSPF, SDN, or MPLS-based forwarding. SCION's hop fields may resemble MPLS tags, but they have authentication and integrity protection.

Most current work in SDN is primarily applicable to intra-domain communication, while SCION is primarily concerned with improving inter-domain communication, with minimal changes to the network within each domain. SCION can make use of SDN to provide intra-domain communication, thus, the two approaches complement each other.
While some emerging SDN projects attempt to provide inter-domain properties within the existing Internet architecture, such as explicit multi-path support, they lack most of the security and scalability properties offered by SCION.

Amongst the many differences, we list some of the main ones. First, ATM faces inherent scalability problems due to fundamental design decisions. Forwarding and label rewriting can lead to per-channel state at ATM switches. The ATM cell headers can identify up to 2^24 channels at an ingress switch (the UNI interface) and up to 2^28 channels at a core switch (the NNI interface). Increasing the length of the corresponding header fields would enable support for more channels, but does not address the root of the problem: per-channel state is not a scalable solution, especially for core switches. Furthermore, enabling multi-path communication would further harm scalability, since one pair of hosts would set up multiple virtual channels. In SCION, the required forwarding state is embedded into packets, which practically makes switches stateless for forwarding. This design decision makes SCION extremely scalable with respect to the end-point population. Furthermore, ATM’s design decision of having short cells (instead of larger packets) in order to support real-time voice traffic is obsolete in modern networks; full-length 1500-byte packets do not incur significant processing delays in practice.
Second, ATM was not designed with security in mind, which raises multiple problems in an inter-domain deployment scenario. Quality of Service (QoS), which is one of the most attractive properties of ATM, cannot be guaranteed in an inter-domain environment where a channel traverses multiple domains with conflicting interests. For example, channel setup signals could be modified en route without being detected. Furthermore, a host has no control over the selected path and cannot avoid potentially malicious domains. However, the lack of (enforceable) path control is a missing property from other architectures as well, e.g., IP. SCION treats security as an integral network design principle, offering strong security guarantees such as enforceable path control.

No, SCION makes it strictly harder for a government to censor networks. We are not aware of an attack that a government could perform on SCION that could not be performed on today's Internet. On the other hand, many attacks that are possible in today's Internet, do not work in SCION, for example route hijacking attacks — a SCION path cannot be diverted due to the separation of control and data planes.

In SCION, ISPs control what paths they offer to their clients. Moreover, ISPs can still control what amount of bandwidth they let flow over a given link. With such bandwidth control, they can steer the traffic and clients will automagically be diverted toward paths with more bandwidth. Especially with SIBRA, the ISP has fine-grained and explicit control over how much bandwidth is provided on each link.