SAVNET Group X. Song Internet-Draft Z. Kou Intended status: Standards Track ZTE Corporation Expires: 21 April 2024 19 October 2023 IGP POI for Intra-domain SAV draft-song-savnet-intra-domain-igp-poi-00 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 21 April 2024. Copyright Notice 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. Song & Kou Expires 21 April 2024 [Page 1] Internet-Draft IGP POI for Intra-domain SAV October 2023 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. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 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 Song & Kou Expires 21 April 2024 [Page 2] Internet-Draft IGP POI for Intra-domain SAV October 2023 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):The tag for IGP 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. 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. Song & Kou Expires 21 April 2024 [Page 3] Internet-Draft IGP POI for Intra-domain SAV October 2023 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) |--- +------------+ Figure 1: IGP POI Method for Multi-homing Scenario 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. Song & Kou Expires 21 April 2024 [Page 4] Internet-Draft IGP POI for Intra-domain SAV October 2023 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 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. Song & Kou Expires 21 April 2024 [Page 5] Internet-Draft IGP POI for Intra-domain SAV October 2023 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 | +-----------------------+-----+--------------------+ 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 | +-----------------------+-----+--------------------+ | P2 | 1 | Int2 | +-----------------------+-----+--------------------+ Table 2: Prefix-to-Interface Mapping Table at ER2 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. Song & Kou Expires 21 April 2024 [Page 6] Internet-Draft IGP POI for Intra-domain SAV October 2023 4. IGP Extension with POI 4.1. OSPFv2 Extended Prefix POI sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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. 4.3. ISIS Extended Prefix POI sub-TLV 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]). Song & Kou Expires 21 April 2024 [Page 7] Internet-Draft IGP POI for Intra-domain SAV October 2023 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ISIS Extended Prefix POI sub-TLV Format 5. 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. 6. 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. 7. Acknowledgements TBD. 8. References 8.1. Normative References Song & Kou Expires 21 April 2024 [Page 8] Internet-Draft IGP POI for Intra-domain SAV October 2023 [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, . [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, . 8.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, 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., Huang, M., Chen, L., Geng, N., Qin, L., and F. Gao, "Intra-domain Source Address Validation (SAVNET) Architecture", Work in Progress, Internet-Draft, Song & Kou Expires 21 April 2024 [Page 9] Internet-Draft IGP POI for Intra-domain SAV October 2023 draft-li-savnet-intra-domain-architecture-03, 25 July 2023, . [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 Song & Kou Expires 21 April 2024 [Page 10]