Markdown Version | Session Recording

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.