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

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 18 February 2024.¶

Copyright Notice

Copyright (c) 2023 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.¶

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 own subnets with the connectivity to other ASes. The intra-domain SAV for AS X has two goals: i) blocking the illegitimate packets originated from the local subnets of AS X 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 subnets to other ASes (e.g., AS Y). If AS X deploys intra-domain SAV, the spoofed packets from its own subnet can be locked 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 subnets 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 |
  +------+                   +------+

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

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

• ACL-based ingress filtering [RFC2827][RFC3704] is a typical mechanism for intra-domain SAV. ACL rules can be configured for blocking or permitting packets with specific source addresses. This mechanism can be applied at the downstream interfaces of edge routers connecting the subnets or at the downstream interfaces of aggregation routers [manrs-antispoofing]. The validation at downstream interfaces will prevent local subnets from spoofing source prefixes of other subnets. Besides, at the upstream interfaces of routers connecting other ASes, ACL can be enabled for blocking packets with disallowed source prefixes, such as the internal source prefixes owned by the subnets [nist-rec]. In any application scenario, ACL rules should be updated in time to be consistent with the latest filtering criteria.¶
• Strict uRPF [RFC3704] is another commonly used mechanism for SAV in intra-domain networks. Routers deploying strict uRPF accept a data packet only when i) the local FIB contains a prefix encompassing the packet's source address and ii) the corresponding outgoing interface for the prefix in the FIB matches the packet's incoming interface. Otherwise, the packet will be blocked. Strict uRPF is usually used at downstream interfaces of edge routers connecting local subnets.¶
• Loose uRPF [RFC3704] takes a looser validation mechanism than strict uRPF to avoid improper block. A packet will be accepted if the local FIB contains a prefix encompassing the packet's source address. The incoming interface of the packet is not checked. Upstream interfaces can enable loose uRPF for blocking non-global addresses [nist-rec].¶
• Carrier Grade NAT has some operations on the source addresses of packets, but is not an anti-spoofing tool, as described in [manrs-antispoofing]. If the source address of a packet is in the INSIDE access list, the NAT rule can translate the source address to an address in the pool OUTSIDE. The NAT rule cannot judge whether the source address is spoofed or not. In addition, the packet with a spoofed source address will be forwarded directly if the spoofed source address is not included in the INSIDE access list. Therefore, Carrier Grade NAT cannot help block or traceback spoofed packets, and other SAV mechanisms are still needed.¶

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

+-------------------------------------------------------------+
|                                                      AS     |
|                        +----------+                         |
|                        | Router 3 |                         |
| FIB on Router 1        +----------+  FIB on Router 2        |
| Dest         Next_hop   /\      \    Dest         Next_hop  |
| 10.1.0.0/16  Subnet 1   /        \   10.0.0.0/16  Subnet 1  |
| 10.0.0.0/16  Router 3  /         \/  10.1.0.0/16  Router 3  |
|                +----------+     +----------+                |
|                | Router 1 |     | Router 2 |                |
|                +-----+#+--+     +-+#+------+                |
|                        /\         /                         |
|   Outbound traffic with \        / Inbound traffic with     |
|   source IP addresses    \      /  destination IP addresses |
|   of 10.0.0.0/16          \    \/  of 10.0.0.0/16           |
|                           Subnet 1                          |
|                        (10.0.0.0/15 )                       |
|                                                             |
+-------------------------------------------------------------+

                + Packets with              + Packets with
                | spoofed p1/p2             | spoofed p1/p2
+--------------|---------------------------|----------+
|  AS          \/                          \/         |
|          +--+#+-----+               +---+#+----+    |
|          | Router 3 +-------------->| Router 4 |    |
|          +----------+               +----------+    |
|             /     \                      |          |
|            /       \                     |          |
|          \/         \/                   \/         |
|  +----------+     +----------+      +----------+    |
|  | Router 1 |     | Router 2 |      | Router 5 |    |
|  +----------+     +----------+      +----------+    |
|        \              /                   |         |
|         \            /                    |         |
|          \          /                     \/        |
|           Subnet1(p1)                 Subnet2(p2)   |
+-----------------------------------------------------+

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

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

• Native IP forwarding: including both forwarding based on global routing table and CE site forwarding of VPN.¶
• IP-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): focusing on the validation of the outer layer IP address.¶
• Validating both IPv4 and IPv6 addresses.¶

Scope does not include:¶

• Non-IP packets: including MPLS label-based forwarding and other non-IP-based forwarding.¶

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

Authors' Addresses