]> Zhongguancun Laboratory

Beijing China caoqian@zgclab.edu.cn

Zhongguancun Laboratory

Beijing China huangmq@mail.zgclab.edu.cn

Everything OPS

Belgium benoit@everything-ops.net

Huawei

Beijing China zhoutianran@huawei.com

Operations and Management opsawg IPFIX, Source Address Validation (SAV) This document specifies the IP Flow Information Export Information Elements to export the context and outcome of Source Address Validation enforcement data. These SAV-specific Information Elements provide detailed insight into why packets are identified as spoofed by capturing the specific SAV rules that triggered validation decisions. This operational visibility is essential for network operators to observe SAV enforcement behavior and analyze source address spoofing events detected by SAV.

Introduction Source Address Validation (SAV) serves as a fundamental defense mechanism against IP source address spoofing. Despite its critical role in network security, current SAV implementations lack operational visibility, making it difficult to answer essential operational questions:

• How many packets are identified as spoofed and dropped by SAV?
• Which interfaces receive spoofed packets and which source prefixes are targeted?
• Which specific SAV rules trigger the enforcement actions?
• Are SAV rules functioning as intended or potentially misconfigured?

This document introduces a set of SAV-specific IP Flow Information Export (IPFIX) Information Elements (IEs) that enable detailed reporting of Source Address Validation enforcement actions. These elements align with the SAV concepts and operational models defined in , and provide traffic observations that can be operationally correlated with the SAV configuration and state information available via the YANG data model .

Terminology 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. This document makes use of the terms defined in , and . The following terms are used as defined in :

• IPFIX
• IPFIX Information Elements
• Template
• Template Record
• Data Record
• Data Set
• Exporter
• Collector

The following terms are used as defined in .

• SAV rule
• Validation mode

SAV Overview and IPFIX Export Requirements This section outlines the operational requirements for SAV telemetry export using IPFIX, based on the generalized SAV architectural framework defined in . The SAV framework establishes four canonical validation modes that model validation policies:

• Interface-based prefix allowlist (Mode 1): Validates that a source prefix is explicitly permitted on the incoming interface.
• Interface-based prefix blocklist (Mode 2): Validates that a source prefix is not explicitly blocked on the incoming interface.
• Prefix-based interface allowlist (Mode 3): Validates that a packet is received on an interface explicitly permitted for its source prefix.
• Prefix-based interface blocklist (Mode 4): Validates that a packet is not received on an interface explicitly blocked for its source prefix.

These modes can be applied independently or in combination on a router, following a defined validation procedure (Section 2 of ). Furthermore, when identifying a packet as spoofed, a range of traffic handling policies (e.g. discard, rate-limit, redirect) can be applied. However, the generalized SAV model requires corresponding operational visibility capabilities. Without integrated telemetry, operators face significant challenges in:

• Enforcement Visibility: Observing SAV enforcement actions and identifying which rules were triggered.
• Operational Analysis: Understanding the context of SAV decisions and troubleshooting unexpected enforcement behavior.
• Threat Intelligence: Analyzing traffic patterns identified as spoofed by SAV.

To address these limitations, IPFIX and provide a vendor-neutral protocol for SAV telemetry. The exported data must provide insight into:

• The validation outcome and specific reason for the decision
• The identity and type of SAV rule or rule set that influenced the decision
• The configured rule content that was evaluated during validation
• The enforcement action applied to spoofed packets

The following section defines the IPFIX IEs that meet these requirements.

IPFIX SAV Information Elements This section defines the IEs used for SAV telemetry. These IEs have been specified in accordance with the guidelines in .

Design Rationale The SAV IPFIX IEs are designed to provide detailed visibility into SAV enforcement actions, enabling network operators and automation systems to monitor and troubleshoot SAV operations effectively. The design follows these principles:

• Scope. The SAV-specific IEs are used to report the outcome and context of SAV processing for data plane traffic observations. Interface, device or network-level SAV configuration is out of scope for these IEs and is covered by the SAVNET YANG data model.
• Conceptual Alignment. The elements align with the validation modes and rule types defined in , ensuring consistency with the architectural SAV concepts.
• Semantic Correlation. The IPFIX encoding preserves the semantic relationships defined in , which enables correlation between IPFIX Data Records in the data plane and YANG configuration/state data in the control plane, facilitating comprehensive analysis.
• Structured Encoding. The savMatchedContentList is encoded as a subTemplateList to represent the multi-field tuples of SAV rules. The structure of subTemplateList was chosen because it can encapsulate heterogeneous fields (e.g., prefix, length, interface) within a single list element. The list semantics (allOf, exactlyOneOf) directly encode the SAV validation logic (e.g., matching all rules in an allowlist vs. exactly one in a blocklist) into the data structure.

