The Incentive Consideration for Source Address Validation in Intra-domain and Inter-domain Networks (SAVNET)
Lancheng Qin
Tsinghua University
Beijing
China
qlc19@mails.tsinghua.edu.cn
Dan Li
Tsinghua University
Beijing
China
tolidan@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
jianping@cernet.edu.cn
15 September 2022
Source address spoofing remains a significant challenge in today's Internet. Although source address validation (SAV) mechanisms, such as ingress filtering [RFC2827], unicast Reverse Path Forwarding (uRPF)[RFC3704], and the Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) [RFC8704], have been proposed for a long time, none of them have been widely deployed due to their technical limitations, lack of incentive, or other problems. This document specifically explains the incentive problem of existing SAV mechanisms and clarifies the incentive that SAVNET hopes to achieve.

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 8174 [RFC8174].

Introduction
Source address spoofing is one of the most important security threats in the Internet. By using forged source IP addresses, attackers can well hide their real identities and carry out various malicious attacks [RFC6959], among which reflection attack is the most common and harmful. In the reflection attack, the attacker spoofs the victim's source IP address and sends requests to servers with reflection and amplification functions, such as DNS or NTP servers. Upon receiving the requests, these servers reply a large number of responses to the victim, resulting in a large-scale Distributed Denial of Service (DDoS) attack to the victim.
To mitigate source address spoofing, several source address validation (SAV) mechanisms (e.g., ingress filtering [RFC2827], unicast Reverse Path Forwarding (uRPF) [RFC3704], and the Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) [RFC8704]) have been proposed to identify and reject traffic with forged source IP addresses. However, they have not been widely deployed due to their technical limitations, lack of incentive, or other problems. Source address spoofing remains a significant challenge in today's Internet.
To help narrow the gap of existing SAV mechanisms, [draft-li-savnet-intra-domain-problem-statement] and [draft-wu-savnet-inter-domain-problem-statement] describe the fundamental problems of existing SAV mechanisms and define the requirements for the new SAV mechanism. This document further explains the incentive problem of existing SAV mechanisms and specifies the incentive that SAVNET hopes to achieve.

Terminology
SAV: Source Address Validation, i.e. validating the authenticity of a packet's source IP address.
Three roles in a reflection attack:
- Attacker. A malicious host that spoofs the victim's source IP address when sending a request to the reflector.
- Reflector. A reflective server (e.g., DNS or NTP server) that receives the forged request and responds to the victim.
- Victim. An innocent host that receives a lot of responses from the reflector, resulting in a DoS attack.

The importance of incentive for SAV deployment
Ingress filtering, or BCP38 [RFC2827] requires the network to implement SAV filtering on its outgoing traffic. If all networks deploy BCP38 and only allow outgoing traffic with legitimate source addresses, source address spoofing can be effectively prevented. However, although BCP38 has been proposed for more than 20 years and is highly recommended by the Mutually Agreed Norms for Routing Security (MANRS), it is still not widely deployed in today's Internet. One main reason is that operators lack incentive to deploy BCP38 in their networks. The benefits from deploying BCP38 do not flow to the deployed network, but to the rest of the Internet. Specifically, if a network deploys BCP38, it does not get any benefit from the deployment and is still vulnerable to reflection attacks from other networks. As a result, most networks are reluctant to deploy BCP38 and prefer to wait for others to deploy.
The deployment problem faced by BCP38 tells us that a desirable SAV mechanism must provide direct incentive/benefits to the deployed network. If a network deploys SAV but finds that it only helps other networks, the network will not be motivated to deploy SAV. If a network deploys SAV and finds that sometimes it can help itself (compared with not deploying), the network will be more motivated to deploy SAV.

Incentive comparison between EFP-uRPF and SAVNET
More recently, RFC8704 or BCP84 [RFC8704] proposes the Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) and recommends operators to adopt EFP-uRPF in most inter-domain scenarios. However, EFP-uRPF is essentially performing ingress filtering at a higher aggregation point (i.e., the top AS of a customer cone) and also has misaligned incentive problems.
In the following, we use reflection attack as an example to measure the incentive that EFP-uRPF or SAVNET can provide to the victim network. We simplify the participants in a reflection attack into three roles (attacker network, reflector network, and victim network) and enumerate three attack scenarios by changing the relative positions of the three roles. In each scenario, we suppose the victim network always deploys SAV mechanism (EFP-uRPF or SAVNET), because only the victim can get benefit from the SAV mechanism. Then, for any deployment case of the other two networks (i.e., attacker network and reflector network), we check whether the reflection attack can be prevented. If so, the victim network has strong motivation to deploy SAV; if not, the victim network has weak motivation to deploy SAV.

