]> Zhongguancun Laboratory

Beijing China qinlc@mail.zgclab.edu.cn

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Routing SAVNET SAV Source Address Validation (SAV) prevents source address spoofing. This document explains that SAVNET relies on authoritative information. It also describes how to handle missing or conflicting data. The guidance minimizes improper blocks and improper permits while supporting reliable SAV enforcement.

Introduction Source Address Validation (SAV) prevents source address spoofing and enforces BCP38 , BCP84 , and . SAV relies on authoritative information to determine which source addresses are legitimate. However, SAV may encounter situations where this information is missing or conflicting. This document provides a conceptual framework for understanding authoritative information in the context of SAVNET, including:

• What constitutes authoritative information and which sources can be trusted.
• How to handle missing authoritative information.
• How to reconcile conflicting authoritative sources.
• The role of non-authoritative information as a reference in contextual or policy-based decisions.

By clarifying these principles, the document aims to guide the design and operation of SAV mechanisms that are both secure and operationally reliable, while minimizing improper blocks and improper permits.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

What Constitutes Authoritative Information Authoritative information determines which source addresses are legitimate. To be considered authoritative, information should meet the following criteria:

• Organizational authority: The source must be maintained by an entity that has recognized authority over the relevant prefixes or networks.
• Verifiability: The source must provide a mechanism to verify its correctness and authenticity, such as cryptographic validation.
• Timeliness: The information must reflect the current operational state and be updated promptly to avoid reliance on stale or outdated data.
• Integrity and security: The source must be resistant to unauthorized modifications or tampering.

Based on these criteria, authoritative information in SAVNET typically includes:

• RPKI objects: Cryptographically verifiable objects such as ROAs (Route Origin Authorizations) , ASPAs (Autonomous System Provider Authorizations) , and TOAs (Traffic Origin Authorizations) that provide explicit assertions about origin authorization or transit authorization.
• Local or static configuration: Operator-defined rules specifying source address permissions for hosts, non-BGP customer networks, or external ASes.

Note on routing information: Routing information from intra-domain or inter-domain protocols (e.g., IGP, BGP) may indicate reachable prefixes and their origins, but it cannot be considered authoritative by itself because it may include unauthorized or forged routes. If routing information is used to derive SAV rules, it should be validated—such as via RPKI-based Route Origin Validation (ROV)—before being treated as a trusted source. By defining authoritative information in this way, SAV mechanisms can rely on sources that provide sufficient guarantees of correctness, integrity, and timeliness, reducing the risk of improper blocks or improper permits in filtering.

When Authoritative Information Is Missing SAV may encounter situations where authoritative information about a particular prefix or source entity is unavailable. Such situations can arise for various reasons, including:

• The relevant RPKI objects (e.g., ROAs, ASPAs, TOAs) do not exist or have not yet been published.
• Local configuration has not been defined for a newly connected host, non-BGP customer network, or external AS.

When authoritative information is missing, SAV solutions must decide how to handle traffic from the corresponding source addresses. Several approaches have been considered:

• Conservative approach: Treat the source addresses as unauthorized and block traffic. This minimizes the risk of accepting spoofed packets but may result in legitimate traffic being dropped.
• Permissive approach: Allow traffic from the source addresses by default. This avoids accidental disruption of legitimate communications but increases the risk of accepting spoofed packets.
• Contextual approach: Use non-authoritative or contextual information when authoritative information is missing. Non-authoritative or contextual information may include trusted routing information, historical traffic patterns, or operational context. Given the current limited deployment of authoritative information, this approach is often the only practical means to achieve incremental progress in SAV enforcement.

Even when non-authoritative or contextual information (e.g., trusted routing information) is used, such information may also be missing for specific prefixes or ASes. Operators must determine how enforcement should behave under uncertainty. Possible behaviors include strict blocking, permissive acceptance, or intermediate strategies, such as permitting traffic while logging and investigating. defines a broader set of traffic-handling actions, including rate limiting, traffic redirection, counting, sampling, and monitoring, which can help operators manage uncertainty while maintaining operational continuity.

