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 SCIONLab code repository on Github. We currently support three main ways to run SCION:
What are the benefits for an ISP to deploy SCION?
An ISP can offer new services to its customers, for example:
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:
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 18.04.
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.
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.