Session Date/Time: 18 Mar 2025 02:30

nasr

Summary

This meeting was held to discuss the potential formation of a new working group, "nasr" (Network Attestation for Secure Forwarding). The session included presentations on use cases, a problem statement and proposed architecture. A significant portion of the meeting was devoted to Q&A regarding the problem definition, scope, and overlap with existing IETF efforts. Ultimately, based on the lack of clear consensus shown by the polls, the AD decided not to form a working group, and encouraged proponents to explore existing working groups such as RATS and PanRG.

Key Discussion Points

Use Cases: Diego presented use cases focused on data sovereignty (e.g., Swiss bank data not traversing France), compliance to regulatory requirements, and network virtualization. Concerns were raised regarding the end-to-end principle and whether the stated requirements justified a network-layer solution. The term "path compliance" was also questioned as being potentially misleading.
Problem Statement: Peter outlined the problem as the customer's inability to control the location and security attributes of their network traffic. He proposed that Nasr could enable verification of network path and security properties.
Relationship to RATS: Several attendees questioned the relationship to the RATS (Remote ATtestation procedureS) working group and the potential for overlapping work. Proponents clarified that Nasr would build upon RATS but address areas outside of RATS' scope, particularly the "proof of transit" aspect.
Proof of Transit: Discussion covered limitations of existing proof of transit mechanisms, particularly their inability to prove "non-transit". Performance concerns associated with per-packet proof of transit were also raised. It was clarified that iterative hashing would be used.
Scope: The intended scope was clarified as limited to single administrative domains initially, not large-scale internet deployments. It was emphasized that the proposed solution was intended as a specific service offering and not a general-purpose security solution. The session looked to emphasize network neutrality.
Configuration Attestation: A major point of discussion revolved around what is revealed with attestation. There was some uncertainty if the architecture required the sharing of complete image information, but this claim was refuted as only hash values are communicated.
Regulatory Compliance: While some use cases involved regulatory drivers, it was clarified that Nasr aimed to fulfill customer requirements arising from those regulations, rather than directly addressing regulatory mandates.
Path vs. Paths: Discussions about single-path vs multi-path environments. Real-world networks require highly available and resilient service.
Concerns about Feasibility & Capture Feasability was a concern regarding complex configurations. There was concern that preferred pathways can result in capture of the forwarding and that the "human element" needs to be taken into consideration.

Decisions and Action Items

No Working Group Formation: The AD decided not to form a new Nasr working group.
Explore Existing Working Groups: Proponents are encouraged to explore existing working groups (RATS, PanRG, SPRING, Routing) for relevant work and potential contributions.
Address Concerns: Proponents should address concerns raised during the meeting regarding tractability, scalability, validation of requirements, the architecture, and integration with RATS.
Further Refine Architecture The lack of clarity about how information is exchanged within the network element is to be worked on.

Next Steps

Proponents should continue discussions on the Nasr mailing list, focusing on refining the problem statement, architecture, and scope.
Investigate the possibility of contributing relevant components to existing working groups.