Source Prefix Advertisement for Intra-domain SAVNET

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 9 January 2025.¶

Copyright Notice

Copyright (c) 2024 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

The purpose of intra-domain source address validation (SAV) is to prevent outgoing data packets from an intra-domain subnet (e.g., a host network or a customer network) from forging source addresses of other intra-domain subnets or other ASes, and to prevent incoming data packets from external ASes from forging source addresses of the local AS. To this end, intra-domain SAV should focus on SAV at edge routers (i.e., host-facing routers or customer-facing routers), and AS border routers (see [I-D.ietf-savnet-intra-domain-architecture]). Specifically, edge routers should block data packets from the connected host network or customer network with a spoofed source IP address not belonging to that network. AS border routers should block data packets from other ASes with a spoofed source IP address belonging to the local AS.¶

Existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation (see [I-D.ietf-savnet-intra-domain-problem-statement]). Specifically, ACL-based ingress filtering (BCP38 [RFC2827]) requires manual operations to configure and update the SAV rules, while uRPF-based solutions (BCP84 [RFC3704]) may improperly block legitimate data packets in the scenario of routing asymmetry. To improve the accuracy upon existing intra-domain SAV solutions and enable automatic update, intra-domain SAVNET architecture requires SAVNET routers to automatically generate SAV rules by using SAV-specific information [I-D.ietf-savnet-intra-domain-architecture].¶

This document proposes the Source Prefix Advertisement (SPA) technology for intra-domain SAVNET, called SPA-based SAVNET. Following the intra-domain SAVNET architecture, SPA-based SAVNET focuses on SAV at edge routers and AS border routers in an intra-domain network. It allows SAVNET routers within an intra-domain network to communicate SAV-specific information through SPA messages. SAVNET routers will not communicate SAV-specific information with routers/devices in intra-domain subnets and other ASes. By using SAV-specific information, SAVNET routers can generate more accurate and robust SAV rules in an automatic way.¶

This document introduces the content of SPA messages and the process of generating SAV rules using SPA messages. SPA messages can be transmitted by a new protocol or an extension to an existing protocol. Protocol designs and extensions are not in the scope of this document.¶

2. Goal of SPA-based SAVNET

Figure 1 shows an intra-domain network that adopts SPA-based SAVNET. Router 1 and Router 2 are edge routers that enable SAV at the interfaces facing to a subnet. Router 3 is an AS border router that enables SAV at the interfaces facing to an AS.¶

This document defines four types of interfaces that should enable SPA-based SAVNET:¶

• Single-homing interface. The interface of an edge router that faces to a singled-homed subnet. For example, Intf.1 in Figure 1 is a "Single-homing interface".¶

• Complete multi-homing interface. For an edge router facing to a multi-homed subnet, if all routers facing to the multi-homed subnet are in the same AS, the interface facing to this subnet is "Complete multi-homing interface". In this case, the multi-homed subnet is called complete multi-homed subnet. For example, Intf.2 and Intf.3 in Figure 1 are "Complete multi-homing interfaces".¶

• Incomplete multi-homing interface. For an edge router facing to a multi-homed subnet, if some other routers facing to the multi-homed subnet are in other ASes, the interface facing to this subnet is "Incomplete multi-homing interface". In this case, the multi-homed subnet is called incomplete multi-homed subnet. For example, Intf.4 in Figure 1 is "Incomplete multi-homing interface".¶

• Internet interface. The interface of an AS border router that faces to another AS. Generally, a network usually has multiple "Internet interfaces" for load balancing or backup. For example, Intf.5 and Intf.6 in Figure 1 are "Internet interfaces".¶

+-----------------------------------------+
|               Other ASes                |
+-----------------------------------------+
              |      |                |
              |      |                |
+-------------|------|----------------|---+
| AS          |      |                |   |
|       Intf.5|      |Intf.6          |   |
|           +-*------*-+              |   |
|           | Router 3 |              |   |
|           +----------+              |   |
|              /     \                |   |
|             /       \               |   |
|            /         \              |   |
|   +----------+     +----------+     |   |
|   | Router 1 |     | Router 2 |     |   |
|   +--#-----#-+     +-#-----*--+     |   |
|Intf.1|      \Intf.2 /Intf.3 \Intf.4 |   |
|      |       \     /         \      |   |
|      |        \   /           \     |   |
|   Subnet1    Subnet2           Subnet3  |
|    (P1)      (P2, P3)          (P4,P5)  |
+-----------------------------------------+

