SAVNET's Incentive Consideration for Defense Against Reflection Attacks

Abstract

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 limitation in accuracy, lack of incentive, or other cost concerns. This document specifically explains the incentive problem of existing SAV mechanisms and clarifies the direct incentive that SAVNET hopes to achieve.¶

1. 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 will 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 limitation in accuracy, lack of incentive, or other cost concerns. 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] summarize the fundamental problems of existing SAV mechanisms and define the requirements for new SAV mechanisms. This document further explains the misaligned incentive problem of existing SAV mechanisms and specifies the direct incentive that SAVNET hopes to achieve. The direct incentive of SAV refers to a network deploying SAV can protect itself from being the victim of source address spoofing attacks, espacially the most important reflection attacks.¶

2. 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.¶

Two results in the incentive comparison between EFP-uRPF and SAVNET:¶

• "FAIL" means the victim network deploying SAV (EFP-uRPF or SAVNET) cannot help itself prevent the reflection attack.¶
• "WORK" means the victim network deploying SAV (EFP-uRPF or SAVNET) can help itself prevent the reflection attack.¶

3. The Importance of Direct 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), some ASes still do not deploy BCP38. One main reason is that operators lack incentive to deploy BCP38 in their networks. Specifically, BCP38 only prevents the AS who deploys SAV from originating spoofed traffic but does not protect the AS from receiving spoofed traffic or being the victim of an attack. The benefits from deploying BCP38 do not flow to the deployed network, but to the rest of the Internet. As a result, some ASes are reluctant to deploy BCP38 and prefer to wait for others to deploy.¶

The deployment problem faced by BCP38 tells us that a good 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.¶

4. The Demand for Defense Against Reflection Attack

Nowadays, reflection attack has become one of the most common attacks based on source address spoofing. However, the victim network in a reflection attack may not receive the spoofed request. If an intermediate network deploys SAV to protect itself from being the victim of source address spoofing attacks, such as single-packet attacks, flood-based DoS, and etc [RFC6959], it can help prevent the reflection attack when receiving the spoofed request. Therefore, to mitigate reflection attacks, customer or user networks are increasingly asking their upstreaming providers to deploy SAV as close to the source as possible and to protect their source addresses from being forged. Considering the security demand of customer or user networks, network operators would be willing to improve their competitiveness by providing defense against reflection attacks, so they will attract more users and gain more profits.¶

However, BCP38 is not aligned with the demand for defense against reflection attacks. The operator who deploys BCP38 neither protects itself from receiving spoofed traffic nor protects its customer or user networks from reflection attacks. More recently, RFC8704 or BCP84 [RFC8704] proposes the Enhanced Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) and recommends operators to adopt EFP-uRPF at customer interfaces in most inter-domain scenarios. Different from BCP38, EFP-uRPF provides some direct incentive, as it aims to protect the deployed AS from receiving spoofed traffic from customer interfaces. Nonetheless, EFP-uRPF is essentially performing ingress filtering at a higher aggregation point (i.e., the top AS of a customer cone). It only validates traffic from customer interfaces but does not validate traffic from provider and peer interfaces. The operator who deploys EFP-uRPF only prevents its customer cone from originating spoofed traffic, but does not protect the customer cone from receiving spoofed traffic or being the victim of a reflection attack from outside the customer cone. Moreover, the victim network will not gain additional protection against reflection attack even if it also deploys EFP-uRPF. Therefore, EFP-uRPF cannot perfectly meet the demand for defense against reflection attacks.¶

5. Incentive Comparison Between EFP-uRPF and SAVNET

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.¶

Since there is no specific SAVNET solution yet, we assume SAVNET can meet the following requirements:¶

• Validate traffic from all directions.¶
• Match the real data-plane forwarding path originated from each deployed AS.¶

                   +---------+
                   |   AS2   +-+Reflector
                   ++/\+-----+
                     /     \
            request /       \ response
                   /         \
                  /           \
          +---------+      +-+\/+----+
Attacker+-+   AS1   |      |   AS3   +-+ Victim
          +---------+      +---------+


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

 Figure 1: The first reflection attack scenario.

                  +---------+
                  |   AS3   +-+Victim
                  ++/\+--+/\+
                    /    \ \
                   /      \ \
                  /request \ \ response
                 /          \ \
          +---------+     + \/+-----+
Attacker+-+   AS1   |     |   AS2   +-+Reflector
          +---------+     +---------+


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

 Figure 2: The second reflection attack scenario.

                +---------+
                |   AS1   +-+Attacker
                +----+/\+-+
                  /    \ \
                 /      \ \
                /response\ \request
               /          \ \
        +----+\/+-+     +--+\/+---+
Victim+-+   AS3   |     |   AS2   +-+Reflector
        +---------+     +---------+


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

 Figure 3: The third reflection attack scenario.

6. 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. It is worth noting that AS1 and AS2 in above scenarios can also be targets of reflection attacks from other networks. Therefore, a network has more incentive to deploy SAVNET as the SAV mechanism, because its own network will have high probability of being protected against reflection attacks.¶

7. Acknowledgments

TBD¶

8. Normative References

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

Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source Address Validation in Intra-domain Networks (Intra-domain SAVNET) Gap Analysis, Problem Statement and Requirements", 7 November 2022.

[draft-wu-savnet-inter-domain-problem-statement]

Wu, J., Li, D., Qin, L., Huang, M., and N. Geng, "Source Address Validation in Inter-domain Networks (Inter-domain SAVNET) Gap Analysis, Problem Statement and Requirements", 7 November 2022.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <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, May 2000, <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, March 2004, <https://www.rfc-editor.org/info/rfc3704>.

[RFC6959]

McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, DOI 10.17487/RFC6959, May 2013, <https://www.rfc-editor.org/info/rfc6959>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8704]

Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, <https://www.rfc-editor.org/info/rfc8704>.