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 25 July 2025.¶

Copyright Notice

Copyright (c) 2025 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. A multi-fence architecture called Source Address Validation Architecture (SAVA) [RFC5210] was proposed to implement SAV at three levels: access-network SAV, intra-domain SAV, and inter-domain SAV. The multi-fence architecture helps enhance the effectiveness of SAV across the whole Internet by preventing or mitigating source address spoofing at multiple levels.¶

Access-network SAV mechanisms (such as SAVI [RFC7039], IP Source Guard (IPSG) [IPSG], and Cable Source-Verify [cable-verify]) can ensure that a host must use the source IP address assigned to the host. Given numerous access networks managed by different operators throughout the world, it is difficult to require all access networks to deploy SAV simultaneously. Therefore, intra-domain SAV and inter-domain SAV are needed to block source-spoofed data packets from access networks as close to the source as possible. Intra-domain SAV and inter-domain SAV perform SAV at the granularity of IP prefixes, which is coarser than the granularity of access network SAV (i.e., IP address), 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 Autonomous Systems (ASes). Intra-domain 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 the rest of the Internet. Intra-domain SAV for AS X aims at achieving two goals: i) blocking source-spoofed packets originated from its host networks or customer networks using a source address of other networks; and ii) blocking source-spoofed packets coming from other ASes using a source address of AS X.¶

Figure 1 illustrates the goals and function of intra-domain SAV with two cases. Case i shows that the host network or customer network of AS X originates source-spoofed packets using a source address of other networks. If AS X deploys intra-domain SAV, the spoofed packets can be blocked by host-facing routers or customer-facing routers of AS X (i.e., Goal i). Case ii shows that AS X receives source-spoofed packets using a source address of AS X 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 border routers of AS X (i.e., Goal ii).¶

Case i: The host network or customer network of AS X originates
        packets spoofing source addresses of other networks
Goal i: If AS X deploys intra-domain SAV,
        the spoofed packets can be blocked by AS X

                                    Spoofed packets
                                    using source addresses
  +-------------------------------+ of other networks     +------+
  | Host/Customer Network of AS X |---------------------->| AS X |
  +-------------------------------+                       +------+

Case ii: AS X receives packets spoofing source addresses of AS X
         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
           using source addresses
  +------+ of AS X               +------+
  | AS X |<----------------------| AS Y |
  +------+                       +------+

The scope of intra-domain SAV includes all IP-encapsulated scenarios:¶

• Native IP forwarding: including both forwarding based on global routing table and VPN forwarding.¶

• IP-encapsulated Tunnel (IPsec [RFC4301], GRE [RFC2784], SRv6 [RFC9256], 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 the following, this document provides gap analysis of existing intra-domain SAV mechanisms, concludes main problems of existing intra-domain SAV mechanisms, and proposes requirements for future ones.¶

2. Existing Intra-domain SAV Mechanisms

This section introduces existing intra-domain SAV mechanisms, including BCP38 [RFC2827] and BCP84 [RFC3704].¶

• ACL-based ingress filtering or BCP38 [RFC2827] requires that network operators manually configure ACL rules on intra-domain routers to block or permit data packets using specific source addresses. This mechanism can be used on interfaces of host-facing or customer-facing routers facing an intra-domain host/customer network to prevent the corresponding host/customer network from spoofing source prefixes of other networks [manrs-antispoofing]. In addition, it is also usually used on interfaces of AS border routers facing an external AS to block data packets using disallowed source addresses, such as internal source addresses owned by the local AS [nist-rec]. In any application scenario, ACL rules must be updated in time to be consistent with the latest filtering criteria when the network changes.¶

• Strict uRPF [RFC3704] is also typically used on interfaces of host-facing or customer-facing routers facing an intra-domain host/customer network. Routers deploying strict uRPF accept a data packet only when i) the local FIB contains a prefix covering 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.¶

• Loose uRPF [RFC3704] uses a looser validation method. A packet will be accepted if the router's local FIB contains a prefix covering the packet's source address regardless of the interface from which the packet is received. In fact, interfaces of AS border routers facing an external AS may use loose uRPF to block incoming data packets using non-global addresses [nist-rec].¶

• Carrier Grade NAT has some operations on the source addresses of packets, but it 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 determine whether the source address is spoofed or not. In addition, the packet using a spoofed source address will still be forwarded if the spoofed source address is not included in the INSIDE access list. Therefore, Carrier Grade NAT cannot help identify and block source-spoofed data packets.¶

3. Gap Analysis

