| Internet-Draft | SPA-based SAVNET | October 2024 |
| Li, et al. | Expires 23 April 2025 | [Page] |
This document proposes the Source Prefix Advertisement (SPA) technology for intra-domain SAVNET, called SPA-based SAVNET. SPA-based SAVNET allows routers in an intra-domain network to exchange SAV-specific information through SPA messages. Compared with existing intra-domain SAV mechanisms RFC2827 [RFC3704], SPA-based SAVNET can generate more accurate and robust SAV rules on intra-domain routers in an automatic way. This document introduces the content of SPA messages and the process of generating SAV rules. 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.¶
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 23 April 2025.¶
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.¶
The main purpose of the intra-domain SAV for an AS A, is to block spoofing data packets from a host network or a customer network that use source addresses of other networks, as well as block spoofing data packets from other ASes that use source addresses of AS A (see [I-D.ietf-savnet-intra-domain-problem-statement]). However, existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation. Specifically, ACL-based ingress filtering (BCP38 [RFC2827]) requires manual operations to configure and update SAV rules, and strict uRPF (BCP84 [RFC3704]) may improperly block legitimate data packets in the scenario of routing asymmetry. To improve the accuracy upon existing intra-domain SAV mechanisms 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 allows SAVNET routers in an intra-domain network to signal SAV-specific information through SPA messages. 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. 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.¶
The reader is encouraged to be familiar with [I-D.ietf-savnet-intra-domain-problem-statement] and [I-D.ietf-savnet-intra-domain-architecture].¶
SAV Rule: The rule that describes the mapping relationship between a source address (prefix) and its valid incoming router interface(s).¶
SAVNET Router: An intra-domain router that deploys SPA-based SAVNET.¶
Host-facing Router: An intra-domain router facing an intra-domain host network.¶
Customer-facing Router: An intra-domain router facing an intra-domain customer network.¶
Single-homed Stub Network: A stub network that is belonging to or connected to only one AS.¶
Multi-homed Stub Network: A stub network that is belonging to or connected to multiple ASes.¶
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.¶
SPA-based SAVNET requires SAVNET routers to signal SAV-specific information through SPA message communication. The SAV-specific information contains the necessary information that improves the accuracy of SAV rules and cannot be learned from existing routing information. By using SAV-specific information, SAVNET routers can generate allowlist SAV rules (i.e., "Interface-based prefix allowlist" mode in [I-D.huang-savnet-sav-table]) or blocklist SAV rules (i.e., "Interface-based prefix blocklist" mode in [I-D.huang-savnet-sav-table]) on specific router interfaces.¶
The SAVNET router can be an intra-domain router facing a stub network (e.g., a host network and a customer network) or facing an external AS. Specifically, to block spoofing data packets from a host network or a customer network that use source addresses of other networks, SPA-based SAVNET can generate an allowlist on interfaces facing a host network or a customer network. The allowlist contains source prefixes of the corresponding network, because data packets from the network can only use source addresses belonging to the network unless there is a special case such as Direct Server Return (DSR). To block spoofing data packets from other ASes that use source addresses of the local AS, SPA-based SAVNET can generate a blocklist on interfaces facing an external AS, containing source prefixes of the local AS.¶
In the following, Section 3 introduces content of the SPA message and procedure of SAV rule generation. Section 4 introduces the most recommended use case, an alternative use case, and two corner use cases of SPA-based SAVNET, respectively.¶
Source Prefix Advertisement (SPA) procedure includes three main steps: SPA message generation, SPA message communication, and SAV rule generation.¶
A SPA message contains two main types of information:¶
Source Prefix: This information contains source prefixes learned from the router's local routes to its stub network, i.e., the locally-known source prefixes of the stub network. Specifically, each Dest Prefix in RIB that has an outgoing interface towards the stub network will be considered as a source prefix of the stub network. Note that in the case of asymmetric routes, the locally-known source prefixes may be only a part of all source prefixes of the stub network.¶
Stub Network Identifier: For each source prefix contained in the SPA message, it is binded with a Stub Network Identifier (SNI). The SNI is used to identify which stub network owns the source prefix. Prefixes belonging to the same stub network MUST have an identical and unique SNI value. Different stub networks MUST have different SNI values. The SNI is the key SAV-specific information used by SPA-based SAVNET when generating allowlists or blocklists.¶
Source prefixes contained in a SPA message indicate source addresses that can only be used by data packets received from the stub network. Therefore, only SAVNET routers facing a single-homed stub network (but there can be multiple links between the intra-domain network and the stub network) will generate SPA messages.¶
After generating SPA messages, the SAVNET router will provide its SPA messages to other SAVNET routers in the same intra-domain network. Figure 1 shows an example of SPA message communication. Routers A and B are host-facing routers facing the same single-homed stub network. Router C is an AS border router (ASBR) facing an external AS. Routers A and B can automatically exchange their SPA messages to ensure that they learn the full source prefixes of the stub network, even if there is an asymmetric route. Router A or B can automatically provide its SPA message to Router C, informing Router C which source addresses cannot be used by data packets from an external AS.¶
+------------+
| Other ASes |
+-----+------+
|
+-------------------|--------------------+
| +----+-----+ AS |
| | Router C | |
| +----------+ |
| /\ /\ |
| / \ |
| SPA message / \ SPA message |
| of Router A/ \of Router B |
| / SPA message \ |
| / of Router A \ |
| +----------+ ---------> +----------+ |
| | Router A | | Router B | |
| +------+---+ <--------- +--+-------+ |
| \ SPA message / |
| \ of Router B / |
| \ / |
| +--------------+ |
| | Stub Network | |
| +--------------+ |
+----------------------------------------+
Implementation consideration: Since the SPA message contains source prefixes of a stub network, SPA message communication can be implemented by using existing intra-domain routing protocols (e.g., OSPF, IS-IS, iBGP). When distributing the IP information of the stub network through the intra-domain routing protocol, the SAVNET router can bind the SNI with the IP information. This document focuses on the protocol-independent design of SPA-based SAVNET. Protocol designs and extensions are not in the scope of this document.¶
After receiving SPA messages from other SAVNET router, each SAVNET router will generate allowlists or blocklists on specific interfaces:¶
Allowlist generation procedure: A SAVNET router facing a stub network can generate an allowlist on the corresponding interface by using its own SPA message as well as SPA messages of other SAVNET routers (if any) facing the same stub network. All source prefixes in SPA messages with the SNI of its stub network will be added into the allowlist. The stub network can be a host network, a customer network, a stub OSPF area, or a stub AS. When using an allowlist on an interface facing a stub network, it must ensure that the stub network is not multi-homed to another AS.¶
Blocklist generation procedure: A SAVNET router can generate a blocklist by using SPA messages from other SAVNET routers. All source prefixes in SPA messages will be added into the blocklist. The blocklist is recommended to be used on interfaces facing an external AS or facing a stub network that is multi-homed to multiple ASes.¶
SPA-based SAVNET is highly recommended to be deployed at host-facing routers, customer-facing routers, and AS border routers. It is because that these routers are closer to the source and thus will be more effective in identifying and discarding source-spoofed data packets. SPA-based SAVNET generates allowlists on interfaces facing a host network, a customer network, or a stub AS, and generates blocklists on interfaces facing a non-stub AS.¶
Figure 2 shows an example of the most recommended use case. SPA-based SAVNET is deployed at Routers A, B, and C. The stub network 1 or 2 can be a host network, a customer network, or a stub AS. Stub network 1 is single-homed to the intra-domain network but multi-connected to Routers A and B. Stub network 1 is single-homed to the intra-domain network and single-connected to Router B. Router C is connected to an external non-stub AS. Stub network 1 has two source prefixes P1 and P2. Due to traffic engineering and load balance, Router A only learns the route to prefix P1 from its Interface '#' and Router B only learns the route to prefix P2 from its Interface '#'. The SNI value of stub network 1 is set as 1, and the SNI value of stub network 2 is set as 2.¶
+---------------+
| Non-stub ASes |
+---------------+
|
+----------------------------|------------------------------+
| +----#-----+ |
| | Router C | |
| +----------+ |
| ^ |
| SPA message | SPA message |
| of Router A | of Router B |
| | |
| +-----------------+-----------------+ |
| | Other intra-domain routers | |
| +---+----------------------------+--+ |
| ^ | | ^ |
|SPA message | | SPA message SPA message | | SPA message |
|of Router A | | of Router B of Router A | | of Router B |
| | v v | |
| +----------+ +----------+ |
| | Router A | | Router B | |
| +------#---+ +--#---X---+ |
| \ / \ |
| \ / \ |
| \ / \ |
| +----------------+ +----------------+|
| | Stub Network 1 | | Stub Network 2 ||
| +----------------+ +----------------+|
| (Source prefixes: (Source prefixes: |
| P1 and P2) P3) |
+-----------------------------------------------------------+
SPA message of Router A:
[Source Prefix: P1, SNI: 1]
SPA message of Router B:
{[Source Prefix: P2, SNI: 1], [Source Prefix: P3, SNI: 2]}
Router A generates a SPA message containing source prefix P1 with a SNI value of 1. Router B generates a SPA message containing source prefix P2 with a SNI value of 1, and source prefix P3 with a SNI value of 1. After that, Router A or Router B provides its SPA message to other SAVNET routers. Router A or Router B finally generates an allowlist on its Interface '#' containing source prefixes P1 and P2, because both source prefixes have the SNI value of stub network 1. In addition, Router B generates an allowlist on its Interface 'X' containing source prefix P3 because only prefix P3 has the SNI value of stub network 2. Router C finally generates a blocklist on its Interface '#' containing all source prefixes of all SPA messages, i.e., prefixes P1, P2, and P3.¶
By using the allowlist or blocklist on different router interfaces, the intra-domain network can effectively prevent spoofing data packets from entering the intra-domain network while avoiding improper blocks. Routers A and B will only allow data packets from stub network 1 with source addresses in prefixes P1 and P2. Router B will only allow data packets from stub network 2 with source addresses in prefix P3. Router C will block data packets from external ASes with source addresses in prefixes P1, P2, and P3.¶
SPA-based SAVNET can also be used on Area Border Routers (ABR) in inter-area cases. For example, if the stub network in Figure 2 is a stub OSPF area, SPA-based SAVNET can also generate an allowlist on interfaces facing the stub OSPF area and thus only allow data packets using source addresses belonging to the stub OSPF area. However, it is less effective than deploying SPA-based SAVNET on interfaces facing a host network, a customer network, or a stub AS, because allowlists on ABRs are coarser. As a result, deploying SPA-based SAVNET on ABRs is an alternative rather than the most recommended use case.¶
In the case of DSR, the content server in a stub network will send data packets using source addresses of the anycast server in another AS (see [I-D.ietf-savnet-intra-domain-problem-statement]). To avoid blocking these special data packets, these specially used source addresses should be added into allowlists on interfaces facing a stub network where the content server locates.¶
As mentioned in Section 3, if a stub network is multi-homed to other ASes, SPA-based SAVNET must not generate SPA messages for this stub network and must not use an allowlist on the interface facing this stub network. It is because the router facing this stub network may only learns a part of source prefixes of the stub network. Therefore, it is recommended to use a blocklist in this case.¶
The propagation speed of SPA messages is a key factor affecting 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.¶
In the most recommended use case, SPA-based SAVNET is deployed on all host-facing routers, customer-facing routers, and AS border routers. When SPA-based SAVNET has not been deployed in all of these required routers simultaneously, SPA-based SAVNET supports incremental deployment by providing incremental benefits.¶
For allowlist generation, if the SAVNET router faces a stub network with only one link to the intra-domain network, it can generate an accurate allowlist on the corresponding interface without SPA messages of other routers. If the SAVNET router faces a stub network with multiple links to the intra-domain network, it only needs SPA messages of other routers facing the same stub network to generate a complete allowlist.¶
For blocklist generation, if the SAVNET router only learns partial internal prefixes, the generated blocklist can still be used to prevent spoofing data packets using source addresses in these prefixes from entering the intra-domain network.¶
As a result, when SPA-based SAVNET is partially deployed on the required routers, it can still block spoofing data packets on SAVNET routers.¶
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.¶
This document has no IANA actions.¶