Internet-Draft Intra-domain SAVNET Problem Statement August 2024
Li, et al. Expires 3 February 2025 [Page]
Workgroup:
SAVNET
Internet-Draft:
draft-ietf-savnet-intra-domain-problem-statement-04
Published:
Intended Status:
Informational
Expires:
Authors:
D. Li
Tsinghua University
J. Wu
Tsinghua University
L. Qin
Zhongguancun Laboratory
M. Huang
Zhongguancun Laboratory
N. Geng
Huawei

Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements

Abstract

This document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements.

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 3 February 2025.

Table of Contents

1. Introduction

Source Address Validation (SAV) is important for defending against source address spoofing attacks and allowing accurate traceback. A multi-fence architecture called Source Address Validation Architecture (SAVA) [RFC5210] was proposed to validate source addresses at three levels: access network SAV, intra-domain SAV, and inter-domain SAV. When SAV is not fully enabled at the edge of the Internet, the multi-fence architecture can help enhance the validation across the whole Internet and thus reduce the opportunities of launching source address spoofing attacks.

Particularly, access network SAV ensures that a host uses a valid address assigned to the host statically or dynamically. In this way, the host cannot use the source address of another host. There are many mechanisms for SAV in access networks. Static ACL rules can be manually configured for validation by specifying which source addre-sses are acceptable or unacceptable. Dynamic ACL is another efficient mechanism which is associated with authentication servers (e.g., RADIUS and DIAMETER). The servers receive access requests and then install or enable ACL rules on the device to permit particular users' packets. SAVI [RFC7039] represents a kind of mechanism enforcing that the legitimate IP address of a host matches the link-layer property of the host's network attachment. For example, SAVI solution for DHCP [RFC7513] creates a binding between a DHCPv4/DHCPv6-assigned IP address and a link-layer property (like MAC address or switch port) on a SAVI device. IP Source Guard (IPSG) [IPSG] combined with DHCP snooping is an implementation of SAVI solution for DHCP. Cable Source-Verify [cable-verify] also shares some features of SAVI and is used in cable modem networks. Cable modem termination system (CMTS) devices with Cable Source-Verify maintain the bindings of the CPE's IP address, the CPE's MAC address, and the corresponding cable modem identifier. When receiving packets, the device will check the validity of the packets according to the bindings.

Given numerous access networks managed by different operators throughout the world, it is difficult to require all access networks to effectively deploy SAV. Therefore, intra-domain SAV and inter-domain SAV are needed to block spoofing traffic as close to the source as possible. Both intra-domain SAV and inter-domain SAV usually perform validation at the granularity of IP prefixes, which is coarser than the validation granularity of access network SAV, as an IP prefix covers a range of IP addresses.

This document focuses on the analysis of intra-domain SAV. In contrast to inter-domain SAV, intra-domain SAV does not require collaboration between different ASes. The SAV rules can be generated by the AS itself. Consider an AS X which provides its host networks or customer networks with the connectivity to other ASes. The intra-domain SAV for AS X has two goals: i) blocking the illegitimate packets originated from its host networks or customer networks with spoofed source addresses; and ii) blocking the illegitimate packets coming from other ASes which spoof the source addresses of AS X.

Figure 1 illustrates the function of intra-domain SAV with two cases. Case i shows that AS X forwards spoofed packets originated from its host networks or customer networks to other ASes (e.g., AS Y). If AS X deploys intra-domain SAV, the spoofed packets from its host networks or customer networks can be blocked by AS X itself (i.e., Goal i). Case ii shows that AS X receives the packets which spoof AS X's source addresses from other ASes (e.g., AS Y). If AS X deploys intra-domain SAV, the spoofed packets from AS Y can be blocked by AS X (i.e., Goal ii).

Case i: AS X forwards spoofed packets originated from its
        host networks or customer networks to other ASes (e.g., AS Y)
Goal i: If AS X deploys intra-domain SAV,
        the spoofed packets can be blocked by AS X

  +------+  Spoofed packets  +------+
  | AS X |------------------>| AS Y |
  +------+                   +------+


Case ii: AS X receives packets spoofing
         AS X's source addresses from other ASes (e.g., AS Y)
Goal ii: If AS X deploys intra-domain SAV,
         the spoofed packets can be blocked by AS X

  +------+  Spoofed packets  +------+
  | AS X |<------------------| AS Y |
  +------+                   +------+
