IP-in-SCION Tunneling: Basics
Time estimate: 50 minutes
IP-in-SCION tunneling is a mechanism that allows to tunnel IP packets between two IP-in-SCION
tunneling endpoints. This mechanism enables any type of application and IP based communication to
take advantage of SCION-based networking without the need to update any application, client, or
server. With the configuration of the scion_tunneling section you can define what IP prefixes are
advertised to and accepted from remote peers.
Unless stated otherwise, all commands are assumed to be run from the
workspace directory on your training VM. The built-in terminal in
the editor will put you automatically in the right
directory. To open the built-in terminal use the Ctrl+` shortcut.
Alternatively, you can click the Menu button in the top left, then
select View -> Show Terminal . This will bring up the terminal and puts
you in the correct working directory (~/workspace) for all the tasks in
this training.
Task 1. Download the SCION appliance configuration
Start with downloading the SCION appliance configurations for the Corpbank and Stabank AS so that we can inspect and modify them.
Download the current SCION appliance configurations:
operator@training:~/workspace$ appliance-cli context select edge.zurich.corpbank
operator@training:~/workspace$ appliance-cli get config > edge.zurich.corpbank.appliance.json
operator@training:~/workspace$ appliance-cli context select edge.geneva.corpbank
operator@training:~/workspace$ appliance-cli get config > edge.geneva.corpbank.appliance.json
operator@training:~/workspace$ appliance-cli context select edge.lugano.stabank
operator@training:~/workspace$ appliance-cli get config > edge.lugano.stabank.appliance.json
After modifying the configurations, you can push them back to the appliances by running the following commands:
operator@training:~/workspace$ appliance-cli context select APPLIANCE_NAME
operator@training:~/workspace$ appliance-cli put config <APPLIANCE_NAME.appliance.json
It's important to keep the < in the command, for example:
operator@training:~/workspace$ appliance-cli put config <edge.zurich.corpbank.appliance.json
Keep a copy of the configuration files so that you can easily roll back the changes made in the course of this exercise:
operator@training:~/workspace$ cp edge.zurich.corpbank.appliance.json edge.zurich.corpbank.appliance.json.backup
operator@training:~/workspace$ cp edge.geneva.corpbank.appliance.json edge.geneva.corpbank.appliance.json.backup
operator@training:~/workspace$ cp edge.lugano.stabank.appliance.json edge.lugano.stabank.appliance.json.backup
Task 2. Inspect the SCION tunneling configuration
Open the downloaded edge.zurich.corpbank.appliance.json file and look for the scion_tunneling
section.
Solution
The scion_tunneling configuration consists of seven sections.
Domains
The most important subsection of scion_tunneling is domains. It describes routing domains
that are the primary mechanism to configure the SCION paths used when communicating with remote IP
destinations. Conceptually, a routing domain is defined by a set of IP prefixes to which a common
set of traffic policies should be applied.
A routing domain can be further restricted with a set of acceptable remote SCION ASes. This is useful when a domain should only include remote ASes of a specific ISD or a specific set of remote ASes.
Furthermore, a domain also includes the ability to limit the IP prefixes that are announced by the local Anapaya EDGE appliance to remote IP-in-SCION tunneling endpoints.
Finally, a domain defines traffic policies that allow users to influence and control the path selection process of the Anapaya EDGE appliance. For example, an operator can define policies to keep traffic within a certain jurisdiction or avoid specific network providers. A traffic policy references path filters to specify the set of SCION paths that should be considered for the path selection (defined in Path Filters). Each path filter defines a subset of all available SCION paths.
Path filters are combined into a failover sequence to define the order in which the path filters are considered. The path filters in a failover sequence are applied separately to the set of possible paths until one of them returns a non-empty path set.
Finally, each traffic policy references a traffic matcher that defines the set of IP packets for which the failover sequence should be applied (defined in Traffic Matchers).
The configuration for the Corpbank EDGE in Zurich contains a single domain stabank:
The stabank domain restricts the set of prefixes announced to Stabank to 10.2.0.0/24 and only
accepts the 10.8.0.0/24 prefix from Stabank. The set of paths towards Stabank is not restricted.
All IP traffic for Stabank is routed over all available paths.
Besides the unique name each domain is configured with four fields:
Remote ISD-ASes
The remote_isd_ases section contains a list of SCION AS matchers that - together with an action
(ACCEPT or REJECT) - define the set of SCION ASes that are part of the domain. This has the
effect that IP prefix announcements will be accepted from these remote ASes and all IP traffic will
be tunneled over paths that end in one of these remote ASes.
A SCION AS matcher has the form <isd>-<as> where <isd> is the ISD ID and <as> is the AS ID.
Both <isd> and <as> can be 0 to match all ISDs and all ASes respectively. E.g., the matcher
1-ff00:0:1 matches exactly one single AS, 1-0 matches all ASes that are part of ISD 1, and
0-ff00:0:1 matches the specific AS in all ISDs. A single 0 (or 0-0) matches all ASes in all
ISDs.
The matchers are applied to the complete list of remote ASes defined in the
scion_tunneling.remotes subsection (Remotes).
In our case the remote_isd_ases subsection contains only one matcher that matches exactly
1-ff00:1:3, the ISD-AS number of the Stabank AS.
Prefixes
The prefixes section of the domain configuration defines the set of IP prefixes that are
accepted and announced by the local endpoint. To define these sets the accept_filter and
announce_filter subsections are used. Each filter is a list of IP prefix matchers combined with an
action. The action is either ACCEPT or REJECT to implement allow- and block lists.
The accept and announce filters are what the name implies - filters. They define the complete set of prefixes that can be accepted/announced. The effective set of IP prefixes depends on the network state (prefixes learned from the remote ASes, locally learned prefixes, and statically configured prefixes). The effective set of accepted prefixes is created by applying the accept filter on the prefixes that are learned from the remote ASes. The effective set of announced IP prefixes is created by applying the announce filter on the local IP prefixes that are either statically configured or learned via an internal routing protocol, e.g., BGP.
In the configuration of the Corpbank edge in Zurich only the 10.8.0.0/24 prefix is accepted. The
announcements to the Stabank (i.e. the remotes in the domain) are restricted to the 10.2.0.0/24
prefix.
A domain can be labeled as default with default: true. This means that it is used when no other
domain matches a packet's destination, i.e., the default domain implicitly accepts the entire IP
space that is not covered by other domains. If a domain is configured as default no accept filter
needs to be specified.
Traffic Policies
Traffic policies define how traffic is routed within a domain. A traffic policy contains a traffic matcher that defines the set of IP packets to which the policy applies and a set of path filters (grouped into a failover sequence) that defines what paths are allowed to be used by the matched packets.
In our case there is only one traffic policy. It uses the match-all-traffic-matcher that is
defined in Traffic Matchers and matches all IP packets. The failover sequence
contains a single path filter allow-all-path-filter that accepts all paths. The path filter is
defined in Path Filters.
Endpoint
The local endpoint configuration defines the local IP-in-SCION tunneling endpoint. The local
endpoint configuration contains the local network ip address on which IP packets that should
be encapsulated are received. In addition to that a set of ports for data, control, and probing
purposes is configured.
However, these ports do not need to be set explicitly as the Anapaya EDGE appliance will
automatically fill them in if left empty. For the ip both, IPv4 and IPv6 addresses can be
configured. Finally the enabled field can be used to enable and disable the tunneling endpoint.
Remotes
Remote IP-in-SCION tunneling endpoints are automatically discovered within their respective SCION
AS. However, the set of remote ASes which should be considered for remote endpoint discovery needs
to be statically provided. The remotes section contains a list of all remote SCION ASes towards
which the local endpoint should establish IP-in-SCION tunnels.
In the case of the Corpbank EDGE in Zurich only the Stabank AS is configured:
Path Filters
A path filter defines a set of paths by applying the filter to all available paths. The filter is identified by a unique name and can contain an Access Control List (ACL) and a hop pattern both of which operate on hop predicates.
A hop predicate defines a hop of a SCION path and has the form <isd>-<as>#<interface>, where
<isd> is the SCION ISD identifier, <as> is the SCION AS identifier, and <interface> is the
interface identifier of a SCION path hop, i.e., the SCION link in the given SCION AS. The hop
predicate can be fully or partially qualified, i.e., all entries of the hop predicate are optional
or can include wildcards (0). A single 0 matches every SCION path hop.
An ACL consists of a list of ACL entries. Each ACL entry has the form <action> <hop-predicate>,
where the action can either be accept (+) or deny (-). The hop predicate is optional. If no hop
predicate is specified, the action matches every hop, i.e., a single + is the default accept
action and a single - is the default deny action. The ACL is applied by sequentially applying
all ACL entries to paths. If the ACL is empty, it defaults to accepting all paths.
A hop pattern defines a sequence of hop predicates that a path has to match to be accepted. It
can be thought of as a regular expression on SCION paths. Each hop predicate can optionally be
extended with a modifier * or +. The * modifier means 0 or more occurrences. The + means one
or more occurrences.
The config for the Corpbank EDGE in Zurich only specifies an ACL with just one entry. The entry is
the default accept action and thus the allow-all path filter accepts all paths.
The path filter is referenced in the failover sequence of the stabank domain's traffic policy in
Traffic Policies
Traffic Matchers
Traffic matchers specified in the traffic_matchers section are used to choose which traffic policy
is used to route IP traffic. Each traffic policy in a domain (Traffic Policies)
references a traffic matcher by name. The configuration for the Zurich EDGE defines the
match-all-traffic-matcher traffic matcher that matches all IP traffic.
The condition of the traffic matcher describes which IP packets are matched. In our case the
condition is just the boolean constant true and therefore matches all IP packets. The full
syntax for the traffic matcher's condition is explained in the
IP-in-SCION tunneling documentation
Static Announcements
The static_announcements section defines the prefixes to be distributed to remote SCION ASes.
Note that the prefix must also match the announce-filter to get distributed remote ASes.
While it might appear that there is duplication between the static announcements and the announce
filter, they both are required as they serve different purposes. You can define a set of static
prefixes in the static_announcements section but then selectively decide which ones to distribute
to particular remote ASes in the announce_filter section. Also note that the announce_filter
section applies to any outgoing prefixes, including non-static prefixes, e.g., prefixes learned
locally via BGP.
Optional next hop tracking is a simple mechanism to retract prefixes from being advertised if the network is not accessible. This allows for some level of dynamic behavior without having to use a proper dynamic routing protocol such as BGP.
With next hop tracking configured, the Anapaya EDGE appliance monitors an IP address and retracts
the associated prefixes (10.2.0.3/32) if the address (10.2.0.3) stops responding to pings.
Task 3. Check the runtime state of Prefix Announcements
The current status of network prefixes announced by the local SCION ASes and prefixes learned from the remote SCION ASes are exposed by the Anapaya EDGE appliance.
Inspect the current state of the gateway process. Note that the gateway is the process that
configures and processes everything related to IP-in-SCION tunneling. The appliance-cli tool can
be used to display various diagnostics.
operator@training:~/workspace$ appliance-cli context select edge.zurich.corpbank
operator@training:~/workspace$ appliance-cli get debug/scion-tunneling/sgrp/peers
{
peers: [
{
announced: ["10.2.0.3/32"]
last-received: "2023-03-14T15:47:32Z"
local-isd-as: "1-ff00:1:2"
received: ["10.8.0.2/32", "10.8.0.5/32"]
remote-address: "10.8.0.1:30256"
remote-isd-as: "1-ff00:1:3"
}
]
}
operator@training:~/workspace$ appliance-cli get debug/scion-tunneling/sgrp/local-prefixes
{
local-prefixes: {
bgp: {
prefixes: null
}
static: {
prefixes: null
}
static-probed: [
{
last-success: "2023-03-14T15:51:48Z"
next-hop: "10.2.0.3"
prefixes: ["10.2.0.3/32"]
reachable: true
}
]
}
}
The process of announcing locally owned IP prefixes to remotes and receiving their announcements is
implemented using a protocol called SCION Gateway Routing Protocol (SGRP). This is why the
endpoint is part of the sgrp section.
We can see that the prefix 10.2.0.3/32 is being advertised and the prefix 10.8.0.2/32 was
learned from a remote AS.
We also see that the next hop 10.2.0.3 (recall that next hop tracking was switched on in the
configuration file) is responding to pings.
Now inspect the prefixes that are being advertised and learned in the Stabank AS.
Solution
operator@training:~/workspace$ appliance-cli context select edge.lugano.stabank
operator@training:~/workspace$ appliance-cli get debug/scion-tunneling/sgrp/peers
{
peers: [
{
announced: ["10.8.0.2/32", "10.8.0.5/32"]
last-received: "2023-03-14T15:52:42Z"
local-isd-as: "1-ff00:1:3"
received: ["10.2.0.3/32"]
remote-address: "10.2.0.1:30256"
remote-isd-as: "1-ff00:1:2"
}
{
announced: ["10.8.0.2/32", "10.8.0.5/32"]
last-received: "2023-03-14T15:52:42Z"
local-isd-as: "1-ff00:1:3"
received: ["10.2.0.3/32"]
remote-address: "10.2.0.2:30256"
remote-isd-as: "1-ff00:1:2"
}
]
}
Task 4. Stop advertising a prefix
Modify the IP-in-SCION tunneling configuration such that Corpbank stops advertising the prefix
10.2.0.3/32 to Stabank.
Solution
Delete the announce_filter rule from edge.zurich.corpbank.appliance.json and edge.geneva.corpbank.appliance.json.
{
"announce_filter": []
}
Alternatively, delete the corresponding static_announcements rule. However, note that this will
stop the prefix from being advertised to any remote AS.
{
"static_announcements": []
}
Push the configuration
operator@training:~/workspace$ appliance-cli context select edge.zurich.corpbank
operator@training:~/workspace$ appliance-cli put config <edge.zurich.corpbank.appliance.json
operator@training:~/workspace$ appliance-cli context select edge.geneva.corpbank
operator@training:~/workspace$ appliance-cli put config <edge.geneva.corpbank.appliance.json
Log into the only host of the Stabank AS and make sure that the prefix is no longer learned.
Solution
The list of received prefixes is empty.
operator@training:~/workspace$ appliance-cli context select edge.lugano.stabank
operator@training:~/workspace$ appliance-cli get debug/scion-tunneling/sgrp/peers
{
peers: [
{
announced: ["10.8.0.2/32", "10.8.0.5/32"]
last-received: "2023-03-14T15:54:42Z"
local-isd-as: "1-ff00:1:3"
received: ["10.2.0.3/32"]
remote-address: "10.2.0.1:30256"
remote-isd-as: "1-ff00:1:2"
}
{
announced: ["10.8.0.2/32", "10.8.0.5/32"]
last-received: "2023-03-14T15:54:42Z"
local-isd-as: "1-ff00:1:3"
received: null
remote-address: "10.2.0.2:30256"
remote-isd-as: "1-ff00:1:2"
}
]
}
Task 5. Stop accepting a prefix
Return Corpbank into the previous state.
cp edge.zurich.corpbank.appliance.json.backup edge.zurich.corpbank.appliance.json
operator@training:~/workspace$ appliance-cli context select edge.zurich.corpbank
operator@training:~/workspace$ appliance-cli put config <edge.zurich.corpbank.appliance.json
cp edge.geneva.corpbank.appliance.json.backup edge.geneva.corpbank.appliance.json
operator@training:~/workspace$ appliance-cli context select edge.geneva.corpbank
operator@training:~/workspace$ appliance-cli put config <edge.geneva.corpbank.appliance.json
Now, modify the Corpbank appliances configuration so that they accept NO prefixes from Stabank.
Solution
Replace the ACCEPT action in the rule by REJECT.
Alternatively, delete the accept_filter rule from edge.zurich.corpbank.appliance.json and
edge.geneva.corpbank.appliance.json
{
"accept_filter": []
}
Push the configuration:
operator@training:~/workspace$ appliance-cli context select edge.zurich.corpbank
operator@training:~/workspace$ appliance-cli put config <edge.zurich.corpbank.appliance.json
operator@training:~/workspace$ appliance-cli context select edge.geneva.corpbank
operator@training:~/workspace$ appliance-cli put config <edge.geneva.corpbank.appliance.json
Verify that the Corpbank Anapaya EDGE appliances do not accept the remote prefix from Stabank anymore.
Solution
The prefixes are no longer passing the accept filters.
operator@training:~/workspace$ appliance-cli context select edge.zurich.corpbank
operator@training:~/workspace$ appliance-cli get debug/scion-tunneling/sgrp/domains
{
domains: {
stabank: {
announced: ["10.2.0.3/32"]
received: null
}
}
}
You can now revert the config again.
cp edge.zurich.corpbank.appliance.json.backup edge.zurich.corpbank.appliance.json
operator@training:~/workspace$ appliance-cli context select edge.zurich.corpbank
operator@training:~/workspace$ appliance-cli put config <edge.zurich.corpbank.appliance.json
cp edge.geneva.corpbank.appliance.json.backup edge.geneva.corpbank.appliance.json
operator@training:~/workspace$ appliance-cli context select edge.geneva.corpbank
operator@training:~/workspace$ appliance-cli put config <edge.geneva.corpbank.appliance.json
Task 6. Next-Hop Tracking
Set up next-hop tracking in edge.lugano.stabank. The prefixes 10.8.0.2/32 and 10.8.0.5/32
should be advertised only if the IP address 10.8.0.2 responds to pings.
Solution
Push the configuration:
operator@training:~/workspace$ appliance-cli context select edge.lugano.stabank
operator@training:~/workspace$ appliance-cli put config <edge.lugano.stabank.appliance.json
Bring down the interface with address 10.8.0.2 on endhost-lugano-stabank.
operator@training:~/workspace$ lxc shell endhost-lugano-stabank
root@endhost-lugano-stabank:~# ip link set lan down
To find out which interface is configured with a given IP address you can run
root@endhost-lugano-stabank:~# ip address show
Check whether the next hop tracker realizes that the address is inaccessible.
Solution
The next hop is not reachable.
operator@training:~/workspace$ appliance-cli context select edge.lugano.stabank
operator@training:~/workspace$ appliance-cli get debug/scion-tunneling/sgrp/local-prefixes
{
local-prefixes: {
bgp: {
prefixes: null
}
static: {
prefixes: null
}
static-probed: [
{
last-success: "2023-03-14T16:45:18Z"
next-hop: "10.8.0.2"
prefixes: ["10.8.0.2/32"]
reachable: false
}
]
}
}
operator@training:~/workspace$ appliance-cli get debug/scion-tunneling/sgrp/peers
{
peers: [
{
announced: null
last-received: "2023-03-14T16:45:41Z"
local-isd-as: "1-ff00:1:3"
received: ["10.2.0.3/32"]
remote-address: "10.2.0.1:30256"
remote-isd-as: "1-ff00:1:2"
}
{
announced: null
last-received: "2023-03-14T16:45:41Z"
local-isd-as: "1-ff00:1:3"
received: ["10.2.0.3/32"]
remote-address: "10.2.0.2:30256"
remote-isd-as: "1-ff00:1:2"
}
]
}
Check whether the prefix was retracted from Corpbank.
Solution
operator@training:~/workspace$ appliance-cli context select edge.zurich.corpbank
operator@training:~/workspace$ appliance-cli get debug/scion-tunneling/sgrp/peers
{
peers: [
{
announced: ["10.2.0.3/32"]
last-received: "2023-03-14T16:47:02Z"
local-isd-as: "1-ff00:1:2"
received: null
remote-address: "10.8.0.1:30256"
remote-isd-as: "1-ff00:1:3"
}
]
}
Bring up the interface on endhost-lugano-stabank with address 10.8.0.2.
operator@training:~/workspace$ lxc shell endhost-lugano-stabank
root@endhost-lugano-stabank:~# ip link set lan up
Check whether the prefix is again received at Corpbank.
Solution
operator@training:~/workspace$ appliance-cli context select edge.zurich.corpbank
operator@training:~/workspace$ appliance-cli get debug/scion-tunneling/sgrp/peers
{
peers: [
{
announced: ["10.2.0.3/32"]
last-received: "2023-03-14T16:47:42Z"
local-isd-as: "1-ff00:1:2"
received: ["10.8.0.2/32", "10.8.0.5/32"]
remote-address: "10.8.0.1:30256"
remote-isd-as: "1-ff00:1:3"
}
]
}