| Internet-Draft | Intra-domain SAVNET Problem Statement | July 2022 |
| Li, et al. | Expires 11 January 2023 | [Page] |
Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) aims to make improvements to existing intra-domain Source Address Validation (SAV). This document provides the gap analysis of existing intra-domain SAV mechanisms, describes the fundamental problems, and defines the requirements for improvements.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 8174 [RFC8174].¶
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 11 January 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
Source Address Validation (SAV) is important for defending against source address spoofing attacks and accurately tracing back to the attackers. To be as effective as possible, SAV should be implemented as close to the source as possible. Given numerous access networks managed by different operators, it is difficult to require all access networks to deploy SAV. When some access networks do not deploy SAV, intra-domain SAV helps filter out spoofed packets as close to the source as possible.¶
Ingress filtering [RFC2827] [RFC3704] is the current practice of intra-domain SAV. It is recommended to be deployed at the ingress point of each subnet to prevent spoofed packets from entering the intra-domain network. Static Access Control List (ACL) is a typical implementation of ingress filtering. Operators can configure some matching rules to specify which source addresses are acceptable (or unacceptable). The information of ACL should be updated manually so as to keep consistent with the newest filtering criteria, which inevitably limits the flexibility and accuracy of SAV. Strict unicast Reverse Path Forwarding (uRPF) [RFC3704] is another suitable solution to achieve ingress filtering in intra-domain networks. Routers deploying strict uRPF accept a data packet only when i) the local forwarding information base (FIB) contains a prefix encompassing the packet's source address and ii) the corresponding forwarding action for the prefix matches the packet's incoming port. Otherwise, the packet will be blocked. However, in the scenario where data packets are under asymmetric routing, strict uRPF often improperly blocks legitimate traffic. Feasible uRPF and loose uRPF are two other alternative implementations of ingress filtering, but their filtering rules are very loose and generally permit all received packets. Therefore, a new intra-domain SAV mechanism is required to improve accuracy upon current ones.¶
This document provides the gap analysis of existing intra-domain SAV mechanisms, describes their fundamental problems, and defines the requirements for improvements.¶
SAV: Source Address Validation, i.e. validating the authenticity of a packet's source IP address.¶
SAV rule: The filtering rule generated by the intra-domain SAV mechanism that determines valid incoming interfaces for a specific source prefix.¶
SAV table: The data structure that stores SAV rules on the data plane. The router queries its local SAV table to validate the authenticity of source addresses.¶
Improper block: Cases when packets with legitimate source addresses are improperly blocked.¶
Improper permit: Cases when packets with spoofed source addresses are improperly permitted.¶
As shown in Figure 1, ingress filtering is typically deployed at the ingress point of the subnet. It only works for outbound traffic (traffic from subnet to intra-domain network) but does not work for inbound traffic (traffic from intra-domain network to subnet). It prevents the deployed area from sending spoofed packets, but does not protect the deployed area from source address spoofing attacks. Due to the lack of inbound SAV, spoofed packets (even with source addresses of the subnet itself) can easily enter the subnet, although the edge router connected to the subnet has deployed ingress filtering. Therefore, it is generally agreed that ingress filtering only helps when all edge routers in the Autonomous System (AS) have deployed ingress filtering.¶
+-----------------------------------------------------+ | AS | | +----------+ +----------+ | | | Router 2 | | Router 3 | | | +------+\+-+ +-+/+------+ | | \ / | | Inbound traffic | | \ / | | +-+\/++\/+-+ | | | Router 1 | | | +----^-----+ | | Ingress filtering+---> | | | Outbound|traffic | | | | | +----------+ | | | Subnet | | | +----------+ | | | +-----------------------------------------------------+ Figure 1: Ingress filtering only works for outbound traffic¶
Even if all edge routers implement ingress filtering with strict uRPF, strict uRPF may also fail in the case of multi-homed subnet. Figure 2 illustrates a multi-homed subnet scenario. Subnet 1 is attached to two edge routers, i.e. Router 1 and Router 2. Due to the load balance policy of Subnet 1, Subnet 1 advertises 10.0.0.0/16 to Router1 and 10.1.0.0/16 to Router 2, respectively. Then, Router 1 and Router 2 will advertise the learned sub prefixes to other routers in the AS through intra-domain routing protocols such as OSPF and IS-IS. In the end, Router 1 learns the route to 10.1.0.0/16 from Router 3, and Router 2 learns the route to 10.0.0.0/16 from Router 4.¶
If Router 1 applies strict uRPF at the subnet interface, the SAV rule is that Router 1 only accepts packets with source addresses of 10.0.0.0/16 from Subnet 1. Although Subnet 1 only advertises 10.0.0.0/16 to Router 1, it may send packets with source addresses of prefix 10.1.0.0/16 to Router 1. In this case, strict uRPF at Router 1 will improperly block these legitimate packets. Similarly, when Router 2 with strict uRPF receives packets with source addresses of prefix 10.0.0.0/16 from Subnet 1, it will also improperly block these legitimate packets.¶
+---------------------------------------------------------------+
| AS |
| 10.1.0.0/16 +----------+ +----------+ |
| +--------------> Router 2 +-----+ Router 4 | |
| | +----------+ +----------+ |
| | | |
| +---------------+ | |
| | Subnet 1 | | |
| | 10.0.0.0/15 | | |
| +---------------+ | |
| | | |
| | +----------+ +----------+ |
| +--------------> Router 1 +-----+ Router 3 | |
| 10.0.0.0/16 +----------+ +----------+ |
| |
+---------------------------------------------------------------+
Figure 2: A multi-homed subnet scenario.¶
Given the technical limitations of existing ingress filtering mechanisms (for example, strict uRPF-based ingress filtering may fail in multi-homed subnet scenario, while ACL-based ingress filtering needs costly manual operation), it is difficult to require all edge routers of an AS to implement ingress filtering simultaneously. Moreover, subnets in a large AS may also be managed by different operators (e.g., subnets in the education network are administered by different campuses). Some operators may not be willing to apply ingress filtering, since ingress filtering does not protect the deployed area from source address spoofing attacks but constrains the behavior of the deployed area.¶
+------------------------------------------------------------------+
| |
| AS |
| +----------+ +----------+ |
| | Router 6 +------------+ Router 7 | |
| +----------+ +----------+ |
| / / \ |
| / / \ |
| / / \ |
| +----------+ +----------+ +----------+ |
| | Router 2 | | Router 5 | | Router 4 | |
| +-+--------+ +----+-----+ +--------+-+ |
| + \ + \ / + |
| Subnet2(p2) \ Subnet5(p5)\ / Subnet4(p4) |
| \ \ / + |
| +----------+ +----------+ | |
| | Router 1 | | Router 3 +------+ |
| +-----+----+ +-----+----+ |
| + + |
| Subnet1(p1) Subnet3(p3) |
+------------------------------------------------------------------+
Router 1, 2, 6, and 7 deploy ingress filtering
Router 3, 4, and 5 do not deploy ingress filtering
Figure 3: A partial deployment scenario
¶
Figure 3 illustrates a partial deployment scenario. There are seven routers in the AS. Router 1, 2, 3, 4, and 5 are edge routers. Router 6 and 7 are two intra-domain routers located at the aggregation points, which are responsible for transmitting traffic. Assume Router 1 and 2 apply ingress filtering at subnet interfaces, while Router 3, 4, and 5 do not apply ingress filtering. In this case, although Subnet 1 and 2 cannot forge source addresses of other subnets, Subnet 3, 4, and 5 can easily forge source addresses of the deployed area. For example, when Subnet 3, 4, and 5 send spoofed packets with source addresses of p1 or p2 to carry out reflection attacks, Router 1 and 2 may receive these spoofed packets but cannot identify and reject them. To improve the effectiveness of intra-domain SAV when it is partially deployed, it is necessary to perform SAV at more intra-domain routers (at least routers at aggregation points).¶
To this end, Router 6 and Router 7 apply SAV filtering with strict uRPF at interfaces connected to neighboring routers. However, there will be improper block problems in the case of routing asymmetry. Assume there is asymmetric routing between p2 and p3. The forwarding path from p2 to p3 is Router 2 -> Router 6 -> Router 7 -> Router 5 -> Router 3. While the forwarding path from p3 to p2 is Router 3 -> Router 4 -> Router 7 -> Router 6 -> Router 2 because of traffic engineering. If Router 7 applies strict uRPF at interfaces connected to the undeployed area, one SAV rule is that packets with source addresses of p3 must arrive from Router 5 since the next hop to p3 in Router 7's FIB is Router 5. In this way, when Router 3 sends legitimate packets with source addresses of p3 to p2, Router 7 will improperly block these packets upon receiving them from Router 4.¶
Besides, once an edge router misbehaves, packets with spoofed source addresses can successfully flow from the misbehaved edge router to anywhere in the intra-domain network. To increase the resilience of intra-domain SAV to potential misbehavior, it is desirable to also perform SAV at other intra-domain routers to block spoofed packets as close to the source as possible. However, as mentioned above, existing ingress filtering mechanisms are not competent to perform accurate SAV for packets received from a neighboring router, and can cause traffic disruption.¶
High accuracy, i.e., avoiding improper block problems while trying best to reduce improper permit problems, is the basic and key problem of an SAV mechanism. However, ACL-based ingress filtering needs manual configuration and thus faces limitations in flexibility and accuracy in dynamic networks. Strict uRPF-based ingress filtering automatically generates SAV tables, but may improperly block legitimate traffic in some cases. The root cause is that strict uRPF leverages the local FIB table to determine the incoming interface for source addresses, which may not match the real data-plane forwarding path from the source, due to the existence of asymmetric routes. Hence, it may mistakenly consider a valid incoming interface as invalid, resulting in improper block problems; or consider an invalid incoming interface as valid, resulting in improper permit problems. Essentially, it is impossible to generate an accurate SAV table solely based on the router's local information due to the existence of asymmetric routes.¶
Currently, ingress filtering is applied at edge routers and only works for outbound traffic but does not work for inbound traffic. This kind of implementation aims to prevent the deployed area from sending spoofed packets, but not to protect the deployed area from attacks. The benefits of the adoption of ingress filtering flow to the rest of the AS, but not to the deployed area itself. As aforementioned, when ingress filtering is partially deployed, the deployed area is still vulnerable to reflection attacks from the undeployed area.¶
To improve the accuracy and incentive upon current intra-domain SAV mechanisms, the architecture of intra-domain SAVNET should satisfy the following requirements.¶
To determine the accurate incoming interfaces for a specific source prefix, routers should be able to learn the real incoming interfaces for packets originated from the subnet which owns the source prefix. In other words, SAV table generation should follow real data-plane forwarding path information. Since this requirement cannot be met by using local FIB information, additional mechanisms are needed to deliver the required information.¶
Intra-domain SAVNET should be deployed in more routers than only the first-hop router (ingress filtering), and should work for traffic coming from all directions (i.e. for traffic from both subnet and neighboring router).¶
Intra-domain SAVNET should support incremental deployment and can provide direct benefits to the deployed area. When it is partially deployed, it should help the deployed area mitigate reflection attacks from undeployed area.¶
TBD¶
TBD¶