]> Zhongguancun Laboratory

Beijing China qinlc@mail.zgclab.edu.cn

Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

ZTE Corporation

Nanjing China song.xueyan2@zte.com.cn

New H3C Technologies

Beijing China linchangwang.04414@h3c.com

China Mobile

Beijing China yueshengnan@chinamobile.com

Routing LSR Internet-Draft 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 ). This document describes a method to implement SPA-based SAVNET by using OSPF and IS-IS.

Introduction SPA-based SAVNET 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 . This document describes a method to implement SPA information communication by using OSPF and IS-IS. The reader is encouraged to be familiar with .

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.

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 when, and only when, they appear in all capitals, as shown here.

Communicating SPA Information via IS-IS and OSPF

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 , 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.

Communicating SPA information via the IGP + IGP LSDB | | | +-----^------+ | | +-----+------+ | | | | | | | | +-------+---------+ | | +--------v--------+ | | | SAVNET Agent | | | | SAVNET Agent | | | | +-------------+ | | | | +-------------+ | | | | | Information | | | | | | Information | | | | | | Provider | | | | | | Receiver | | | | | +-------------+ | | | | +-------------+ | | | +-----------------+ | | +-----------------+ | | | | | +---------------------+ +---------------------+ ]]>

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 .

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.

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 ), 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).

Administrative Tag Sub-TLV of OSPF For routers running OSPF, they can carry the SNI value in the Administrative Tag Sub-TLV within the OSPF Extended Prefix TLV Sub-TLV .

Administrative Tag Sub-TLV of OSPFv3 For routers running OSPFv3, they can include the SNI value in the Administrative Tag Sub-TLV within the OSPFv3 Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV .

Security Considerations The security considerations described in also applies to this document.

IANA Considerations TBD.

References Normative References This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. [STANDARDS-TRACK] OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible. OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support. LabN Consulting, L.L.C. Cisco Systems Futurewei Technologies It is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous System (AS) External and Not-So-Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended Link State Advertisements (LSAs), multiple administrative tags may be advertised for all types of prefixes. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The new intra-domain source address validation (SAV) mechanism requires improving the accuracy (especially avoiding blocking legitimate traffic) and supporting automatic update (see [I-D.ietf-savnet-intra-domain-problem-statement]). To this end, this document proposes an intra-domain SAV mechanism, called source prefix advertisement (SPA) for intra-domain SAVNET (SPA-based SAVNET for short), to advance the technology for intra-domain SAV. SPA-based SAVNET allows routers in an intra-domain network to exchange SPA information. By using SPA information and routing information, intra-domain routers can determine more accurate SAV rules in an automatic manner.