Routers 1 and 2 are edge routers
Router 3 is an AS border router
Intf '#' enables prefix allowlist
Intf '*' enables prefix blocklist

The goal of SPA-based SAVNET is to automatically generate prefix allowlist or blocklist for the four types of interfaces:¶

• Single-homing interface. SPA-based SAVNET generates a prefix allowlist (i.e., "Interface-based prefix allowlist" mode in [I-D.huang-savnet-sav-table]) at each "Single-homing interface". The prefix allowlist should contain all source prefixes of the connected subnet and blocks data packets from that subnet with source addresses not belonging to these source prefixes. In Figure 1, the prefix allowlist for Intf. 1 should contain the source prefix of Subnet1 (i.e., prefix P1).¶

• Complete multi-homing interface. Same as "Single-homing interface", SPA-based SAVNET generates a prefix allowlist at each "Complete multi-homing interface", containing all source prefixes of the connected subnet. In Figure 1, the prefix allowlists for Intf. 2 or Intf. 3 should include the source prefixes of Subnet2 (i.e., prefixes P2 and P3). By using the prefix allowlist, Routers 1 and 2 can accurately block spoofing data packets from Subnet2 using source IP addresses not in prefixes P2 and P3.¶

• Incomplete multi-homing interface. For an "Incomplete multi-homing interface", if there is a asymmetric routing among the connected subnet and its multiple provider networks, it is hard to identify all source prefixes of the subnet without communication between the multiple provider networks. Therefore, SPA-based SAVNET generates a prefix blocklist (i.e., "Interface-based prefix blocklist" mode in [I-D.huang-savnet-sav-table]) at each "Incomplete multi-homing interface". The prefix blocklist should include all source prefixes belonging to the subnets connected to "Single-homing interfaces" and "Complete multi-homing interfaces". In Figure 1, the prefix blocklist of Intf. 4 should contain the source prefixes of Subnet1 and Subnet2 (i.e., prefixes P1, P2, and P3).¶

• Internet interface. Same as "Incomplete multi-homing interface", SPA-based SAVNET generates a prefix blocklist at each "Internet interface", containing all source prefixes belonging to the subnets connected to "Single-homing interfaces" and "Complete multi-homing interfaces". In Figure 1, the prefix blocklist of Intf. 5 and Intf. 6 should contain the source prefixes of Subnet1 and Subnet2 (i.e., prefixes P1, P2, and P3).¶

3. Source Prefix Advertisement Procedure

Source Prefix Advertisement (SPA) procedure includes three main steps: SPA message generation, SPA message communication, and SAV rule generation.¶

4. Use Case

Figure 2 shows a use case of SPA-based SAVNET in an intra-domain network. Intf.1 of Router 1 is a "Single-homing interface" facing to Subnet1 which has prefix P1. Intf.2 of Router 1 and Intf.3 of Router 2 are "Complete multi-homing interfaces" facing to Subnet2 which has prefixes P2 and P3. Due to traffic engineering and load balance, Router 1 only learns the route to prefix P2 from Intf.2, while Router 2 only learns the route to prefix P3 from Intf.3. Intf.4 of Router 2 is an "Incomplete multi-homing interface" facing to Subnet 3 which has prefixes P4 and P5. Intf.5 and Intf.6 of Router 3 are "Internet interfaces" facing to other ASes.¶

+-------------------------------------------+
|               Other ASes                  |
+----------------+------+----------------+--+
                 |      |                |
                 |      |                |
+----------------|------|----------------|--+
|    AS          |      |                |  |
|          Intf.5+      +Intf.6          |  |
|             +-+*+----+*+-+             |  |
|             |  Router 3  |             |  |
| [P1,SI,     /\--------/\-+  [P1,SI,    |  |
| Sub1,SRC]   / /        \ \  Sub1,SRC]  |  |
| [P2,CI,    / /[P3,CI,   \ \ [P2,CI,    |  |
| Sub2,SRC] / /  Sub2,SRC] \ \ Sub2,SRC] |  |
|     +------\/----+   +-----\/-----+    |  |
|     |  Router 1  |   |  Router 2  |    |  |
|     +--+#+---+#+-+   +-+#+---+*+--+    |  |
|   Intf.1|      \Intf.2 /Intf.3 \Intf.4 |  |
|         |       \     /         \      |  |
|         |        \   /           \     |  |
|      Subnet1    Subnet2           Subnet3 |
|       (P1)      (P2, P3)          (P4,P5) |
+-------------------------------------------+