This section elaborates the key problems of current intra-domain SAV on host-facing or customer-facing routers and SAV on AS border routers, respectively.¶

 +---------------------------------------------------------+
 |                                                      AS |
 |                     +----------+                        |
 |                     | Router 3 |                        |
 |                     +----------+                        |
 |                       /      \                          |
 |                      /        \                         |
 |                     /          \                        |
 |             +----------+     +----------+               |
 |             | Router 1 |     | Router 2 |               |
 |             +-----+#+--+     +-+#+------+               |
 |                   /\           /                        |
 |Traffic with        \          / Traffic with            |
 |source IP addresses  \        /  destination IP addresses|
 |of 2001:db8::/33      \      \/  of 2001:db8::/33        |
 |                  +----------------+                     |
 |                  |  Host/Customer |                     |
 |                  |    Network 1   |                     |
 |                  |(2001:db8::/32) |                     |
 |                  +----------------+                     |
 |                                                         |
 +---------------------------------------------------------+

 FIB of Router 1                 FIB of Router 2
 Dest               Next_hop     Dest               Next_hop
 2001:db8:8000::/33 Network 1    2001:db8:8000::/33 Router 3
 2001:db8::/33      Router 3     2001:db8::/33      Network 1

 The legitimate traffic originated from Network 1 with source IP
 addresses of 2001:db8::/33 will be improperly blocked by Router 1
 if Router 1 uses strict uRPF.

          +-------------------------+
          |          AS Y           | AS Y announces the route
          |   (where the anycast    | for anycast prefix P3
          |    server is located)   | in BGP
          +-----------+-------------+
                      |
                      |
          +-----------+-------------+
          |       Other ASes        |
          +-------------------------+
             /                    \
            /                      \
           /                        \
+------------------+   +---------------------------------------+
|      AS Z        |   |         +----------+             AS X |
| (where the user  |   |         | Router 4 |                  |
|    is located)   |   |         +----------+                  |
+------------------+   |              |                        |
                       |              |                        |
                       |         +----+-----+                  |
                       |         | Router 5 |                  |
                       |         +----#-----+                  |
                       |              /\    DSR responses with |
                       |              |     source IP addresses|
                       |              |     of P3              |
                       |       +---------------+               |
                       |       | Host/Customer |               |
                       |       |   Network 2   |               |
                       |       |     (P2)      |               |
                       |       +---------------+               |
                       | (where the edge server is located)    |
                       +---------------------------------------+
DSR response packets from edge server in Network 2 with
source IP addresses of P3 (i.e., the anycast prefix) will
be improperly blocked by Router 5 if Router 5 uses strict uRPF.

 Packets with +              Packets with +
 spoofed P1/P2|              spoofed P1/P2|
+-------------|---------------------------|---------+
|   AS        \/                          \/        |
|         +--+#+-----+               +---+#+----+   |
|         | Router 3 +---------------+ Router 4 |   |
|         +----------+               +----+-----+   |
|          /        \                     |         |
|         /          \                    |         |
|        /            \                   |         |
| +----------+     +----------+      +----+-----+   |
| | Router 1 |     | Router 2 |      | Router 5 |   |
| +----------+     +----------+      +----+-----+   |
|        \             /                  |         |
|         \           /                   |         |
|          \         /                    |         |
|       +---------------+         +-------+-------+ |
|       |   Customer    |         |     Host      | |
|       |   Network     |         |   Network     | |
|       |     (P1)      |         |     (P2)      | |
|       +---------------+         +---------------+ |
|                                                   |
+---------------------------------------------------+

4. Problem Statement

As analyzed above, existing intra-domain SAV mechanisms have significant limitations on automatic update or accurate validation.¶

ACL-based ingress filtering relies on manual configurations and thus requires high operational overhead in dynamic networks. To guarantee accuracy of ACL-based SAV, network 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 can automatically update SAV rules, but may improperly block legitimate traffic under asymmetric routing scenario or hidden prefix scenario. It may mistakenly consider a valid incoming interface as invalid, resulting in improper block problems; or it may mistakenly consider an invalid incoming interface as valid, resulting in improper permit problems.¶

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

In summary, uRPF cannot guarantee the accuracy of SAV because it solely uses the router’s local FIB or RIB information to determine SAV rules. A router cannot see the asymmetric route between itself and another router/network from its own perspective. As a result, strict uRPF has improper block problems in the scenario of asymmetric route. The network operator has a comprehensive perspective so he/she can configure the correct SAV rules. However, manual configuration has limitations on automatic update.¶

5. Requirements for New SAV Mechanisms

The key to overcoming the problems is to automatically combine perspectives of multiple routers, allowing each router to form a more comprehensive perspective. To this end, new SAV solutions can allow routers to exchange and update the asymmetric information that affects the accuracy of SAV (i.e., SAV-specific information) in an automatic way. Then, routers can use SAV-specific information and local routing information to determine accurate SAV rules.¶

It is also important to reduce the complexity and overhead of SAV implementation. To this end, routers MUST NOT signal too much information. Only information that cannot be learned from local routing information and is necessary for SAV should be signaled. In addition, in order to better compatibility with the current intra-domain network, it is recommended that existing routing protocols can be used to implement the SAV function.¶

Specifically, this section lists the following five requirements that should be considered when designing new intra-domain SAV mechanisms.¶

6. Security Considerations

The new intra-domain SAV mechanisms should 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 messages that deliver the required SAV information, and consider avoiding unintentional misconfiguration. It is not necessary to provide protection against compromised or malicious intra-domain routers which poison existing control or management plane protocols. Compromised or malicious intra-domain routers may not only affect SAV, but also disrupt the whole intra-domain routing domain. Security solutions to prevent these attacks are beyond the capability of intra-domain SAV.¶

7. IANA Considerations

This document does not request any IANA allocations.¶

8. 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, Tony Przygienda, Yingzhen Qu, Changwang Lin, James Guichard, Linda Dunbar, Robert Sparks, Yu Fu, Stephen Farrel etc.¶

9. References

Authors' Addresses