| Internet-Draft | IGP Extensions for SPI | March 2024 |
| Li, et al. | Expires 5 September 2024 | [Page] |
This document proposes a new intra-domain SAV solution, called Source Prefix Identification (SPI), and designs IGP extensions for implementing SPI.¶
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 (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.¶
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.¶
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.¶
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.¶
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 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.¶
+-----------------------------------------------------+ | 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 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:¶
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.¶
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.¶
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.¶
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.¶
After receiving SPI information from host-facing and customer-facing routers, AS border routers can identify source prefixes of the AS accordingly.¶
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.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The detailed design is TBD.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The detailed design is TBD.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The detailed design is TBD.¶
This document has no IANA requirements.¶