Scenario 1
Figure 1 shows the first reflection attack scenario where the reflector network is located between the attacker network and the victim network. The attacker spoofs the source address of the victim and sends a forged request to the reflector. After receiving the request from attacker, the reflector responds to the victim.
                   +---------+
                   |   AS2   +-+Reflector
                   ++/\+-----+
                     /     \
            request /       \ response
                   /         \
                  /           \
          +---------+      +-+\/+----+
Attacker+-+   AS1   |      |   AS3   +-+ Victim
          +---------+      +---------+

              AS1: Attacker network
              AS2: Reflector network
              AS3: Victim network

 Figure 1: The first reflection attack scenario.

Case 1: only AS3 deploys SAV

All SAV mechanisms fail if only AS3 deploys SAV in scenario 1
Relationship between AS1 and AS2 | Relationship between AS2 and AS3 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | FAIL
P2P | P2C | FAIL | FAIL | FAIL
C2P | C2P | FAIL | FAIL | FAIL
C2P | P2P | FAIL | FAIL | FAIL
C2P | P2C | FAIL | FAIL | FAIL
Table 1 shows the effectiveness of EFP-uRPF and SAVNET against the reflection attack under different relationships among AS1, AS2, and AS3. We omit combinations of relationships that violate valley-free principle. If only the victim network deploys SAV, both EFP-uRPF and SAVNET fail to prevent the reflection attack in scenario 1, because the victim network does not receive the forged request at all.

Case 2: AS1 and AS3 deploy SAV

SAVNET works best if AS1 and AS3 deploy SAV in scenario 1
Relationship between AS1 and AS2 | Relationship between AS2 and AS3 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | WORK
P2P | P2C | FAIL | FAIL | WORK
C2P | C2P | FAIL | FAIL | WORK
C2P | P2P | FAIL | FAIL | WORK
C2P | P2C | FAIL | FAIL | WORK
Table 2 shows that SAVNET works best when victim network and attacker network deploy SAV. In our preliminary idea of SAVNET, each deployed network notifies the valid incoming interfaces for its source prefixes to other deployed networks. If AS1 and AS3 deploy SAVNET, AS1 learns that traffic with victim's source address must come from outside the AS, not inside the AS. Therefore, SAVNET in AS1 can successfully detect the forged request and prevent the reflection attack. However, since EFP-uRPF in AS1 does not verify outgoing traffic, EFP-uRPF fails in this deployment case.

Case 3: AS2 and AS3 deploy SAV

SAVNET works best if AS2 and AS3 deploy SAV in scenario 1
Relationship between AS1 and AS2 | Relationship between AS2 and AS3 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | WORK
P2P | P2C | FAIL | FAIL | WORK
C2P | C2P | WORK | WORK | WORK
C2P | P2P | WORK | WORK | WORK
C2P | P2C | WORK | FAIL | WORK
As shown in Table 3, SAVNET works best when victim network and reflector network deploy SAV. If AS2 and AS3 deploy SAVNET, AS2 learns that traffic with victim's source address must come from AS3, so it will block the forged request from AS1. If AS2 and AS3 deploy EFP-uRPF, since EFP-uRPF only work for traffic from customer interfaces, EFP-uRPF algorithm A and algorithm B both fail when AS1 is the provider/peer of AS2. EFP-uRPF algorithm A works well when AS1 is the customer of AS2, but EFP-uRPF algorithm B still fails when AS1 and AS3 are both in the customer cone of AS2, because EFP-uRPF algorithm B cannot identify source address spoofing between ASes in customer cone.

Case 4: AS1, AS2, and AS3 deploy SAV

