]> Huawei

Beijing China gengnan@huawei.com

Zhongguancun Laboratory

Beijing China qinlc@zgclab.edu.cn

Routing SAVNET Internet-Draft This document provides an overview of terms and abbreviations related to Source Address Validation (SAV). Its purpose is to establish a common and consistent set of terminology for use across SAV-related discussions and documents. This document explicitly does not serve as an authoritative source of correct terminology.

Introduction This document provides an overview of terms and abbreviations related to Source Address Validation (SAV). Its purpose is to establish a common and consistent set of terminology for use across SAV-related discussions and documents. This document explicitly does not serve as an authoritative source of correct terminology.

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.

General Terms

Network and Topology Terms

• Autonomous System (AS): A set of routers under a single technical administration .
• AS Number (ASN): A 16-bit or 32-bit number uniquely identifying an Autonomous System.
• Sub Network: A sub network may operate its own internal routing protocols, but it is considered part of the AS in the global routing system. It is connected to one or more routers of the AS for Internet connectivity. It originates traffic but does not transit traffic for other networks .
• Provider (aka Provider AS): The provider in a customer-to-provider relationship (if looked at from the opposite direction, provider-to-customer ). A Provider may propagate any available route to a Customer .
• Customer (aka Customer AS): The customer in a customer-to-provider relationship. A Customer may propagate any route learned from a Customer, or that is locally originated, to a Provider. All other routes must not be propagated .
• Peer (aka Peer AS or Lateral Peer or Lateral Peer AS): The peers in a lateral peering relationship. A Peer may propagate any route learned from a Customer, or that is locally originated, to a Peer. All other routes must not be propagated .
• Customer Cone: The set of ASes that an AS can reach by using only provider-to-customer links .
• Provider Cone: The set of ASes that an AS can reach by using only customer-to-provider links .

Router and Interface Terms

• Edge Router: The router that is directly connected to a Sub Network or a host .
• AS Border Router (ASBR): The router that connects an AS to other ASes.
• Internal Router: The router that is neither an edge router nor a border router in an AS.
• Customer Interface (aka Customer-facing Interface): The interface of an ASBR facing a Customer .
• Lateral Peer Interface (aka Lateral Peer-facing Interface): The interface of an ASBR facing a Lateral Peer .
• Provider Interface (aka Provider-facing Interface): The interface of an ASBR facing a Provider .

Routing Terms

• Interior Gateway Protocol (IGP): A type of routing protocol used within a single AS to exchange routing information between routers.
• Intermediate System to Intermediate System (IS-IS): A link-state routing protocol belonging to IGP and designed to dynamically exchange routing information within a single AS .
• Open Shortest Path First (OSPF): Another link-state routing protocol belonging to IGP and designed to dynamically exchange routing information within a single AS .
• Border Gateway Protocol (BGP): A path-vector routing protocol used in the global Internet to exchange routing information between different ASes .
• Routing Information Base (RIB): A database within a router or network host that stores routing information. RIB is also known as routing table.
• Forwarding Information Base (FIB): The table containing the information necessary to forward IP Datagrams . FIB is also known as forwarding table. FIB stores the best active routes, which are a subset of those found in the RIB.
• Virtual Routing and Forwarding (VRF): The routing (or forwarding) tables separate from the global routing (or forwarding) table in a router .
• Asymmetric Routing: Asymmetric routing means a packet traverses from a source to a destination in one path and takes a different path when it returns to the source. Asymmetric routing can occur within an AS due to routing policy, traffic engineering, etc .

Routing Security Terms

• Resource Public Key infrastructure (RPKI): A specialized public key infrastructure (PKI) framework to support improved security for the Internet's BGP routing infrastructure .
• Route Origin Authorization (ROA): A digitally signed object in the RPKI that provides a means of verifying that an IP address block holder has authorized an AS to originate routes to one or more prefixes within the address block .
• Autonomous System Provider Authorization (ASPA): A digitally signed object in the RPKI, that authorizes one or more other ASes as its upstream providers .
• Internet Routing Registry (IRR): A public database which allows Internet service providers to publish and look up Internet number bindings and policy objectives.
• Resource holder: A legitimate holder of either IP address or AS number resources .

Others

• Direct Server Return (DSR): A Content Delivery Network (CDN) technique. The anycast server receives requests from users and creates tunnels to the edge server, and the edge server directly sends the requested content to users. The source address of the response packets is the anycast IP address of the anycast server, but the network hosting the edge server does not announce the anycast address in BGP .

SAV Terms

General SAV Terms

