| Internet-Draft | IGP POI for Intra-domain SAV | October 2023 |
| Song & Kou | Expires 21 April 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 21 April 2024.¶
Copyright (c) 2023 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):The tag for IGP 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
| ER1 | | ER2 |
+-----+ +-------+
Int1\ +------------+ /Int2
(P1, POI1)\ | Access | /(P2, POI1)
\ | Network | /
---| (POI:1) |---
+------------+
As an example, in the multi-homing scenario, if 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 both edge routers (ER1, ER2). In this scenario, the strict uRPF method does not work well, while the feasible URPF works with some limitations when the propagation of prefixes is not followed.¶
The IGP POI method is applied and works well for source address validation on incoming interface (facing Prefix Originated Network directionality) of edge or boundary routers. The Prefix Originated Indicator (POI) is used for the identification of the source prefix originated location or directionality.¶
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 rule applied to the incoming interface of ER1 are showed as the following table 1.¶
| Source Address Prefix | POI | Incoming Interface |
|---|---|---|
| P1 | 1 | Int1 |
| P2 | 1 | Int1 |
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 |
| P2 | 1 | Int2 |
The SAV rules are applied to the incoming interfaces (Int1, Int2) of edge routers (ER1, ER2) over which the data packets of Source Address Prefix (P1, P2) 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 sub-TLV of OSPFv2 (see [RFC7684]) Extended Prefix TLV which is used to advertise prefix information. When the route type of OSPFv2 Extended Prefix TLV is Intra-Area (1) or Inter-Area (3) 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 and OSPFv3 Inter-Area 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POI ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
TBD.¶