| Internet-Draft | DSAV Framework | January 2022 |
| Li, et al. | Expires 15 July 2022 | [Page] |
This document provides an overall framework of Distributed Source Address Validation (DSAV) including both intra-domain and inter-domain levels. It also describes related considerations.¶
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 15 July 2022.¶
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 to mitigate source address spoofing and contribute to the Internet security. However, existing SAV mechanisms have limitations in accuracy. Specifically, intra-domain SAV mechanisms (e.g. strict uRPF[RFC3704]) usually improperly block legitimate traffic in the case of routing asymmetry, while inter-domain SAV mechanisms (e.g. loose uRPF[RFC3704] and EFP-uRPF[RFC8704]) provide overly loose SAV rules which can improperly permit spoofed traffic. The root cause of their limitations is that they all achieve SAV based on local forwarding information base (FIB) or routing information base (RIB), which may not match the real forwarding direction from the source. In order to guarantee the accuracy, SAV should follow the real data-plane forwarding path.¶
This document provides a framework to generate accurate SAV rules on routers at both intra-domain and inter-domain levels. In Distributed Source Address Validation (DSAV) framework, each router or AS originates individual protocol messages to its neighbors, carrying local source information and corresponding destination information which takes the neighbor as the next hop. Upon receiving a protocol message, the router or AS identifies a valid incoming interface for the related source addresses. After that, it decides whether to terminate the message or further relay new protocol messages to its neighbors based on the destination information of the received message. In this way, the source information will propogate through all possible forwarding paths originated from the source.¶
This document also describes basic considerations related to DSAV, including accuracy, consistency, deployability, and security.¶
Some definitions during a propagation process:¶
DSAV provides a framework for distributedly generating SAV rules on nodes at both intra-domain and inter-domain levels. Intra-domain SAV avoids source address spoofing within the same AS. Inter-domain SAV prevents source address spoofing among ASes. Despite of different application scenarios and protocol details, DSAVs at the two levels hold the same key idea. The core workflow of DSAV is briefly described as follows:¶
Figure 1 illustrates the workflow of DSAV. The network runs some routing protocols such as OSPF, IS-IS, or BGP among the four nodes. Each node owns a unique source prefix ( e.g. P1 for Node 1). Let's consider the propagation process where Node 1 is the initial node. Node 1 sends an original message to the neighbor Node 2, carrying its source prefix (i.e., P1) and destination prefixes whose next-hop node in FIB is Node 2 (i.e., P2, P3, P4). When Node 2 receives the message, it specifies interface '#' as the valid incoming interface for prefix P1. Then, Node 2 checks the destination prefixes according to its local FIB. Since P3 and P4 are not Node 2's source prefixes, it should relay messages to the corresponding next-hop nodes, i.e. Node 3 and Node 4. The message destined to Node 3 carries the destination prefix P3, while the message destined to Node 4 carries the destination prefix P4. The source prefix in each relayed message keeps the same. When Node 3 or Node 4 receives the message from Node 2, it also learns and enables the SAV rule <P1, interface '#'> but terminates the message.¶
+----------+
| Node 1 +---+P1
+----+-----+
| pkt:src_v=[P1],
| dst_v=[P2,P3,P4]
pkt:src_v=[P1], |
+----------+ dst_v=[P4] +-----#-----+
| Node 4 #-------------+ Node 2 |---+P2
+-----+----+ +-----+-----+
| | pkt:src_v=[P1],
+ | dst_v=[P3]
P4 |
+-----#-----+
| Node 3 +---+P3
+-----------+
- P1, P2, P3, and P4 are prefixes belonging to
Node 1, 2, 3, and 4, respectively.
- Node 1 is the initial node, and Node 3 and Node 4
are the terminate nodes in this propagation process.
- '#' means the legitimate interface for the
data-plane packets with source addresses of P1.
Figure 1: The workflow of DSAV
¶
Containing source prefixes and destination prefixes in a message sometimes induces much unnecessary overhead. For example, a change on a destination prefix or forwarding path will make the initial node advertise its source prefixes again even though no changes happen on its local source prefixes at all. A separate source information advertisement is taken to tackle the above problem.¶
Particularly, a node can be represented by a node ID (e.g., the router-ID for a router or the ASN for an AS). For each initial node, its source prefixes together with its node ID can be advertised to other nodes through broadcast or existing underlay routing protocols (such as OSPF, IS-IS, and BGP). Then, other nodes will know the mapping from a node ID to a list of source prefixes. Now, the protocol message does not need to carry a long list of source prefixes whose field can be replaced with just one source node ID.¶
Although separate source information advertisement help reduce communication overhead, including destination prefixes in messages can still be costly, especially in inter-domain scenarios with a large number of destination prefixes.¶
Similarly, a list of destination prefixes can also be replaced with a destination node IDs (e.g., the router-ID for a router or the ASN for an AS). Considering that a node may have hundreds of different prefixes, this can significantly reduce overhead. However, the replacement of destination prefixes may result in accuracy problems in some scenarios where the destination prefixes belonging to a same destination node have different forwarding paths. Some additional mechanisms need to be imported into these scenarios.¶
The goal of DSAV is to achieve high accuracy, i.e., avoid improper block problems and try best to reduce improper permit problems. The improper block problem means legitimate traffic is mistakenly dropped. The improper permit problem means spoofed traffic is mistakenly passed.¶
The accuracy of DSAV is determined by the accuracy of source information advertisement and propagation process. The incompleteness of received source information can compromise the accuracy of SAV. So, each initial node should discover and advertise local source information carefully with the help of either automatic programs or manual configurations. In the case of incomplete source information, the node can take a remedy method at the data plane, i.e., only drop packets with known source addresses but coming from invalid interfaces. Packets with unknown source addresses should be accepted by default. More details will be described in Section 6.¶
The key of DSAV is to generate SAV rules strictly following the real data-plane forwarding paths. Any factor that can affect forwarding should be considered. Here are three kinds of common forwarding cases:¶
As described in Section3, DSAV can work well in the first case. To ensure accuracy in arbitrary routing scenarios, the last two cases should also be considered.¶
The factors influencing the accuracy of DSAV may change with time. Such changes will lower the performance of SAV and lead to improper block or improper permit problems. The SAV rules generated through DSAV should be updated in time so as to keep consistent with routing states. The consistency of DSAV is important for the SAV framework working well in real networks.¶
A simple method is to send updated messages periodically. An aging mechanism can also be used for SAV rules. That is, SAV rules will expire after a period of time. However, these solutions may take much time before eliminating improper block and improper permit problems. Some quick convergence mechanisms are necessary to achieve consistency of DSAV in time. Here are some preliminary ideas for different cases:¶
It is difficult to ensure that all nodes deploy DSAV simultaneously, especially at inter-domain level. In this case, each node only learns partial source address information or incomplete legitimate incoming interfaces for a source prefix, which can lead to improper block problems. Therefore, DSAV should support incremental and partial deployment.¶
When deployed incrementally or partially, nodes should still aviod improper block problems and minimize improper permit problems based on incomplete SAV tables. The process of data-plane SAV is as follows:¶
Since inter-domain topology is greatly complex and ASes are managed by individual network operators, determining whether the incoming interface information for a source prefix is learned completely is a real challenge. Besides, in DSAV framework, neighboring (next-hop) node plays an important role in the propagation of probing packets, namely, a node cannot send or receive any probing packet if its neighboring nodes don't support DSAV. Hence, at inter-domain level, DSAV recommends incremental deployment by customer cones. This deployment pattern ensures that each AS learns complete source address information and incoming interface information for other ASes within the same customer cone. With the merger of different customer cones where DSAV is deployed, the deployment scope of DSAV will gradually expand, and the defense capability against source address spoofing will gradually increase.¶
TBD¶