[Note: edited from AI generated summary]
Session Date/Time: 24 Jul 2026 12:00

Summary

The SAVNET Working Group meeting at IETF 126 was chaired by Joel Halpern and Ron Bonica. The meeting covered updates on active working group drafts and several new proposals focusing on both intra-domain and inter-domain source address validation (SAV) mechanisms, routing security coordination, Internet Exchange Point (IXP) deployments, and SAV monitoring requirements.

Key Discussion Points

1. Administration and Introduction

• Joel Halpern opened the meeting, presented the Note Well, provided meeting tips, and reviewed the agenda. No changes were made to the agenda.

2. Updates on PI-SAV for CC

• Presenter: Mingqing Huang
• Discussion:
• Mingqing presented updates on Provider Interface SAV for Customer Cones (PI-SAV for CC) and addressed feedback from previous sessions.
• Q&A: Sriram asked about the percentage of prefix reduction in the SAV table compared to the full routing table (1.3 million prefixes). Mingqing noted that this depends on the size of the customer cone and the chosen approach, adding that evaluations show SPCC performs better than SSCC in terms of independence degree.

3. Update on the BAR-SAV Draft

• Presenter: Kotikalapudi Sriram
• Discussion:
• Sriram presented updates to the BAR-SAV draft, focusing on its intra-domain component, security considerations, and the use of ROA/ASPA-derived deny lists for prefix filtering.
• Q&A:
  • Lancheng noted that the intra-domain component of BAR-SAV aligns with his intra-domain SAV draft and suggested combining forces. He also pointed out that ROAs contain AS numbers rather than customer identifiers, meaning operators still need out-of-band customer coordination to map prefixes correctly.
  • Lancheng questioned the value of an additional deny list for prefix filtering if ASes can already detect leaks/hijacks using ASPA and ROAs. He suggested discussing this aspect in the GROW working group. Sriram agreed that while GROW is a valid venue, prefix filtering directly benefits SAV by ensuring the RIB remains clean.
  • Antoine Fressancourt sought clarification on why local configuration takes precedence over ROAs when a customer announces an aggregate prefix (e.g., /23) but chooses not to announce its more-specifics. Sriram explained that the configuration agreement between the customer and operator controls which prefixes are actively routed vs. which are only permitted for SAV.
  • Mingqing Huang raised concerns regarding the overhead of running routing security validations and potential impacts on incremental deployment. Sriram clarified that BAR-SAV does not perform ROV/ASPA verification itself; it relies on the routing engine to clean the RIB.
  • Chat Log Context: Igor Lubashev noted in the chat that in intra-domain scenarios, the customer might not connect via BGP at all (e.g., renting servers in a provider's datacenter), meaning the provider announces the IPs on their behalf. Sriram also clarified in chat that more-specific prefixes are included in ROAs in case the prefix user wishes to withdraw the less-specific prefix in the future.

4. Using SOAs to Bootstrap Inter-AS Source Address Protection Services

• Presenter: Minglin Jia
• Discussion:
• The presenter proposed using Service Obligation Associations (SOAs) within the RPKI system to bootstrap bilateral source address protection.
• Q&A:
  • Antoine expressed concern over the proliferation of new security records (TOA, SODA, SOA), noting it may make routing security incomprehensible for simpler networks already struggling to deploy ROAs and ASPAs.
  • Nan asked if SOA records are dynamic. The presenter replied that the bootstrap information in the SOA is designed to be highly stable.

5. Updates on Inter-domain Source Address Validation Based on AS Relationships (RB-SAV)

• Presenter: Shuqi Liu
• Discussion:
• The presenter outlined updates to Relationship-Based SAV (RB-SAV) since IETF 123.
• No question asked.

6. Source Prefix Advertisement (SPA) for Inter-domain SAVNET

• Presenter: Nan Geng
• Discussion:
• Nan presented a mechanism where a source AS advertises its locally known customer cone and prefix set directly to validating ASes using SPA messages. This leverages the observation that the source AS has the most accurate view of its own prefix authorization.
• Q&A:
  • Antoine asked about authorization and how to prevent malicious downstream ISPs from advertising fake SPA records. Joel agreed, pointing out that as proposed, there is no authentication mechanism for SPA, and restricting propagation to single hops is insufficient. The issue was deferred to the mailing list.
  • Libin asked if SPA excludes other existing data sources like ROA or TOA. Nan responded that these sources will be taken into account when generating SPA messages.

7. Update on Intra-domain Source Address Validation Architecture

• Presenter: Lancheng Qin
• Discussion:
• Lan Cheng shared architectural updates to align the document with the intra-domain problem statement and terminology.
• Q&A:
  • Sriram asked why there would be "hidden prefixes" in an intra-domain environment where the customer is directly connected. Lancheng explained that "hidden prefix" refers to a configuration agreement where a customer is authorized to source traffic from a prefix but does not advertise it in routing. Sriram suggested this is simply standard static configuration.
  • Minqing recommended categorizing different multi-homing and asymmetric routing scenarios in the architecture to guide developers.

8. Information Requirements for Monitoring Source Address Validation Enforcement

• Presenter: Lancheng Qin
• Discussion:
• Lan Cheng introduced an initial draft defining the monitoring requirements for SAV. It classifies monitoring into three perspectives. The presenter requested feedback from the community regarding additional metrics and whether existing telemetry/monitoring protocols can support these requirements.

Decisions and Action Items

• Consolidation of Intra-domain SAV Ideas: Sriram and Lancheng agreed to collaborate offline to align and potentially integrate the intra-domain SAV concepts in draft-ietf-sidrops-bar-sav and draft-ietf-savnet-intra-domain-architecture.
• Mailing List Redirection:
• Detailed discussion on the precedence of local configuration over ROAs in BAR-SAV was deferred to the mailing list.
• Security and authentication concerns regarding Source Prefix Advertisements (SPA) were deferred to the mailing list.

Next Steps

• Continued discussion on the mailing list regarding the newly presented monitoring and SOA draft proposals.
• Refinement of the active working group drafts in preparation for IETF 127 in San Francisco.