Internet-Draft DSAV Framework December 2021
Li, et al. Expires 14 June 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-li-dsav-framework-00
Published:
Intended Status:
Informational
Expires:
Authors:
D. Li
Tsinghua
J. Wu
Tsinghua
M. Huang
Huawei
L. Qin
Tsinghua
N. Geng
Huawei

Distributed Source Address Validation (DSAV) Framework

Abstract

This document provides an overall framework of Distributed Source Address Validation (DSAV) including both intra-AS and inter-AS levels. It also describes related considerations.

Requirements Language

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 2119 [RFC2119].

Status of This Memo

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 14 June 2022.

Table of Contents

1. Introduction

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-AS SAV mechanisms (e.g. strict uRPF[RFC3704]) have serious false positive problems in the case of routing asymmetry, while inter-AS SAV mechanisms (e.g. loose uRPF[RFC3704] and EFP-uRPF[RFC8704]) have inherent false negative problems. 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 path probing-based framework to generate accurate SAV tables on routers at both intra-AS and inter-AS levels. In Distributed Source Address Validation (DSAV) framework, each router or AS originates probing packets carrying source address information as well as destination address information. Routers or ASes along the forwarding path can identify valid incoming interfaces for related source prefixes and relay new probing packets based on the destination address information. In particular, multicast tree-like path probing and separate address information advertisement are proposed in DSAV to reduce the communication overhead.

This document also describes basic considerations related to DSAV, including accuracy, consistency, and deployability.

2. Terminology

Distributed Source Address Validation (DSAV)

Some definitions during a path probing process:

3. DSAV Framework

DSAV is a path probing-based SAV framework for generating SAV rules on routers. It supports SAV at both the intra-AS and inter-AS levels. Intra-AS SAV avoids source address spoofing from within AS. Inter-AS SAV prevents source address spoofing among ASes. Despite of different application scenarios, DSAVs at the two levels hold the same key idea. The core workflow of DSAV is briefly described as follows:

  1. A probe initiation node (router or AS) generates probing packets carrying the source prefixes originated locally and the destination prefixes reachable by the node.
  2. Each probing packet will be forwarded from the probe initiation node to the corresponding destination node specified by the packets.
  3. Each on-path node along the forwarding path of the probing packet will learn the arrival interface of the probing packet. The learned interface will be considered as a legitimate arrival interface for data packets with same source IP addresses carried by the probing packet. The pair <source prefix, interface> will be taken as SAV rules on on-path nodes.
  4. These on-path nodes will enable the learned SAV rule at their data plane. Any data packets mismatching the SAV rule will be considered as forged traffic and be dropped immediately.
  5. Every node can act as a probe initiation node as well as an on-path node at the same time. It can send original probing packets to protect its source addresses from be forged by attackers. Meanwhile, it can be an on-path node and generates SAV rules for source addresses of other probe initiation node.
  6. The above steps can be executed periodically or when any of source address information, destination address information, or forwarding rules change.

Figure 1 illustrates the workflow of DSAV. There are total of four nodes in the network shown in Figure 1. The network runs some routing protocols such as OSPF, IS-IS, and BGP. Thus, Prefixes P1 and P2, belonging to Node 1 and Node 3 respectively, are reachable by all the nodes. Let's consider a path probing process where Node 1 is the probe initiation node. Node 1 sends a probing packet carrying source address information (i.e., P1) and destination address information (i.e., P2). According to the destination address information, the probe packet will be forwarded through the path of Node 1 -> Node 2 -> Node 3. Node 2 and Node 3 (i.e., on-path nodes) will learn the SAV rule for P1, i.e., the pair <P1, interface '#'>. The rule indicates that data packets with source addresses of P1 should arrive at Node 2 and Node 3 from interface '#'. In this way, when Node 4 forwards packets with spoofed addresses of P1' to Node 2, Node 2 will drop them immediately based on the SAV rules.

                        +---------------+
                        |     Node 1    +---+P1
                        +-------+-------+
                                |
                                | probing pkt:src_v=[P1],dst_v=[P2]
                                |
      +----------+      +-------#-------+
      |  Node 4  +------+     Node 2    |
      +-----+----+      +-------+-------+
            |                   |
            +                   | probing pkt:src_v=[P1],dst_v=[P2]
            P1'                 |
                        +-------#--------+
                        |     Node 3     +---+P2
                        +----------------+
      P1 is the source prefix of Node 1.
      P1' is the spoofed P1 by Node 4.
      P2 is the source prefix of Node 3.
      '#' means the legitimate interface for packets with
          source addresses of P1.

              Figure 1: An illustration of DSAV

The example in Figure 1 shows a very simple DSAV scenario. In real networks, there can be lots of nodes as well as a large number of IP address prefixes. To provide a complete protection for the target network, every node can act as a probe initiation node and send probing packets, which will inevitably result in much overhead and limit the scalability of DSAV. To address the issue, two mechanisms, i.e., multicast tree-like path probing and separate prefix information advertisement, are proposed and presented next.

3.1. Multicast Tree-like Path Probing

Consider that the number of probe initiation nodes and their reachable destination prefixes can be extremely large. The communication overhead of DSAV is unacceptable for each node sending an individual probing packet to each reachable destination prefix. Multicast tree-like path probing is such a mechanism that can greatly reduce the number of probing packets.

