Network Working Group W. Cheng Internet Draft China Mobile Intended status: Standards Track C. Lin Expires: December 30, 2024 New H3C Technologies S. Yue China Mobile July 3, 2024 Signaling SAVNET Capability Using IGP draft-cheng-lsr-adv-savnet-capbility-00 Abstract 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 and guide the design of new intra-domain SAV solutions,[I-D.ietf-savnet-intra-domain-architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information in intra-domain networks. This document defines a mechanism to signal the SAVNET capablity and the source prefix using IGP and BGP-LS. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Cheng, et al. Expire December 30, 2024 [Page 1] Internet-Draft Signaling SAVNET Capability Using IGP July 2024 This Internet-Draft will expire on December 30, 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Requirements Language.....................................3 2. Signaling SAVNET Capability Using IS-IS........................3 2.1. SAVNET Capabilities Sub-TLV...............................3 2.2. Source Prefix Flag........................................4 3. Signaling SAVNET Capability Using OSPF.........................5 3.1. SAVNET Capabilities Sub-TLV...............................5 3.2. Source Prefix Flag........................................6 4. Signaling SAVNET Capability Using OSPFv3.......................6 4.1. SAVNET Capabilities Sub-TLV...............................6 4.2. Source Prefix Flag........................................8 5. Signaling SAVNET Capability in BGP-LS..........................8 6. Security Considerations........................................8 7. IANA Considerations............................................8 8. References.....................................................9 8.1. Normative References......................................9 8.2. Informational References.................................10 Authors' Addresses...............................................10 Cheng, et al. Expires December 30, 2024 [Page 2] Internet-Draft Signaling SAVNET Capability Using IGP July 2024 1. Introduction 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]). ACL-based ingress filtering requires manual operations to configure and update the SAV rules, while uRPF-based solutions may improperly block legitimate data packets in the scenario of routing asymmetry. To address these problems and guide the design of new intra-domain SAV solutions,[I-D.ietf-savnet-intra-domain-architecture] proposes the architecture of intra-domain SAVNET and introduces the use of SAV-specific information in intra-domain networks. Following the intra-domain SAVNET architecture, this document defines a mechanism to signal the SAVNET capability and the source prefix using IGP and BGP-LS. This document focuses on announcing the SAVNET capability of the router. When the SAVNET capability is enabled, a flag can be used to indicate whether the prefix being announced is a SAVNET source prefix. Announcing the SAVNET capability and source prefix facilitates the operations and management of SAVNET and the implementation of specific schemes. The specific processing of SAVNET entries is not within the scope of this document. 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. 2. Signaling SAVNET Capability Using IS-IS 2.1. SAVNET Capabilities Sub-TLV A node indicates that it supports the SAVNET functionality as specified in [I-D.ietf-savnet-intra-domain-architecture] by advertising a new SAVNET Capabilities sub-TLV of the Router Capability TLV [RFC7981]. The SAVNET Capabilities sub-TLV may contain optional sub-sub-TLVs. No sub-sub-TLVs are currently defined. The SAVNET Capabilities sub-TLV has the following format: Cheng, et al. Expires December 30, 2024 [Page 3] Internet-Draft Signaling SAVNET Capability Using IGP July 2024 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 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | optional sub-sub-TLVs... where: o Type: TBD. Single octet, as defined in Section 9 of [ISO10589]. o Length: Single octet, as defined in Section 9 of [ISO10589]. The length value is 2 + length of sub-sub-TLVs. o Flags: 2 octets. The following flags are defined: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: S-flag: If set, the router supports SAVNET functionality. The remaining bits, including bit 0, are reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt. 2.2. Source Prefix Flag IPv4 SAVNET source prefixes are advertised using "IP Extended Reach TLV" (type 135), while IPv6 SAVNET source prefixes are advertised using "IPv6 Reachability TLV" (type 236, RFC5308). A new bit in the IPv4/IPv6 Extended Reachability Attribute Flags [RFC7794] is defined: S-Flag: Source Prefix Flag (Bit TBD) When set, it indicates that the prefix is used for source address validation in the data plane. Cheng, et al. Expires December 30, 2024 [Page 4] Internet-Draft Signaling SAVNET Capability Using IGP July 2024 3. Signaling SAVNET Capability Using OSPF 3.1. SAVNET Capabilities Sub-TLV The SAVNET Capabilities TLV is used by an OSPF router to advertise its support for the SAVNET functionality. This is an optional top- level TLV of the OSPF Router Information LSA [RFC7770] that MUST be advertised by an SAVNET-enabled router. The RI LSA can be advertised at any of the defined opaque flooding scopes (link, area, or Autonomous System (AS)). For the purpose of SAVNET Capabilities TLV advertisement, area-scoped flooding is REQUIRED. Link and AS-scoped flooding is OPTIONAL. The format of the OSPF SAVNET Capabilities TLV is shown 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type: 2-octet field. The value for this type is 20. o Length: 2-octet field. The total length (in octets) of the value portion of the TLV, including nested sub-TLVs. o Reserved: 2-octet field.It MUST be set to 0 on transmission and MUST be ignored on receipt. o Flags: 2-octet field. The flags are defined as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cheng, et al. Expires December 30, 2024 [Page 5] Internet-Draft Signaling SAVNET Capability Using IGP July 2024 where: S-flag: If set, the router supports SAVNET functionality. The remaining bits, including bit 0, are reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt. The SAVNET Capabilities TLV may contain optional sub-TLVs. No sub- TLVs are defined in this specification. 3.2. Source Prefix Flag SAVNET source prefixes are advertised using "OSPFv2 Extended Prefix Opaque LSA"[RFC7684]. A new bit in Flags field of the OSPFv2 Extended Prefix TLV [RFC7684] is defined: S-Flag: Source Prefix Flag (Bit TBD) When set, it indicates that the prefix is used for source address validation in the data plane. 4. Signaling SAVNET Capability Using OSPFv3 4.1. SAVNET Capabilities Sub-TLV The SAVNET Capabilities TLV is used by an OSPFv3 router to advertise its support for the SAVNET functionality. This is an optional top- level TLV of the OSPFv3 Router Information LSA [RFC7770] that MUST be advertised by an SAVNET-enabled router. This TLV MUST be advertised only once in the OSPFv3 Router Information LSA. When multiple SAVNET Capabilities TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the OSPFv3 Router Information LSA. If the SAVNET Capabilities TLV appears in multiple OSPFv3 Router Information LSAs that have different flooding scopes, the TLV in the OSPFv3 Router Information LSA with the area-scoped flooding scope MUST be used. If the SAVNET Capabilities TLV appears in multiple OSPFv3 Router Information LSAs that have the same flooding scope, the TLV in the OSPFv3 Router Information LSA with the numerically smallest Link State ID MUST be used, and subsequent instances of the TLV MUST be ignored. Cheng, et al. Expires December 30, 2024 [Page 6] Internet-Draft Signaling SAVNET Capability Using IGP July 2024 The OSPFv3 Router Information LSA can be advertised at any of the defined flooding scopes (link, area, or Autonomous System (AS)). For the purpose of SAVNET Capabilities TLV advertisement, area- scoped flooding is REQUIRED. Link and AS-scoped flooding is OPTIONAL. The format of the OSPFv3 SAVNET Capabilities TLV is shown 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type: 2-octet field. The value for this type is 20. o Length: 2-octet field. The total length (in octets) of the value portion of the TLV, including nested sub-TLVs. o Reserved: 2-octet field.It MUST be set to 0 on transmission and MUST be ignored on receipt. o Flags: 2-octet field. The flags are defined as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: S-flag: If set, the router supports SAVNET functionality. The remaining bits, including bit 0, are reserved for future use. They MUST be set to zero on transmission and MUST be ignored on receipt. Cheng, et al. Expires December 30, 2024 [Page 7] Internet-Draft Signaling SAVNET Capability Using IGP July 2024 The SAVNET Capabilities TLV may contain optional sub-TLVs. No sub- TLVs are defined in this specification. 4.2. Source Prefix Flag SAVNET source prefixes are advertised using "OSPFv3 Extended LSA", including "E-Intra-Area-Prefix-LSA", "E-Inter-Area-Prefix-LSA" and "E-AS-External-LSA".[RFC8362]. A new bit in the prefix Attribute Flags [I-D. draft-ietf-lsr-ospf- prefix-extended-flags-00] are defined: S-Flag: Source Prefix Flag (Bit TBD) When set, it indicates that the prefix is used for source address validation in the data plane. 5. Signaling SAVNET Capability in BGP-LS The IGP extensions defined in this document can be advertised via BGP-LS (distribution of Link-State and Traffic Engineering information using BGP) [RFC7752] using existing BGP-LS TLVs. This section defines the following Node Attribute TLV: +============+==============================+ | Type | Description | +============+==============================+ | TBD | the SAVNET-Capabilities TLV | +------------+------------------------------+ 6. Security Considerations TBD. 7. IANA Considerations TBD Cheng, et al. Expires December 30, 2024 [Page 8] Internet-Draft Signaling SAVNET Capability Using IGP July 2024 8. References 8.1. Normative 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, . [I-D.ietf-savnet-intra-domain-architecture]Li, D., Wu, J., Qin, L., Geng, N., and L. Chen, "Intra-domain Source Address Validation (SAVNET) Architecture",Work in Progress, Internet-Draft, draft-ietf-savnet-intra-domain- architecture-00, 12 April 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, 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, . Cheng, et al. Expires December 30, 2024 [Page 9] Internet-Draft Signaling SAVNET Capability Using IGP July 2024 8.2. Informational References [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 Weiqiang Cheng China Mobile China Email: chengweiqiang@chinamobile.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Shengnan Yue China Mobile China yueshengnan@chinamobile.com Cheng, et al. Expires December 30, 2024 [Page 10]