When Authoritative Sources Conflict SAV may encounter situations where multiple sources of authoritative information provide overlapping or apparently conflicting statements about the legitimacy of a source address or prefix. Such conflicts can arise, for example, when:

• Different RPKI objects (ROAs, ASPAs, TOAs) provide overlapping assertions for the same prefix.
• Local or static configurations overlap with information from other authoritative sources.

SAV solutions should treat all authoritative sources as equally credible and merge information from all sources. Any address or prefix authorized by at least one source should be considered legitimate. This approach ensures that no legitimate source address is incorrectly blocked, reducing improper blocks while maintaining reliable SAV enforcement. Non-authoritative or contextual information may be consulted as a reference to support operational understanding (see Section 3), but it must not override or negate any authorization provided by an authoritative source.

Discussion and Next Steps This document provides a conceptual framework for understanding authoritative information in SAVNET, addressing scenarios where information is missing or conflicting. The following points highlight key considerations for SAV design and operations:

• Definition of authoritative information: SAV must rely on sources that are verifiable, secure, timely, and maintained by recognized authorities, such as RPKI signed objects (ROAs, ASPAs, TOAs), SAV-specific signaling with security guarantees, or operator-defined local/static configuration.
• Handling missing information: When authoritative information is unavailable, fallback strategies—conservative, permissive, or contextual/policy-based using non-authoritative information as reference—should be defined.
• Conflict resolution: Conflicting authoritative sources should be merged to ensure all authorized prefixes and source addresses are preserved.
• Open questions: Additional work may include defining authoritative attributes in greater detail, coordinating with other working groups (e.g., GROW, OSPAWG) for operational guidance, and specifying mechanisms to securely exchange SAV-specific signaling information.

This framework provides a foundation for discussion and standardization of SAV mechanisms that rely on authoritative information, ensuring both security and operational reliability.

Security and Operational Considerations Reliable SAV enforcement depends on correct identification of legitimate source addresses. Inaccurate, missing, or conflicting authoritative information can lead to operational and security risks, including:

• Improper blocks: Legitimate traffic is blocked, potentially disrupting services.
• Improper permits: Spoofed or unauthorized traffic is accepted, increasing vulnerability to attacks.

Mitigation strategies include:

• Validation and cross-checking: Ensure authoritative sources are consistent and verifiable.
• Timely updates and monitoring: Maintain freshness of authoritative information to avoid reliance on stale data.
• Documentation and operational procedures: Clearly define policies for missing, inaccurate, or conflicting authoritative information, including fallback handling.
• Fallback and reference mechanisms: Non-authoritative information (e.g., routing data) may be used as a reference in contextual or policy-based approaches but must never be treated as definitive.
• Merge strategy for conflicts: All authoritative sources should be combined, ensuring that any prefix or source address authorized by at least one source is accepted, minimizing improper blocks.

By implementing these practices, networks can maintain reliable SAV enforcement while reducing both security and operational risks. This approach emphasizes using authoritative information wherever possible and leveraging non-authoritative data only as a reference when necessary.

IANA Considerations This document does not request any IANA allocations.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. Zhongguancun Laboratory Workonline Tsinghua University Akamai This document defines a standard profile for Traffic Origin Authorizations (TOAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A TOA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate traffic using source IP addresses within the address block. Yandex JetLend Internet Initiative Japan BSD Software Development Vigil Security, LLC Workonline This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. Zhongguancun Laboratory China Mobile Tsinghua University Huawei Technologies Zhongguancun Laboratory The SAV rules of existing source address validation (SAV) mechanisms, are derived from other core data structures, e.g., FIB-based uRPF, which are not dedicatedly designed for source filtering. Therefore there are some limitations related to deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces the general SAV capabilities from data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document.