Figure 1: An example for illustrating intra-domain SAV

There are many mechanisms for intra-domain SAV. This document provides the gap analysis of existing intra-domain SAV mechanisms. According to the gap analysis, the document concludes the main problems of existing mechanisms and describes the requirements for future intra-domain SAV mechanisms.

1.1. Terminology

SAV Rule: The rule in a router that describes the mapping relationship between a source address (prefix) and the valid incoming interface(s). It is used by a router to make SAV decisions and is inferred from the SAV Information Base.

SAV Table: The table or data structure that implements the SAV rules and is used for source address validation in the data plane.

Host-facing Router: An intra-domain router of an AS which is connected to a host network (i.e., a layer-2 network).

Customer-facing Router: An intra-domain router of an AS which is connected to a customer network running the routing protocol (i.e., a layer-3 network).

AS Border Router: An intra-domain router of an AS which is connected to other ASes.

Improper Block: The validation results that the packets with legitimate source addresses are blocked improperly due to inaccurate SAV rules.

Improper Permit: The validation results that the packets with spoofed source addresses are permitted improperly due to inaccurate SAV rules.

Outbound Traffic: For a network, the outbound traffic is the traffic that flows from the network to other networks.

Inbound Traffic: For a network, the inbound traffic is the traffic that flows from other networks to the network.

1.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Existing Mechanisms

Ingress filtering [RFC2827][RFC3704] is the current practice of intra-domain SAV. This section briefly introduces the existing intra-domain SAV mechanisms.

3. Gap Analysis

Existing intra-domain SAV mechanisms either require high operational overhead or have limitations in accuracy. They may improperly block the traffic with legitimate source addresses (i.e., improper block) or improperly permit the traffic with spoofed source addresses (i.e., improper permit).

3.1. Outbound Traffic Validation

Outbound traffic validation is typically implemented at downstream interfaces of host-facing or customer-facing routers to validate packets originated from their host networks or customer networks, since it is most effective closer to the edges of the Internet. As described previously, ACL rules can be configured at downstream interfaces for ingress filtering. These rules need to be updated when prefixes or topologies of host networks or customer networks change. If ACL rules are not updated in time, improper block or improper permit may occur. To ensure the accuracy of SAV in dynamic networks, high operational overhead will be induced to achieve timely updates for ACL configurations.

Strict uRPF can also be used for outbound traffic validation, but there may be improper block problem in multi-homing and asymmetric routing scenario. Figure 2 shows such a case. In the figure, Network 1 is a host/customer network of the AS. It owns prefix 192.0.2.0/24 [RFC6890] and is attached to two intra-domain edge routers, i.e., Router 1 and Router 2. For the load balance purpose of inbound traffic, Network 1 expects the inbound traffic destined for the sub-prefix 192.0.2.128/25 to come only from Router 1 and the inbound traffic destined for the other sub-prefix 192.0.2.0/25 to come only from Router 2. To this end, Router 1 only learns the route to sub-prefix 192.0.2.128/25 from Network 1, while Router 2 only learns the route to the other sub-prefix 192.0.2.0/25 from Network 1. Then, Router 1 and Router 2 advertise the sub-prefix information to routers in the AS through intra-domain routing protocols such as OSPF or IS-IS. Finally, Router 1 learns the route to 192.0.2.0/25 from Router 3, and Router 2 learns the route to 192.0.2.128/25 from Router 3. The FIBs of Router 1 and Router 2 are shown in the figure. Although Network 1 does not expect inbound traffic destined for 192.0.2.0/25 to come from Router 1, it may send outbound traffic with source addresses of prefix 192.0.2.0/25 to Router 1 for load balance of outbound traffic. As a result, there is asymmetric routing of data packets between Network 1 and Router 1. Similarly, Network 1 may also send outbound traffic with source addresses of prefix 192.0.2.128/25 to Router 2, resulting in asymmetric routing between Network 1 and Router 2.

 +---------------------------------------------------------------+
 |                                                           AS  |
 |                         +----------+                          |
 |                         | Router 3 |                          |
 |FIB of Router 1          +----------+  FIB of Router 2         |
 |Dest           Next_hop   /\      \    Dest           Next_hop |
 |192.0.2.128/25 Network 1  /        \   192.0.2.0/25   Network 1|
 |192.0.2.0/25   Router 3  /         \/  192.0.2.128/25 Router 3 |
 |                  +----------+     +----------+                |
 |                  | Router 1 |     | Router 2 |                |
 |                  +-----+#+--+     +-+#+------+                |
 |                        /\           /                         |
 |    Outbound traffic with\          /Inbound traffic with      |
 |    source IP addresses   \        / destination IP addresses  |
 |    of 192.0.2.0/25        \      \/ of 192.0.2.0/25           |
 |                     +----------------+                        |
 |                     |  Host/Customer |                        |
 |                     |    Network 1   |                        |
 |                     | (192.0.2.0/24) |                        |
 |                     +----------------+                        |
 |                                                               |
 +---------------------------------------------------------------+

 The outbound traffic with source IP addresses of 192.0.2.0/25 will
 be improperly blocked by Router 1 if Router 1 uses strict uRPF.
