| Internet-Draft | IGP POI for Intra-domain SAV | January 2024 |
| Song, et al. | Expires 27 July 2024 | [Page] |
This document describes an IGP Prefix Originated Indicator (POI) method for Source Address Validation (SAV) on routers to mitigate source address spoofing attack and improve the accuracy of source address validation in intra-domain networks.¶
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 27 July 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.¶
Source Address Validation (SAV) is one important way to mitigate source address spoofing attacks in the data plane. There are some existing mechanisms like URPF-related technologies can be used to deploy SAV in intra-domain and inter-domain networks. However, these technologies may improperly permit spoofed traffic or block legitimate traffic with some limitations.¶
As analyzed at [I-D.ietf-savnet-intra-domain-problem-statement], strict uRPF (see [RFC3704]) technology is simple to implement and provides a very reasonable way to single-homing scenarios for ingress filtering. An ingress packet at a border router is accepted only if the Forwarding Information Base (FIB) contains a prefix that encompasses the source address and forwarding information for that prefix points back to the interface over which the packet was received. But when networks are multi-homed or un-symmetric, routes are not symmetrically announced to all transit providers, if the incoming interface of received packets is different with the export interface for routing of the source address it may bring wrong block for logic source address prefixes.¶
Loose URPF (see [RFC3704]) takes a looser validation mechanism than strict URPF to avoid improper block but may permit improperly spoofed source address. The FP-uRPF (see [RFC3704]) attempts to strike the balance of the strict and loose uRPF but still has some shortcoming. The EFP-uRPF (see [RFC8704]) provides a more feasible way in overcoming the improper block of strict uRPF in asymetric routing scenario, but EFP-uRPF has not been implemented in practical networks yet.¶
This document describes an IGP Prefix Originated Indicator (POI) method for Source Address Validation on routers to mitigate source address spoofing attack and improve the accuracy of source address validation in intra-domain networks.¶
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.¶
Refer to [I-D.li-savnet-intra-domain-architecture] for the key terms used in this document.¶
Prefix Originated Indicator (POI):A tag for IGP/BGP source Prefix Origin Identification.¶
The document provides an IGP Prefix origin Indicator (POI) method for identifying the origin of source prefixes to avoid attacks caused by source address spoofing. The POI characteristic for source address prefix is propagated by IGP route. Its corresponding IGP extension for source address prefix validation refers to section 4.¶
The IGP POI method can help overcome the improper filtering problem with strict URPF in asymmetrical or multi-homing scenarios. The method is based on the principal that if IGP route flooding for multiple prefixes with the same prefix origin, the data packets received over different incoming interfaces of edge routers should also be transmitted legitimately regarding when the Routing Information Base (RIB) contains the prefix that encompasses the source address the packet was received.¶
It's noted that the complete path validation against IGP path attribute of a route is out of the scope of the document. The validation for route prefix origin is authorized by the fact prefix holder is also out of the scope of the document.¶
The document proposes a means by which IGP can make use of the POI assignment to each IGP route prefix extracted from the received packets in the incoming interfaces of edge routers to achieve proper source address validation. The document only provides considerations on Source Address Validation in intra-domain networks in data plane.¶
The following figure 1 shows an example for IGP POI method used in multi-homing scenario for SAV intra-domain network.¶
+------------+
---| Transit |---
/ | Network | \
DestP| NH / +------------+ \ DestP | NH
-----|---- Int3/ \Int4 ------|----
P2 |Int3 +-----+ +-------+ P1 |Int4
P1 |Int1 | ER1 | | ER2 | P2 |Int2
+-----+ +-------+
Int1\ /Int2
(P1, POI1)\ +------------+ /
\ | Access | /(P2, POI1)
\ | Network | /
--| (POI:1) |---
+------------+
(P1, P2)
The figure 1 shows an example of asymmetrical routes in multi-homing scenarios, and here the multi-homing is dual-homing. The Access Network (tagged with POI 1 for indication of the source prefix originated location or directionality), announces IGP routes for both prefixes (P1, P2) to the edge routers (ER1, ER2). To achieve traffic load-balance the P1 route maybe advertised to ER1 and P2 route advertised to ER2. The FIB table is generated as showed in the figure1. It's obvious that strict uRPF method for source address validation does not work well in the asymmetrical route scenario. The traffic of prefix P2 incoming from the interface Int1 of ER1 will be blocked falsely. The feasible URPF can work but still have some limitations when the propagation of prefixes is not followed.¶
The IGP POI method this document proposes can work well for source address validation on incoming interface of edge or boundary routers in this scenario. In the example showed in figure 1, the routers in Access Network can be considered as SAV Source Entity and identified POI 1, while the edge routers ER1 and ER2 be considered as SAV Validation Entity. The incoming packets of multiple prefixes with the same POI tag are considered from the same source originated location or directionality and be filtered equivalently.¶
The IGP POI method is applied as follows:¶
Only the IGP POI method is not enough for source address validation. The SAV validation rules SHOULD also be combined to apply to the incoming interface of the edge router. That is, based on the mapping policy between the source address prefix and incoming interface received data packet, to achieve accurate validation of source data packets. The SAV rule/function involves 2 characters: source address prefix and incoming interface.¶
The objectives of SAV function include (1) set prefix-to-interface mapping of IGP route prefix from IGP neighbor with the incoming interface as route policy deployed at the edge routers, (2) match the validation mapping policy and (3) decide the validation state for the source address. When the traffic of one specific address prefix received at one interface of the edge routers, the validation policy should be deployed and filtered the source address. And based-on the validation state the source address should be validated correctly.¶
The validation state is considered to include:¶
When the source address received of traffic which prefix derived from the IGP route is not matched with the incoming interface, i.e., the POI information of source address prefix is not matched with the POI policy applied to the incoming interface, the SAV validation state is considered as "Invalid". Only the prefix matched with the incoming interface the validation state is set as "valid". Similarly, if no valid route be found its corresponding address packets should be discarded and its validation state should be set as "NotFound".¶
In the above example showed in section 3.1, the SAV rules applied to the incoming interface of ER1 are showed as the following table 1.¶
| Source Address Prefix | POI | Incoming Interface |
|---|---|---|
| P1 | 1 | Int1, Int3 |
| P2 | 1 | Int1, Int3 |
The SAV rules applied to the incoming interface of ER2 are showed as the following table 2.¶
| Source Address Prefix | POI | Incoming Interface |
|---|---|---|
| P1 | 1 | Int2, Int4 |
| P2 | 1 | Int2, Int4 |
The SAV rules are applied to the incoming interfaces of edge routers over which the data packets of Source Address Prefix with the same POI in this example are received. The ingress packets at edge routers are validated by SAV ruleds and be accepted and transmitted legitimately when the POI information of the source address prefix matched with the POI policy of the incoming interface. With the POI method and SAV rules constructed at the edge routers, the limitation of strict URPF is overcome and the IGP SAV method works.¶
The OSPFv2 POI TLV is a new optional sub-TLV of OSPFv2 (see [RFC7684]) Extended Prefix TLV which is used to advertise prefix information. The POI sub-TLV is carried to identify the prefix originated source information.¶
The format for the OSPFv2 POI sub-TLV is shown as below:¶
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POI ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPFv3 POI TLV is a sub-TLV of OSPFv3 (see [RFC8362]) Intra-Area-Prefix TLV, Inter-Area-Prefix TLV or External-Prefix TLV which are used for advertising OSPFv3 prefix information. The OSPFv3 POI sub-TLV is carried to identify the prefix originated source information.¶
The format for the OSPFv3 Extended Prefix POI sub-TLV is the same as OSPFv2.¶
The ISIS POI TLV is a sub-TLV of the following ISIS TLVs:¶
TLV-135 (Extended IPv4 reachability) (see [RFC5305]).¶
TLV-235 (Multi-topology IPv4 Reachability) (see [RFC5120]).¶
TLV-236 (IPv6 IP Reachability) (see [RFC5308]).¶
TLV-237 (Multi-topology IPv6 IP Reachability) (see [RFC5120]).¶
The TLVs are used for advertising ISIS prefix information. The ISIS POI sub-TLV is carried to identify the prefix originated source information.¶
The format for the ISIS POI sub-TLV is shown as below:¶
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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POI ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The instantiation of SAV POI requires POI-related configurations of the SAV validation entities. The management and optimization of SAV POIs requires monitoring of the status of SAV validation in the underlying intra-domain networks and reporting relevant information to the upper-layer network controller for processing.¶
SAV POI needs to be advertised and processed by the SAV Validation entity, which means that some fields in the data packet should be used to identify POI indicating the directionality or location of the source prefix originated. In order to satisfy scalability requirements of source address validation, POI can be deployed at different granularity, such as Area Prefix Originated Indicator (Area POI), Router level Prefix Originated Indicator (Router POI), and Prefix POI, etc.¶
The Area POI is an optimal approach provided in this document, which introduces an optional sub-TLV of OSPF Extended Prefix TLV and sub-TLV of ISIS Extended Prefix TLV, its extension format refers to section 4. The POI information is carried and advertised to indicate the source prefix originated OSPF or ISIS area.¶
The Router POI is one practical way to reuse some of the existing fields to indicate the directionality or location of the source packets belong to. It's suggested to use router-id as POI to identify source router, the prefix source OSPF router-id is carried at prefix source OSPF router-id Sub-TLV and advertised by the originating node, its format follows [RFC9084]. Similarly, the router-id of ISIS instance is carried at IPV4/IPV6 Source Router ID sub-TLV and advertised by the originated source router, see [RFC7794].¶
The Prefix POI is the most granular source address validation policy. Based on different deployment considerations Service Operators can select different granularity of source address validation.¶
Security considerations for IGP SAV are covered in the SAVNET Intra-domain Architecture (see [I-D.li-savnet-intra-domain-architecture]). The OSPFv2 security considerations are covered in [RFC7684]. The OSPFv3 security considerations are covered in [RFC8362]. The ISIS security considerations are covered in [RFC5305], [RFC5120], [RFC5308]. These security considerations also apply to this document.¶
This document creates 3 new registries:¶
The detailed registry information is TBD.¶
The authors would like to acknowledge Aijun Wang for his valuable comments on this document.¶