SAVNET works best if AS1, AS2, and AS3 deploy SAV in scenario 1
Relationship between AS1 and AS2 | Relationship between AS2 and AS3 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | WORK
P2P | P2C | FAIL | FAIL | WORK
C2P | C2P | WORK | WORK | WORK
C2P | P2P | WORK | WORK | WORK
C2P | P2C | WORK | FAIL | WORK
In scenario 1, SAVNET still works best when all three roles deploy SAV. When they deploy SAVNET, both AS1 and AS2 can effectively identify and block the forged request. When they deploy EFP-uRPF, only AS2 sometimes can prevent the reflection attack, with the same results as Section 4.1.3.

Scenario 2
Figure 2 shows the second reflection attack scenario. In scenario 2, the victim network is located between the attack network and the reflector network. When attacker sends a forged request to the reflector, the request first arrives at the victim network and then be forwarded to the reflector network. Subsequently, the reflector responds to the victim.
                  +---------+
                  |   AS3   +-+Victim
                  ++/\+--+/\+
                    /    \ \
                   /      \ \
                  /request \ \ response
                 /          \ \
          +---------+     + \/+-----+
Attacker+-+   AS1   |     |   AS2   +-+Reflector
          +---------+     +---------+

              AS1: Attacker network
              AS2: Reflector network
              AS3: Victim network

 Figure 2: The second reflection attack scenario.

Case 1: only AS3 deploys SAV

SAVNET works best if only AS3 deploys SAV in scenario 2
Relationship between AS1 and AS3 | Relationship between AS3 and AS2 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | WORK
P2P | P2C | FAIL | FAIL | WORK
C2P | C2P | WORK | WORK | WORK
C2P | P2P | WORK | WORK | WORK
C2P | P2C | WORK | WORK | WORK
Table 5 shows the effectiveness of EFP-uRPF and SAVNET when only AS3 in scenario 2 deploys SAV. If AS3 deploys SAVNET, it can reject the forged request when it receives the forged request. If AS3 deploys EFP-uRPF, it only works when AS1 is the customer of AS3 because EFP-uRPF only implements SAV filtering at customer interfaces.
We also compare EFP-uRPF and SAVNET in the following three deployment cases. We find that if the SAV mechanism is EFP-uRPF algorithm A or EFP-uRPF algorithm B, only the victim network in scenario 2 has the possibility to reject the forged request by implementing SAV. Even if attacker network or reflector network also deploys EFP-uRPF, it does not provide additional assistance to victim network. Therefore, on the basis that the victim network has deployed SAV, SAVNET always works best in different deployment cases.

Case 2: AS1 and AS3 deploy SAV

SAVNET works best if AS1 and AS3 deploy SAV in scenario 2
Relationship between AS1 and AS3 | Relationship between AS3 and AS2 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | WORK
P2P | P2C | FAIL | FAIL | WORK
C2P | C2P | WORK | WORK | WORK
C2P | P2P | WORK | WORK | WORK
C2P | P2C | WORK | WORK | WORK

Case 3: AS2 and AS3 deploy SAV

SAVNET works best if AS2 and AS3 deploy SAV in scenario 2
Relationship between AS1 and AS3 | Relationship between AS3 and AS2 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | WORK
P2P | P2C | FAIL | FAIL | WORK
C2P | C2P | WORK | WORK | WORK
C2P | P2P | WORK | WORK | WORK
C2P | P2C | WORK | WORK | WORK

Case 4: AS1, AS2, and AS3 deploy SAV

SAVNET works best if AS1, AS2, and AS3 deploy SAV in scenario 2
Relationship between AS1 and AS3 | Relationship between AS3 and AS2 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | WORK
P2P | P2C | FAIL | FAIL | WORK
C2P | C2P | WORK | WORK | WORK
C2P | P2P | WORK | WORK | WORK
C2P | P2C | WORK | WORK | WORK

Scenario 3
Figure 3 shows the third reflection attack scenario. The attacker network is located between the victim network and the reflector network. Attacker spoofs victim's source address in the request sent to reflector. Reflector receives the request from the attacker network and sends a response to the victim network via the attacker network.
Below we make the incentive comparison between EFP-uRPF and SAVNET in scenario 3. By varying SAV deployment status of attacker network and reflector network, we find all SAV mechanisms fail in preventing the reflection attack in this scenario. For victim network, it does not receive the forged request. For attacker network and reflector network, SAV in their networks cannot identify this spoofing because the forged source address (i.e., victim's source address) shares the same valid incoming interface with the actual one (i.e., attacker's source address).
                +---------+
                |   AS1   +-+Attacker
                +----+/\+-+
                  /    \ \
                 /      \ \
                /response\ \request
               /          \ \
        +----+\/+-+     +--+\/+---+