• Source Address Spoofing (aka Source Address Forgery): The act of using spoofed source IP addresses assigned to other machines. Malicious actors use IP spoofing to invoke a variety of attacks, including Distributed Denial of Service (DDoS) attacks, policy evasion, and a range of application-level attacks . A spoofed source address can be either IPv4 or IPv6.
• Source Address Validation (SAV): A kind of techniques for the detection and mitigation of Source Address Spoofing . Routers conduct SAV on data packet in the data plane. SAV focuses on the scenarios of native IP forwarding or IP-encapsulated tunnel (IPsec, GRE, SRv6, etc.). Note that, the SAV mechanisms that the SAVNET working group is interested in should not modify data plane packets .
• SAV Rule: The rule that describes the binding relationship between a source address (prefix) and a valid/invalid incoming interface(s) . SAV Rules can be used for validating whether a data packet with a source address arrive at the router (enforing SAV based on SAV Rules) from an expected interface, and thus determining whether the source address is spoofed (i.e., valid) or not (i.e., invalid).
• SAV Table: The table or data structure that implements the SAV rules and is used for performing source address validation in the data plane .
• Access Network SAV: It prevents a host in a network from spoofing the address of another host in the same network segment. Access Network SAV enables source address-granularity of protection .
• Intra-domain SAV (aka Intra-AS SAV): It prevents a Sub Network from using a source address out of the Sub Network or prevents a host from using a source address out of the network segment. Intra-domain SAV mostly enables source prefix-granularity of protection.
• Inter-domain SAV (aka Inter-AS SAV): It prevents Source Address Spoofing packets across ASes. Inter-domain SAV mostly enables source prefix-granularity of protection.
• Source Address Validation Architecture (SAVA): A multiple-fence architecture that takes Access Network SAV, Intra-AS SAV, and inter-AS SAV . The assumption here is that when access-network SAV is not universally deployed, Intra-AS SAV and Inter-AS SAV can increase the defense in depth by blocking spoofing packets that have entered the network.
• Source Address Validation in Intra-domain and Inter-domain Networks (SAVNET): It refers to both Intra-domain SAV and Inter-domain SAV. The SAVNET working group was created for the evolvement of SAVNET mechanisms .

SAV Enforcement Terms

• Validation Mode: The mode indicates how SAV Rules are logically organized and used to conduct validation .
• Interface-based Source Prefix Allowlist (aka Source Prefix Allowlist): A Validation Mode that takes effect on a specific interface. The interface enabling this mode maintains a source prefix list. Only the source addresses encompassed by the source prefixes recorded in the list will be considered valid, otherwise invalid .
• Interface-based Source Prefix Blocklist (aka Source Prefix Blocklist): A Validation Mode that takes effect on a specific interface. The interface enabling this mode maintains a source prefix list. Any source addresses encompassed by the source prefixes recorded in the list will be considered invalid, otherwise valid .
• Source Prefix-based Interface Allowlist: A Validation Mode that takes effect at the router scale. The router enabling this mode will record the source prefixes attached with an interface allowlist. For the packet whose source address is encompassed by a recorded source prefix, the packet is considered valid only when its incoming interface is included in the corresponding interface allowlist. Otherwise, the packet is considered invalid. For the packet whose source address is encompassed by no recorded source prefix, the validity of the packet is unknown .
• Source Prefix-based Interface Blocklist: A Validation Mode that takes effect at the router scale. The router enabling this mode will record the source prefixes attached with an interface blocklist. For the packet whose source address is encompassed by a recorded source prefix, the packet is considered valid only when its incoming interface is not included in the corresponding interface allowlist. Otherwise, the packet is considered invalid. For the packet whose source address is encompassed by no recorded source prefix, the validity of the packet is unknown .
• Improper Block (aka False Positive): The problem that the packets with legitimate source addresses are improperly considered invalid due to inaccurate SAV Rules .
• Improper Permit (aka False Negative): The problem that the packets with spoofed source addresses are improperly considered valid due to inaccurate SAV Rules .
• Traffic Handling Policy: The data plane action taken on the incoming packet after the SAV process on the packet. Besides "Discard", many other actions such as "Permit", "Rate Limit", and "Traffic Redirect" can be chosen and taken for the packet with the invalid state .

SAV Mechanism Terms

