IGP POI for Intra-domain SAV

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 , strict uRPF (see ) 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 ) takes a looser validation mechanism than strict URPF to avoid improper block but may permit improperly spoofed source address. The FP-uRPF (see ) attempts to strike the balance of the strict and loose uRPF but still has some shortcoming. The EFP-uRPF (see ) 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 when, and only when, they appear in all capitals, as shown here.

Refer to 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.

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:

Enable the incoming interface of ER1 and ER2 with POI policy function for filtering or validating the source prefix from the right prefix originated network.
Enable the IGP neighbor routers with POI functionality for the identification of the source prefix originated location or directionality. The POI information of source address prefix can be learned by the edge routers via route propagation.
The edge routers (ER1, ER2) gets the source prefix POI information and gets the prefix (P1, P2) from the same prefix originated network, generates the full source prefix table (P1, P2).

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:

Valid: The address prefix of received traffic matches the incoming interface.
Invalid: The address prefix of received traffic does not match the incoming interface.
NotFound: The address prefix of received traffic is not found.

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 ) 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:

The OSPFv3 POI TLV is a sub-TLV of OSPFv3 (see ) 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 ). TLV-235 (Multi-topology IPv4 Reachability) (see ). TLV-236 (IPv6 IP Reachability) (see ). TLV-237 (Multi-topology IPv6 IP Reachability) (see ). 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:

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 . 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 . 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 ). The OSPFv2 security considerations are covered in . The OSPFv3 security considerations are covered in . The ISIS security considerations are covered in , , . These security considerations also apply to this document.

This document creates 3 new registries:

OSPFv2 Extended Prefix POI Sub-TLVs.
OSPFv3 Extended Prefix POI Sub-TLVs.
ISIS Extended Prefix POI Sub-TLVs.

The detailed registry information is TBD.

The authors would like to acknowledge Aijun Wang for his valuable comments on this document.