# Path Aware Networking Research Group (panrg)   {#path-aware-networking-research-group-panrg}

Chairs: Jen Linkova, Brian Trammell (Google)

Notetaker: Simon Leinen (SWITCH)

## Introduction   {#introduction}

[Chair slides][1]

### Chair Updates   {#chair-updates}

RFC 9473 (path properties) published

## Path Energy Traffic Ratio API (petra)   {#path-energy-traffic-ratio-api-petra}

Luis Contreras (Telefonica) presenting [slides][2]. Joint work by
Telefonica and Cisco in the framework of an EU project. Goal: Provide
visibility about energy consumption on a path via an (REST?) API to be
used externally (e.g. SD-WAN customers) or internally
(operations/optimization).

Future devices may reduce the "baseline" (load-independent) level of
energy consumption by adopting techniques such as "sleep mode".

Q&A

Eliot Lear (Cisco): Have you considered the energy source in your
analysis? A: Not currently. In the future, could be integrated in
additional data sources like the inventory.

Ali Rezaki: There's ongoing work on carbon related to networking.
Question of creating an API towards the energy grid came up. Do you
consider this as well? Luis: Not currently, but we can look at it.

Brian suggests to take further discussion to the list, and notes that
the recently published path properties RFC doesn't really talk about
these aspects.

## SCION Control Plane & Data Plane   {#scion-control-plane--data-plane}

Corine de Kater (SCION Association) presenting [slides][3].

Points to Hackathon, the results of which will be presented later today
at the Hackdemo Happy Hour.

Overview of SCION architecture. Main components:

*   Data plane
*   Control plane
*   Control plane PKI

ASes (Core and other) participate in Isolation Domains (ISDs).  
Each ISD has its own root of trust (expressed in a TRC).

*   [draft-dekater-panrg-scion-overview][4]
*   [draft-rustignoli-panrg-scion-components][5]
*   [draft-dekater-scion-pki][6]
*   [draft-dekater-scion-controlplane][7]
*   [draft-dekater-scion-dataplane][8] (NEW)

### Control Plane—Inter-Domain Routing   {#control-planeinter-domain-routing}

Overview of main processes: Beaconing (by Core ASEs, for discovery of
paths), Registration (to make path segments available to other ASes),
Resolution (by source endpoints)

The general case of a path consists of three path segments: An "up", a
"core", and a "down" path segment.

### Data Plane   {#data-plane}

Path information is carried in packets. It consists of (AS/interface)
hop fields and is authenticated using a MAC. Routers check the MAC
during forwarding. ASes only forward traffic along authorized paths.

### Notes on drafts   {#notes-on-drafts}

IANA and Security Considerations still to be fleshed out.

Looking for feedback on how to continue in the IETF.

Q&A

Doug Montgomery: Do you envision ISDs to be roughly proportional to
maybe the number of Tier-1s today, or the number of ASes? And can ISDs
be recursive, i.e. can you have ISDs inside an ISD. A: An ISD should
have a logical boundary, e.g. correspond to a nation state, or to a
"vertical" (e.g. the financial sector, as the Swiss SSFN).

Éric Vyncke (Cisco): The MAC is supposedly used with a shared secret. A
(Nicola Rustignoli): The secret is per AS. Q: How can you share the
secret with other ASes? A: Not necessary, the MACs are checked only be
the AS that originates the secret.

Roland Bless (KIT): How is time synchronized. There could be a
bootstrapping issue. A (Nicola): Requirements are relatively used, on
the order of tens of seconds.

T...? (Huawei): Can core ASes be connected over multiple hops? A: The
intention is that the number of core ASes within an ISD is limited to a
small number.

David Venhoek: Question about path segments. How can an intermediate
system check that those haven't been combined in an illegal/unwanted
way? A (Nicola): The MACs are chained, so such manipulations would
require collusion of multiple ASes.

Waldemar Augustyn: Hearing about Cryptography and ten-second tolerance,
have you thought about networks with loose synchronization, such as
networks in space? A: Hasn't been studied yet.

Eliot Lear (Cisco): Do you envision a concept of proving that an
intended path was actually taken? A (Nicola): There is a (data-plane)
extension for proof-of-transit. This will be prevented tomorrow at a
meeting about path validation.

## Operational Aspects of SCION   {#operational-aspects-of-scion}

Sam Hitz (Anapaya) presenting [slides][9].

Topics: The SCION Internet Ecosystem, how to bootstrap an ISD, how to
become an AS, IP-in-SCION tunneling, how SCION is deployed and used
today, long-term need for standardization.