Victim+-+   AS3   |     |   AS2   +-+Reflector
        +---------+     +---------+

             AS1: Attacker network
             AS2: Reflector network
             AS3: Victim network

 Figure 3: The third reflection attack scenario.

Case 1: only AS3 deploys SAV

All SAV mechanisms fail if only AS3 deploys SAV in scenario 3
Relationship between AS3 and AS1 | Relationship between AS1 and AS2 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | FAIL
P2P | P2C | FAIL | FAIL | FAIL
C2P | C2P | FAIL | FAIL | FAIL
C2P | P2P | FAIL | FAIL | FAIL
C2P | P2C | FAIL | FAIL | FAIL

Case 2: AS1 and AS3 deploy SAV

All SAV mechanisms fail if AS1 and AS3 deploy SAV in scenario 3
Relationship between AS3 and AS1 | Relationship between AS1 and AS2 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | FAIL
P2P | P2C | FAIL | FAIL | FAIL
C2P | C2P | FAIL | FAIL | FAIL
C2P | P2P | FAIL | FAIL | FAIL
C2P | P2C | FAIL | FAIL | FAIL

Case 3: AS2 and AS3 deploy SAV

All SAV mechanisms fail if AS2 and AS3 deploy SAV in scenario 3
Relationship between AS3 and AS1 | Relationship between AS1 and AS2 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | FAIL
P2P | P2C | FAIL | FAIL | FAIL
C2P | C2P | FAIL | FAIL | FAIL
C2P | P2P | FAIL | FAIL | FAIL
C2P | P2C | FAIL | FAIL | FAIL

Case 4: AS1, AS2, and AS3 deploy SAV

All SAV mechanisms fail if AS1, AS2, and AS3 deploy SAV in scenario 3
Relationship between AS3 and AS1 | Relationship between AS1 and AS2 | EFP-uRPF algorithm A | EFP-uRPF algorithm B | SAVNET
P2C | P2C | FAIL | FAIL | FAIL
P2P | P2C | FAIL | FAIL | FAIL
C2P | C2P | FAIL | FAIL | FAIL
C2P | P2P | FAIL | FAIL | FAIL
C2P | P2C | FAIL | FAIL | FAIL

Summary
Overall, neither SAVNET nor EFP-uRPF completely prevents the reflection attack. But for any attack scenario or deployment case, we find that SAVNET is doing better or not worse than EFP-uRPF. Therefore, a network has more incentive to deploy SAVNET as the SAV mechanism, because its own network will have high probability to be protected from reflection attacks.

Acknowledgments
TBD

Normative References
[draft-li-savnet-intra-domain-problem-statement]

Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements
Dan Li
Tsinghua University
Beijing
China
tolidan@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
jianping@cernet.edu.cn
Lancheng Qin
Tsinghua University
Beijing
China
qlc19@mails.tsinghua.edu.cn
Mingqing Huang
Huawei
Beijing
China
huangmingqing@huawei.com
Nan Geng
Huawei
Beijing
China
gengnan@huawei.com
10 July 2022
[draft-wu-savnet-inter-domain-problem-statement]

Source Address Validation in Inter-domain Networks (Inter-domain SAVNET) Gap Analysis, Problem Statement and Requirements
Jianping Wu
Tsinghua University
Beijing
China
jianping@cernet.edu.cn
Dan Li
Tsinghua University
Beijing
China
tolidan@tsinghua.edu.cn
Lancheng Qin
Tsinghua University
Beijing
China
qlc19@mails.tsinghua.edu.cn
Mingqing Huang
Huawei
Beijing
China
huangmingqing@huawei.com
Nan Geng
Huawei
Beijing
China
gengnan@huawei.com
10 July 2022
[RFC2827]
[RFC3704]
[RFC8704]
[RFC8174]
[RFC6959]