Particularly, a probe initiation node only needs to send one probing packet to each of its neighboring nodes (Here, packet fragmentation is not considered for brevity). Each probing packet carries a source prefix list and a destination prefix list. The source prefix list includes all the source address prefixes originated locally. The destination prefix list contains all the reachable destination prefixes corresponding to the same next hop in the FIB. Then, the probing packet is sent to the corresponding next-hop node, i.e., the on-path node of the probing packet. The on-path node receives the probing packet and generates SAV rules in the same way as described previously. After that, the on-path node relays the received probing packet and sends packets to one or more neighboring nodes according to the destination prefix list of the received packet. Each probing packet relayed by the on-path node carries an updated destination prefix list that is a subset of the original list. The updated list contains only the destination prefixes of the original list corresponding to the same neighboring node. Note that, the source prefix list has no need to be updated. The relayed probing packet will then continue probing forwarding paths through the updated destination prefix list. The following on-path nodes will generate SAV rules accordingly and relay the probing packets until reaching all the destination nodes. The traversed forwarding paths during a path probing process look like a multicast tree, and the probe initiation node of the process is the root of the tree.

                                +----------+
                                |  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 IP address prefixes belonging
            to Node 1, 2, 3, and 4, respectively.
        Node 1 is the probe initiation node, and the other
            nodes are on-path nodes.
        '#' means the legitimate interface for the packets with
            source addresses of P1.

      Figure 2: An example of multicast tree-like path probing

An example of multicast tree-like path probing is shown in Figure 2. Node 1 is the probe initiation node, and P2~P4 are reachable locally. Node 1 sends a probing packet to Node 2 with source prefix list [P1] and destination prefix list [P2, P3, P4]. Node 2 learns the SAV rule from the probing packet and relays the packet with updated destination prefix list to Node 3 and 4. The source prefix list keeps unchanged, while the destination prefix list is updated according to the forwarding rules on Node 2. Finally, Node 2~4 learn and enable the SAV rule, i.e., <P1, interface '#'>.

With multicast tree-like path probing, DSAV can reduce much unnecessary probing packets in networks and thus consumes less network resources.

3.2. Separate Address Information Advertisement

Probing packets may have large packet sizes because their source and destination prefix lists can be very large. Besides, a binding of prefix information advertisement and path probing will sometimes induce much unnecessary overhead. For example, a change on either destination prefix information or forwarding rules will make the probe initiation node advertise its source address information again even though no changes happen on source address information at all. Separate address information advertisement is taken to tackle the above problem by decoupling address information advertisement and path probing.

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 probe initiation node, its source addresses 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, every node will know the mappings from a node ID to a list of source addresses. Now, probing packets do not need to carry a long list of source address prefixes whose field can be replaced with just one source node ID.

Similarly, the reachable destination information of each probe initiation node can also be advertised separately, and then the destination prefix list in a probing packet can be replaced with a list of destination node IDs. However, the replacement of source and destination prefix lists may result in false negative problems in some scenarios where the destination prefixes belonging to the same destination node have different forwarding paths. Some additional mechanisms need to be imported into these scenarios.

4. Accuracy

The goal of DSAV is to achieve high accuracy, i.e., achieve zero false positive and try best to reduce false negative. Zero false positive guarantees legitimate traffic not being dropped by mistake, while reducing false negative means filtering source address forgery traffic as much as possible.

The accuracy of DSAV is determined by the accuracy of source address information advertisement, destination address information advertisement, and path probing results. The completeness of address information advertisement is important for the accuracy improvement of DSAV. So, each probe initiation node should discover and advertise local address information carefully with the help of either automatic programs or manual configurations. In the case of incomplete address information advertisement, on-path nodes can take a remedy method in their data planes, i.e., a combination of allowlist and blocklist. Allowlist blocks any packets with unknown source addresses or illegal arrival interfaces, which requires complete address information advertisement. In contrast, blocklist only drops packets with known source addresses but illegal arrival interfaces. Packets with unknown source addresses are accepted under blocklist. Combining allowlist and blocklist properly is helpful to eliminate false positive cases.

The accuracy of path probing is also challenging. Path probing should fully discover all the real forwarding paths of each destination prefix. Any factor that can affect forwarding should be considered. Here are three kinds of common forwarding cases:

To achieve high accuracy of path probing, either a probe initiation node or an on-path node need to answer two questions accurately: which set of next-hop interfaces are for probing and what is the destination prefix list of the probing packet for each next-hop interface. Before sending/relaying probing packets, a node should look up all the local forwarding rules to answer the above two questions.

5. Consistency

The factors influencing the accuracy of DSAV may change with time. Such changes will lower the performance of SAV and lead to false positive/negative problems. The SAV rules generated through DSAV should be updated in time so as to keep consistent with new source address information, destination address information or path probing results. The consistency of DSAV is important for the SAV framework working well in real networks.

A simple method is to update source/destination address information and probe forwarding paths 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 false positive/negative. Some quick convergence mechanisms are necessary to achieve consistency of DSAV in time. Here are some preliminary ideas for different cases:

6. Deployability

It is difficult to ensure that all nodes deploy DSAV simultaneously, especially at inter-AS 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 false positive problems. Therefore, DSAV should support incremental and partial deployment.

When deployed incrementally or partially, nodes should still achieve zero false positive and minimize false negative based on incomplete SAV tables. The process of data-plane SAV is as follows:

Since inter-AS topology is greatly complex and ASes are managed by individual network operators, determining wheter 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-AS 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.

7. Security

TBD

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2827]
Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, , <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704]
Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, , <https://www.rfc-editor.org/info/rfc3704>.
[RFC5210]
Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, "A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience", RFC 5210, DOI 10.17487/RFC5210, , <https://www.rfc-editor.org/info/rfc5210>.
[RFC7039]
Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, , <https://www.rfc-editor.org/info/rfc7039>.
[RFC8704]
Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, , <https://www.rfc-editor.org/info/rfc8704>.

Authors' Addresses

Dan Li
Tsinghua
Beijing
China
Jianping Wu
Tsinghua
Beijing
China
Mingqing Huang
Huawei
Beijing
China
Lancheng Qin
Tsinghua
Beijing
China
Nan Geng
Huawei
Beijing
China