Guaranteed communication despite DDoS attacks – Scion

Frequently Asked Questions (FAQ)

How to Deploy SCION

Does the entire world need to switch to SCION at the same time, or can SCION be incrementally deployed?

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.

Can SCION run on existing network hardware?

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.

I’d like to download and use SCION, what can I do?

SCION is open source, please check the SCION code repository on Github . We currently support three main ways to run SCION:

1. Run local, either with Mininet or with processes.
2. Run a host and use the SCION network.
3. Connect your domain to the SCION network.

What are the benefits for an ISP to deploy SCION?

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.

My company would like to try out SCION. What are some of the use cases for which it is useful and how can we get started to try them out?

In the initial stages of SCION deployment, 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 Swisscom or 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.

What properties can SCION offer if some of its links connecting deploying ISPs are over the traditional Internet?

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.

Which ports does SCION run on?

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

What is the operating system that SCION runs on?

SCION currently runs on Ubuntu 16.04.

How SCION Works

Do you use countries as ISDs? Doesn't that create opportunities for government intervention and censorship?

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.

Why partition the Internet into ISDs at all? Shouldn't the Internet be a globally-connected entity?

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 .

Is SCION a source-routed architecture?

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.

Does SCION need flow state to be set up on intermediate routers before communication can occur?

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.

How is SCION overcoming configuration errors? Is this simply an artifact of the isolation property (one AS's errors don't impact others) or the reduction in configuration complexity?

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.

SCION's PCBs reveal information about how ASes are willing to route traffic (or some fraction of that information since only a subset of all paths are shared at a given time). Are ASes willing to share such information broadly?

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.

How is multi-path concealing link failures from applications? A loss of some packets on some path will still introduce delays and retransmissions. ▾

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.

Does SCION require public IP addresses?

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.

Does SCION work for hosts behind NATs?

Yes.

How is SCION different from OSPF, SDN, or MPLS?

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.

How is SCION really different from SDN?

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.

How is SCION different from Asynchronous Transfer Mode (ATM)?

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.

Miscellaneous

Does SCION make it easier to censor the Internet?

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.

Would ISPs be happy with letting clients control their communication paths?

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.