| Internet-Draft | IGP-SAVNET | June 2024 |
| Li, et al. | Expires 16 December 2024 | [Page] |
This document proposes a new IGP-based intra-domain source address validation (SAV) solution, called IGP-SAVNET, which improves the accuracy upon current intra-domain SAV solutions. It allows intra-domain routers to communicate SAV-specific information using the intra-domain routing protocol or an extension to the intra-domain routing protocol. By using SAV-specific information, intra-domain routers can generate and update accurate SAV rules in an automatic way.¶
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 16 December 2024.¶
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 purpose of intra-domain 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 on host-facing routers, customer-facing routers, and AS border routers (see [I-D.ietf-savnet-intra-domain-architecture]). Specifically, host-facing routers or customer-facing 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.¶
However, 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]). ACL-based ingress filtering requires manual operations to configure and update the SAV rules, while uRPF-based solutions may improperly block legitimate data packets in the scenario of routing asymmetry. To address these problems and guide the design of new intra-domain SAV solutions, [I-D.ietf-savnet-intra-domain-architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information in intra-domain networks.¶
Following the intra-domain SAVNET architecture, this document proposes a new IGP-based intra-domain SAV solution, called IGP-SAVNET, which improves the accuracy upon current intra-domain SAV solutions. It allows host-facing routers, customer-facing routers, and AS border routers to communicate SAV-specific information using the intra-domain routing protocol or an extension to the intra-domain routing protocol. By using SAV-specific information, these routers can generate and update accurate SAV rules in an automatic way.¶
The reader is encouraged to be familiar with [I-D.ietf-savnet-intra-domain-problem-statement] and [I-D.ietf-savnet-intra-domain-architecture].¶
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.¶
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.¶
Host-facing Router: An intra-domain router of an AS which is connected to an intra-domain host network (i.e., a layer-2 network).¶
Customer-facing Router: An intra-domain router of an AS which is connected to an intra-domain 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.¶
Goal 1: The host-facing router or customer-facing router should identify source prefixes belonging to its host network or customer network and block data packets from its host network or customer network using source addresses not belonging to the network. For example, in Figure 1, Routers A and B should generate SAV rules at the interface '#' and block data packets from Network 1 using source addresses not belonging to Network 1. Router C should generate SAV rules at interfaces '#' and block data packets from Network 2 using source addresses not belonging to Network 2.¶
Goal 2: The AS border router should identify source prefixes belonging to the local AS and block data packets from other ASes using source addresses belonging to the local AS. For example, in Figure 1, Routers D and E should generate SAV rules at interface '#' and block data packets from other ASes using source addresses belonging to the local AS.¶
+----------------------------------+
| Other ASes |
+----------------------------------+
| |
+---------------|----------------------------|--------------+
| Intra-domain | | |
| | | |
| +-----#----+ +-----#----+ |
| | Router D | | Router E | |
| +----------+ +----------+ |
| | | |
| | | |
| +----------------------------------------+ |
| | Other intra-domain routers | |
| +----------------------------------------+ |
| / \ | |
| / \ | |
| +----------+ +----------+ +----------+ |
| | Router A | | Router B | | Router C | |
| +----#-----+ +-------#--+ +-----#----+ |
| \ / | |
+--------+\------------/---------------------|--------------+
\ / |
+------------------+ +------------------+
| Customer or Host | | Customer or Host |
| Network 1 | | Network 2 |
+------------------+ +------------------+
To achieve the above two goals, IGP-SAVNET allows host-facing routers, customer-facing routers, and AS border routers to communicate SAV-specific information between each other through IGP. These routers will not communicate SAV-specific information with routers/devices in host networks, customer networks, and other ASes. In the following, this document describes how IGP-SAVNET works to meet the goals.¶
SAV on a customer-facing (or host-facing) router aims to identify source prefixes belonging to the customer (or host) network. After that, the customer-facing (or host-facing) router can perform accurate SAV filtering by only accepting data packets from its customer (or host) network with source addresses belonging to that network.¶
If the customer (or host) network is single-homed, the customer-facing (or host-facing) router can directly identify source prefixes through its local routes to that network.¶
If the customer (or host) network is multi-homed, the customer-facing (or host-facing) router may fail to identify all source prefixes of that network through its local routes to that network in the scenario of routing asymmetry (see [I-D.ietf-savnet-intra-domain-problem-statement]). For example, in Figure 2, due to traffic engineering, Router A only learns the route to sub prefix 10.1.0.0/16 from Network N, while Router B only learns the route to the other sub prefix 10.0.0.0/16 from Network N. In this case, as described in [I-D.ietf-savnet-intra-domain-problem-statement], strict uRPF on Router A will block data packets from the customer (or host) network with legitimate source addresses in prefix 10.0.0.0/16, and strict uRPF on Router B will block data packets from the customer (or host) network with legitimate source addresses in prefix 10.1.0.0/16. To achieve accurate SAV on routers facing the multi-homed customer (or host) network, IGP-SAVNET allows routers facing the same customer (or host) network to identify source prefixes of the network through SAV-specific information communication.¶
+-----------------------------------------------------+ | AS | | [10.1.0.0/16]+[tag n] | | +----------+ +---------------------> +----------+ | | | Router A | SAV-specific info | Router B | | | +-------#--+ <---------------------+ +--#-------+ | | | [10.0.0.0/16]+[tag n] | | | | | | | | | | | | +--------------------+ | | | | | Customer or Host | | | | +----| Network N |-----+ | | +--------------------+ | | (10.0.0.0/15 ) | +-----------------------------------------------------+
A detailed description of SAV procedure is as follows:¶
Tag Assignment: Each single-homed or multi-homed customer (or host) network is assigned a unique tag value. For example, in Figure 2, Network N is assigned tag n. The tag value for can be configured and updated manually.¶
SAV-specific Information Communication: Each customer-facing (or host-facing) router provides its SAV-specific information of its customer (or host) networks to other intra-domain routers. The SAV-specific information of a customer (or host) network contains the prefixes learned through the router's local routes to the network and the tag value of the network. For example, Router A can provide its SAV-specific information, which contains prefix 10.1.0.0/16 and tag n, to other intra-domain routers. This procedure can be implemented by using IGP or extensions to IGP, which will be elaborated in Section 5.¶
SAV-specific Information Processing: When a router receives SAV-specific information containing the same tag value as its customer (or host) network, it considers that the prefixes contained in the SAV-specific information also belong to its customer (or host) network. For example, Router B will identify prefix 10.1.0.0/16 as a source prefix of Network N after receiving the SAV-specific information provided by Router A.¶
Source Prefix Identification: By integrating prefixes learned through SAV-specific information provided by other routers with prefixes learned through its local routes, the customer-facing (or host-facing) router can identify complete source prefixes of its customer (or host) network. For example, Router B will identify that both prefix 10.1.0.0/16 and prefix 10.0.0.0/16 belong to Network N after processing SAV-specific information provided by Router A. Similarly, Router A will also identify complete source prefixes of Network N after processing SAV-specific information provided by Router B.¶
SAV Rule Generation: Each customer-facing (or host-facing) router generates an allowlist containing source prefixes of its customer (or host) network at the interface facing that network. Only data packets using source addresses covered in the allowlist will be accepted at this interface.¶
SAV on an AS border router aims to identify source prefixes belonging to the local AS. After receiving SAV-specific information or routing information originating from host-facing and customer-facing routers through IGP, AS border routers can identify source prefixes of the local AS accordingly and generate a blocklist containing these source prefixes. After that, data packets arriving from other ASes with source addresses belonging to the local AS will be blocked on the AS border router.¶
The key idea is to add the tag value into the prefix information when the customer-facing (or host-facing) router distributes the prefix information of its customer (or host) network. As shown in Figure 3, the SAVNET Agent of a Sender Router provides its SAV-specific information to other SAVNET routers via IGP. After receiving SAV-specific information from other SAVNET routers, the SAVNET Agent of the Receiver Router generates SAV rules by using SAV-specific information from other SAVNET routers and/or its own SAV-specific information. The Sender Router can be a customer-facing router or a host-facing router. The Receiver Router can be a customer-facing router, a host-facing router, or an AS border router.¶
+---------------------+ +---------------------+ | Sender Router | SAV-specific | Receiver Router | | +------------+ | Information | +------------+ | | | IGP LSDB +------------------------->+ IGP LSDB | | | +-----^------+ | | +-----+------+ | | | | | | | | +-------+---------+ | | +--------v--------+ | | | SAVNET Agent | | | | SAVNET Agent | | | | +-------------+ | | | | +-------------+ | | | | | Information | | | | | | Information | | | | | | Provider | | | | | | Receiver | | | | | +-------------+ | | | | +-------------+ | | | +-----------------+ | | +-----------------+ | | | | | +---------------------+ +---------------------+
The overall procedure of SAV-specific information communication is as follows:¶
At the Sender Router: Carry its SAV-specific information (e.g., the tag information of the customer or host network) through the Link State Database (LSDB) of IGP. The IGP will synchronize the LSDB, including node information, link information, prefix information, and tag information.¶
At the Receiver Router: After receiving SAV-specific information carried in the LSDB, its SAVNET Agent extracts SAV-specific information from the LSDB of IGP and then generates SAV rules as described in Section 4.¶
In the following, this document presents two approaches to implement SAV-specific information communication among intra-domain routers.¶
When a router distributes IP prefix information of the customer or host network, it can carry the tag of that network in the Administrative Tag Sub-TLV.¶
When a router receives IP prefix information, it checks if there is a locally configured interface with the same tag as the Administrative Tag information carried in the prefix. If such an interface exists, SAVNET rules will be added, with the prefix being the received prefix and the interface being the locally configured interface with this tag.¶
As shown in Figure 2, assume Network N is assigned tag n. In the prefix information of 10.1.0.0/16 published by Router A, tag n is carried via the Administrative Tag Sub-TLV. Similarly, in the prefix information of 10.0.0.0/16 published by Router B, tag n is carried via the Administrative Tag Sub-TLV. When Router A receives the prefix information of 10.0.0.0/16, it checks that the carried tag n matches the tag of Network N, and thus determines that prefix 10.0.0.0/16 also belongs to Network N. Similarly, Router B determines that prefix 10.1.0.0/16 also belongs to Network N using the same process.¶
For routers running IS-IS, they can carry the tag in the Administrative Tag Sub-TLV (defined in [RFC5130]), which can be included in: Extended IP Reachability TLV (135), Multi-Topology Reachable IPv4 Prefixes TLV (235), IPv6 Reachability TLV (236), Multi-Topology Reachable IPv6 Prefixes TLV (237).¶
For routers running OSPF, they can carry the tag in the Administrative Tag Sub-TLV [I-D.ietf-lsr-ospf-admin-tags] within the OSPF Extended Prefix TLV Sub-TLV [RFC7684].¶
For routers running OSPFv3, they can include the tag in the Administrative Tag Sub-TLV [I-D.ietf-lsr-ospf-admin-tags] within the OSPFv3 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV [RFC8362].¶
In practice, intra-domain routers may also use the Administrative Tag Sub-TLV for other purposes (e.g., route filtering), and multiple Administrative Tag Sub-TLVs may be carried in the IP prefix information simultaneously. Therefore, using the existing Administrative Tag Sub-TLV for SAV-specific information communication may conflict with other routing policies that also use Administrative Tags as filtering criteria. To address this issue, this document proposes Approach #2 in the following.¶
To avoid possible conflicts and facilitate operation and management, it is more recommended to define and use a dedicated SAVNET Tag Sub-TLV to tranmit SAV-specific information.¶
Figure 4 shows the structure of SAVNET Tag Sub-TLV of IS-IS. It can be included in the following TLVs: Extended IP Reachability TLV (135), Multi-Topology Reachable IPv4 Prefixes TLV (235), IPv6 Reachability TLV (236), Multi-Topology Reachable IPv6 Prefixes TLV (237).¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-SPI(TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAVNET Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: A 8-bit field set to TBD.
Length: 4 octets.
SAVNET Tag: The tag of the customer or host network.
Figure 5 shows the structure of SAVNET Tag Sub-TLV of OSPF and OSPFv3.¶
The SAVNET Tag Sub-TLV of OSPF specified herein will be valid as a sub-TLV of the following TLVs specified in [RFC7684]:¶
Extended Prefix TLV advertised in the OSPFv2 Extended Prefix LSA¶
The SAVNET Tag Sub-TLV of OSPFv3 specified herein will be valid as a sub-TLV of the following TLVs specified in [RFC8362]:¶
Inter-Area-Prefix TLV advertised in the E-Inter-Area-Prefix-LSA.¶
Intra-Area-Prefix TLV advertised in the E-Intra-Area-Prefix-LSA.¶
External-Prefix TLV advertised in the E-AS-External-LSA and the E-NSSA-LSA.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type - Link Tag | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAVNET Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: A 16-bit field set to TBD.
Length: 4 octets.
SAVNET Tag: The tag of the customer or host network.
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 requirements.¶