**Session Date/Time:** 19 Mar 2024 03:00

# savnet

## Summary
The SAVNET working group meeting focused on updates to existing drafts and discussions surrounding source address validation techniques.  The meeting covered intra and inter-domain architectures, solutions for spoofing attacks, and related topics such as RPKI and ASPA usage, BGP extensions, and YANG models. Several drafts were presented, followed by discussions and action items.

## Key Discussion Points

*   **Intra-domain SAVNET Architecture:** Discussion on updates to the architecture document, including clarifying router roles (host-facing, customer-facing, AS border router) and data plane considerations.  The importance of using self-specific information for accurate SAV filtering was highlighted.
*   **Inter-domain SAVNET Architecture:**  Review of updates to the inter-domain architecture draft, focusing on incorporating considerations for IR data, validating source-specific information, and distinguishing between general and specific information sources.  A new architecture figure displaying network topology and communication flows was added.
*   **RPKI and ASPA Usage Concerns:** A recurring concern regarding the use of RPKI objects. The problem with stricter filtering when RPKI data is unavailable was highlighted, with a call for new signed objects. Concerns were raised that a systemic failure in the global RPKI system leads to traffic being dropped.
*   **Man-in-the-Middle Attacks:** Discussion on how current solutions address or fail to address man-in-the-middle attacks where attackers insert prefixes into BGP with valid AS origins. The need for forward signing mechanisms was discussed.
*   **General Source Address Validation Capabilities:** Presentation of a draft summarizing general SAV capabilities, including source address allow lists and block lists.
*   **DNS Proxy Based Method Improvements:** Presentation of a method to improve the measurement of IP source outbound spoofing by using traceroute with DNS queries. This enables learning the path of DNS queries to distinguish between true and false positives.
*   **Intra-domain South Support we are IGP and we are PGP:** Presentation discussing the use of IGP and BGP to propagate SAV information. The proposal involved using IGP and BGP to disseminate source prefixes and connectivity information to generate SAV routing tables.
*   **Biconself - new interdoman solution:** A new approach was proposed. Biconself uses Aspar and Rola Stetter to generate self filters. It has a primary design to warding in proper block while maintaining directionality.
*   **Sign the subnet peering information object** Proposing a new content type for systphy object.

## Decisions and Action Items

*   **Call for Working Group Adoption:**  The chairs called for working group adoption for several drafts, including the intra-domain and inter-domain architecture documents.
*   **Address RPKI Concerns:** The authors of solutions using RPKI data were urged to address the concerns raised regarding the potential for stricter filtering in the event of RPKI data unavailability, potentially by exploring new signed objects.
*   **Consider Man-in-the-Middle Attacks:** The authors of solutions should address the need for methods to defend against man-in-the-middle attacks in BGP.
*   **Incorporate Multi-homing Scenario:** The authors of the IGP/BGP-based SAV solution agreed to add a multi-homing scenario to their draft.
*   **Clarify ASPA Usage:** The authors need to make the description clear in how AS path's are interpreted. They currently are bidirectional, which may not be correct.
*   **Define Address Family:** In the object that defines the peering information, the address family should be defined and more than one IP address may need to be supported.

## Next Steps

*   Authors will revise their drafts to incorporate the feedback received during the meeting.
*   Continued discussion on the mailing list to address remaining issues and refine proposed solutions.
*   Possible mergers of some documents with the Architect document.