SAVNET D. Li
Internet-Draft J. Wu
Intended status: Informational Tsinghua University
Expires: 9 October 2025 L. Qin
M. Huang
Zhongguancun Laboratory
N. Geng
Huawei
7 April 2025
Source Address Validation in Intra-domain Networks Gap Analysis, Problem
Statement, and Requirements
draft-ietf-savnet-intra-domain-problem-statement-15
Abstract
This document provides a gap analysis of existing intra-domain source
address validation mechanisms, describes the fundamental problems,
and defines the basic requirements for technical improvements.
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 9 October 2025.
Copyright Notice
Copyright (c) 2025 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
Li, et al. Expires 9 October 2025 [Page 1]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Existing Intra-domain SAV Mechanisms . . . . . . . . . . . . 5
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Intra-domain SAV on Customer-facing or Host-facing
Routers . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Asymmetric Routing . . . . . . . . . . . . . . . . . 6
3.1.2. Hidden Prefix . . . . . . . . . . . . . . . . . . . . 8
3.2. Intra-domain SAV on AS Border Routers . . . . . . . . . . 10
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 11
5. Requirements for New SAV Mechanisms . . . . . . . . . . . . . 12
5.1. Accurate Validation . . . . . . . . . . . . . . . . . . . 12
5.2. Automatic Update . . . . . . . . . . . . . . . . . . . . 12
5.3. Working in Incremental Deployment . . . . . . . . . . . . 12
5.4. Fast Convergence . . . . . . . . . . . . . . . . . . . . 13
5.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Source Address Validation (SAV) is important for defending against
source address spoofing attacks. Network operators can implement SAV
mechanisms at multiple levels: access-network SAV, intra-domain SAV,
and inter-domain SAV (see [RFC5210]). Access-network SAV (e.g., SAVI
[RFC7039], IP Source Guard (IPSG) based on DHCP snooping [IPSG], and
Cable Source-Verify [cable-verify]) is typically deployed on switches
inside the access network to prevent a host from using the source
address of another host. When access-network SAV is not universally
deployed, intra-domain SAV on routers can help block spoofing traffic
as close to the source as possible.
The "domain" used in this document means the Autonomous System (AS).
For example, an AS that consists of multiple IGP instances is a
single domain. If an Internet Service Provider (ISP) consists of
multiple ASes, each AS is a single domain.
Li, et al. Expires 9 October 2025 [Page 2]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
This document focuses only on the analysis of intra-domain SAV.
Unlike inter-domain SAV which requires information (e.g., Border
Gateway Protocol (BGP) data) provided by other ASes to determine SAV
rules, intra-domain SAV for an AS determines SAV rules solely by the
AS itself without cooperation with other ASes. Intra-domain SAV for
an AS aims at achieving two goals: i) blocking spoofed data packets
originated from customer networks or host networks of the AS that use
a source address of other networks; and ii) blocking spoofed data
packets coming from external ASes that use a source address of the
local AS.
Figure 1 illustrates the goals of intra-domain SAV with two cases.
Case i shows that the customer network or host network of AS X
originates spoofed data packets using a source address of other
networks. If AS X deploys intra-domain SAV, the spoofed data packets
can be blocked (i.e., Goal i). Case ii shows that AS X receives
spoofed data packets using a source address of AS X from an external
AS. If AS X deploys intra-domain SAV, the spoofed data packets can
be blocked (i.e., Goal ii).
Case i: The customer network or host network of AS X originates
spoofed data packets using a source address of other networks
Goal i: If AS X deploys intra-domain SAV,
the spoofed data packets can be blocked
Spoofed data packets
using a source address
+-------------------------------+ of other networks +------+
| Customer/Host Network of AS X |---------------------->| AS X |
+-------------------------------+ +------+
Case ii: AS X receives spoofed data packets using a source address of
AS X from an external AS
Goal ii: If AS X deploys intra-domain SAV,
the spoofed data packets can be blocked
Spoofed data packets
using a source address
+------+ of AS X +------+
| AS X |<----------------------| AS Y |
+------+ +------+
Figure 1: Two Goals of intra-domain SAV
This document clarifies that the scope of SAV is to check the
validity of the source address of data packets in IP-encapsulated
scenarios including:
Li, et al. Expires 9 October 2025 [Page 3]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
* Native IP forwarding: including global routing table forwarding
and VPN forwarding scenarios.
* IP-encapsulated Tunnel (IPsec [RFC4301], GRE [RFC2784], SRv6
[RFC9256], etc.): focusing on the validation of the outer layer IP
address.
* Both IPv4 and IPv6 addresses.
SAV does not check non-IP packets in MPLS label-based forwarding and
other non-IP-based forwarding scenarios.
In the following, this document provides a gap analysis of existing
intra-domain SAV mechanisms, concludes key problems to solve, and
proposes basic requirements for future ones.
1.1. 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.
Host-facing Router: An intra-domain router that is connected to hosts
or switches through a layer-2 connection.
Host Network: An intra-domain user network that only originates
traffic and consists of hosts or/and switches. It sends traffic to
other networks through the host-facing router.
Customer-facing Router: An intra-domain router that is connected to
customer networks through a layer-3 connection (e.g., the static
route).
Customer Network: An intra-domain user network that only originates
traffic and consists of hosts and routers. It sends traffic to other
networks through the customer-facing router. Different from host
network, routers within the customer network run routing protocols.
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.
SAV-specific Information: The information specialized for SAV rule
generation, which is exchanged among intra-domain routers.
Li, et al. Expires 9 October 2025 [Page 4]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
1.2. 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. Existing Intra-domain SAV Mechanisms
This section introduces existing intra-domain SAV mechanisms,
including BCP38 [RFC2827] and BCP84 [RFC3704].
* ACL-based ingress filtering or BCP38 [RFC2827] requires that
network operators manually configure ACL rules on routers to block
or permit data packets with specific source addresses. This
mechanism can be used on interfaces of customer-facing or host-
facing routers facing a customer network or host network to
prevent the corresponding network from spoofing source prefixes of
other networks. In addition, it is also usually used on
interfaces of AS border routers facing an external AS to block
data packets using disallowed source addresses, such as internal
source addresses owned by the local AS [nist-rec]. In any
application scenario, ACL rules must be updated in time to be
consistent with the latest filtering criteria when the network
changes.
* Strict uRPF [RFC3704] is also typically used on interfaces of
customer-facing or host-facing routers facing a customer network
or host network. Routers deploying strict uRPF accept a data
packet only when i) the local Forwarding Information Base (FIB)
contains a prefix covering the packet's source address and ii) the
corresponding outgoing interface for the prefix in the FIB matches
the packet's incoming interface. Otherwise, the packet will be
blocked.
* Loose uRPF [RFC3704] uses a looser validation method. A packet
will be accepted if the router's local FIB contains a prefix
covering the packet's source address regardless of the interface
from which the packet is received. In fact, interfaces of AS
border routers facing an external AS may use loose uRPF to block
incoming data packets using non-global addresses [nist-rec]. EFP-
uRPF [RFC8704] is another SAV mechanism which can be used on AS
border routers as well. This document does not analyze EFP-uRPF
because it is an inter-domain SAV mechanism with a different goal
from those described in Section 1.
Li, et al. Expires 9 October 2025 [Page 5]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
In summary, ACL-based ingress filtering and uRPF are the two most
commonly used intra-domain SAV mechanisms. This document provides a
gap analysis of these two mechanisms in Section 3.
3. Gap Analysis
This section elaborates the key problems of current intra-domain SAV
on customer-facing or host-facing routers and intra-domain SAV on AS
border routers, respectively.
3.1. Intra-domain SAV on Customer-facing or Host-facing Routers
Towards Goal i in Figure 1, intra-domain SAV is typically deployed on
interfaces of customer-facing routers or host-facing routers facing a
customer network or host network to validate data packets originated
from that network, since SAV is more effective when deployed closer
to the source. ACL-based ingress filtering and strict uRPF are
commonly used for this purpose.
ACL rules must be manually updated according to prefix changes or
topology changes in a timely manner. Otherwise, if ACL rules are not
updated in time, improper block or improper permit problems may
occur. To ensure the accuracy of ACL rules in dynamic networks, high
operational overhead will be induced to achieve timely updates for
ACL configurations.
Strict uRPF can generate and update SAV rules in an automatic way but
it will cause improper blocks in the scenario of asymmetric routing
or hidden prefix.
3.1.1. Asymmetric Routing
Asymmetric routing means a packet traverses from a source to a
destination in one path and takes a different path when it returns to
the source. Figure 2 shows an example of asymmetric routing in a
multi-homing scenario. The customer network (e.g., a campus network
or an enterprise network) owns prefix 2001:db8::/55 [RFC6890] and is
connected to two routers of the AS, i.e., Router 1 and Router 2.
Router 1, Router 2, and Router 3 of the AS exchange routing
information through the intra-domain routing protocol. For load
balancing of traffic flowing to the customer network, the customer
network expects the incoming traffic destined for prefix
2001:db8::/56 to come from Router 1 and the incoming traffic destined
for prefix 2001:db8:0:100::/56 to come from Router 2. To this end,
it requires that only Router 1 advertises the route information of
prefix 2001:db8::/56 and only Router 2 advertises the routing
information of prefix 2001:db8:0:100::/56 through the intra-domain
routing protocol. Figure 2 shows the FIB entries associated with the
Li, et al. Expires 9 October 2025 [Page 6]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
two prefixes for Router 1 and Router 2.
+----------------------------------------------------------+
| AS |
| +----------+ |
| | Router 3 | |
| +----------+ |
| / \ |
| / \ |
| / \ |
| +----------+ +----------+ |
| | Router 1 | | Router 2 | |
| +----------+ +----------+ |
| /\ / |
|Traffic with \ / Traffic with |
|source IP addresses \ / destination IP addresses|
|of 2001:db8:0:100::/56 \ \/ of 2001:db8:0:100::/56 |
| +----------------+ |
| | Customer | |
| | Network | |
| |(2001:db8::/55) | |
| +----------------+ |
| |
+----------------------------------------------------------+
FIB of Router 1 FIB of Router 2
Dest Next_hop Dest Next_hop
2001:db8::/56 Customer 2001:db8:0:100::/56 Customer
Nestwork Network
2001:db8:0:100::/56 Router 3 2001:db8::/56 Router 3
The legitimate traffic originated from customer network with
source IP addresses in 2001:db8:0:100::/56 will be improperly blocked
by strict uRPF on Router 1.
Figure 2: Asymmetric routing in a multi-homing scenario
While the customer network does not expect traffic destined for
prefix 2001:db8:0:100::/56 to come from Router 1, it can send traffic
with source addresses of prefix 2001:db8:0:100::/56 to Router 1. As
a result, there is asymmetric routing of data packets between the
customer network and Router 1. Arrows in the figure indicate the
flowing direction of traffic. If Router 1 adopts strict uRPF, by
checking the FIB entry that matches prefix 2001:db8:0:100::/56, the
SAV rule is that Router 1 only accepts data packets with source
addresses of 2001:db8:0:100::/56 from Router 3. Therefore, when
customer network sends data packets with source addresses of
2001:db8:0:100::/56 to Router 1, strict uRPF on Router 1 will
Li, et al. Expires 9 October 2025 [Page 7]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
improperly block these legitimate data packets. Similarly, if Router
2 adopts strict uRPF, it will improperly block legitimate data
packets from customer network that use a source address of prefix
2001:db8::/56.
3.1.2. Hidden Prefix
In the hidden prefix scenario, the host originates data packets using
a source address that is not advertised through the intra-domain
routing protocol. The Content Delivery Networks (CDN) and Direct
Server Return (DSR) technology is a representative example of hidden
prefix scenario. The edge server in an AS will send DSR response
packets using a source address of the anycast server which is located
in another remote AS. However, the source address of anycast server
is hidden from the intra-domain routing protocol and intra-domain
routers in the AS. While this is an inter-domain scenario, DSR
response packets will be improperly blocked by strict uRPF when edge
server is located in a customer network or a host network.
Li, et al. Expires 9 October 2025 [Page 8]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
+-------------------------+
| AS Y | AS Y announces the route
| (where the anycast | for anycast prefix P3
| server is located) | in BGP
+-----------+-------------+
|
|
+-----------+-------------+
| Other ASes |
+-------------------------+
/ \
/ \
/ \
+------------------+ +---------------------------------------+
| AS Z | | +----------+ AS X |
| (where the user | | | Router 4 | |
| is located) | | +----------+ |
+------------------+ | | |
| | |
| +----+-----+ |
| | Router 5 | |
| +----------+ |
| /\ DSR responses with |
| | source IP addresses|
| | of P3 |
| +---------------+ |
| | Host | |
| | Network | |
| | (P2) | |
| +---------------+ |
| (where the edge server is located) |
+---------------------------------------+
DSR response packets from edge server in the host network with
source IP addresses of P3 (i.e., the anycast prefix) will
be improperly blocked by Router 5 if Router 5 uses strict uRPF.
Figure 3: Hidden prefix in CDN and DSR scenario
Li, et al. Expires 9 October 2025 [Page 9]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
For example, in Figure 3, assume the edge server is located in the
host network and Router 5 only learns prefix P2 from the interface
connected to the host network. When edge server receives the request
from the remote anycast server, it will directly return DSR response
packets using the source address of anycast server (i.e., P3). If
Router 5 adopts strict uRPF, the SAV rule is that Router 5 only
accepts packets with source addresses of P2 from the host network.
As a result, DSR response packets will be blocked by strict uRPF on
Router 5. If Router 5 adopts loose uRPF which does not check the
default route, loose uRPF at this interface will also improperly
block DSR response packets when prefix P3 only matches the default
route in the FIB of Router 5.
3.2. Intra-domain SAV on AS Border Routers
Towards Goal ii in Figure 1, intra-domain SAV is typically deployed
on interfaces of AS border routers facing an external AS to validate
packets arriving from other ASes. Figure 4 shows an example of SAV
on AS border routers. In the figure, Router 3 and Router 4 deploy
intra-domain SAV on interface '#' for validating data packets coming
from external ASes. ACL-based ingress filtering and loose uRPF are
commonly used for this purpose.
Packets with + Packets with +
spoofed P1/P2| spoofed P1/P2|
+-------------|---------------------------|---------+
| AS \/ \/ |
| +--+#+-----+ +---+#+----+ |
| | Router 3 +---------------+ Router 4 | |
| +----------+ +----+-----+ |
| / \ | |
| / \ | |
| / \ | |
| +----------+ +----------+ +----+-----+ |
| | Router 1 | | Router 2 +------+ Router 5 | |
| +----------+ +----------+ +----+-----+ |
| \ / | |
| \ / | |
| \ / | |
| +---------------+ +-------+-------+ |
| | Customer | | Host | |
| | Network | | Network | |
| | (P1) | | (P2) | |
| +---------------+ +---------------+ |
| |
+---------------------------------------------------+
Figure 4: An example of SAV on AS border routers
Li, et al. Expires 9 October 2025 [Page 10]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
By configuring ACL rules, data packets that use disallowed source
addresses (e.g., non-global addresses or internal source addresses)
can be blocked at AS border routers. However, the operational
overhead of maintaining updated ACL rules will be extremely high when
there are multiple AS border routers adopting SAV as shown in
Figure 4.
As for loose uRPF, it sacrifices the directionality of SAV and has
limited blocking capability, because it allows packets with source
addresses that exist in the FIB table on all router interfaces.
4. Problem Statement
As analyzed above, existing intra-domain SAV mechanisms have
significant limitations on automatic update or accurate validation.
ACL-based ingress filtering relies on manual configurations and thus
requires high operational overhead in dynamic networks. To guarantee
accuracy of ACL-based SAV, network operators have to manually update
the ACL-based filtering rules in time when the prefix or topology
changes. Otherwise, improper block or improper permit problems may
appear.
Strict uRPF can automatically update SAV rules, but may improperly
block legitimate traffic under asymmetric routing scenario or hidden
prefix scenario. As analyzed in Section 3.1, it may mistakenly
consider a valid incoming interface as invalid, resulting in
legitimate data packets being blocked (i.e., improper block problem).
Loose uRPF is also an automated SAV mechanism but its SAV rules are
overly loose. As analyzed in Section 3.2, any spoofed data packet
using a source address covered by the FIB will be accepted by loose
uRPF (i.e., improper permit problem).
In summary, strict uRPF cannot guarantee the accuracy of SAV because
it solely uses the router’s local FIB information to determine SAV
rules, which may not match the incoming interfaces of legitimate data
packets from the source in the case of asymmetric routing and hidden
prefix. As a result, strict uRPF will improperly block legitimate
data packets. The network operator has a comprehensive perspective
so it can configure the correct SAV rules. However, manual
configuration has limitations in automatic update.
Li, et al. Expires 9 October 2025 [Page 11]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
5. Requirements for New SAV Mechanisms
To address the problems of current intra-domain SAV mechanisms, this
section lists five basic requirements for technical improvements and
related discussions that should be considered when designing the new
intra-domain SAV mechanism.
5.1. Accurate Validation
The new intra-domain SAV mechanism MUST improve the accuracy upon
existing intra-domain SAV mechanisms. It MUST achieve the two goals
described in Section 1 to block those spoofing traffic from customer
networks, host networks, and external ASes. Meanwhile, it MUST avoid
blocking legitimate data packets, especially when there are
asymmetric routes or network changes. Intra-domain SAV on a
customer-facing router or host-facing router can generate an
allowlist SAV rule at the interface facing the customer network or
host network. The allowlist contains the source IP address space of
traffic originated from the corresponding customer network or host
network. Intra-domain SAV on an AS border router can generate a
blocklist SAV rule at the interface facing an external AS. The
blocklist contains the source IP address space of traffic originated
from the local AS. To overcome the improper block problems, routers
may need to use more information (e.g., SAV-specific information)
other than the local FIB information to determine SAV decisions. By
integrating more information, routers may learn the asymmetric
routing or hidden prefix, resulting in more accurate SAV rules.
5.2. Automatic Update
The new intra-domain SAV mechanism MUST be able to automatically
generate and update SAV rules on routers, rather than relying
entirely on manual updates like ACL-based ingress filtering.
Although some necessary configurations may be needed to improve the
accuracy of SAV, automation helps reduces operational overhead in SAV
rule generation.
5.3. Working in Incremental Deployment
The new intra-domain SAV mechanism MUST specify the deployment scope
(i.e., which routers the mechanism is used on) and MUST provide
incremental benefits when incrementally deployed within the specified
deployment scope. That is, it MUST NOT be effective only when fully
deployed. In the incremental deployment scenario, it MUST be able to
fulfill or partially fulfill the goals described in Section 1 and
MUST avoid improper blocks.
Li, et al. Expires 9 October 2025 [Page 12]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
5.4. Fast Convergence
The new intra-domain SAV mechanism MUST update SAV rules in time when
prefix changes, route changes, or topology changes occur in an AS.
Two considerations must be taken into account if SAV-specific
information is designed and used by the new intra-domain SAV
mechanism. First, the mechanism MUST allow routers to exchange the
updated SAV-specific information in a timely manner. Second, the
mechanism MUST NOT require routers to signal too much SAV-specific
information for the SAV function, because this may greatly increase
the burden on the control plane of routers and even compromise the
performance of the current protocols.
5.5. Security
The new intra-domain SAV mechanisms MUST NOT introduce additional
security vulnerabilities or confusion to the existing intra-domain
architectures or protocols. Section 6 details the security scope and
security considerations for the new intra-domain SAV mechanism.
6. Security Considerations
Similar to the security scope of intra-domain routing protocols,
intra-domain SAV mechanisms can ensure integrity and authentication
of protocol messages that deliver the required SAV-specific
information, and consider avoiding unintentional misconfiguration.
It is not necessary to provide protection against compromised or
malicious intra-domain routers which poison existing control or
management plane protocols. Compromised or malicious intra-domain
routers may not only affect SAV, but also disrupt the whole intra-
domain routing domain. Security mechanisms to prevent these attacks
are beyond the capability of intra-domain SAV.
7. IANA Considerations
This document does not request any IANA allocations.
8. Acknowledgements
Many thanks to the valuable comments from: Jared Mauch, Barry Greene,
Fang Gao, Kotikalapudi Sriram, Anthony Somerset, Yuanyuan Zhang, Igor
Lubashev, Alvaro Retana, Joel Halpern, Aijun Wang, Michael
Richardson, Li Chen, Gert Doering, Mingxing Liu, Libin Liu, John
O'Brien, Roland Dobbins, Xiangqing Chang, Tony Przygienda, Yingzhen
Qu, Changwang Lin, James Guichard, Linda Dunbar, Robert Sparks, Yu
Fu, Stephen Farrel etc.
9. References
Li, et al. Expires 9 October 2025 [Page 13]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
9.1. Normative References
[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>.
9.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>.
[RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
"A Source Address Validation Architecture (SAVA) Testbed
and Deployment Experience", RFC 5210,
DOI 10.17487/RFC5210, June 2008,
<https://www.rfc-editor.org/info/rfc5210>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
Li, et al. Expires 9 October 2025 [Page 14]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
[cable-verify]
"Cable Source-Verify and IP Address Security", January
2021, <https://www.cisco.com/c/en/us/support/docs/
broadband-cable/cable-security/20691-source-verify.html>.
[IPSG] "Configuring DHCP Features and IP Source Guard", January
2016, <https://www.cisco.com/c/en/us/td/docs/switches/lan/
catalyst2960/software/release/12-
2_53_se/configuration/guide/2960scg/swdhcp82.html>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013,
<https://www.rfc-editor.org/info/rfc7039>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>.
[nist-rec] "Resilient Interdomain Traffic Exchange - BGP Security and
DDoS Mitigation", January 2019,
<https://www.nist.gov/publications/resilient-interdomain-
traffic-exchange-bgp-security-and-ddos-mitigation">.
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Lancheng Qin
Zhongguancun Laboratory
Beijing
China
Email: qinlc@mail.zgclab.edu.cn
Li, et al. Expires 9 October 2025 [Page 15]
Internet-Draft Intra-domain SAVNET Problem Statement April 2025
Mingqing Huang
Zhongguancun Laboratory
Beijing
China
Email: huangmq@mail.zgclab.edu.cn
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Li, et al. Expires 9 October 2025 [Page 16]