savRuleType (unsigned8) The savRuleType element classifies the rule as either an allowlist or a blocklist. The values correspond to the check type concepts in the SAV architecture:

• A value of 0 is reserved to indicate that no value is available.
• A value of 1 (allowlist) indicates the packet was validated against an allowlist.
• A value of 2 (blocklist) indicates the packet was validated against a blocklist.

savTargetType (unsigned8) The savTargetType element specifies the lookup key used by the SAV rule. It may be used in conjunction with savRuleType to fully define the validation mode applied.

• A value of 0 is reserved to indicate that no value is available.
• A value of 1 (interface-based) indicates the rule is indexed by an interface (e.g., "on interface X, what prefixes are allowed/blocked?").
• A value of 2 (prefix-based) indicates the rule is indexed by a source prefix (e.g., "for prefix Y, which interfaces are allowed/blocked?").

savMatchedContentList (subTemplateList) The savMatchedContentList element carries the content of the rules that were relevant to the validation decision, encoded as a subTemplateList according to . Each element in the list represents a complete SAV rule tuple. The content and semantics of the list are defined by the savRuleType:

• For Allowlist non-matches (savRuleType=1): The savMatchedContentList consists of the set of all rule tuples from the consulted SAV allowlist at the time of the packet's processing. The subTemplateList semantic MUST be allOf (0x03), indicating that the packet was validated against all these rules and did not match any of them.
• For Blocklist matches (savRuleType=2): The savMatchedContentList contains the matched rule tuple from the consulted SAV blocklist. The subTemplateList semantic MUST be exactlyOneOf (0x01), indicating that the packet matched this specific rule.

Semantic Interpretation of Standard Information Elements: When standard IPFIX IEs (such as ingressInterface, sourceIPv4Prefix, sourceIPv4PrefixLength or their IPv6 equivalents) are used within the subTemplateList of savMatchedContentList, they represent values from the SAV rule configuration, rather than from the actual packet being validated. This contextual distinction is critical for correct interpretation:

• In the parent Data Record: These IEs describe attributes of the actual spoofed packets that were validated by SAV.
• Within savMatchedContentList: These same IEs describe the configured SAV rule parameters that were evaluated during validation.

This approach ensures clear semantic distinction by reusing existing IEs, without requiring definition of new elements for SAV rule parameters.

savPolicyAction (unsigned8) The savPolicyAction indicates the action applied to packets identified as spoofed. The action taken is a matter of local policy. This element reports the outcome.

• A value of 0 is reserved to indicate that no value is available.
• A value of 1 (permit) indicates packets represented by the record were allowed to proceed (monitoring only).
• A value of 2 (discard) indicates packets represented by the record were discarded or dropped.
• A value of 3 (rate-limit) indicates packets represented by the record were subject to a rate-limiting policy.
• A value of 4 (redirect) indicates packets represented by the record were redirected to an alternative destination.
• Values 5-255 are reserved for future extension.

Use Cases The SAV-specific IPFIX IEs defined in this document enable network operators to answer critical operational questions that are currently unaddressable without telemetry for SAV: SAV Enforcement Monitoring: Use savRuleType (TBD1), savTargetType (TBD2), savPolicyAction (TBD4) and standard IPFIX counters, to quantify SAV enforcement actions, analyze their distribution across different validation modes, and identify applied SAV enforcement actions (discard, rate-limit, redirect) at the data plane level. This complements control-plane monitoring via YANG models, providing visibility into actual enforcement behavior rather than configured rules. Rule-Level Attribution and Troubleshooting: Use savMatchedContentList (TBD3) to determine the specific SAV rule configuration that triggered enforcement decisions, including the exact rule parameters (interfaces, prefixes) evaluated during validation, whether for allowlist failures or blocklist matches. Forensic Analysis and Compliance: SAV Data Records include both SAV-specific Information Elements and traditional packet-level details (source/destination addresses, ports, protocol), providing complete information for incident investigation and compliance reporting. Operators can use these records to investigate the source and nature of spoofing attacks, and gather evidence to support external trust initiatives and regulatory compliance reporting.

Operational Considerations While this document defines new IPFIX IEs using standard IPFIX mechanisms, implementors should consider:

• Exporter Implementation: Exporters MUST properly encode the subTemplateList structure for savMatchedContentList and ensure semantic consistency between savRuleType and list contents. Exporters MUST also define the sub-templates (e.g., 901-904) used in savMatchedContentList prior to exporting Data Records that use them.
• Collector Processing: Collectors MUST be capable of parsing subTemplateList structure and understanding the context-dependent semantics of standard IEs within savMatchedContentList. Collectors MUST associate the sub-templates with the main template for correct interpretation.
• Export Volume and Aggregation: When savMatchedContentList is used for allowlist non-matches, the exported record carries the full consulted allowlist, which may generate excessive IPFIX traffic. To bound export load, exporters SHOULD consider rate limiting, sampling , or aggregation . Exporters MAY aggregate packets sharing the same Flow Key and SAV context into a single Data Record, including over a reporting interval. For allowlist non-match events, aggregation is more constrained because the consulted allowlist may change between packets. Exporters SHOULD avoid combining packets validated against different allowlist contents into the same Data Record.

