SAVNET Group X. Song Internet-Draft Z. Kou Intended status: Standards Track ZTE Corporation Expires: 27 July 2024 Y. Fu China Unicom C. Lin New H3C Technologies 24 January 2024 IGP POI for Intra-domain SAV draft-song-savnet-intra-domain-igp-poi-01 Abstract 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. Status of This Memo 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 Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Song, et al. Expires 27 July 2024 [Page 1] Internet-Draft IGP POI for Intra-domain SAV January 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. IGP POI for Intra-domain SAV . . . . . . . . . . . . . . . . 3 3.1. IGP POI Method . . . . . . . . . . . . . . . . . . . . . 3 3.2. SAV Function . . . . . . . . . . . . . . . . . . . . . . 5 4. IGP Extension with POI . . . . . . . . . . . . . . . . . . . 7 4.1. OSPFv2 Extended Prefix POI sub-TLV . . . . . . . . . . . 7 4.2. OSPFv3 Extended Prefix POI sub-TLV . . . . . . . . . . . 7 4.3. ISIS Extended Prefix POI sub-TLV . . . . . . . . . . . . 7 5. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 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 Song, et al. Expires 27 July 2024 [Page 2] Internet-Draft IGP POI for Intra-domain SAV January 2024 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. 2. Conventions 2.1. Requirements Language 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. 2.2. Terminology 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. 3. IGP POI for Intra-domain SAV 3.1. IGP POI Method 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. Song, et al. Expires 27 July 2024 [Page 3] Internet-Draft IGP POI for Intra-domain SAV January 2024 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) Figure 1: IGP POI Method for multi-homing Scenario 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 Song, et al. Expires 27 July 2024 [Page 4] Internet-Draft IGP POI for Intra-domain SAV January 2024 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: 1. 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. 2. 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. 3. 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). 3.2. SAV Function 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 Song, et al. Expires 27 July 2024 [Page 5] Internet-Draft IGP POI for Intra-domain SAV January 2024 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 | +-----------------------+-----+--------------------+ Table 1: Prefix-to-Interface Mapping Table at ER1 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 | +-----------------------+-----+--------------------+ Table 2: Prefix-to-Interface Mapping Table at ER2 Song, et al. Expires 27 July 2024 [Page 6] Internet-Draft IGP POI for Intra-domain SAV January 2024 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. 4. IGP Extension with POI 4.1. OSPFv2 Extended Prefix POI sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: OSPFv2 Extended Prefix POI sub-TLV Format 4.2. OSPFv3 Extended Prefix POI sub-TLV 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. 4.3. ISIS Extended Prefix POI sub-TLV The ISIS POI TLV is a sub-TLV of the following ISIS TLVs: Song, et al. Expires 27 July 2024 [Page 7] Internet-Draft IGP POI for Intra-domain SAV January 2024 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ISIS Extended Prefix POI sub-TLV Format 5. Scalability 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. Song, et al. Expires 27 July 2024 [Page 8] Internet-Draft IGP POI for Intra-domain SAV January 2024 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. 6. Security Considerations 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. 7. IANA Considerations This document creates 3 new registries: 1. OSPFv2 Extended Prefix POI Sub-TLVs. 2. OSPFv3 Extended Prefix POI Sub-TLVs. 3. ISIS Extended Prefix POI Sub-TLVs. The detailed registry information is TBD. 8. Acknowledgements The authors would like to acknowledge Aijun Wang for his valuable comments on this document. 9. References 9.1. Normative References Song, et al. Expires 27 July 2024 [Page 9] Internet-Draft IGP POI for Intra-domain SAV January 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC9084] Wang, A., Lindem, A., Dong, J., Psenak, P., and K. Talaulikar, Ed., "OSPF Prefix Originator Extensions", RFC 9084, DOI 10.17487/RFC9084, August 2021, . 9.2. Informative References [I-D.ietf-savnet-intra-domain-problem-statement] Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source Address Validation in Intra-domain Networks Gap Analysis, Song, et al. Expires 27 July 2024 [Page 10] Internet-Draft IGP POI for Intra-domain SAV January 2024 Problem Statement, and Requirements", Work in Progress, Internet-Draft, draft-ietf-savnet-intra-domain-problem- statement-02, 17 August 2023, . [I-D.li-savnet-intra-domain-architecture] Li, D., Wu, J., Qin, L., Geng, N., Chen, L., Huang, M., and F. Gao, "Intra-domain Source Address Validation (SAVNET) Architecture", Work in Progress, Internet-Draft, draft-li-savnet-intra-domain-architecture-06, 21 January 2024, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, . Authors' Addresses Xueyan Song ZTE Corporation China Email: song.xueyan2@zte.com.cn Zenggui Kou ZTE Corporation China Email: kou.zenggui@zte.com.cn Yu Fu China Unicom China Email: fuy186@chinaunicom.cn Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Song, et al. Expires 27 July 2024 [Page 11]