Clarification on a previous question about Core ASes: Core ASes roughly
correspond to the top-tier ISPs *in a domain*, e.g. within a given
(ISD's) country.

Envision an ISD per country, and additional industry-specific ISDs.

ISD concepts: common access rules, voting members, CAs (at least one).
TRC (Trust Root Configuration) has to be installed by all ISD
participants.

Since SCION forwarding doesn't require longest-prefix lookups, it
doesn't require TCAM and can be efficiently implemented on COTS (e.g.
x86) CPUs.

SCION ASNs are different from the ASNs used in BGP. Current practice in
SCION (exercised by Anapaya for now) is to give BGP ASN holders the same
ASN for use in SCION. There's ample additional (SCION-specific) ASN
space. SCION ASNs also have the scope of an ISD.

### IP-in-SCION Tunneling   {#ip-in-scion-tunneling}

99% of current production use is based on encapsulation of IP in SCION
(tunneling).

### Production Use Cases Today   {#production-use-cases-today}

Multi-provider/multi-organization ecosystems. E.g. Swiss Finance, see
subsequent talk by Fritz Steinmann. Have their own ISD, with access
controlled rules set by national bank. Resilience is provided through
multi-provider support.

Reducing attack surface of mission-critical systems that don't require
full/legacy Internet access.

A few numbers:

*   7 Isolation Domains (4 geographical, 3 industry-specific)
*   106 SCION ASes
*   1 IXP (SwissIX) with dedicated SCION peering mesh
*   (almost) 100% SCION coverage in Switzerland
*   Global reach limited (islands) but growing

### Long-Term Need for Standardization   {#long-term-need-for-standardization}

Concerns about interoperability and long-term evolution (and governance
thereof).

Interoperability layer with the current Internet should be formalized.

Q&A

Michael Hollyman (Verisign): What is the effect on SCION encapsulation
on the (overlay) MTU? A: This is indeed variable. The good thing is that
it is encoded explicitly in SCION. Applications have to adapt
accordingly.

## SCION Deployment Experience: the Secure Swiss Finance Network (SSFN)   {#scion-deployment-experience-the-secure-swiss-finance-network-ssfn}

Fritz Steinmann (Six) presenting [slides][10]

Outlines Six's role as operator of financial infrastructure, in
particular Swiss Interbank Clearing (SIC). Currently accessed through a
private (semi-public, MPLS-based) network. Striving for broader access,
e.g. to include "neobanks" that don't have premises like traditional
institutions; must contain associated risks and ensure enforceability of
governance. Goal: Move from a hub-and-spoke architecture to a more
community-based/Internet-like infrastructure.

Explains the structure of the SSFN ISD. Governance is separate from
(core) service provision.

TRC Creation and Maintenance

Well-defined lifecycle (see Control-Plane PKI I-D,
draft-dekater-scion-pki). Key and TRC practices, in particular creation
ceremonies, should be designed according to individual ISD requirements.
Illustrated by screenshot from recently performed TRC renewal ceremony.
SSFN decided to renew every year rather than less frequencly, to ensure
that the practice and knowledge remain fresh.

### How could IETF help?   {#how-could-ietf-help}

Standardization could improve adoption, in particular by larger vendors
and operators.

Q&A

## SCION—Final Discussion   {#scionfinal-discussion}

Nicola Rustignoli (SCION Association) presenting [slides][11].

Gives overview of current I-Ds, outlines required work on them. Could be
submitted via ISE process?

Research aspects of SCION should be kept in a RG (e.g. PANRG)

Use initial specs for future IETF work to evolve SCION in the long term.

Discussion/Q&A:

Lancheng Qin (Tsinghua University): MAC will be checked by routers
during forwarding. Have you measured forwarding performance? A (Sam):
For now (and for years to come), IP and SCION will be handled by
separate infrastructure. Current commodity-CPU-based SCION routers can
handle tens of millions and pps, and hundreds of Gbps on a relatively
modest server. This is plenty for the use cases we see today, though it
might be hard to move all video traffic from the current Internet to
SCION.

Doug Montgomery: What would be the overlap between SCION and the RPKI,
which is currently experiencing increased adoption? A (Sam): SCION trust
anchors are completely separate from RPKI. It could be discussed whether
RPKI could be used to publish information about mapping from IP space to
SCION ISD/ASes. For native SCION application, RPKI isn't technically
necessary.

Brian Trammell: Question about *naming*. How do you get to SCION
addresses? A (Sam): Not relevant in IP-in-SCION tunneling. For native
SCION, we currently envision using TXT records to encode ISD/AS
information to supplement existing address information. Brian recommends
to talk to some of the DNS people here.

Rod van Meter (Keio University): First talk was about reducing energy
consumption. How energy efficient is the signing and checking of
millions of signatures per second? A (Sam): Signing (of path segments)
only happens in the control plane, at relatively low rates. The MAC uses
symmetric cryptography. Checking the signatures is the most
energy-intensive part of forwarding. There is a paper by people at ETH
Zurich about energy consumption of SCION forwarding compared to
traditional (TCAM-based) routers using longest-prefix matches. The
results look favorable to SCION.