Figure 2: Asymmetric routing in the multi-homing scenario

Strict uRPF takes the entries in FIB for SAV. It can improperly block data packets that use legitimate source IP addresses when asymmetric routing exists. In the figure, if Router 1 applies strict uRPF at interface '#', the SAV rule is that Router 1 only accepts packets with source addresses of 192.0.2.128/25 from Network 1. Therefore, when Network 1 sends packets with source addresses of 192.0.2.0/25 to Router 1, strict uRPF at Router 1 will improperly block these legitimate packets. Similarly, when Router 2 with strict uRPF deployed receives packets with source addresses of prefix 192.0.2.128/25 from Network 1, it will also improperly block these legitimate packets because strict uRPF at Router 2 will only accept packets from Network 1 using source addressses of prefix 192.0.2.0/25. Therefore, strict uRPF may cause improper block problem in the case of asymmetric routing.

3.2. Inbound Traffic Validation

Inbound traffic validation is performed at upstream interfaces of AS border routers to validate the packets from other ASes. Figure 3 shows an example of inbound SAV. In the figure, Router 3 and Router 4 deploy SAV mechanisms at interface '#' for validating external packets. Hence, there are multiple points for inbound traffic validation for the AS.

ACL-based ingress filtering is usually used for validating inbound traffic. By configuring specified ACL rules, inbound packets with disallowed source prefixes (e.g., non-global addresses or the internal source prefixes) can be blocked. As mentioned above, ACL-based ingress filtering requires timely updates when the routing status changes dynamically. When the ACL rules are not updated in time, there may be improper block or improper permit problems. The operational overhead of maintaining updated ACL rules will be extremely high when there are multiple inbound validation points as shown in Figure 3.

Loose uRPF is another inbound SAV mechanism and is more adaptive than ACL-based rules. But it sacrifices the directionality of SAV and has limited blocking capability, because it allows packets with source addresses that exist in the FIB table at all router interfaces.

 Packets with +              Packets with +
 spoofed P1/P2|              spoofed P1/P2|
+-------------|---------------------------|---------+
|   AS        \/                          \/        |
|         +--+#+-----+               +---+#+----+   |
|         | Router 3 +---------------+ Router 4 |   |
|         +----------+               +----+-----+   |
|          /        \                     |         |
|         /          \                    |         |
|        /            \                   |         |
| +----------+     +----------+      +----+-----+   |
| | Router 1 |     | Router 2 |      | Router 5 |   |
| +----------+     +----------+      +----+-----+   |
|        \             /                  |         |
|         \           /                   |         |
|          \         /                    |         |
|       +---------------+         +-------+-------+ |
|       |     Host      |         |   Customer    | |
|       |   Network     |         |   Network     | |
|       |     (P1)      |         |     (P2)      | |
|       +---------------+         +---------------+ |
|                                                   |
+---------------------------------------------------+
Figure 3: A scenario of inbound SAV

4. Problem Statement

Accurate validation and low operational overhead are two important design goals of intra-domain SAV mechanisms. As analyzed above, asymmetric routing and dynamic networks are two challenging scenarios for the two goals. In these scenarios, existing SAV mechanisms have problems of inaccurate validation or high operational overhead.

ACL-based SAV relies on manual configurations and thus requires high operational overhead in dynamic networks. Operators have to manually update the ACL-based filtering rules in time when the prefix or topology changes. Otherwise, improper block or improper permit problems may appear.

Strict uRPF-based SAV can automatically update SAV rules, but may improperly block legitimate traffic under asymmetric routing. 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 problem; or it may consider an invalid incoming interface as valid, resulting in improper permit problem.

