lsr D. Li Internet-Draft L. Qin Intended status: Standards Track Tsinghua University Expires: 5 September 2024 C. Lin New H3C Technologies 4 March 2024 IGP Extensions for Source Prefix Identification draft-li-lsr-extensions-for-spi-00 Abstract This document proposes a new intra-domain SAV solution, called Source Prefix Identification (SPI), and designs IGP extensions for implementing SPI. 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 5 September 2024. Copyright Notice 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. Li, et al. Expires 5 September 2024 [Page 1] Internet-Draft IGP Extensions for SPI March 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Source Prefix Identification (SPI) . . . . . . . . . . . . . 3 3.1. SPI on host-facing or customer-facing routers . . . . . . 3 3.2. SPI on AS border routers . . . . . . . . . . . . . . . . 5 4. IGP Extension Considerations for SPI . . . . . . . . . . . . 5 4.1. IS-IS Extension Considerations for SPI . . . . . . . . . 5 4.2. OSPF Extension Considerations for SPI . . . . . . . . . . 6 4.3. OSPFv3 Extension Considerations for SPI . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Intra-domain source address validation (SAV) plays an important role in defending against source address spoofing attacks in intra-domain networks. However, existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84 [RFC3704]) have problems of high operational overhead or inaccurate validation (see [I-D.ietf-savnet-intra-domain-problem-statement]). To address these problems, [I-D.li-savnet-intra-domain-architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information. According to the intra-domain SAVNET architecture, this document proposes a new intra-domain SAV solution, called Source Prefix Identification (SPI), and designs IGP extensions for implementing SPI. 1.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. Li, et al. Expires 5 September 2024 [Page 2] Internet-Draft IGP Extensions for SPI March 2024 2. Terminology SAV Rule: The rule in a router that describes the mapping relationship between a source address (prefix) and the valid incoming interface(s). It is used by a router to make SAV decisions and is inferred from the SAV Information Base. Host-facing Router: An intra-domain router of an AS which is connected to a host network (i.e., a layer-2 network). Customer-facing Router: An intra-domain router of an AS which is connected to a customer network running the routing protocol (i.e., a layer-3 network). AS Border Router: An intra-domain router of an AS which is connected to other ASes. 3. Source Prefix Identification (SPI) SPI aims to achieve accurate intra-domain SAV in host-facing routers, customer-facing routers, and AS border routers in an automatic way. In the following, this document describes how SPI works to meet the design goals of intra-domain SAVNET. 3.1. SPI on host-facing or customer-facing routers SPI on a host-facing (or customer-facing) router aims to identify source prefixes belonging to its host (or customer) network. After that, the host-facing (or customer-facing) router can perform accurate SAV filtering by only accepting data packets from its host (or customer) network with source addresses belonging to that network. If the host (or customer) network is single-homed, the host-facing (or customer-facing) router can easily identify source prefixes through its local routes to that network. However, if the host (or customer) network is multi-homed, the router may fail to identify all source prefixes of that network in the scenario of routing asymmetry (see [I-D.ietf-savnet-intra-domain-problem-statement]). To achieve accurate SAV on routers facing multi-homed host (or customer) networks, SPI allows routers facing the same network to identify source prefixes of the network through SPI information. Li, et al. Expires 5 September 2024 [Page 3] Internet-Draft IGP Extensions for SPI March 2024 +-----------------------------------------------------+ | AS | | [10.1.0.0/16]+[tag n] | | +----------+ +---------------------> +----------+ | | | Router A | SPI info | Router B | | | +------+#+-+ <---------------------+ +-+#+------+ | | + [10.0.0.0/16]+[tag n] + | | | | | | | | | | | +--------------------+ | | | | | Host (or Customer) | | | | +----+ Network N +-----+ | | +--------------------+ | | (10.0.0.0/15 ) | +-----------------------------------------------------+ Figure 1: Source prefix identification for a multi-homed host (or customer) network Figure 1 shows the process of identifying source prefixes for a multi-homed host (or customer) network. In this example, due to traffic engineering, Router A only learns the route to sub prefix 10.1.0.0/16 from Network N, while Router B only learns the route to the other sub prefix 10.0.0.0/16 from Network N. A detailed description of SPI procedure is as follows: 1. Each host (or customer) network is assigned a unique tag value and all router interfaces facing the network are configured with the same tag value. For example, if Network N is assigned tag n, Interfaces '#' in Router A and Router B will be configured with tag n as well. 2. Each host-facing (or customer-facing) router provides SPI information to other intra-domain routers. The SPI information contains the prefixes learned through its local routes to its host (or customer) network and the tag value of the network. For example, Router A will send SPI information to other intra-domain routers containinig prefix 10.1.0.0/16 and tag n. 3. When a router receives SPI information with the same tag value as its host (or customer) network, it considers that the prefixes contained in the SPI information also belong to the host (or customer) network. For example, Router B will identify prefix 10.1.0.0/16 as a source prefix of Network N after receiving the SPI information provided by Router A. Li, et al. Expires 5 September 2024 [Page 4] Internet-Draft IGP Extensions for SPI March 2024 4. By integrating prefixes learned through SPI information with prefixes learned through its local routes, the host-facing (or customer-facing) router can identify all source prefixes of its host (or customer) network. For example, Router B will identify that both prefix 10.1.0.0/16 and prefix 10.0.0.0/16 belong to Network N after receiving the SPI information provided by Router A. Similarly, Router A will also identify complete source prefixes of Network N after receiving the SPI information provided by Router B. 3.2. SPI on AS border routers After receiving SPI information from host-facing and customer-facing routers, AS border routers can identify source prefixes of the AS accordingly. 4. IGP Extension Considerations for SPI In the following, this Section introduces IS-IS extensions and OSPF extensions for communicating SPI information among intra-domain routers, respectively. The key idea is to add the tag value into the prefix information when the host-facing (or customer-facing) router distributes or propagates the prefix information of its host (or customer) network. 4.1. IS-IS Extension Considerations for SPI For host-facing routers running IS-IS protocol，they can carry the tag in the Administrative Tag Sub-TLV [RFC5130] when distributing IP prefix information. For customer-facing routers running IS-IS protocol, they should add the tag in the prefix information received from the customer network. In this case, since they cannot use the Administrative Tag Sub-TLV, it may be necessary to define a new Sub-TLV to carry the tag. For example, as shown in Figure 2, a new Sub-TLV (called Link-tag Sub- TLV) in Extended IS Reachability (22) can be defined to carry the tag of a customer network. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: New Link-Tag Sub-TLV of IS-IS Li, et al. Expires 5 September 2024 [Page 5] Internet-Draft IGP Extensions for SPI March 2024 The detailed design is TBD. 4.2. OSPF Extension Considerations for SPI For host-facing routers running OSPF protocol, they have the capability to carry the tag in the Route-Tag when distributing IP prefix reachability information. To this end, a new Route-Tag Sub- TLV under the OSPFv2 Extended Prefix TLV in the Extended Prefix Opaque LSA (see [RFC7684]) can be defined to convey the tag information. The format for the new Route-Tag Sub-TLV definition is as follows: 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 - Route Tag | Sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: New Route-Tag Sub-TLV of OSPF For customer-facing routers running OSPF protocol, as the prefixes in the LSAs sent by the peer devices do not include a tag, it is alternative to extend the carrying of tags in the neighbor information. A new Sub-TLV (called Link-Tag Sub-TLV) can be defined under the OSPFv2 Extended Link TLV in the Extended Link Opaque LSA, as specified in [RFC7684], to convey the tag information. The format for the new Sub-TLV definition is as follows: 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 - Link Tag | Sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: New Link-Tag Sub-TLV of OSPF The detailed design is TBD. Li, et al. Expires 5 September 2024 [Page 6] Internet-Draft IGP Extensions for SPI March 2024 4.3. OSPFv3 Extension Considerations for SPI For host-facing routers running OSPFv3 protocol, they can include the tag in the Route-Tag Sub-TLV [RFC8362] when distributing IP prefix reachability information. The Route-Tag Sub-TLV can serve as a Sub- TLV under the Inter-Area-Prefix TLV, Inter-Area-Router TLV, and External-Prefix TLV, carrying tag information for corresponding types of routes. For customer-facing routers running OSPFv3 protocol, given that the prefixes in the LSAs sent by peer devices do not include a tag, it is alternative to expand the inclusion of tags in neighbor information. A new Sub-TLV (called Link-tag Sub-TLV) under the OSPFv3 Router-Link TLV in the OSPFv3 E-Router-LSA, as specified in [RFC8362], can be defined to convey the tag information. The format for the new Sub- TLV definition is as follows: 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 - Link Tag | Sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: New Link-Tag Sub-TLV of OSPFv3 The detailed design is TBD. 5. Security Considerations TBD 6. IANA Considerations This document has no IANA requirements. 7. References 7.1. Normative References [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, . Li, et al. Expires 5 September 2024 [Page 7] Internet-Draft IGP Extensions for SPI March 2024 [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, DOI 10.17487/RFC5130, February 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, . [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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.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-03, 13 February 2024, . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . Authors' Addresses Li, et al. Expires 5 September 2024 [Page 8] Internet-Draft IGP Extensions for SPI March 2024 Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Lancheng Qin Tsinghua University Beijing China Email: qlc19@mails.tsinghua.edu.cn Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Li, et al. Expires 5 September 2024 [Page 9]