]> Tsinghua University

Beijing China tolidan@tsinghua.edu.cn

Tsinghua University

Beijing China qlc19@mails.tsinghua.edu.cn

New H3C Technologies

Beijing China linchangwang.04414@h3c.com

Routing lsr SAV This document proposes a new intra-domain SAV solution, called Source Prefix Identification (SPI), and designs IGP extensions for implementing SPI.

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 and BCP84 ) have problems of high operational overhead or inaccurate validation (see ). To address these problems, 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.

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.

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.

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.

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

Source prefix identification for a multi-homed host (or customer) network +----------+ | | | Router A | SPI info | Router B | | | +------+#+-+ <---------------------+ +-+#+------+ | | + [10.0.0.0/16]+[tag n] + | | | | | | | | | | | +--------------------+ | | | | | Host (or Customer) | | | | +----+ Network N +-----+ | | +--------------------+ | | (10.0.0.0/15 ) | +-----------------------------------------------------+ ]]>

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

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.

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.

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

New Link-Tag Sub-TLV of IS-IS

The detailed design is TBD.

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 ) can be defined to convey the tag information. The format for the new Route-Tag Sub-TLV definition is as follows:

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 , to convey the tag information. The format for the new Sub-TLV definition is as follows:

New Link-Tag Sub-TLV of OSPF

The detailed design is TBD.

OSPFv3 Extension Considerations for SPI For host-facing routers running OSPFv3 protocol, they can include the tag in the Route-Tag Sub-TLV 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 , can be defined to convey the tag information. The format for the new Sub-TLV definition is as follows:

New Link-Tag Sub-TLV of OSPFv3

The detailed design is TBD.

Security Considerations TBD

IANA Considerations This document has no IANA requirements.

References Normative References Tsinghua University Tsinghua University Tsinghua University Huawei Zhongguancun Laboratory Huawei Zhongguancun Laboratory This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms that only depend on routers' local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL rules that require manual efforts to accommodate to network dynamics, SAVNET routers learn the SAV rules automatically in a distributed way. 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. 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 Tsinghua University Tsinghua University Tsinghua University Huawei Huawei This document provides the gap analysis of existing intra-domain source address validation mechanisms, describes the fundamental problems, and defines the requirements for technical improvements. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.