YANG-IPFIX Mapping The mappings between the SAV YANG data model and IPFIX IEs are considered based on the common foundation of the general SAV capabilities document . The operational correlation is demonstrated in Table 1, which defines the values for the designed IEs mapped from the corresponding SAV Management YANG Module. Table 1: Mappings between SAV YANG Data Model and IPFIX Information Elements The savPolicyAction element carries real-time SAV decisions applied to spoofed packets. It does not directly map to YANG configuration node. The code points for these IEs are maintained by IANA in the corresponding subregistries of the IPFIX registry. Future additions or changes are managed via Expert Review as described in IANA Considerations.

Security Considerations The SAV-specific Information Elements defined in this document export data that reveals the security posture of a network's source address validation deployment. This data is sensitive and warrants additional considerations beyond those in .

• Rule Configuration Disclosure: The savMatchedContentList element, when used with the allOf semantic for allowlist non-matches, exports the complete set of source prefixes permitted on an interface. An adversary with access to these IPFIX exports, for example via a compromised collector, could learn which source prefixes are allowed on each interface. This information could then be used to forge packets with spoofed source addresses drawn from those permitted prefixes, thereby increasing the adversary's ability to evade source address validation.
• Enforcement State Disclosure: The savPolicyAction element with the value permit (monitoring only) reveals that SAV is not actively enforcing on a given path. This information could be exploited by an adversary to identify interfaces or prefixes where spoofed traffic would not be dropped.
• IPFIX Export Amplification: A sustained spoofing attack can trigger a large volume of IPFIX exports and may overload the collector or the management plane, causing a secondary denial-of-service effect. This risk is especially relevant when allowlist non-match records carry the full consulted allowlist. The guidance in Operational Considerations can help mitigate this risk.
• Transport Security: Given the sensitivity of SAV enforcement data, exporters and collectors SHOULD use encrypted transport such as TLS or DTLS as described in to protect SAV Data Records from eavesdropping and tampering.
• Access Control: Collectors that store SAV enforcement data SHOULD restrict access to authorized operators, as the data reveals both the SAV configuration and its enforcement outcomes.

Other security considerations described in apply to this document.

IANA Considerations This document requests IANA actions for the IPFIX registry . Specifically, it requests the creation of new subregistries for the value spaces of selected SAV-specific Information Elements, and the allocation of four new IPFIX Information Elements.

New IPFIX Sub-registries IANA is requested to create new subregistries under the IPFIX IEs registries. These subregistries specify the value spaces for the savRuleType, savTargetType, and savPolicyAction IEs. The corresponding IE definitions are provided in New Information Elements. The allocation policy is Expert Review .

IPFIX savRuleType (TBD1) Subregistry

• Reference: This document, savRuleType; , Section 2 (Validation Modes)
• Allocation Policy: Expert Review
• Expert Guidance: Experts should ensure that new values are consistent with the SAV architecture concepts defined in , particularly the validation modes and rule types (allowlist or blocklist).

Initial values:

IPFIX savTargetType (TBD2) Subregistry

• Reference: This document, savTargetType; , Section 2 (Validation Modes)
• Allocation Policy: Expert Review
• Expert Guidance: Experts should consult to ensure new values align with the defined target types (interface-based or prefix-based).

Initial values:

IPFIX savPolicyAction (TBD4) Subregistry

• Reference: This document, savPolicyAction; , Section 4 (Traffic Handling Policies)
• Allocation Policy: Expert Review
• Expert Guidance: Experts should ensure that new actions are consistent with the SAV traffic handling policies defined in .

Initial values:

New Information Elements This document also requests IANA to allocate four new IEs under the "IPFIX Information Elements" registry available at . Note that three of these IEs (savRuleType, savTargetType, and savPolicyAction) have associated value spaces. The corresponding subregistries are defined in New IPFIX Sub-registries.

savRuleType

• ElementID: TBD1
• Name: savRuleType
• Abstract Data Type: unsigned8
• Data Type Semantics: identifier
• Description: Identifies the validation rule type triggered during SAV enforcement.
• Reference: This document, IPFIX savRuleType Subregistry

savTargetType

• ElementID: TBD2
• Name: savTargetType
• Abstract Data Type: unsigned8
• Data Type Semantics: identifier
• Description: Specifies the entity type against which validation was performed.
• Reference: This document, IPFIX savTargetType Subregistry

