Agenda

Note Well and Agenda Bashing

Note takers: Henk and Peter (Chunchi) Liu

Chairs (5 Min, 0930-0940)

Why are we here?

Introductory slides and information about BOF.
This session is a NON-WG forming BOF, and is about getting to a common
understanding about the problem.

Michael Prorock: Non-Forming BOF right? Because I saw a charter in
development.
Nancy: Yes, this is for community understanding the problem.
Luigi: Charter writing starts early before WG-formation process. RATS is
the base technology and SAVNET will be orthogonal and complement to NASR
bidirectionally.

Rudiger Volk: Since there is "Secure Routing" in the title of this BoF,
why not talk about other existing routing security methods like works in
SIDROPS?

Luigi: It is not qbout securing existing routing protocols. Is about
choosing a path with the level of trust that I want and verify that the
traffic goes through that path.

Toerless Eckert: the title and the intent doesn't consider or detail
what is behind 'trust' of a router. Trust & what to trust & what trust
actually means in the NASR context is vital.
Nancy: let's see the problem statement first and then discuss?

Use cases, Business, and Technology drivers

Secure Routing Path Considerations, Meiling Chen (10 Min, 0940-0950)

No questions in favor of time

Path Validation Application Scenarios, Diego Lopez (10 Min, 0950-1000)

Roy Williams: I'm wondering whether adding new nodes is going to be
covered in this discussion?
Diego Lopez: I do not see why not.

Frank: There is no protecton against passive tapping?
Diego Lopez: No protection if you have physical access.

Rüdiger Volk: Trusted elements might in path might not be under your
control? So I could quite securely fix properties of the "static
elements". But making secure statements about an element seems much more
difficult. What about uncertified elements?
Diego Lopez: What is a Security Property is up to you. But you can do
RATS per element. Path usage is an additional opportunity to detect
missconfiguration.

Path Characteristics Verification and Attestation Services, Yutaka Oiwa (10 Min, 1000-1010)

Nicola Rustignoli: Lots of prior art on inter-domain in SCION (e.g.,
trust model) that could be applied here.
MCR: What kind of base protocol would enable Inter-Operator acces in the
PCS context?
Yutaka Oiwa: Something in the higher layers.
Nicola: We have path lookup processes (SCION control plane).

Trusted connection service for enterprise customers with high security requirements, Yu Fu (10 Min, 1010-1020)

No comments

End-to-end use cases (AI and beyond) which require NASR, Ramki Krishnan (10 Min, 1020-1030)

Diego presents on-site due to audio issues on the remote side. In the
last 2 min of presentation time Ramki gained mic powers and concluded
the presentation.

Mike Prorock: In context of AI-model in regulatory/gov context, what are
your thoughts about resilience here? What's the expected (cost of)
overhead?
Ramki Krishnan: Availabilty due to on-path mistrust of course increases
cost. Encryption not sufficient if metadata not protected.

Roman Danyliw: What's the linkage of crowdstrike example you brought up
and this BoF?
Ramki Krishnan: It's about availability.

Sue Hares: Suggests that we include more details to the layer and
protocols (BGP as an example) may be impacted or relevant. Why is this
different from all the stuff done by the operators that already secure
their routing equipment. There are a lot of operator-specific measures
in place. Asking Diego to elaborate on details later. RATS is of course
known and understood

Use Case Consolidation for NASR, Liu Chunchi (Peter), (5 Min, 1030-1035) AND Problemn Statement, Liu Chunchi (10 Min, 1035-1045)

There are already 2 presenations merged here (not architecture).

Monty Wiseman: Coordinating with WIMSE, since there might be some
overlap?

Roy Williams: Read the use case document and there is verbage that needs
to be clarified. Section 5.3 talks about
prevention, and a couple of cases in these presentations pretent to
prevent or control leakage of data. But in Section 7.2 it says it's out
of scope to cover prevention or control. So there's some mixed signals
in your use cases that it could help if you clarify.
Peter: In the future, need to have more services to ordinary cases
(email traversing a secure route); for now focus on business use cases.

Leakage prevention will be a requirement. Some items was not timely
updated.

Kathleen Moriarty: In the chat there is some discussions on brittleness.
Past working groups in the routing area sometimes are limited to an
administrative domain. Is this meant to be limited to an administrative
domain it or is it meant for for the big internet or hybrid Cloud use?
Peter: It is not limited to a domain, connectivity is widespread so
operators need to coordinate across domains.
Kathleen: So the brittleness increases in the inter-domain scope.

Yutaka Oiwa: There are gaps today, BGP and SDN were mentionsed, it is
also dedicatedly managed. The question is: what are the assumption of
closing that gap?
Peter: There is no need for operator A to look into the operator B's
domain by the use of tailored Attestation Results.

