Internet-Draft IGP-SPA March 2025
Qin, et al. Expires 17 September 2025 [Page]
Workgroup:
LSR
Internet-Draft:
draft-li-lsr-igp-based-intra-domain-savnet-04
Published:
Intended Status:
Informational
Expires:
Authors:
L. Qin
Zhongguancun Laboratory
D. Li
Tsinghua University
X. Song
ZTE Corporation
C. Lin
New H3C Technologies
S. Yue
China Mobile

IGP-based Source Prefix Advertisement for Intra-domain SAVNET

Abstract

SPA-based SAVNET is a new intra-domain source address validation (SAV) mechanism which requires exchanging and communicating SPA information among routers in an intra-domain network (see [I-D.li-savnet-source-prefix-advertisement]). This document describes a method to implement SPA-based SAVNET by using OSPF and IS-IS.

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 17 September 2025.

Table of Contents

1. Introduction

SPA-based SAVNET [I-D.li-savnet-source-prefix-advertisement] is proposed to improve the accuracy and robustness of intra-domain SAV. It can be used on customer-facing routers, host-facing routers, and AS border routers of an AS. Each customer (or host) network is assigned a unique stub network identifier (SNI) value. The customer-facing (or host-facing) router provides its SPA information, which includes the prefix information and the SNI value of the connected customer (or host) network, to other routers in the same AS. By learning SPA information, customer-facing routers, host-facing routers, and AS border routers can generate more accurate SAV rules on router interfaces facing a customer network, a host network, or an external AS.

The detailed procedures of SPA information generation and SAV rule generation have been described in [I-D.li-savnet-source-prefix-advertisement]. This document describes a method to implement SPA information communication by using OSPF and IS-IS. The reader is encouraged to be familiar with [I-D.li-savnet-source-prefix-advertisement].

1.1. Terminology

SAV Rule: The rule that describes the mapping relationship between a source address (prefix) and its valid incoming router interface(s).

Host Network: An intra-domain stub network consists of hosts.

Customer Network: An intra-domain stub network consists of hosts and routers.

Host-facing Router: An intra-domain router facing an intra-domain host network.

Customer-facing Router: An intra-domain router facing an intra-domain customer network.

1.2. 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. Communicating SPA Information via IS-IS and OSPF

2.1. Overview

The key idea is to add the SNI value into the prefix information when the customer-facing (or host-facing) router distributes the prefix information of its customer (or host) network via the IGP. As shown in Figure 1, the SAVNET Agent of a Sender Router provides its SPA information to other SAVNET routers via IGP. After receiving SPA information from other routers, the SAVNET Agent of the Receiver Router generates SAV rules by using SPA information or/and routing information. The Sender Router can be a customer-facing router or a host-facing router. The SPA information includes the prefix information and the SNI value of the connected customer (or host) network. The Receiver Router can be a customer-facing router, a host-facing router, or an AS border router.

   +---------------------+                +---------------------+
   |   Sender Router     |   Prefix and   |   Receiver Router   |
   |   +------------+    |   SNI Value    |    +------------+   |
   |   |  IGP LSDB  +------------------------->+  IGP LSDB  |   |
   |   +-----^------+    |                |    +-----+------+   |
   |         |           |                |          |          |
   | +-------+---------+ |                | +--------v--------+ |
   | |   SAVNET Agent  | |                | |   SAVNET Agent  | |
   | | +-------------+ | |                | | +-------------+ | |
   | | | Information | | |                | | | Information | | |
   | | | Provider    | | |                | | | Receiver    | | |
   | | +-------------+ | |                | | +-------------+ | |
   | +-----------------+ |                | +-----------------+ |
   |                     |                |                     |
   +---------------------+                +---------------------+
Figure 1: Communicating SPA information via the IGP

The overall procedure of SPA information communication is as follows:

  • At the Sender Router: The SAVNET Agent provides the SNI value of the connected customer network or host network to the Link State Database (LSDB) of IGP. The IGP will synchronize the LSDB, which includes prefix information and SNI value, among routers runing the IGP.

  • At the Receiver Router: The SAVNET Agent extracts prefix information and SNI value from the LSDB of IGP and then generates SAV rules as described in [I-D.li-savnet-source-prefix-advertisement].

2.2. Using the existing Administrative Tag Sub-TLV

The existing administrative Tag Sub-TLV of IS-IS and OSPF can be used for SPA information communication. Specifically, when a customer-facing (or host-facing) router distributes IP prefix information of the connected customer (or host) network, it carries the SNI value of that network in the Administrative Tag Sub-TLV.

2.2.1. Administrative Tag Sub-TLV of IS-IS

For routers running IS-IS, they can carry the SNI value in the Administrative Tag Sub-TLV (defined in [RFC5130]), which can be included in: SRv6 Locator TLV (27), IPv4 Algorithm Prefix Reachability TLV (126), IPv6 Algorithm Prefix Reachability (127), Extended IP Reachability TLV (135), Multi-Topology Reachable IPv4 Prefixes TLV (235), IPv6 Reachability TLV (236), Multi-Topology Reachable IPv6 Prefixes TLV (237).

2.2.2. Administrative Tag Sub-TLV of OSPF

For routers running OSPF, they can carry the SNI value in the Administrative Tag Sub-TLV [I-D.ietf-lsr-ospf-admin-tags] within the OSPF Extended Prefix TLV Sub-TLV [RFC7684].

2.2.3. Administrative Tag Sub-TLV of OSPFv3

For routers running OSPFv3, they can include the SNI value in the Administrative Tag Sub-TLV [I-D.ietf-lsr-ospf-admin-tags] within the OSPFv3 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV [RFC8362].

3. Security Considerations

The security considerations described in [I-D.li-savnet-source-prefix-advertisement] also applies to this document.

4. IANA Considerations

TBD.

5. References

5.1. Normative References

[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, , <https://www.rfc-editor.org/info/rfc5130>.
[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, , <https://www.rfc-editor.org/info/rfc7684>.
[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, , <https://www.rfc-editor.org/info/rfc8362>.
[I-D.ietf-lsr-ospf-admin-tags]
Lindem, A., Psenak, P., and Y. Qu, "Extensions to OSPF for Advertising Prefix Administrative Tags", Work in Progress, Internet-Draft, draft-ietf-lsr-ospf-admin-tags-29, , <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-admin-tags-29>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

5.2. Informative References

[I-D.li-savnet-source-prefix-advertisement]
Li, D., Geng, N., and L. Qin, "Source Prefix Advertisement for Intra-domain SAVNET", Work in Progress, Internet-Draft, draft-li-savnet-source-prefix-advertisement-02, , <https://datatracker.ietf.org/api/v1/doc/document/draft-li-savnet-source-prefix-advertisement/>.

Authors' Addresses

Lancheng Qin
Zhongguancun Laboratory
Beijing
China
Dan Li
Tsinghua University
Beijing
China
Xueyan Song
ZTE Corporation
Nanjing
China
Changwang Lin
New H3C Technologies
Beijing
China
Shengnan Yue
China Mobile
Beijing
China