savMatchedContentList

• ElementID: TBD3
• Name: savMatchedContentList
• Abstract Data Type: subTemplateList
• Data Type Semantics: list
• Description: The content of the SAV rules relevant to the validation decision.
• Reference: This document, savMatchedContentList

savPolicyAction

• ElementID: TBD4
• Name: savPolicyAction
• Abstract Data Type: unsigned8
• Data Type Semantics: identifier
• Description: Action applied to packets identified as spoofed.
• Reference: This document, IPFIX savPolicyAction Subregistry

References Normative References 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. 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. This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102. This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations. This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References Tsinghua University Zhongguancun Laboratory New H3C Technologies Tsinghua University Huawei China Mobile This document describes a YANG data model for Intra-domain and Inter-domain Source Address Validation (SAVNET). The model serves as a base framework for configuring and managing an SAV subsystem, including SAV rule and SAV Tables, and expected to be augmented by other SAV technology models accordingly. Additionally, this document also specifies the model for the SAV Static application. 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) that are not dedicatedly designed for source filtering. Consequently, these mechanisms have limitations in deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces general SAV capabilities from a data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. [STANDARDS-TRACK] This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals. n.d.

IPFIX Encoding Examples This appendix provides encoding examples for the SAV-specific IPFIX IEs defined in this document.

Template Record and Data Record with Sub-Template List This example demonstrates the encoding for two observed SAV enforcement events representing different validation scenarios and address families as shown in Table 2. Table 2: Two Observed SAV Validation Events The first event represents an IPv4 allowlist non-match event where a packet from source 192.0.2.100 arriving on interface 5001 failed to match any source prefixes configured in the interface-based allowlist. The second event represents an IPv6 blocklist match event where a packet from source 2001:db8::1 was received on interface 5002, which matched a prefix-based blocklist rule.

Sub-Template Definitions The following sub-templates are defined for use within the savMatchedContentList element to encode different types of SAV rule mappings based on address family and validation target type. The savMatchedContentList element is encoded as a subTemplateList according to . The template IDs used in these examples are exemplary and chosen arbitrarily. In actual implementations, exporters MUST assign unique template IDs within the IPFIX session for these sub-templates.

• Sub-Template 901: IPv4 Interface-to-Prefix Mapping

This sub-template is used when savTargetType=1(interface-based validation mode) for IPv4 traffic. It contains the mapping from an interface to source IPv4 prefixes as defined in the SAV rule configuration. It can be used for both blocklist and allowlist. Figure 1: Sub-Template 901 (IPv4 Interface-to-Prefix Mapping)

• Sub-Template 902: IPv6 Interface-to-Prefix Mapping This sub-template is the IPv6 equivalent of Sub-Template 901, used for interface-based validation with IPv6 traffic.

Figure 2: Sub-Template 902 (IPv6 Interface-to-Prefix Mapping)

• Sub-Template 903: IPv4 Prefix-to-Interface Mapping

This sub-template is used when savTargetType=2(prefix-based validation mode) for IPv4 traffic. It contains the mapping from a source IPv4 prefixes to interface as defined in the SAV rule configuration. It can be used for both blocklist and allowlist. Figure 3: Sub-Template 903 (IPv4 Prefix-to-Interface Mapping)

• Sub-Template 904: IPv6 Prefix-to-Interface Mapping

This sub-template is the IPv6 equivalent of Sub-Template 903, used for prefix-based validation with IPv6 traffic. Figure 4: Sub-Template 904 (IPv6 Prefix-to-Interface Mapping)

Main Template Record The main Template Record (ID 400) contains fields for exporting detailed SAV enforcement information including the validation outcome and the specific rule content that triggered the action. The template incorporates the savMatchedContentList element as a variable-length subTemplateList to carry the relevant SAV rule contents using the appropriate sub-templates defined above. Figure 5: Main Template Record (ID 400)

Data Set Example The following Data Set contains two Data Records that represent the two SAV validation scenarios in Table 2. The first Data Record (allowlist non-match) encodes the complete set of allowed prefixes using Sub-Template 901 with the allOf semantic (0x03). The allowlist includes three SAV rules for ingressInterface 5001, with sourceIPv4Prefix values 198.51.100.0/24, 203.0.113.0/24, and 192.0.2.128/25. The second Data Record (blocklist match) encodes the specific blocked interface using Sub-Template 904 with the exactlyOneOf semantic (0x01). The matched rule is sourceIPv6Prefix 2001:db8::/32 on ingressInterface 5002. The figure below uses abbreviated IE names: savRT for savRuleType, savTT for savTargetType, savAct for savPolicyAction, sPrf4Len for sourceIPv4PrefixLength, and sPrf6Len for sourceIPv6PrefixLength. Figure 6: Data Set Example