**Session Date/Time:** 25 Jul 2024 16:30

# nasr

## Summary

This was a non-working group forming BoF session on network attestations for secure routing. The session covered use cases from operators (China Mobile, China Unicom), explored existing technologies like RATS and proof-of-transit, and discussed architectural considerations for inter-domain trust. The goal was to assess community interest and understanding of the problem before considering forming a working group. A key theme was validating path properties beyond basic routing protocol security.

## Key Discussion Points

*   **Problem Statement:** Traditional routing security focuses on route announcement, not hop-by-hop forwarding assurance. VPNs and TLS alone are insufficient due to potential vulnerabilities and the lack of trust in intermediate network elements.
*   **Use Cases:**
    *   Data leakage prevention during wide-area transmission (e.g., campus to data center).
    *   Orchestrated connectivity meeting client requirements for trustworthiness or security properties.
    *   Routing auditing to prove traffic traversed specific, trusted elements in a defined order.
    *   Secure AI inference with proper data governance
    *   Bank data compliance with in-country routing
*   **Existing Technologies:**
    *   **RATS (Remote Attestation Procedures):** Used for device trustworthiness attestation (claims, evidence, verification). Key to establishing node and link integrity.
    *   **Proof-of-Transit:** Validates path behavior at the data plane, often using techniques like Shamir sharing secrets. Can verify traversal order.
    *   **SRv6:** Used for pass computation and orchestration
    *   **Anima ACP: ** Possible profile with per hop link encryption
*   **Multi-Domain Challenges:** Key issue is exchanging relevant material (golden values for attestation, shared secrets for proof-of-transit) between domains.  Need to address trust boundaries and business relationships.
*   **Architectural Considerations:**  Different approaches exist:
    *   Orchestrator interactions with routing platforms (potential use of I2RS/RESTCONF).
    *   Verification within a single operator vs. end-to-end across multiple operators.
    *   Granularity of verification: per-packet vs. periodic sampling using IOM.
*   **Concerns:**
    *   Brittleness and fragility of solutions (reliance on static networks, potential impact of adding new nodes).
    *   Cost and complexity of deploying and maintaining the system.
    *   Potential for abuse (making it easier for malicious actors to control routing).
    *   Impact on network management by network operators
*   **Need for Clearer Scoping:** The community called for a more simplified single use case description to illustrate specific technology application and deployment. There were also calls to ensure this proposed work does not depend on proof of transit

## Decisions and Action Items

*   **Action Item:** Peter will consolidate and categorize the use cases presented.
*   **Action Item:** Presenters to provide more detailed explanations of their architectures, clearly articulating dependencies and potential gaps.

## Next Steps

*   Continue discussions on the mailing list.
*   Evaluate the problem statement and community interest.
*   Determine if the topic is suitable for a formal working group.
*   Scope problem with clear use case, and avoid being too general. Also ensure this scope does not hinge on proof of transit.