Proposed Strawman Architecture, Michael Richardson (15 Min, 1045-1100)

Yutaka Oiwa: What is "the orechtrator" in this presentation?
MCR: It's a thing that arranges stuff, like in SDN. In non-SDN case,
e.g. in OSPF, it is a device that has to collect all the attestation
evidence from all "your things" and offers an API to share left and
right.
Yutaka Oiwa: So not an orchestrator of NASR archietecture.
MCR: Yes. RATS would be "vertical interfaces" and "the rest would be
horizontal interface".

Sue Harres: I2RS is not a protocol. There was not a lot of feedback on
the trustworthiness of network functions in I2NSF. Why do expect more
interest here?
MCR: Sorry for mislabeling, help me were you can. These are strawman
slide that must be improved.

Roman Danyliw: I am having trouble follow all the network diagrams
across all the use case presentations. Help me understand. Who are "the
parties in the path"?
MCR: E.g., requirement traffic with src&dst in a country must remain in
the system boundary of that country (Swiss bank example). The operator
with that requirement does not want vendor lock-in. That is why evidence
and AR conveyance must be interoperable between all the APIs.
Roman Danyliw: Thanks for the clarification, but I am not sure that I
would have unpacked that from the presentations. Relevant to understand
which threat models apply.

Nancy: It is critical that everbody understands the problem statement.

Gunter Van de Velde: On slide 4 link between green and blue router is
that a link?
MCR: yes
Gunter Van de Velde: Could that be a tunnel?
MCR: Yes, but people would prefer not to put a tunnel there (for more
transparent remote attestation).
Gunter Van de Velde: So showing the "underlayer" in an overlay network
scenario would be the thing?
MCR: yes

Open Mic / Discussion, Everybody (20 Min, 1100-1120)

Nancy: Slide 4 of MRC's deck in Proposed Strawman Architecture

Nicola Rustignoli: While SCION uses tunnels today, it addresses the
problem statement to some extend already. But there is of course a gap
with the overlay used and the PoT.

Michael Prorock: I get the use case. There are things that make me
deeply nervous about this assuming not only "bad actors", but also, for
example, vendors "pulling the plug on a trusted node". But as the work
will continue anyway, it should have feedback from lots of parties.

Nancy: You just volunteered to provide that feedback. ;-)

Wes Hardaker: I think I understand the usecase & the need (e.g., MCR
"banks inside a nation system boundary"). The problem is when there are
2 operators this model probably works. But when there are 10+ banks and
10+ operators, how would you solve this without multi-hop routing
techniques including packet marking? In an air-gapped network this would
also work great, but why would you need it there in the first place?
MCR: I do not think that it is a problem from where the packet arrives,
as it is marked and comes with the to be specified ARs.

Diego Lopez: The idea is, if you use a tunnel, that you can provide some
Evidence that this tunnel remained in a certain system boundary (e.g.,
inside "Switzerland").

Toerless Eckert: Love to see this forward. A lot of solution building
blocks might already be in ANIMA: link encryption via ANIMA enrollment
procedures. It would be great, if people start with the most simple
scenario. It is very hard to review the current diverse set of more
complex scenarios to start with. You could also start without the PoT,
intially.
Nancy: What building blocks in ANIMA are you referring to?
Toerless Eckert: RFC8994 Certificates&Key for per-hop link encryption.
MCR: I cannot see why per-hop link encryption help here.
Nancy: What I hear is we have to clarify: in ANIMA is talking about the
trust and what it serves, NASR might profile ANIMA building blocks.
Toerless Eckert: ANIMA nails down the extact functionality you want to
have.
Rüdiger Volk: ANIMA is scoped to "limited domain".
Toerless Eckert: The "limited domain" can be a international bank with
100k employees.
Nancy: Can you elaborate how SCION helps?
Toerless Eckert: We can assess SCION and see which pieces we can use in
NASR.

Rüdiger Volk: MCR, you were talking about cost. I can see very high cost
and more brittleness. As a service provider, up-leveling your current
general purpose backbone infrastucture and then let all customer pay for
it does not seem to be a valid proposition. The brittleness here might
be high due to lack of available resources. Some customer use cases may
not need the proofs for every data packet. Making the data flows
auditable is interesting. Appraising only data plane operation is one
thing, but properties of your whole data path is another. What
characteristics are interesting there is the important task.
Yutaka Oiwa: It is important what the customer wants. Focus on
requirements that then will be encoded in data. PoT is interesting, but
optional.
Andrew Campling: Implication for physical network management? The NASR
approach might facilitate Internet-fragmentation
Luigi: We have Rudiger, Yutaka, and Andrew volunteering as reviewers ;-)

Closure, Chairs (10 Min, 1120-1130)

Deb Cooley: there is still the need for clarification of work and scope;
let's put this to the list, the outcome is still TBD.