NASR BoF

March 18, 2025

Chairs: Nancy Cam-Winget, Luigi Iannone

Minute Taker: Antoine Fressancourt

Note: Similar points as reported in these minutes have been
discussed on the chat. The complete log can be found at HERE.

Note Well and Agenda Bashing

Change from presented agenda: decision to have open technical discussion
before charter discussion. Agenda agreed by the room.

Why are we here?

• Presentation of timeline of NASR related work. Collective effort to
  reach this level of understanding.

Use Case & Problem Statement

Use cases (Diego Lopez)

• Presentation of reference use cases and their implications.

• Leman Lake use case related to banking regulation constraints in
  Switzerland:

  • Shortest path between Sion and Geneve goes through France, which
    is not compliant
  • NASR would like to provide means to control that the followed
    path goes through the longer path in Switzerland.

• What is the interaction with end-to-end principle and encryption?

  • NASR is complementary to end-to-end security, provides answer to
    regulation requirements.

• Why is not end-to-end protection sufficient and why should we care
  about where the traffic goes through?

  • Operators and regulators have requirements for instance traffic
    not leaving a country.

• Would be good to have actual concrete examples of existing
  regulations.

• Technical requirements are not very persuasive. Regulatory
  requirements might be, but need to be clearly presented.
• NASR being a possible way to address pervasive traffic monitoring
  threats.

• Trusted Path work in RATS WG provides some guarantees of the path
  taken in the network, but here there is a tighter scope, which is
  what needs to be clarified. 3GPP may be an example who would benefit
  of NASR.

• Level of Compliance - LoC: Customers to verify some properties.

• Proof of transit does not imply that the packet didn't exit the
  path. Maybe path compliance is not the right term to be used.

  • Better to avoid talking about path assurance since the term may
    be even more misleading.
  • Path attestation goes beyond checking node identity, can attest
    ingress / egress interfaces and links taken by packets.

• There is work about proof of transit that has been done in SFC, what
  is needed to highlight what is not there (in routing, RATS, SFC PoT)
  which NASR will provide.

  • NASR is the joint use of attestation techncology and proof of
    transit.

• What about lawful interceptions?

  • Trustworthiness as defined in RATS can attest that a router does
    what is supposed to do, including lawful interception if it is
    what it is supposed to do.

• Sensitive Data Routing and Healthcare IoT Routing use cases have
  been just briefly presented in the sake of time.

Problem statement (Peter Liu)

• Why NASR Now?

  1. Customers cannot control which geolocation the traffic transits
  2. Customers cannot request traffic traverse devices, links,
     services that meet their certain security requirements

• Goal to provide visibility and verifiability

  • Built on top of RATS to provide accountable forwarding. Gap
    between routing security and forwarding security. NASR
    complementary with routing security

• There is work from RATS, like RFC 9684, that can be used in NASR.
  Why an independent effort? Why not putting this work in an existing
  WG?

  • RATS is the building block to create path attestation, whose
    usage is then verified with proof of transit. These two things
    together look out of the scope of RATS.
  • NASR does not want to replace RFC 9684, but rather leverage it.

• What is exactly the definition of a path in NASR? BGP session?
  Tunnel? physical links?

  • A document in PANRG has a good definition of what a path is.

• Trustworthiness and traffic engineering are already addressed in
  different places, so what is new in NASR?

  • The possibility for the customers to verify that the traffic has
    been engineered in the way they asked. How to do it is the gap
    NASR wants to fill.

• Candidate solutions from problems exist in other venues (Routing
  security / SFC)

  • True, but they do not address the combination (forwarding).

• Proposed work may result in fragmentation of the Internet, including
  and excluding poeople?

  • No. That is the wrong terminology to use. NASR is about path
    complaint to a set of claims. Is a specific service in a limited
    domain not a general service for the Internet.

• Clarification of requirements whether the requirement is to detect
  nodes along the path that do not support NASR?

  • No. Only have proof that traffic went through a set of nodes
    that support NASR.

• Bringing the work to RATS would not work. RATS is already bloated
  and bringing all this work there is not possible.

• PoT has cryptographic cost.

  • Implementation on SRv6 shows that the cost is very limited.

• Remark about the scope of implementation: Internet or limited
  domain?

  • Is limited domain implemented at the operator level.

• Architecture at a glimpse

• Need to verify every configuration (binary / configuration files /
  routers) in order to determine the properties of the path?

  • This is not how remote attestation works. There is no
    configuration shared, the configuration is attested through
    trusted third party. You share hash values that attest the the
    property.

• Why not doing this in the SFC WG?

  • Piece can be done in other WG, but from a global perspective
    wold be better to have a WG.

• For reliability, what about having multiple paths? Can it be a
  scalability issue?

  • We need to discuss about what is in scope and what can be done.

Charter Discussion (Luigi Iannone)

• Note that expected NASR work is complementary to E2E encryption
• Complementary to RATS
• Initial focus on limited domain
• Routing part out of scope
• Method to express claims inheriting from RATS
• Need to clarify the threat model

• Clarifying question about confusion on use cases requirements,
  whether or not to attest everything along a path.

  • Only attest the positive part, whether it passes through a node.
    Cannot prove that it does not go through other nodes.

• Remark from SCION: there is a problem and use case to address, SCION
  proposes another solution to the problem. PoT has been evaluated as
  an experimental extension. SCION is willing to open up NASR work
  between domain to propose technical elements to the problem.

• Remark about mismatch between presented use case (lac Leman) and the
  proposed work, why cannot be solved with VPN?
  • VPN is not path-aware and GDPR is one example of regulation
    about where data can or cannot go.

Explore Consensus & Next Steps

Question? Yes / No / No Opinion

• Is the problem understood? 58 / 37 / 5
• Is the problem tractable? 47 / 52 / 10
• Is IETF right venue to solve the pb? 84 / 11 / 6
• Do you believe we should create a new WG to address the pb? 55 / 45
  / 7

• Do you agree with the current proposed charter to form NASR as a WG?
  34 / 57 / 14

• AD suggested that NASR get as much work as possible in RATS before
  attempting to form a WG because of lack of strong consensus.
  Concerns about tractability need to be clarified (What can be
  proved? Is RATS sufficient to verify attestation codes?) Also
  important to answer the question who will implment this.