IGP Extensions for Source Prefix Identification
draft-li-lsr-extensions-for-spi-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dan Li , Lancheng Qin , Changwang Lin | ||
| Last updated | 2024-03-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-lsr-extensions-for-spi-00
lsr D. Li
Internet-Draft L. Qin
Intended status: Standards Track Tsinghua University
Expires: 5 September 2024 C. Lin
New H3C Technologies
4 March 2024
IGP Extensions for Source Prefix Identification
draft-li-lsr-extensions-for-spi-00
Abstract
This document proposes a new intra-domain SAV solution, called Source
Prefix Identification (SPI), and designs IGP extensions for
implementing SPI.
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 5 September 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 (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.
Li, et al. Expires 5 September 2024 [Page 1]
Internet-Draft IGP Extensions for SPI March 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Source Prefix Identification (SPI) . . . . . . . . . . . . . 3
3.1. SPI on host-facing or customer-facing routers . . . . . . 3
3.2. SPI on AS border routers . . . . . . . . . . . . . . . . 5
4. IGP Extension Considerations for SPI . . . . . . . . . . . . 5
4.1. IS-IS Extension Considerations for SPI . . . . . . . . . 5
4.2. OSPF Extension Considerations for SPI . . . . . . . . . . 6
4.3. OSPFv3 Extension Considerations for SPI . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. 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
[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.
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.
Li, et al. Expires 5 September 2024 [Page 2]
Internet-Draft IGP Extensions for SPI March 2024
2. 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.
3. 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.
3.1. 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 [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.
Li, et al. Expires 5 September 2024 [Page 3]
Internet-Draft IGP Extensions for SPI March 2024
+-----------------------------------------------------+
| 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: Source prefix identification for a multi-homed host (or
customer) network
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:
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.
Li, et al. Expires 5 September 2024 [Page 4]
Internet-Draft IGP Extensions for SPI March 2024
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.
3.2. 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.
4. 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.
4.1. 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 [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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: New Link-Tag Sub-TLV of IS-IS
Li, et al. Expires 5 September 2024 [Page 5]
Internet-Draft IGP Extensions for SPI March 2024
The detailed design is TBD.
4.2. 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 [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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: 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 [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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: New Link-Tag Sub-TLV of OSPF
The detailed design is TBD.
Li, et al. Expires 5 September 2024 [Page 6]
Internet-Draft IGP Extensions for SPI March 2024
4.3. OSPFv3 Extension Considerations for SPI
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: New Link-Tag Sub-TLV of OSPFv3
The detailed design is TBD.
5. Security Considerations
TBD
6. IANA Considerations
This document has no IANA requirements.
7. References
7.1. Normative References
[I-D.li-savnet-intra-domain-architecture]
Li, D., Wu, J., Qin, L., Geng, N., Chen, L., Huang, M.,
and F. Gao, "Intra-domain Source Address Validation
(SAVNET) Architecture", Work in Progress, Internet-Draft,
draft-li-savnet-intra-domain-architecture-06, 21 January
2024, <https://datatracker.ietf.org/doc/html/draft-li-
savnet-intra-domain-architecture-06>.
Li, et al. Expires 5 September 2024 [Page 7]
Internet-Draft IGP Extensions for SPI March 2024
[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, February 2008,
<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, November
2015, <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, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative 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,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-problem-statement-03>.
[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, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
Authors' Addresses
Li, et al. Expires 5 September 2024 [Page 8]
Internet-Draft IGP Extensions for SPI March 2024
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Lancheng Qin
Tsinghua University
Beijing
China
Email: qlc19@mails.tsinghua.edu.cn
Changwang Lin
New H3C Technologies
Beijing
China
Email: linchangwang.04414@h3c.com
Li, et al. Expires 5 September 2024 [Page 9]