Session Date/Time: 24 Mar 2022 09:00

savnet

Summary

This session was an exploratory Birds of a Feather (BoF) to discuss the problem of Source Address Validation (SAV) within and between Autonomous Systems (ASes) and to gauge community interest in developing new technical solutions. The discussion highlighted the limitations of existing node-level SAV mechanisms, such as various forms of uRPF, which often lead to either improper packet blocking (due to asymmetric routing or complex BGP policies) or improper packet permitting (allowing spoofed traffic within customer cones). Two potential network-level solution directions, DSAV and ISAV, were presented, aiming to overcome these limitations by establishing more accurate SAV tables or cryptographic packet tags, respectively. While community interest in addressing the problem was clear, it was decided that more discussion is needed before considering a Working Group.

Key Discussion Points

Limitations of Existing SAV Mechanisms:
- uRPF (Strict, Feasible, Loose): Prone to improper blocks in the presence of asymmetric routing or complex BGP policies, and improper permits in multi-homed or customer-cone scenarios.
- SAVI: Primarily focused on host-level validation in access networks and is insufficient when not globally deployed.
- eFP uRPF (RFC8704): While an enhancement, it does not fully resolve the improper block/permit issues, particularly in inter-domain contexts (e.g., Algorithm A leading to improper blocks, Algorithm B to improper permits).
- Root Cause: Existing uRPF-based mechanisms are "node-level" and rely on a router's local FIB/RIB, which may not accurately reflect the real data plane forwarding path.
Requirements for New SAV Technology:
- Accuracy: Crucial to avoid improper blocking of legitimate traffic and reduce improper permitting of spoofed traffic.
- Network-Level Approach: Needed to build SAV tables that align with the real data plane forwarding path, independent of the local FIB/RIB.
- Scalability: Must be efficient in computation and communication overhead for large-scale deployment.
- Incremental Deployment: Partial deployment should still provide benefits.
- Security: Integrity and security of protocol messages must be guaranteed.
DSAV (Distributed Control Plane Protocol for SAV):
- Concept: Uses a distributed control plane protocol to discover real data plane forwarding paths via hop-by-hop prefix notifications, generating accurate SAV tables in routers along these paths.
- Mechanism: Notification messages contain a Source Prefix field (unchanging) and a Propagation Scope field (list of destination prefixes for the next hop, derived from FIB). Nodes originate, relay, or terminate messages based on their FIBs.
- Benefits: Aims to avoid improper blocks and permits seen with uRPF in both intra- and inter-domain scenarios, allowing deployment in specific areas to protect against spoofing from outside those areas.
- Open Questions:
  - Accuracy: How to account for policy-based routing (static routes, ACL redirection) that affects forwarding paths.
  - Scalability: Compression of protocol messages (long IP lists).
  - Convergence: Handling temporary inconsistencies between FIB changes and SAV table updates; fast reroute scenarios.
  - Incremental Deployment: Support for multiple disconnected deployed areas.
  - Security: Threat model for DSAV messages.
  - Privacy: Inter-domain DSAV may expose local routing policy information, requiring a privacy/security trade-off.
ISAV (End-to-End Data Plane Approach):
- Concept: A cryptographic-based SAV scheme where source and destination ASes perform end-to-end packet tag synchronization. Packets carry a legal tag verified by the destination.
- Implementation: Utilizes AS Border Routers (ABRs) for data plane tag operations and AS Control Servers (ACSs) for control plane information (e.g., prefix-to-tag mapping).
- Scalability: Achieved through a hierarchical "AS Community" structure, where end-to-end tags are maintained within communities, and "Water ASes" handle tag replacement for inter-community traffic.
- Benefits: Aims to provide consistent security guarantees and scalability for various deployment scales.
- Open Questions:
  - Protocol Support: Viability for both IPv4 and IPv6 (IPv4 option header limitations).
  - Hierarchy Management: Distributed vs. centralized approach for community hierarchy.
  - IPv6 Extension Header: Which specific IPv6 option header to use (current design uses Destination Option Header).
  - Trust Model: How ISAV handles "evil" or non-participating ASes; validation mechanisms beyond community agreement.
  - Overhead: Packet processing latency (~10 µs per packet) and MTU overhead (64-bit MAC in IPv6 extension header).
  - Design Philosophy: Suggestions for static cryptographic setup over dynamic arrangements, and considering encryption alongside authentication.
General Concerns and Community Feedback:
- Trust Model: The need for clear documentation of the trust assumptions for any proposed SAV solution.
- Cost vs. Accuracy: The perennial trade-off, with a preference for achieving high accuracy, then minimizing overhead. The complexity should ideally be comparable to routing protocols.
- Deployment Challenges: Historical difficulties in achieving widespread deployment of SAV mechanisms, including publishing IP address space and managing topology information, often due to operational and resource constraints.
- Scalability: A critical concern for any network-wide protocol due to the large number of nodes and potential computational demands.

Decisions and Action Items

Decision: It was deemed premature to consider forming a Working Group at this time. The problem space and potential solutions require further exploration and refinement.
Action Item: All participants are encouraged to continue discussions and submit comments to the [email protected] mailing list.

Next Steps

Further explore the identified problem space and the root causes of current SAV limitations.
Deepen the technical discussion around the proposed DSAV and ISAV frameworks, addressing the open questions raised during the session.
Evaluate additional potential solutions beyond those presented.
Use the [email protected] mailing list as the primary platform for ongoing discussions to determine if another BoF is warranted, or if there is sufficient interest and maturity to propose a Working Group.