Considerations on Authoritative Information for Source Address Validation
draft-qin-savnet-authoritative-information-01

SAVNET                                                            L. Qin
Internet-Draft                                   Zhongguancun Laboratory
Intended status: Informational                                     D. Li
Expires: 14 August 2026                              Tsinghua University
                                                        10 February 2026

     Considerations on Authoritative Information for Source Address
                               Validation
             draft-qin-savnet-authoritative-information-01

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 14 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Qin & Li                 Expires 14 August 2026                 [Page 1]
Internet-Draft  Authoritative Information Considerations   February 2026

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  What Constitutes Authoritative Information  . . . . . . . . .   3
   3.  When Authoritative Information Is Missing . . . . . . . . . .   4
   4.  When Authoritative Sources Conflict . . . . . . . . . . . . .   5
   5.  Discussion and Next Steps . . . . . . . . . . . . . . . . . .   5
   6.  Security and Operational Considerations . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Source Address Validation (SAV) prevents source address spoofing and
   enforces BCP38 [RFC2827], BCP84 [RFC3704], and [RFC8704].  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.

Qin & Li                 Expires 14 August 2026                 [Page 2]
Internet-Draft  Authoritative Information Considerations   February 2026

   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.

1.1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  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) [RFC9582], ASPAs (Autonomous System
      Provider Authorizations) [I-D.ietf-sidrops-aspa-profile], and TOAs
      (Traffic Origin Authorizations) [I-D.qin-savnet-toa] 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.

Qin & Li                 Expires 14 August 2026                 [Page 3]
Internet-Draft  Authoritative Information Considerations   February 2026

   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.

3.  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.

Qin & Li                 Expires 14 August 2026                 [Page 4]
Internet-Draft  Authoritative Information Considerations   February 2026

   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.  [I-D.ietf-savnet-general-sav-capabilities] 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.

4.  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.

5.  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:

Qin & Li                 Expires 14 August 2026                 [Page 5]
Internet-Draft  Authoritative Information Considerations   February 2026

   *  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.

6.  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.

Qin & Li                 Expires 14 August 2026                 [Page 6]
Internet-Draft  Authoritative Information Considerations   February 2026

   *  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.

7.  IANA Considerations

   This document does not request any IANA allocations.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <https://www.rfc-editor.org/info/rfc3704>.

Qin & Li                 Expires 14 August 2026                 [Page 7]
Internet-Draft  Authoritative Information Considerations   February 2026

   [RFC8704]  Sriram, K., Montgomery, D., and J. Haas, "Enhanced
              Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
              RFC 8704, DOI 10.17487/RFC8704, February 2020,
              <https://www.rfc-editor.org/info/rfc8704>.

   [RFC9582]  Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S.
              Kent, "A Profile for Route Origin Authorizations (ROAs)",
              RFC 9582, DOI 10.17487/RFC9582, May 2024,
              <https://www.rfc-editor.org/info/rfc9582>.

   [I-D.qin-savnet-toa]
              Qin, L., Maddison, B., Li, D., and I. Lubashev, "A Profile
              for Traffic Origin Authorizations (TOAs)", Work in
              Progress, Internet-Draft, draft-qin-savnet-toa-01, 29
              January 2026, <https://datatracker.ietf.org/doc/html/
              draft-qin-savnet-toa-01>.

   [I-D.ietf-sidrops-aspa-profile]
              Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley,
              R., and B. Maddison, "A Profile for Autonomous System
              Provider Authorization", Work in Progress, Internet-Draft,
              draft-ietf-sidrops-aspa-profile-22, 6 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-profile-22>.

   [I-D.ietf-savnet-general-sav-capabilities]
              Huang, M., Cheng, W., Li, D., Geng, N., and L. Chen,
              "General Source Address Validation Capabilities", Work in
              Progress, Internet-Draft, draft-ietf-savnet-general-sav-
              capabilities-02, 10 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
              general-sav-capabilities-02>.

Authors' Addresses

   Lancheng Qin
   Zhongguancun Laboratory
   Beijing
   China
   Email: qinlc@mail.zgclab.edu.cn

   Dan Li
   Tsinghua University
   Beijing
   China
   Email: tolidan@tsinghua.edu.cn

Qin & Li                 Expires 14 August 2026                 [Page 8]