PANRG Interim Minutes - June 2022

Corine de Kater Mulhauser gave an
overview
of the SCION architecture.

Brian Trammell
(as chair)
presided over a Q&A session and a discussion of next steps, including but not
limited to:

• (eventual) adoption of (parts of) SCION as RG drafts?
• larger scale experiments with SCION within the auspices of the RG?
• the RG as a conduit for (parts) of SCION into appropriate IETF WGs?

Comments and Questions on Next Steps

Suresh Krishnan asked how applications use SCION. Adrian Perrig noted that most
users today use IP-to-SCION gateways, but pointed to ongoing work on client
libraries, as well as userspace/applevel support using UDP encapsulation. He
noted connections to Happy Eyeballs and work in the IETF
TAPS working group.

Mirja Kühlewind asked what needs to be standardized here: what's missing in the
documents is how we can split the parts of the system, and how we could use or
extend existing protocols for some of those parts independently. For example,
could IPv6 Segment Routing be adapted
to provide a data plane for SCION? Adrian Perrig noted that there are gaps in
each existing protocol the SCION folks have looked at: SR doesn't provide the
right security mechanisms, and there are path header / length scaling issues to
work out, for example.

Nicola Rustignoli asked whether a planned document presenting a gap analysis to
current Internet protocols would be useful.

Tommy Pauly noted that that's close: he'd like to see an Internet-Draft
enumerating protocol bits thar aren't there. Presenting SCION as a system is
hard; the IETF process doesn't do systems well.

Spencer Dawkins presented the basic question as "what's research, and what's
engineering?". HIP, for example, had an IRTF RG to work out the hard bits, and a
WG to standardize things that were well-understood. A useful SCION approach to
standardization would start by looking at which (existing) protocols can be
reused, which protocols can be extended, and which protocols have to be
invented. Explaining why SCION doesn't reuse existing protocols helps work on
those other protocols, too. A good answer to these questions will be necessary
for work on SCION to advance in the IETF. Additionally, splitting protocols
avoids fate sharing: if all of SCION is one effort, each protocol in that effort
lives or dies together. Spencer also recommended looking at
RFC 7418 to understand the
difference between things that make sense in an RG and things that can go to
(one or more) WG(s).

Brian Trammell (as an individual) suggested an analysis: what happens if you
break up SCION and only implement and deploy one pillar. PKI only? Routing only?
Dataplane only? Does each part of the system have independent utility? On a
first analysis, dataplane-only seems to be the least independently useful of, so
maybe not the first to focus on.

Tommy said he's more interested in figuring out how to evolve the current stack,
instead of completely replacing it. Though it's not clear that's possible, what
do you (the SCION team) thinks makes SCION different from past attempts to do
what it's doing. There are fundamental properties that will make something like
this work -- can we find those properties in an existing Internet protocol? Or
maybe we know we can't. But we should ask the question. Please come from this
angle – what are the properties that make us successful and where could we add
things to existing protocols. Just a gap analysis to the current Internet would
be less helpful.

Brian (as chair) followed up to note that SCION is unique among future Internet
projects in that it has actually deployed stuff for real users. So deployment
experience – positive or negative – would be super interesting and useful for
PANRG. Especially negative experiences, that are less likely to be published in
other academic venues.

Colin Perkins addressed the question of SCION as a system: how can approach
bringing the whole thing in? Should we bring the whole thing in? Clearly there
are good ideas and deployment experience. But it is a system, and a large one,
and the IETF is terrible at systems. We should be thinking about which bits make
sense in the IRTF, but also about which bits we can say are not research, and
which bits are, and figure out how to refer those that are not to the IETF.

Suresh noted that we're mostly looking at reference implementations from ETH,
which probably haven't addressed problems like interoperability across versions.
How someone buids an interoperable implementation should be in a draft. How
versioning works should be in a draft.

Spencer noted at this point that all the feedback in the meeting was how to move
forward, not whether to move forward. Brian, as chair, stated it was a bit early
to take a hum along those lines, as it looked like consensus was emerging that
the increasingly-inaccurately-named "gap analysis" document would provide more
information. Instead, Brian asked whether a "component" or "decomposition"
analysis of SCION, splitting it into its parts and evaluating existing
protocols, or potential extensions thereof, for each of those component
functions

Outcomes

As summarized by Colin, the sense of the RG is that we're interested in talking
about SCION here. The general view (which Colin noted he agrees with) is that
the IETF is bad at systems. So the next logical step is to figure out how to
split SCION into components, that's good input to both the RG and a future
standardization process. The proponents should be prepared to have a discussion
in Philadelphia (IETF 114 in July) focused on this component analysis. This
doesn't necessarily need to be a document, it can be a presentation, but if
there's a document in progress feel free to submit a -00 with gaps in it.

Brian (as chair) noted that the RG was prepared to schedule significant time at
IETF 114 for this discussion, and additional interim meetings to iterate on this
component analysis and next steps after IETF 114.