]> Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Huawei

Beijing China gengnan@huawei.com

Zhongguancun Laboratory

Beijing China qinlc@mail.zgclab.edu.cn

Routing SAVNET Internet-Draft The new intra-domain source address validation (SAV) mechanism requires improving the accuracy (especially avoiding blocking legitimate traffic) and supporting automatic update (see ). To this end, this document proposes an intra-domain SAV mechanism, called source prefix advertisement (SPA) for intra-domain SAVNET (SPA-based SAVNET for short), to advance the technology for intra-domain SAV. SPA-based SAVNET allows routers in an intra-domain network to exchange SPA information. By using SPA information and routing information, intra-domain routers can determine more accurate SAV rules in an automatic manner.

Introduction The main purpose of intra-domain SAV for an AS is blocking spoofing data packets from host networks and customer networks that use a source address of other networks and blocking spoofing data packets from external ASes that use a source address of the local AS (see ). However, existing uRPF mechanisms will improperly block legitimate data packets in the case of asymmetric forwarding or asymmetric routing, while ACL-based ingress filtering relies entirely on manual update (see ). To improve the accuracy and enable automatic update, this document proposes an intra-domain SAV mechanism, called source prefix advertisement (SPA) for intra-domain SAVNET (SPA-based SAVNET for short), to advance the technology for intra-domain SAV. SPA-based SAVNET allows routers in an intra-domain network to exchange SPA information. By using SPA information and routing information, intra-domain routers can determine more accurate SAV rules in an automatic manner. The reader is encouraged to be familiar with and .

Terminology SAV Rule: The rule that describes the mapping relationship between a source address (prefix) and its valid incoming router interface(s). SAVNET Router: An intra-domain router that deploys SPA-based SAVNET. Host Network: An intra-domain stub network consists of hosts. Customer Network: An intra-domain stub network consists of hosts and routers. Host-facing Router: An intra-domain router facing an intra-domain host network. Customer-facing Router: An intra-domain router facing an intra-domain customer network.

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.

Overview of SPA-based SAVNET The deployment scope of SPA-based SAVNET for an AS includes host-facing routers, customer-facing routers, and AS border routers. SPA-based SAVNET allows these routers to exchange SPA information through the existing internal gateway protocol (IGP). By learning SPA information from other SAVNET routers, each SAVNET router can generate an allowlist SAV rule (i.e., "Interface-based prefix allowlist" mode in ) or a blocklist SAV rule (i.e., "Interface-based prefix blocklist" mode in ) on the specific router interface:

• For host-facing routers, they generate an allowlist SAV rule on interfaces facing a host network. The allowlist SAV rule exactly covers the space of source IP addresses that are used by data packets of the host network.
• For customer-facing routers, they generate an allowlist SAV rule on interfaces facing a customer network. The allowlist SAV rule exactly covers the space of source IP addresses that are used by data packets of the customer network.
• For AS border routers, they generate a blocklist SAV rule on interfaces facing an external AS. The allowlist SAV rule exactly covers the space of source IP addresses that are used by data packets of the local AS.

SPA-based SAVNET provides incremental benefits when incrementally deployed within the deployment scope. Every SAVNET router that adopts SPA-based SAVNET can identify spoofing data packets coming from a host network, customer network, or an AS. By using allowlist SAV rules, host-facing routers and customer-facing routers that adopt SPA-based SAVNET will block spoofing data packets from host networks and customer networks that use a source address of other networks. By using blocklist SAV rules, AS border routers that adopt SPA-based SAVNET will block spoofing data packets from external ASes that use a source address of the local AS. In the following, this document describes the protocol-independent designs for SPA-based SAVNET, include procedures for SPA information generation (in ), SPA information communication (in ), and SAV rule generation (in ). SPA information communication can be implemented by using an existing routing protocol. Specific protocol designs or extensions for SPA information communication are not in the scope of this document.

SPA Information Generation Each SAVNET router connected to an intra-domain stub network (e.g., a host network or a customer network) generates SPA information. The content of SPA information mainly includes two parts:

• Source Prefix List (SPL): This list includes prefixes learned from the router's local routes towards the stub network. Specifically, each Dest Prefix in the router's RIB that has an outgoing interface towards the stub network will be included. If there is no asymmetric route between the SAVNET router and the stub network, the generated SPL should cover the source IP address space used by data packets of the stub network. However, if the asymmetric route exists, the generated SPL may include only a portion of the source IP address space of the stub network.
• Stub Network Identifier (SNI): This identifier indicates the identity of a stub network. Every intra-domain stub network must have a unique SNI value. Each prefix in the SPL is labeled with the SNI value of the corresponding stub network.