• Access Control List (ACL) for SAV: A filter that checks the source address of a data packet against a list of acceptable or unacceptable prefixes .
• Strict unicast Reverse Path Forwarding (uRPF): A mechanism that uses FIB for SAV. An ingress packet is accepted only if the FIB contains a prefix that encompasses the source address and forwarding information for that prefix points back to the interface over which the packet was received .
• Feasible-Path uRPF (FP-uRPF): An extension of Strict uRPF. Instead of just inserting one best route there, the alternative paths (if any) have been added as well, and are valid for consideration .
• Loose uRPF: A mechanism checks only for the existence of a route (even a default route, if applicable), not where the route points to (At least some implementations of Loose uRPF check where the default route points to) .
• Loose uRPF Ignoring Default Route: Loose uRPF checks only for the existence of a explicit route (default routes are excluded) .
• VRF uRPF: A mechanism that takes SAV based on VRF table instead of FIB. The specific routes received from external BGP peers will be stored in a dedicated VRF table. VRF uRPF can be implemented to support the strict mode like Strict uRPF or the loose mode like Loose uRPF .
• Enhanced Feasible-Path uRPF (EFP-uRPF): A mechanism that is more flexible about directionality than the FP-uRPF and is for enhancing FP-uRPF in some cases. It is based on the principle that if BGP updates for multiple prefixes with the same origin AS were received on different interfaces (at border routers), then incoming data packets with source addresses in any of those prefixes should be accepted on any of those interfaces .
• BAR-SAV: A mechanism that generates source prefix allowlists by using BGP UPDATE messages, ASPA, and ROA .
• General SAV Information: The information that is not specialized for SAV but can be utilized to generate SAV rules, and is initially utilized for other purposes. Currently, the General SAV Information consists of the information from RPKI ROA objects and ASPA objects, local routing information, and the information from IRR data .
• SAV-specific Information: The information that is specialized for SAV rule generation, includes the source prefixes and their legitimate incoming directions to enter a router or an AS, and is exchanged among routers or ASes.
• SAV-related Information: The information that can be used to generate SAV rules and includes SAV-specific Information and General SAV Information.
• Source Entity (aka Source Router or Source AS): The Entity (Router/AS) that propagates its SAV-specific information to Validation Entity (Router/AS) . Source Entity is the producer of SAV-specific information.
• Validation Entity (aka Validation Router or Validation AS): The Entity (Router/AS) that receives SAV-specific information from Source Entity (Router/AS) . Validation Entity is the consumer of SAV-specific information.

Security Considerations This document provides an overview of terms and abbreviations related to SAV and does not have security considerations.

IANA Considerations There is no IANA requirement.

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 memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK] This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] 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. This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. This memo provides information for the Internet community. 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 discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. This memo defines an Experimental Protocol for the Internet community. This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK] This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK] 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. Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks. 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. Tsinghua University Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory Huawei This document provides a gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the basic requirements for technical improvements. Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory Huawei USA National Institute of Standards and Technology This document provides a gap analysis of existing inter-domain source address validation mechanisms, describes the problem space, and defines the requirements for technical improvements. Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei Zhongguancun Laboratory This document specifies the architecture of intra-domain SAVNET, which aims to achieve accurate source address validation (SAV) at external interfaces of an intra-domain network in an automated manner. It describes the conceptual design of intra-domain SAVNET, along with its use cases and design requirements, to help ensure that the intended objectives are met. Tsinghua University Zhongguancun Laboratory Huawei Zhongguancun Laboratory Zhongguancun Laboratory This document introduces an inter-domain SAVNET architecture for performing AS-level SAV and provides a comprehensive framework for guiding the design of inter-domain SAV mechanisms. The proposed architecture empowers ASes to generate SAV rules by sharing SAV- specific information between themselves, which can be used to generate more accurate and trustworthy SAV rules in a timely manner compared to the general information. During the incremental or partial deployment of SAV-specific information, it can utilize general information to generate SAV rules, if an AS's SAV-specific information is unavailable. Rather than delving into protocol extensions or implementations, this document primarily concentrates on proposing SAV-specific and general information and guiding how to utilize them to generate SAV rules. To this end, it also defines some architectural components and their relations. 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. 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. Huawei Technologies Huawei Technologies Huawei Technologies Huawei Technologies Tsinghua University Many source address validation (SAV) mechanisms have been proposed for preventing source address spoofing. However, existing SAV mechanisms are faced with the problems of inaccurate validation or high operational overhead in some scenarios. This document proposes BGP SAVNET by extending BGP protocol for SAV. This protocol can propagate SAV-related information through BGP messages. The propagated information will help edge/border routers automatically generate accurate SAV rules. These rules construct a validation boundary for the network and help check the validity of source addresses of arrival data packets. Zhongguancun Laboratory Tsinghua University Zhongguancun Laboratory Zhongguancun Laboratory The primary design goal of source address validation (SAV) is avoiding improper blocks (i.e., blocking legitimate traffic) while maintaining directionality (see [I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704]). Existing advanced SAV solutions (e.g., EFP-uRPF [RFC8704]) for an Autonomous System (AS) typically generate ingress SAV allowlist filters on interfaces facing a customer or lateral peer AS. This document analyzes the potential improper block problems when using an allowlist. To avoid improper blocks, this document proposes a new SAV solution by generating an ingress SAV blocklist filter which contains prefixes exclusively belonging to the provider cone. In practice, network operators can flexibly decide to use a blocklist or an allowlist according to their requirements and actual conditions. USA National Institute of Standards and Technology Akamai Technologies USA National Institute of Standards and Technology Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704.