Loose uRPF is also an automated SAV mechanism but its SAV rules are overly loose. Most spoofed packets will be improperly permitted by adopting loose uRPF.

5. Requirements for New SAV Mechanisms

This section lists the requirements which can be a guidance for narrowing the gaps of existing intra-domain SAV mechanisms. The requirements can be fully or partially fulfilled when designing new intra-domain SAV mechanisms.

5.1. Automatic Update

The new intra-domain SAV mechanisms MUST be able to automatically adapt to network dynamics such as routing change or prefix change, instead of purely relying on manual update.

5.2. Accurate Validation

The new intra-domain SAV mechanisms needs to improve the validation accuracy upon existing intra-domain SAV mechanisms. In a static network, improper block MUST be avoided to guarantee that legitimate traffic will not be blocked. Improper permit SHOULD be reduced as much as possible so that the malicious packets with forged source addresses can be efficiently filtered. When there are network changes, the new mechanisms MUST update SAV rules efficiently for keeping the high accuracy of validaiton.

5.3. Working in Incremental/Partial Deployment

The new intra-domain SAV mechanisms SHOULD NOT assume pervasive adoption. Some routers may not be able to be easily upgraded for supporting the new SAV mechanism due to their limitations of capabilities, versions, or vendors. The mechanisms SHOULD be able to provide protection even when it is partially deployed. The effectiveness of protection for the new intra-domain SAV mechanisms under partial deployment SHOULD be no worse than existing mechanisms.

5.4. Fast Convergence

Network changes may cause SAV rules to be inaccurate and need to be updated. The new intra-domain SAV mechanism MUST consider how to update SAV rules quickly so as to minimize improper block and improper permit impacts during convergence.

5.5. Necessary Security Guarantee

Necessary security tools SHOULD be contained in the new intra-domain SAV mechanisms. In an insecure scenario, these security tools can help protect the SAV rule generation process.

6. Intra-domain SAV Scope

The new intra-domain SAV mechanisms work in the same scenarios as existing intra-domain SAV mechanisms. Generally, it includes all IP-encapsulated scenarios:

Scope does not include:

In addition, the new intra-domain SAV mechanisms SHOULD avoid data-plane packet modification. Existing architectures or protocols or mechanisms can be used in the new SAV mechanisms to achieve better SAV function.

7. Security Considerations

The new intra-domain SAV mechanisms MUST NOT introduce additional security vulnerabilities or confusion to the existing intra-domain architectures or control or management plane protocols. Similar to the security scope of intra-domain routing protocols, intra-domain SAV mechanisms SHOULD ensure integrity and authentication of protocol packets that deliver the required SAV information.

The new intra-domain SAV mechanisms do not provide protection against compromised or misconfigured routers that poison existing control plane protocols. Such routers can not only disrupt the SAV function, but also affect the entire routing domain.

8. IANA Considerations

This document does not request any IANA allocations.

9. Acknowledgements

Many thanks to the valuable comments from: Jared Mauch, Barry Greene, Fang Gao, Kotikalapudi Sriram, Anthony Somerset, Yuanyuan Zhang, Igor Lubashev, Alvaro Retana, Joel Halpern, Aijun Wang, Michael Richardson, Li Chen, Gert Doering, Mingxing Liu, Libin Liu, John O'Brien, Roland Dobbins, Xiangqing Chang, etc.

10. References

10.1. Normative References

[manrs-antispoofing]
"MANRS Implementation Guide", , <https://www.manrs.org/netops/guide/antispoofing>.
[nist-rec]
"Resilient Interdomain Traffic Exchange - BGP Security and DDos Mitigation", , <https://www.nist.gov/publications/resilient-interdomain-traffic-exchange-bgp-security-and-ddos-mitigation">.
[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>.
[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>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References

[cable-verify]
"Cable Source-Verify and IP Address Security", , <https://www.cisco.com/c/en/us/support/docs/broadband-cable/cable-security/20691-source-verify.html>.
[IPSG]
"Configuring DHCP Features and IP Source Guard", , <https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_53_se/configuration/guide/2960scg/swdhcp82.html>.
[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>.
[RFC7513]
Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, , <https://www.rfc-editor.org/info/rfc7513>.
[RFC6890]
Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, , <https://www.rfc-editor.org/info/rfc6890>.

Authors' Addresses

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