SPA Information Communication After generating SPA information, each SAVNET router will provide its SPA information to other SAVNET routers. SPA information communication can be implemented by using the IGP (e.g., OSPF, IS-IS, or IBGP). During the propagation of IGP messages, SAVNET routers can learn both routing information and SPA information.

SAV Rule Generation After receiving SPA information from other SAVNET router, SAVNET routers generate allowlist SAV rules or blocklist SAV rules on specific router interfaces. The detailed procedure for allowlist generation is as follows:

1. Considering all stub network connected to the router, create a set of SNI values of these stub network. Call it Set A.
2. Considering all SPA information, for each SNI value in Set A, create a set of unique source prefixes that have the same SNI value. Include these prefixes into the allowlist SAV rule at router interfaces facing the stub network which has the same SNI value.

The detailed procedure for blocklist generation is as follows:

1. Extract unique prefixes from SPA information and routing information learned from the IGP.
2. Include these prefixes into the blocklist SAV rule at router interfaces facing an external AS.

Use Case

SAV on Host-facing Routers, Customer-facing Routers, and AS Border Routers SPA-based SAVNET is used on host-facing Routers, customer-facing Routers, and AS border routers in an intra-domain network. It is a general intra-domain SAV mechanism that apply to different network topologies (e.g., mesh topology or tree topology) or routing scenarios (e.g., asymmetric routing or symmetric routing). The network operator can incrementally deploy SPA-based SAVNET in his/her AS to gradually improve the defense against source address spoofing attacks. shows an example. Customer Network is multi-homed to Routers A and B. Host Network is single-homed to Router C. Routers D and E are connected to external ASes. Data packets from Customer Network can use source addresses in prefixes P1 and P2. Data packets from Host Network can use source addresses in prefix P3. P' is the source IP address space for intra-domain router IPs and link IPs. Assume there is an asymmetric forwarding behavior or an asymmetric route between Router A, Router B, and Customer Network due to traffic engineering and load balance. For example, Router A forwards only data packets with destination addresses in prefix P1 to Customer Network while forwards others to Router B. Router B forwards only data packets with destination addresses in prefix P2 to Customer Network while forwards others to Router A. However, Customer Network will sends data packets with source addresses in prefixes P1 and P2 to both routers. In this case, as described in , strict uRPF on Router A's Interface # will improperly block data packets with source addresses in prefix P2, and strict uRPF on Router A's Interface # will improperly block data packets with source addresses in prefix P2, and strict uRPF on Router B's Interface # will improperly block data packets with source addresses in prefix P1.

An example of the most recommended use case of SPA-based SAVNET

When deploying SPA-based SAVNET in this AS, SAVNET Routers A, B, and C will provide SPA information to other SAVNET routers. By using the received SPA information, Routers A and B will include both prefixes P1 and P2 in the allowlist at the Interface #, because both prefixes have the SNI value of Customer Network, even if the prefix that routers A and B learn from the local route to Customer Network may be different. Router C will include prefix P3 in the allowlist at its Interface #. Routers D and E will include all internal prefixes in the blocklist at their Interfaces #. By using the generated allowlist SAV rules or blocklist SAV rules, SPA-based SAVNET effectively blocks spoofing data packets from host networks and customer networks that use a source address of other networks and blocks spoofing data packets from external ASes that use a source address of the local AS, while avoiding blocking legitimate data packets.

A Special Scenario: Direct Server Return (DSR) In the case of DSR, the content server in a stub network will send data packets using source addresses of the anycast server in another AS (see ). To avoid blocking these special data packets, these specially used source addresses must be added into the allowlist SAV rule at interfaces facing a stub network where the content server locates. Since routers as well as current routing architecture do not have this information, this may requires manual configuration.

Security Considerations The security considerations described in and also applies to this document.

IANA Considerations This document has no IANA actions.

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. Zhongguancun Laboratory China Mobile Tsinghua University Huawei Technologies Huawei Technologies Zhongguancun Laboratory New H3C Technologies 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. 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 requirements for technical improvements. Tsinghua University Tsinghua University Zhongguancun Laboratory Huawei Zhongguancun Laboratory This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms [RFC3704] that only depend on routers' local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL-based ingress filtering [RFC2827] that entirely requires manual efforts to accommodate to network dynamics, SAVNET routers learn SAV rules automatically in a distributed way.