IGP-based Source Address Validation in Intra-domain Networks (Intra-domain SAVNET)
draft-li-lsr-igp-based-intra-domain-savnet-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dan Li , Lancheng Qin , Xueyan Song , Changwang Lin , Shengnan Yue | ||
| Last updated | 2024-10-20 | ||
| Replaces | draft-li-lsr-extensions-for-spi | ||
| 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-igp-based-intra-domain-savnet-03
LSR D. Li
Internet-Draft Tsinghua University
Intended status: Standards Track L. Qin
Expires: 28 April 2025 Zhongguancun Laboratory
X. Song
ZTE Corporation
C. Lin
New H3C Technologies
S. Yue
China Mobile
20 October 2024
IGP-based Source Address Validation in Intra-domain Networks
(Intra-domain SAVNET)
draft-li-lsr-igp-based-intra-domain-savnet-03
Abstract
This document proposes a new IGP-based intra-domain source address
validation (SAV) solution, called IGP-SAVNET, which improves the
accuracy upon current intra-domain SAV solutions. It allows intra-
domain routers to communicate SAV-specific information using the
intra-domain routing protocol or an extension to the intra-domain
routing protocol. By using SAV-specific information, intra-domain
routers can generate and update accurate SAV rules in an automatic
way.
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 April 20, 2025.
Li, et al. Expires April 28, 2025 [Page 1]
Internet-Draft IGP-SAVNET October 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.
Table of Contents
1. Introduction...................................................2
1.1. Requirements Language.....................................3
2. Terminology....................................................3
3. Goals of Intra-domain SAV......................................4
4. Description of the Method......................................5
4.1. SAV procedure on customer-facing or host-facing routers...5
4.2. SAV procedure on AS border routers........................7
5. SAV-specific Information Communication Using IGP...............8
5.1. Approach #1: Using the existing Administrative Tag Sub-TLV9
5.1.1. Administrative Tag Sub-TLV of IS-IS..................9
5.1.2. Administrative Tag Sub-TLV of OSPF..................10
5.1.3. Administrative Tag Sub-TLV of OSPFv3................10
5.1.4. Considerations of using Administrative Tag Sub-TLV..10
5.2. Approach #2: Defining a new SAVNET Tag Sub-TLV...........10
5.2.1. SAVNET Tag Sub-TLV of IS-IS.........................10
5.2.2. SAVNET Tag Sub-TLV of OSPF and OSPFv3...............11
6. Security Considerations.......................................11
7. IANA Considerations...........................................12
8. References....................................................12
8.1. Normative References.....................................12
8.2. Informative References...................................13
Authors' Addresses...............................................14
1. Introduction
The purpose of intra-domain SAV is to prevent outgoing data packets
from an intra-domain subnet (e.g., a host network or a customer
network) from forging source addresses of other intra-domain subnets
or other ASes, and to prevent incoming data packets from external
ASes from forging source addresses of the local AS. To this end,
Li, et al. Expires April 28, 2025 [Page 2]
Internet-Draft IGP-SAVNET October 2024
intra-domain SAV should focus on SAV on host-facing routers,
customer-facing routers, and AS border routers (see [I-D.ietf-
savnet-intra-domain-architecture]). Specifically, host-facing
routers or customer-facing routers should block data packets from
the connected host network or customer network with a spoofed source
IP address not belonging to that network. AS border routers should
block data packets from other ASes with a spoofed source IP address
belonging to the local AS.
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]). ACL-based ingress filtering requires manual operations
to configure and update the SAV rules, while uRPF-based solutions
may improperly block legitimate data packets in the scenario of
routing asymmetry. To address these problems and guide the design
of new intra-domain SAV solutions, [I-D.ietf-savnet-intra-domain-
architecture] proposes the architecture of intra-domain SAVNET and
introduces the use of SAV-specific information in intra-domain
networks.
Following the intra-domain SAVNET architecture, this document
proposes a new IGP-based intra-domain SAV solution, called IGP-
SAVNET, which improves the accuracy upon current intra-domain SAV
solutions. It allows host-facing routers, customer-facing routers,
and AS border routers to communicate SAV-specific information using
the intra-domain routing protocol or an extension to the intra-
domain routing protocol. By using SAV-specific information, these
routers can generate and update accurate SAV rules in an automatic
way.
The reader is encouraged to be familiar with [I-D.ietf-savnet-intra-
domain-problem-statement] and [I-D.ietf-savnet-intra-domain-
architecture].
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.
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.
Li, et al. Expires April 28, 2025 [Page 3]
Internet-Draft IGP-SAVNET October 2024
Host-facing Router: An intra-domain router of an AS which is
connected to an intra-domain host network (i.e., a layer-2 network).
Customer-facing Router: An intra-domain router of an AS which is
connected to an intra-domain 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. Goals of Intra-domain SAV
Goal 1: The host-facing router or customer-facing router should
identify source prefixes belonging to its host network or customer
etwork and block data packets from its host network or customer
network using source addresses not belonging to the network.For
example, in Figure 1, Routers A and B should generate SAV rules at
the interface '#' and block data packets from Network 1 using source
ddresses not belonging to Network 1. Router C should generate SAV
rules at interfaces '#' and block data packets from Network 2 using
source addresses not belonging to Network 2.
Goal 2: The AS border router should identify source prefixes
belonging to the local AS and block data packets from other ASes
using source addresses belonging to the local AS. For example, in
Figure 1, Routers D and E should generate SAV rules at interface '#'
and block data packets from other ASes using source addresses
belonging to the local AS.
Li, et al. Expires April 28, 2025 [Page 4]
Internet-Draft IGP-SAVNET October 2024
+----------------------------------+
| Other ASes |
+----------------------------------+
| |
+---------------|----------------------------|--------------+
| Intra-domain | | |
| | | |
| +-----#----+ +-----#----+ |
| | Router D | | Router E | |
| +----------+ +----------+ |
| | | |
| | | |
| +----------------------------------------+ |
| | Other intra-domain routers | |
| +----------------------------------------+ |
| / \ | |
| / \ | |
| +----------+ +----------+ +----------+ |
| | Router A | | Router B | | Router C | |
| +----#-----+ +-------#--+ +-----#----+ |
| \ / | |
+--------+\------------/---------------------|--------------+
\ / |
+------------------+ +------------------+
| Customer or Host | | Customer or Host |
| Network 1 | | Network 2 |
+------------------+ +------------------+
Figure 1: Goals of Intra-domain SAV
4. Description of the Method
To achieve the above two goals, IGP-SAVNET allows host-facing
routers, customer-facing routers, and AS border routers to
communicate SAV-specific information between each other through IGP.
These routers will not communicate SAV-specific information with
routers/devices in host networks, customer networks, and other ASes.
In the following, this document describes how IGP-SAVNET works to
meet the goals.
4.1. SAV procedure on customer-facing or host-facing routers
SAV on a customer-facing (or host-facing) router aims to identify
source prefixes belonging to the customer (or host) network. After
that, the customer-facing (or host-facing) router can perform
accurate SAV filtering by only accepting data packets from its
customer (or host) network with source addresses belonging to that
network. If the customer (or host) network is single-homed, the
Li, et al. Expires April 28, 2025 [Page 5]
Internet-Draft IGP-SAVNET October 2024
customer-facing (or host-facing) router can directly identify source
prefixes through its local routes to that network. If the customer
(or host) network is multi-homed, the customer-facing (or host-
facing) router may fail to identify all source prefixes of that
network through its local routes to that network in the scenario of
routing asymmetry (see[I-D.ietf-savnet-intra-domain-problem-
statement]). For example, in Figure 2, 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. In this case, as described in
[I-D.ietf-savnet-intra-domain-problem-statement], strict uRPF on
Router A will block data packets from the customer (or host) network
with legitimate source addresses in prefix 10.0.0.0/16, and strict
uRPF on Router B will block data packets from the customer (or host)
network with legitimate source addresses in prefix 10.1.0.0/16. To
achieve accurate SAV on routers facing the multi-homed customer (or
host) network, IGP-SAVNET allows routers facing the same customer
(or host) network to identify source prefixes of the network through
SAV-specific information communication.
+-----------------------------------------------------+
| AS |
| [10.1.0.0/16]+[tag n] |
| +----------+ +---------------------> +----------+ |
| | Router A | SAV-specific info | Router B | |
| +-------#--+ <---------------------+ +--#-------+ |
| | [10.0.0.0/16]+[tag n] | |
| | | |
| | | |
| | +--------------------+ | |
| | | Customer or Host | | |
| +----| Network N |-----+ |
| +--------------------+ |
| (10.0.0.0/15 ) |
+-----------------------------------------------------+
Figure 2: SAV-specific information communication between Routers
A and B
A detailed description of SAV procedure is as follows:
1. Tag Assignment: Each single-homed or multi-homed customer (or
host) network is assigned a unique tag value. For example, in
Figure 2, Network N is assigned tag n. The tag value for can be
configured and updated manually. Specifically, the tag n is
configured on the interface of the customer-facing router
corresponding to this customer network, that is, tag n is
Li, et al. Expires April 28, 2025 [Page 6]
Internet-Draft IGP-SAVNET October 2024
configured on interface # of Router A and also on interface # of
Router B.
2. SAV-specific Information Communication: Each customer-facing (or
host-facing) router provides its SAV-specific information of its
customer (or host) networks to other intra-domain routers. The
SAV-specific information of a customer (or host) network contains
the prefixes learned through the router's local routes to the
network and the tag value of the network. For example, Router A
can provide its SAV-specific information, which contains prefix
10.1.0.0/16 and tag n, to other intra-domain routers. This
procedure can be implemented by using IGP or extensions to
IGP,which will be elaborated in Section 5.
3. SAV-specific Information Processing: When a router receives
SAV-specific information containing the same tag value as the one
configured on its local customer-facing interface, it considers
that the prefixes contained in the SAV-specific information also
belong to its customer (or host) network corresponding to the
customer-facing interface. For example, Router B, after receiving
the SAV-specific information provided by Router A, finds that the
tag n is the same as the tag n configured on its local interface
#, and therefore will identify prefix 10.1.0.0/16 as a source
prefix of Network N.
4. Source Prefix Identification: By integrating prefixes learned
through SAV-specific information provided by other routers with
prefixes learned through its local routes, the customer-facing(or
host-facing) router can identify complete source prefixes of its
customer (or host) 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 processing SAV-specific information provided by
Router A. Similarly, Router A will also identify complete source
prefixes of Network N after processing SAV-specific information
provided by Router B.
5. SAV Rule Generation: Each customer-facing (or host-facing)router
generates an allowlist containing source prefixes of its customer
(or host) network at the interface facing that network. Only data
packets using source addresses covered in the allowlist will be
accepted at this interface.
4.2. SAV procedure on AS border routers
SAV on an AS border router aims to identify source prefixes
belonging to the local AS. After receiving SAV-specific information
or routing information originating from host-facing and customer-
facing routers through IGP, AS border routers can identify source
prefixes of the local AS accordingly and generate a blocklist
containing these source prefixes. After that, data packets arriving
Li, et al. Expires April 28, 2025 [Page 7]
Internet-Draft IGP-SAVNET October 2024
from other ASes with source addresses belonging to the local AS will
be blocked on the AS border router.
Blocklists can be generated on specific interfaces, typically those
connected to external ASes. These interfaces can be manually
configured to generate the blocklist.
The source prefixes that need to be included in the blocklist can be
filtered through specific routing policies or flagged to control
their inclusion. This approach helps manage the source prefixes that
contribute to the blocklist, preventing the creation of an excessive
number of blocklist entries.
5. SAV-specific Information Communication Using IGP
The key idea is to add the tag value into the prefix information
when the customer-facing (or host-facing) router distributes the
prefix information of its customer (or host) network. As shown in
Figure 3,the SAVNET Agent of a Sender Router provides its SAV-
specific information to other SAVNET routers via IGP. After
receiving SAV-specific information from other SAVNET routers, the
SAVNET Agent of the Receiver Router generates SAV rules by using
SAV-specific information from other SAVNET routers and/or its own
SAV-specific information. The Sender Router can be a customer-
facing router or a host-facing router. The Receiver Router can be a
customer-facing router, a host-facing router, or an AS border
router.
+---------------------+ +---------------------+
| Sender Router | SAV-specific | Receiver Router |
| +------------+ | Information | +------------+ |
| | IGP LSDB +------------------------->+ IGP LSDB | |
| +-----^------+ | | +-----+------+ |
| | | | | |
| +-------+---------+ | | +--------v--------+ |
| | SAVNET Agent | | | | SAVNET Agent | |
| | +-------------+ | | | | +-------------+ | |
| | | Information | | | | | | Information | | |
| | | Provider | | | | | | Receiver | | |
| | +-------------+ | | | | +-------------+ | |
| +-----------------+ | | +-----------------+ |
| | | |
+---------------------+ +---------------------+
Figure 3: Overview of SAV-specific information communication
Li, et al. Expires April 28, 2025 [Page 8]
Internet-Draft IGP-SAVNET October 2024
The overall procedure of SAV-specific information communication is
as follows:
* At the Sender Router: Carry its SAV-specific information (e.g.,
the tag information of the customer or host network) through the
Link State Database (LSDB) of IGP. The IGP will synchronize the
LSDB, including node information, link information, prefix
information, and tag information.
* At the Receiver Router: After receiving SAV-specific information
carried in the LSDB, its SAVNET Agent extracts SAV-specific
information from the LSDB of IGP and then generates SAV rules as
described in Section 4.
In the following, this document presents two approaches to implement
SAV-specific information communication among intra-domain routers.
5.1. Approach #1: Using the existing Administrative Tag Sub-TLV
When a router distributes IP prefix information of the customer or
host network, it can carry the tag of that network in the
Administrative Tag Sub-TLV.
When a router receives IP prefix information, it checks if there is
a locally configured interface with the same tag as the
Administrative Tag information carried in the prefix. If such an
interface exists, SAVNET rules will be added, with the prefix being
the received prefix and the interface being the locally configured
interface with this tag.
As shown in Figure 2, assume Network N is assigned tag n, meaning
tag n is configured on both router A's interface # and router B's
interface #. In the prefix information of 10.1.0.0/16 published by
Router A, tag n is carried via the Administrative Tag Sub-TLV.
Similarly, in the prefix information of 10.0.0.0/16 published by
Router B, tag n is carried via the Administrative Tag Sub-TLV. When
Router A receives the prefix information of 10.0.0.0/16, it checks
that the carried tag n matches the tag on interface #, and since
interface # connects to Network N, Router A determines that prefix
10.0.0.0/16 also belongs to Network N.. Similarly, Router B
determines that prefix 10.1.0.0/16 also belongs to Network N using
the same process.
5.1.1. Administrative Tag Sub-TLV of IS-IS
For routers running IS-IS, they can carry the tag 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
Li, et al. Expires April 28, 2025 [Page 9]
Internet-Draft IGP-SAVNET October 2024
Prefixes TLV (235), IPv6 Reachability TLV (236), Multi-Topology
Reachable IPv6 Prefixes TLV (237).
5.1.2. Administrative Tag Sub-TLV of OSPF
For routers running OSPF, they can carry the tag in the
Administrative Tag Sub-TLV [I-D.ietf-lsr-ospf-admin-tags] within the
OSPF Extended Prefix TLV Sub-TLV [RFC7684].
5.1.3. Administrative Tag Sub-TLV of OSPFv3
For routers running OSPFv3, they can include the tag 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].
5.1.4. Considerations of using Administrative Tag Sub-TLV
In practice, intra-domain routers may also use the Administrative
Tag Sub-TLV for other purposes (e.g., route filtering), and multiple
Administrative Tag Sub-TLVs may be carried in the IP prefix
information simultaneously. Therefore, using the existing
Administrative Tag Sub-TLV for SAV-specific information
communication may conflict with other routing policies that also use
Administrative Tags as filtering criteria. To address this issue,
this document proposes Approach #2 in the following.
5.2. Approach #2: Defining a new SAVNET Tag Sub-TLV
To avoid possible conflicts and facilitate operation and management,
it is more recommended to define and use a dedicated SAVNET Tag Sub-
TLV to tranmit SAV-specific information.
5.2.1. SAVNET Tag Sub-TLV of IS-IS
Figure 4 shows the structure of SAVNET Tag Sub-TLV of IS-IS. It can
be included in the following TLVs: 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).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAVNET Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li, et al. Expires April 28, 2025 [Page 10]
Internet-Draft IGP-SAVNET October 2024
Type: A 8-bit field set to TBD.
Length: 4 octets.
SAVNET Tag: The tag of the customer or host network.
Figure 4: SAVNET Tag Sub-TLV of IS-IS
5.2.2. SAVNET Tag Sub-TLV of OSPF and OSPFv3
Figure 5 shows the structure of SAVNET Tag Sub-TLV of OSPF and
OSPFv3.The SAVNET Tag Sub-TLV of OSPF specified herein will be valid
as a sub-TLV of the following TLVs specified in [RFC7684]:
1. Extended Prefix TLV advertised in the OSPFv2 Extended Prefix LSA.
The SAVNET Tag Sub-TLV of OSPFv3 specified herein will be valid as a
sub-TLV of the following TLVs specified in [RFC8362]:
1. Inter-Area-Prefix TLV advertised in the E-Inter-Area-Prefix-LSA.
2. Intra-Area-Prefix TLV advertised in the E-Intra-Area-Prefix-LSA.
3. External-Prefix TLV advertised in the E-AS-External-LSA and the
E-NSSA-LSA.
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 | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAVNET Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: A 16-bit field set to TBD.
Length: 4 octets.
SAVNET Tag: The tag of the customer or host network.
Figure 5: SAVNET Tag Sub-TLV of OSPF and OSPFv3
6. Security Considerations
The security considerations described in
Li, et al. Expires April 28, 2025 [Page 11]
Internet-Draft IGP-SAVNET October 2024
[I-D.ietf-savnet-intra-domain-problem-statement] and
[I-D.ietf-savnet-intra-domain-architecture] also applies to this
document.
7. IANA Considerations
This document adds the following new sub-TLV to the "IS-IS Sub-TLVs
for TLVs Advertising Prefix Information" registry.
+------+---------------------+--+---+---+----+----+----+---+
| Type | Description |27|126|127| 135| 235| 236|237|
+======+=====================+======+===+====+====+====+===+
| TBA | SAVNET Tag Sub-TLV |y | y | y | y | y | y | y |
+------+---------------------+--+---+---+----+----+----+---+
The following values should be allocated from the OSPFv2 Extended
Prefix TLV Sub-TLV Registry [RFC7684]:
* TBD - 32-bit SAVNET Tag TLV
The following values should be allocated from the OSPFv3 Extended-
LSA Sub-TLV Registry [RFC8362]:
* TBD - 32-bit SAVNET Tag TLV
8. References
8.1. Normative 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>.
[I-D.ietf-savnet-intra-domain-architecture] Li, D., Wu, J., Qin, L.,
Geng, N., and L. Chen, "Intra-domain Source Address
Validation (SAVNET) Architecture", Work in Progress,
Internet-Draft, draft-ietf-savnet-intra-domain-
architecture-00, 12 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-architecture-00>.
Li, et al. Expires April 28, 2025 [Page 12]
Internet-Draft IGP-SAVNET October 2024
[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-19, 3 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-
ospf-admin-tags-19>.
[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>.
8.2. Informative References
[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>.
Li, et al. Expires April 28, 2025 [Page 13]
Internet-Draft IGP-SAVNET October 2024
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Lancheng Qin
Zhongguancun Laboratory
Beijing
China
Email: qinlc@mail.zgclab.edu.cn
Xueyan Song
ZTE Corporation
Nanjing
China
Email: song.xueyan2@zte.com.cn
Changwang Lin
New H3C Technologies
Beijing
China
Email: linchangwang.04414@h3c.com
Shengnan Yue
China Mobile
Beijing
China
Email: yueshengnan@chinamobile.com
Li, et al. Expires April 28, 2025 [Page 14]