Source Address Validation Enhanced by Network Controller
draft-tong-savnet-sav-enhanced-by-controller-01
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 | tongtian124 , Changwang Lin , Nan Wang | ||
| Last updated | 2024-10-21 | ||
| 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-tong-savnet-sav-enhanced-by-controller-01
Source Address Validation in Intra-domain and Inter-domain NetworksT. Tong
Internet-Draft China Unicom
Intended status: Informational C. Lin
Expires: 24 April 2025 New H3C Technologies
N. Wang
China Unicom
21 October 2024
Source Address Validation Enhanced by Network Controller
draft-tong-savnet-sav-enhanced-by-controller-01
Abstract
Many newly proposed Source Address Validation (SAV) mechanisms such
as IGP-based and BGP-based SAVNET solutions take a distributed manner
to generate SAV rules, but they are faced with accuracy and
managability challenges in incremental/partial deployment scenarios.
This document proposes a network controller-based solution for
enhancing SAVNET capability in intra-domain and inter-domain
networks, which supports accurate verification, automated
configuration, threat analysis, traceability and visualization.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-tong-savnet-sav-enhanced-by-
controller/.
Discussion of this document takes place on the Source Address
Validation in Intra-domain and Inter-domain Networks Working Group
mailing list (mailto:savnet@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/savnet/. Subscribe at
https://www.ietf.org/mailman/listinfo/savnet/.
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/.
Tong, et al. Expires 24 April 2025 [Page 1]
Internet-Draft SAV Enhanced by Controller October 2024
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 24 April 2025.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scenarios and Requirements for Centralized SAVNET . . . . . . 4
2.1. Challenges and Limitations of Distributed SAVNET in
Incremental/partial deployment . . . . . . . . . . . . . 5
2.2. Obtain information from external systems . . . . . . . . 7
2.3. Automated configuration . . . . . . . . . . . . . . . . . 7
2.4. Analysis and traceability requirements . . . . . . . . . 8
3. Centralized SAVNET capability enhancement solution . . . . . 9
3.1. Key technologies in Intra-domain SAVNET enhancement . . . 10
3.2. Key technologies in Inter-domain SAVNET enhancement . . . 12
4. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Tong, et al. Expires 24 April 2025 [Page 2]
Internet-Draft SAV Enhanced by Controller October 2024
1. Introduction
Distributed SAVNET solutions utilize protocol message exchanges among
SAVNET routers to acquire source prefix information related to other
subnets within intra-domain networks or inter-domain networks, such
as Source Prefix Announcement (SPA) technology for intra-domain
SAVNET, which can be transmitted by a new protocol or an extension to
an existing protocol [I-D.li-savnet-source-prefix-advertisement].
Nonetheless, under circumstances characterized by device
heterogeneity, partial upgrades, asymmetric routing, and peculiar
address, these solutions face diminished accuracy in Source Address
Validation (SAV). Furthermore，there are necessities for enhancement
in areas such as automated configuration, threat analysis,
traceability, and visualization.
In this document, on the basis of distributed intra-domain and inter-
domain SAVNET architecture, we propose a controller-based and
centralized SAVNET enhancement solution. The distributed SAVNET
solutions rely on local routing information and SAV-specific
information. In this solution, the controller can generate and
deliver SAV rules based on the global information, and can also
obtain ROA and other external information to generate inter-domain
SAV rules, so as to achieve accurate source address verification
(SAV) in both intra-domain and inter-domain in a combination of
centralized and distributed ways.
In this solution, SAVNET routers and non-SAVNET routers can cooperate
via the network controller. More accurate source address
verification rules can be generated based on more comprehensive
information in the scenario of partial/incremental deployment of
SAVNET. Concurrently, the SAVNET can support accurate verification,
automated configuration, threat analysis, traceability and
visualization.
1.1. Terminology
* SAV: Source Address Validation
* AS: Autonomous System
* SAV-Specific Information: Information specialized for SAV rule
generation, exchanged between routers or from the network
controller.
* SAV-related Information: The information used by a router to make
SAV decisions. For intra-domain SAV, SAV-related information
includes both local routing information and SAV-specific
information.
Tong, et al. Expires 24 April 2025 [Page 3]
Internet-Draft SAV Enhanced by Controller October 2024
* SAV-specific Information Communication Mechanism: The mechanism
for exchanging SAV-specific information between routers. It can
be either a new protocol or an extension to an existing protocol.
* SAV Information Base: A table or data structure in a router that
stores specific SAV information and local routing information.
* 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 or from
network controller.
* SAVNET Router: An intra-domain router which runs intra-domain
SAVNET.
* SAVNET Agent: The agent in a SAVNET router that is responsible for
communicating SAV-specific information, processing SAV-related
information, and generating SAV rules.
* AS Edge Router: An intra-domain router of an AS which is connected
to client subnets.
* AS Border Router: An intra-domain router of an AS which is
connected to other ASes.
* Improper Block: The validation results that the packets with
legitimate source addresses are blocked improperly due to
inaccurate SAV rules.
* Improper Permit: The validation results that the packets with
spoofed source addresses are permitted improperly due to
inaccurate SAV rules.
* ISP: Internet Service Provider.
2. Scenarios and Requirements for Centralized SAVNET
This section introduces the scenarios and requirements of centralized
SAVNET, including incremental/partial deployment scenario, obtain
information from external systems, automated configuration, analysis
and traceability requirements,etc.
Tong, et al. Expires 24 April 2025 [Page 4]
Internet-Draft SAV Enhanced by Controller October 2024
2.1. Challenges and Limitations of Distributed SAVNET in Incremental/
partial deployment
The current distributed solution which exchanges SAV-specific
information between SAVNET routers depends on devices upgrade.
Devices utilize the source prefix advertisement (SPA) information to
notify other routers about their subnet and prefix information.
Unique subnet ID for each subnet should be planned by network
manager, and additional identification information such as subnet ID
and access mode on the corresponding port of the device should be
configured manually, so as to generate more accurate SAV rules.
However, devices are upgraded gradually due to various limitations
such as device performance、version and vendor. As a result, in an
AS, there are some routers support SAVNET and others do not.
Routers with distributed solution could not generate accurate SAV
rules in incremental/partial deployment scenario. Refer to
[I-D.li-savnet-intra-domain-architecture] and
[I-D.li-savnet-inter-domain-architecture].Though the SAVNET router
can obtain routing information from the local RIB/FIB and generate
SAV rules for certain prefixes, in the absence of SAV-specific
information, the SAV generated based on the local RIB/FIB has the
risk of the improper block and improper permit in special scenarios
such as asymmetric routing scenario.
Figure 1 illustrates the asymmetric routing in a multi-homing subnet
scenario which has been raised in [I-D.ietf-savnet-intra-domain-
problem-statement]. Subnet 1 has a prefix of 10.0.0.0/15 and is
connected to two edge routers, Router 1 and Router 2. Due to the
load balancing policy in the inbound direction of subnet 1, R1 can
only learn subnet prefix 10.1.0.0/16 from subnet 1, while R2 can only
learn subfix 10.0.0.0/16 from subnet 1. After that, R1 learns
another subnet prefix through the intra-domain routing protocol, and
so does R2. The FIB of R1 and R2 are shown in Figure 1. R1 is a
SAVNET router and R2 is a non-SAVNET router, and R1 and R2
communicate with each other through R3, regardless of whether R3 is a
SAVNET router or not, the SPA message cannot be delivered and R2
cannot generate its own SAV-specific information or recognize the
SAV-specific information transmitted from R1. Therefore, R1 can only
collect part of the prefix information of the subnet to generate SAV
rules, and R2 uses the FIB for SAV, then improper block will occur in
both R1 and R2 due to incomplete information.
Tong, et al. Expires 24 April 2025 [Page 5]
Internet-Draft SAV Enhanced by Controller October 2024
+--------------------------------------------------------------------+
| AS |
| +----------+ |
| | Router 3 | |
| FIB on Router 1 +----------+ FIB on Router 2 |
| Dest Next_hop / \ \ Dest Next_hop |
| 10.1.0.0/16 Subnet 1 / \ 10.0.0.0/16 Subnet 1 |
| 10.0.0.0/16 Router 3 / SPA \ 10.1.0.0/16 Router 3 |
| +----------+ +----------+ |
| SAVNET | Router 1 | | Router 2 | Non-SAVNET |
| +---+#+----+ +---+#+----+ |
| \ / |
| \ / |
| +------------+ |
| | Customer | |
| | Network | |
| +------------+ |
| (10.0.0.0/15) |
| |
+--------------------------------------------------------------------+
Figure 1: Asymmetric multi-homing scenario in incremental
deployment of intra- domain
Incremental/partial deployment for inter-domain include: (1) devices
partially support SAVNET in an AS; (2) some ASs support SAVNET, while
others do not. Figure 2 shows that ASBR1/2/3 are SAVNET routers
while ASBR4 is a non-SAVNET router, ASBR4 cannot generate accurate
source address verification rules without obtaining SAV-specific
information from other AS and other routers in its AS.
+-----------------------+ +------------------------+
| AS1 +----------+ | | +--------- + AS2 |
| SAVNET | ASBR 1 | | -------- | | ASBR 3 | SAVNET |
| +----------+ | | +----------+ |
| +----------+ | | +----------+ |
| SAVNET | ASBR 2 | | -------- | | ASBR 4 | Non- |
| +----------+ | | +----------+ SAVNET |
+-----------------------+ +------------------------+
Figure 2: Partial deployment of Savnet for inter-domain
As a result, there is a problem of low accuracy in partial/
incremental deployment scenarios. In addition, how to improve the
protection effect and enhance the incentive is also one of the
enhanced capabilities.
Tong, et al. Expires 24 April 2025 [Page 6]
Internet-Draft SAV Enhanced by Controller October 2024
2.2. Obtain information from external systems
ASBR in each AS collects the SAV-specific information in its AS
domain and synchronizes the SAV-specific information with the ASBR of
the adjacent AS domain, and also obtains the RPKI ROA and ASPA
information, as well as general information such as RIB, FIB, IRR,
etc.Based on the above information sources, each AS generates a
relatively complete source address verification table. So each AS
needs to establish an information exchange channel and mechanism with
the RPKI ROA to ensure network security, but routers shouldn’t
directly interact with the RPKI ROA and other external systems, and a
controller is appropriate to obtain information such as RPKI ROA and
ASPA.
2.3. Automated configuration
Due to the existence of special addresses in the network, such as
anycast addresses, the existing distributed SAVNET solutions need to
manually identify special addresses and adopt corresponding policies,
which brings high management overhead.
For example, in Figure 3, P1~P4 are common prefixes, P5 is an anycast
prefix with multiple legitimate origins including customer network 1,
customer network 3 and external Internet. SAVNET with whitelist to
be generated on interfaces a, b, and c, and SAVNET blacklist can be
generated on interfaces d and e. If subnet 1 could not recognize P5
as an anycast prefix, the blacklist of interfaces d and e includes
prefix P5, causing legitimate packets with P5 as the source to be
filtered by mistake when they enter from interfaces d and e.
Therefore, in order not to include an anycast prefix in a blacklist,
it needs to use a special flag to indicate the anycast prefix when
subnet 1 advertises the prefix P5 through the SPA. Prefix type can
be obtained and configured on the edge router through the controller
if centralized management is possible,.
Tong, et al. Expires 24 April 2025 [Page 7]
Internet-Draft SAV Enhanced by Controller October 2024
+----------------------------------+ +--------------+
| AS 1 | | Other AS |
| +-----------+ | | |
| | Router 3 | |---- | Internet |
| +-----------+ | | |
| / \ | | |
| / \ | | |
| +----------+ +----------+ | | +----------+ |
| | Router 1 | | Router 2 | | | | Router 4 | |
| +---+#+----+ +- -+#+---+ | | +---+#+----+ |
+---------|-----\--------|------\--+ +------|-------+
| \ | \ |
| \ | \ |
| \ | \ |
+------------+ +------------+ +------------+
| Customer | | Customer | | Customer |
| Network 1 | | Network 2 | | Network 3 |
+------------+ +------------+ +------------+
（ prefix-1 and 5）（ prefix-2 and 3）（ prefix-4 and 5）
Figure 3: Impact of anycast prefix
In addition, network providers assign access devices, access ports,
and public IP addresses to users who connect to their networks, so
that the address allocation system in the carrier's network contains
information about the customer's network. Source address
verification technology can be combined with address allocation
systems to automate configuration and achieve traceability based on
source prefix. Centralized network controller can switch the
authentication mode of all SAVNET routers flexibly through the
delivery configuration.
2.4. Analysis and traceability requirements
Current scheme provides flexible verification modes such as dropping,
rate limiting, or allow for the forged packets in the latest draft
sav_table [I-D.huang-savnet-sav-table]. It will play a great role if
the controller can collect more source address forgery information
from the router, analyze and trace the source in a centralized
manner, visualize the source and target of the attack and threat
tracing. Besides, with the continuous expansion of the network scale
and the increasing allocation of IP addresses, IP address conflicts
include IP address conflicts and IP prefix conflicts will appear,
which affects the normal network operation. The controller can find
whether the prefixes are reused by checking the prefixes and their
binding subnet ID.
Tong, et al. Expires 24 April 2025 [Page 8]
Internet-Draft SAV Enhanced by Controller October 2024
3. Centralized SAVNET capability enhancement solution
A high-level view of the Centralized SAVNET framework, without
expanding the functional entities in network controller and Savnet
devices, is illustrated in Figure 4.
+---------------------------------------------------------+
| Controller |
| +----------------------------------------+ |
| | SAVNET Management Plane | |
| +----------------------------------------+ |
| +----------------------------------------+ |
| | SAVNET Control Plane | |
| +----------------------------------------+ |
| |
+---------------------------------------------------------+
/|\
|
|
\|/
+---------------------------------------------------------+
| Savnet Devices |
| SAVNET Device Plane |
+---------------------------------------------------------+
Figure 4: SAVNET capability enhancement architecture based on network
controller
The following planes are defined: SAVNET Management Plane：Responsible
for monitoring, configuring and maintaining SAVNET devices and Non-
SAVNET devices,including delivering configuration to the devices,
displaying and managing source address prefixes and SAV rules on
devices.
SAVNET Control Plane: Responsible for generating SAV rules. The
incoming interfaces of source address prefixes are calculated based
on topology informations，the source address prefixes，roles of
devices. Finally, SAVNET entries/rules are generated and sent to the
corresponding network devices.
SAVNET device data plane: Responsible for maintaining and updating
SAVNET entries from different sources, source address verification on
the data forwarding plane and forwarding packets. The SAVNET entries
can have multiple sources. SAV rules may be derived from intra-
domain or inter-domain control plane protocols, see [I-D. draft-ietf-
savnet-intra-domain-architecture-01] and [I-D.Raft -wu-savnet-inter-
domain-architecture-11] for detail. SAV rules may be from the
controller as well.
Tong, et al. Expires 24 April 2025 [Page 9]
Internet-Draft SAV Enhanced by Controller October 2024
The following interfaces are defined: Report the network topology:
The basic BGP-LS as specified in [RFC9552] applies to this document
to advertise the network information to the controller. Report
source address prefixes and SAVNET capabilities of network devices:
Extend BGP-LS or YANG model to report source address prefixes and
SAVNET capabilities of devices. For BGP-LS extensions, see [I-
D.draft-cheng-lsr-adv-savnet-capbility-00].
Report SAV rules: Monitor and manage SAV rules through a centralized
controller. The protocol extensions of BGP Link-State to collect
source address validation (SAV) rules generated by different
protocols/mechanisms in {I-D. tong-idr-bgp-ls-sav-rule} can
facilitate multi-sourced SAV rule monitoring and management.
Deliver SAV rules: SAV rules can be delivered through YANG [I-D.Li-
savnet-sav-yang], BGP-LS[I-D.haas-savnet-bgp-sav-distribution], and
BGP-FS [I-D.geng-idr-flowspec-sav]. Detailed definition of SAV rules
can see [I-D.draft -huang-savnet-sav-table-07]. When some network
devices do not support SAVNET, the controller can deliver other
protection policies, such as ACL rules, to the corresponding network
devices.
3.1. Key technologies in Intra-domain SAVNET enhancement
This section describes the intra-Domain SAV Enhancement based on
Controller. Figure 5 illustrates Centralized SAVNET capability
enhancement architecture in an intra-domain network. Centralized
Controller can support accurate verification, automated
configuration, threat analysis, traceability and visualization.
Tong, et al. Expires 24 April 2025 [Page 10]
Internet-Draft SAV Enhanced by Controller October 2024
+---------------------------------------------------------+
| |
| SAVNET Controller |
+---------------------------------------------------------+
/|\
|
\|/
+---------------------------------------------------------+
| +--------+ +--------+ |
| | ASBR1 | | ASBR2 | |
| +--------+ +--------+ |
| | | |
| +------------------------------+ |
| | other Routers | |
| +------------------------------+ |
| | | | |
| +--------+ +--------+ +--------+ |
| | R1 | | R2 | | R3 | |
| +--------+ +--------+ +--------+ |
+---------------------------------------------------------+
Figure 5: intra-domain SAVNET capability enhancement architecture
based on network controller
As shown in the figure above, when SAVNET is deployed in the intra-
domain, controller can implement different control policies based on
roles of devices. For the boundary devices in the domain, the
blacklist policy is adopted. For the multi-homing access devices in
the domain, the controller delivers multi-homing SAV rules in a
centralized manner.
Deliver SAV rules in intra-domain: (1) AS Boundary Router (ASBR): The
controller collects source address prefixes of all subnets in the AS
domain, removes special IP addresses or prefixes, such as anycast IP
addresses, generates the SAV rules/policies（in blacklist mode）
containing all source address prefixes of the AS, and sends the SAV
rules/policies to the ASBR. The SAV rules are generated and
delivered to the routers that support SAVNET, and other defense
policies, such as ACL (filtering specific source addresses on
specific incoming interfaces), are generated and delivered to the
routers that do not support SAVNET.
Tong, et al. Expires 24 April 2025 [Page 11]
Internet-Draft SAV Enhanced by Controller October 2024
+-------------------------------------------------+
| |
| SAVNET Controller |
+-------------------------------------------------+
/|\ /|\
| |
\|/ \|/
+--------+ +--------+
| ASBR1 | | ASBR2 |
+--------+ +--------+
SAVNET Router Non-SAVNET Router
Figure 6: Deliver SAV rules to AS Border Routers
(2) Access Router: If a subnet is connected to two access routers and
only one router supports SAVNET and the other does not, the
controller can generate the SAV entry of P2 and send it to access
router R1. The prefix-interface whitelist of access router R1
includes P1 and P2 to avoid false blocking. The controller can also
generate ACL entries with prefixes P1 and P2 and send them to the
access interface of access router R2 which does not support SAVNET.
+-------------------------------------------------+
| |
| SAVNET Controller |
+-------------------------------------------------+
/|\ /|\
| |
\|/ \|/
+---------------+ +---------------+
| Access Router | | Access Router |
+---------------+ +---------------+
SAVNET Router \ / Non-SAVNET Router
P1 \ / P2
+---------------+
| Customer |
| Network |
+---------------+
Figure 7: Deliver SAV rules to access routers
3.2. Key technologies in Inter-domain SAVNET enhancement
In inter-domain source address verification, the controller can also
play an important role.
* Scenario 1: Centralized controller in single management domain
including multiple ASes:
Tong, et al. Expires 24 April 2025 [Page 12]
Internet-Draft SAV Enhanced by Controller October 2024
An ISP has multiple ASes in actual network deployment. If a unified
controller manages multiple ASes, the controller can deliver SAV
rules to the devices of each AS as required.
+-------------------------------------------------+
| Centralized Controller |
+-------------------------------------------------+
/|\ /|\ /|\
| | |
\|/ \|/ \|/
+------------+ +------------+ +------------+
| AS1 | | AS2 | | AS3 |
+------------+ +------------+ +------------+
Figure 8: Centralized controller in single management domain with
multiple ASes
Based on the source addresses prefixes of the entire network,
relationships between ASes, and third-party authentication
information such as ROA objects and ASPA objects, the controller can
calculate the SAV rules of the entire management domain and deliver
SAV rules to the corresponding devices. For a description of the
delivery of SAV rules, see 5.1.
* Scenario 2: Different ASes has different controllers
When different ASes have their own controllers, each controller
collects the complete source address prefixes of the local AS and
sends them to the ASBR. The ASBR generates the inter-domain SAV-
Specific information and advertises it to the ASBR of the neighboring
AS. As shown in Figure 9, not all routers in AS1 and AS2 support
SAVNET，AS1 and AS2 controllers collect the complete source address
prefixes and send to their own ASBRs respetively. The controller can
also deliver the synchronization key to the ASBR to ensure the
reliability and flexibility of inter-domain SAV-Specific information
transmission.
+-------------------+ +-------------------+
| AS1 controller | | AS2 controller |
+-------------------+ +-------------------+
/|\ /|\
| |
\|/ \|/
+-------------------+ +-------------------+
| AS1 | <---> | AS2 |
+-------------------+ +-------------------+
SAV-Specific information
Tong, et al. Expires 24 April 2025 [Page 13]
Internet-Draft SAV Enhanced by Controller October 2024
Figure 9: Centralized controller with one controller within
multiple ASes
Besides，if ASBR of an AS do not support SAVNET and can not generate
the inter-domain SAV-Specific information, SAV-Specific information
can be advertised through network cooperator for rapid deployment as
shown in Figure 9. Each controller can generate SAV rules based on
SAV-Specific information and advertise to ASBRs to achieve source
address verification.
+-----------------------------------------------+
| network cooperator |
+-----------------------------------------------+
/|\ /|\
| SAV-Specific information |
\|/ \|/
+-------------------+ +-------------------+
| AS1 controller | | AS2 controller |
+-------------------+ +-------------------+
/|\ /|\
| SAV rules | SAV rules
\|/ \|/
+-------------------+ +-------------------+
| AS1 | | AS2 |
+-------------------+ +-------------------+
Figure 10: Centralized controller with one controller within
multiple ASes
4. Use Case
Several use cases will illustrate that centralized intra-domain
SAVNET can achieve more accurate and comprehensive SAV.
Case 1: More accurate intra-domain edge protection TBD.
Case 2: More accurate intra-domain border protection TBD.
Case 3: More accurate Inter-domain protection TBD.
Case 4: Accurate protection with anycast IP address TBD.
5. Security Considerations
TBD.
Tong, et al. Expires 24 April 2025 [Page 14]
Internet-Draft SAV Enhanced by Controller October 2024
6. IANA Considerations
TBD.
7. Acknowledgments
TBD.
8. References
8.1. Normative References
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/rfc/rfc9552>.
8.2. Informative References
[I-D.huang-savnet-sav-table]
Huang, M., Cheng, W., Li, D., Geng, N., Liu, Chen, L., and
C. Lin, "General Source Address Validation Capabilities",
Work in Progress, Internet-Draft, draft-huang-savnet-sav-
table-07, 25 August 2024,
<https://datatracker.ietf.org/doc/html/draft-huang-savnet-
sav-table-07>.
[I-D.li-savnet-inter-domain-architecture]
"*** BROKEN REFERENCE ***".
[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-07, 16 March
2024, <https://datatracker.ietf.org/doc/html/draft-li-
savnet-intra-domain-architecture-07>.
[I-D.li-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-li-savnet-intra-domain-problem-
statement-07, 11 March 2023,
<https://datatracker.ietf.org/doc/html/draft-li-savnet-
intra-domain-problem-statement-07>.
Tong, et al. Expires 24 April 2025 [Page 15]
Internet-Draft SAV Enhanced by Controller October 2024
[I-D.li-savnet-source-prefix-advertisement]
Li, D., Geng, N., and L. Qin, "Source Prefix Advertisement
for Intra-domain SAVNET", Work in Progress, Internet-
Draft, draft-li-savnet-source-prefix-advertisement-01, 20
October 2024, <https://datatracker.ietf.org/doc/html/
draft-li-savnet-source-prefix-advertisement-01>.
Authors' Addresses
Tian Tong
China Unicom
Email: tongt5@chinaunicom.cn
Changwang Lin
New H3C Technologies
Email: linchangwang.04414@h3c.com
Nan Wang
China Unicom
Email: wangn161@chinaunicom.cn
Tong, et al. Expires 24 April 2025 [Page 16]