Rod van Meter: Security is one of the key points of SCION. How does it
fit with security mechanisms elsewhere in the architecture, i.e.
naming/DNS, TLS etc.? A (Sam): Very good question. SCION mostly talks
about two things: Routing security—problems such as hijacking are
completely eliminated by SCION. (That was the original research question
motivating the initial work on SCION). The other aspect is availability,
which is usually hard to achieve. Encryption and authentication of
payloads are out of scope.

Tim Chown (JISC): What have you learned in terms of deployability and
adoption from other protocols, e.g. LISP? A (Nicola): SCION is similar
to LISP in that it routes based on ISD/AS, and leaves the IP address
outside. The SCION/IP gateway is the short-term approach to support
interoperation with the legacy network.

Tim Chown: About MTUs: What is the MTU overhead of encapsulation in
SCION? A (Sam): Assuming an average Internet path of 4 ASes, or 5 ASes
because we envision more ASes in SCION, we're talking about 100–120
bytes per packet. With ten hops it would go up to 180–200 bytes.

Roland Bless (KIT): Do ISPs dislike the capability of end systems to
select their paths? Doesn't this interfere with traffic engineering,
which ISPs like to do? A (Sam): This does show up as tension when we
talk to ISPs. Points out that sources can only choose between those
paths that are permitted/announced by the network. Today, most senders
in SCION are SCION/IP Gateways. They keep track of latency/jitter/drop
rates along their different paths, and use that information to map
traffic to different paths. You can show that this (distributed)
approach can achieve better network utilization compared to pure
in-network traffic engineering. ISPs still have the ("nuclear") option
of stopping the advertisement of over-utilized (from the perspective of
the AS) paths.

Rod van Meter: About detection of outages: Do you have a target for
responsiveness of your system to outages/topology changes? A (Sam): SCMP
messages can be used for fast communication of link outages, to support
sub-RTT failover latencies. Within Europe, we see failover latencies
lower than 10 milliseconds. Q: How does this relate to the number of
concurrent connections using a path/link? A: In general,
(many/different) sources will already know about alternate paths and can
switch independently, so no additional beaconing is required for
failover.

Eliot Lear (Cisco, Independent Submissions Editor) invites Éric Vyncke
(Cisco, INT AD) and Colin Perkins (IAB) to the mic. Considers future
steps for the IETF concerning SCION. This RG could decide adopting the
I-Ds. Or the authors might decide to continue working on the documents
until they are ready for submission under the INT area. Éric suggests
that the INT area would be a natural home for this work, but at the
current point feels that this is in the "research" stage and not yet
suitable for standardization. Colin agrees with Eliot in that he sees
many open research questions. Document what you have now, e.g. as
individual submissions. Consider which of the various options (ISE, RG,
IETF WG/INT area) can best support your goals.

Nicola explains that most of the interesting research questions are
outside the "core" of SCION. The PKI and control plane, and possibly
also the data plane, could be published via the ISE stream as
"snapshots". Other aspects could be topics for PANRG to pursue in
parallel.

Eliot suggests that PANRG might want to help by advancing the three
"core" drafts together. Brian (as a chair) thinks this might fit into
the PANRG charter, as example answers to the questions in RFC 9217.

Colin suspects that some of this work will get into IETF territory. Éric
accepts this and notes that the RTG and SEC areas are also on the hook
for aspects of this work.

Meeting closes at 1500.



[1]: https://datatracker.ietf.org/meeting/118/materials/slides-118-panrg-introduction-agenda-note-well-00
[2]: https://datatracker.ietf.org/doc/slides-118-panrg-path-energy-traffic-ratio-api-petra/
[3]: https://datatracker.ietf.org/meeting/118/materials/slides-118-panrg-scion-control-plane-data-plane-01.pdf
[4]: https://datatracker.ietf.org/doc/draft-dekater-panrg-scion-overview/
[5]: https://datatracker.ietf.org/doc/draft-rustignoli-panrg-scion-components
[6]: https://datatracker.ietf.org/doc/draft-dekater-scion-pki
[7]: https://datatracker.ietf.org/doc/draft-dekater-scion-controlplane
[8]: https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane
[9]: https://datatracker.ietf.org/meeting/118/materials/slides-118-panrg-operational-aspects-of-scion-00
[10]: https://datatracker.ietf.org/meeting/118/materials/slides-118-panrg-scion-deployment-experience-the-secure-swiss-finance-network-ssfn-00.pdf
[11]: https://datatracker.ietf.org/meeting/118/materials/slides-118-panrg-scion-final-discussion-00.pdf