Routers 1 and 2 are edge routers
Router 3 is an AS border router
Intf '#' enables prefix allowlist
Intf '*' enables prefix blocklist

Router 1 generates SPA messages for source prefixes (i.e., prefixes P1 and P2) learned from its local routes to Subnet 1 and Subnet 2. For prefix P1, the MIIG-Type is "Single-homing interface", the MIIG-Tag is "Subnet1", and the Source Flag is set (i.e., [P1, SI, Sub1, SRC]). For prefix P2, the MIIG-Type is "Complete multi-homing interface", the MIIG-Tag is "Subnet2", and the Source Flag is set (i.e., [P2, CI, Sub2, SRC]). After generating SPA messages, Router 1 sends its SPA messages to Routers 2 and 3.¶

Router 2 generates SPA messages for prefix P3. The MIIG-Type is "Complete multi-homing interface", the MIIG-Tag is "Subnet2", and the Source Flag is set (i.e., [P3, CI, Sub2, SRC]). After that, it sends its SPA messages to Routers 1 and 3.¶

As described in Section 3.3, Routers 1, 2, and 3 generate SAV rules after receiving SPA messages from other routers. For Router 1, it generates a prefix allowlist at Intf.1 containing prefix P1 by using its own SPA message [P1, SI, Sub1, SRC]. By using its own SPA message [P2, CI, Sub2, SRC] and Router 2's SPA messages [P3, CI, Sub2, SRC], it generates a prefix allowlist at Intf.2 containing prefixes P2 and P3. For Router 2, it generates a prefix allowlist at Intf.2 containing prefixes P2 and P3 by using its own SPA message [P3, CI, Sub2, SRC] and Router 1's SPA message [P2, CI, Sub2, SRC]. At Intf.4, Intf.5, or Intf.6, Router 2 or Router 3 generates a prefix blocklist containing prefixes P1, P2, and P3 by using all SPA messages of Router 1 and Router 2.¶

By using prefix allowlist or blocklist at different interfaces, the intra-domain network can prevent data packets using spoofing source addresses from entering the network while avoiding improper block. Intf.1 will only accept data packets from Subnet 1 with source addresses in prefix P1. Intf.2 and Intf.3 will only accept data packets from Subnet 2 with source addresses in prefixes P2 and P3. Intf.4, Intf.5, and Intf.6 will block data packets from Subnet 3 or other ASes with source addresses in prefixes P1, P2, and P3.¶

5. Convergence Considerations

The propagation speed of SAV-specific is a key factor affecting the convergence. Consider that routing information and SAV-specific information can be originated and advertised through a similar way, SAV-specific information SHOULD at least have a similar propagation speed as routing information. When designing SPA message communication methods, routing protocol-based methods should be preferred.¶

6. Deployment Considerations

SPA-based SAVNET can support incremental deployment by providing incremental benefits. In the scenario of incremental deployment, a router can only receive SPA messages from edge routers that deploy SPA-based SAVNET. For a router with a "Single-homing interface", it can generate accurate SAV rules at that interface without SPA messages from other routers. For a router with a "Complete multi-homing interface", it only needs SPA messages from other edge routers connected to the same subnet, but not from all edge routers. For a router with a "Incomplete multi-homing interface" or "Internet interface", if it only learns partial internal prefixes by processing SPA messages, the generated SAV rule can still prevent spoofing traffic using source addresses in those prefixes from entering the intra-domain network. In addition, the router can use routing information to learn more internal prefixes.¶

7. Security Considerations

The security considerations described in [I-D.ietf-savnet-intra-domain-problem-statement] and [I-D.ietf-savnet-intra-domain-architecture] also applies to this document.¶

8. IANA Considerations

This document has no IANA actions.¶

Authors' Addresses