Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement and Requirements
draft-li-savnet-intra-domain-problem-statement-06
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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Dan Li , Jianping Wu , Lancheng Qin , Mingqing(Michael) Huang , Nan Geng | ||
| Last updated | 2023-02-23 | ||
| Replaced by | draft-ietf-savnet-intra-domain-problem-statement, draft-ietf-savnet-intra-domain-problem-statement | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Candidate for WG Adoption | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-savnet-intra-domain-problem-statement-06
Network Working Group D. Li
Internet-Draft J. Wu
Intended status: Informational L. Qin
Expires: 27 August 2023 Tsinghua University
M. Huang
N. Geng
Huawei
23 February 2023
Source Address Validation in Intra-domain Networks Gap Analysis, Problem
Statement and Requirements
draft-li-savnet-intra-domain-problem-statement-06
Abstract
This document provides the gap analysis of existing intra-domain
source address validation mechanisms, describes the fundamental
problems, and defines the requirements for technical improvements.
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.
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 27 August 2023.
Li, et al. Expires 27 August 2023 [Page 1]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
Copyright Notice
Copyright (c) 2023 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 5
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Outbound Traffic Validation . . . . . . . . . . . . . . . 6
4.2. Inbound Traffic Validation . . . . . . . . . . . . . . . 8
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
6. Requirements for New SAV Mechanisms . . . . . . . . . . . . . 10
6.1. Accurate Validation . . . . . . . . . . . . . . . . . . . 10
6.2. Automatic Update . . . . . . . . . . . . . . . . . . . . 10
6.3. Working in Incremental/Partial Deployment . . . . . . . . 11
7. Intra-domain SAV Scope . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Source Address Validation (SAV) is important for defending against
source address spoofing attacks and allowing accurate traceback. A
multi-fence architecture called Source Address Validation
Architecture (SAVA) [RFC5210] was proposed to validate source
addresses at three levels: access network SAV, intra-domain SAV, and
inter-domain SAV. When SAV is not fully enabled at the edge of the
Internet, the multi-fence architecture can help enhance the
validation across the whole Internet and thus reduce the
opportunities of launching source address spoofing attacks.
Li, et al. Expires 27 August 2023 [Page 2]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
Particularly, access network SAV ensures a host uses a valid address
assigned to the host statically or dynamically. The host cannot use
the source address of another host. There are many mechanisms for
SAV in access networks. Static ACL rules can be statically
configured for validation by specifying which source addresses are
acceptable or unacceptable. Dynamic ACL is another efficient
mechanism which is associated with authentication servers (e.g.,
RADIUS and DIAMETER). The servers receive access requests and then
install or enable ACL rules on the device to permit particular users'
packets. SAVI [RFC7039] represents a kind of mechanism enforcing
that the legitimate IP address of a host matches the link-layer
property of the host's network attachment. For example, SAVI
solution for DHCP [RFC7513] creates a binding between a DHCPv4/
DHCPv6-assigned IP address and a link-layer property (like MAC
address or switch port) on a SAVI device. IP Source Guard (IPSG)
[IPSG] combined with DHCP snooping is an implementation of SAVI
solution for DHCP. Cable Source-Verify [cable-verify] also shares
some features of SAVI and is used in cable modem networks. Cable
modem termination system (CMTS) devices with Cable Source-Verify will
maintain the bindings of the CPE's IP address, the CPE's MAC address,
and the corresponding cable modem identifier. When receiving
packets, the device will check the validity of the packets according
to the bindings.
Given numerous access networks managed by different operators
throughout the world, it is difficult to require all access networks
to effectively deploy SAV. Therefore, behind access network SAV,
intra-domain SAV and inter-domain SAV are needed to provide the
second- and third-level protection, respectively. Both intra-domain
SAV and inter-domain SAV usually perform validation at the
granularity of IP prefixes, which is coarser than access network SAV
as they covers a range of IP addresses.
This document focuses on the analysis of intra-domain SAV. In
contrast to inter-domain SAV, intra-domain SAV does not require
collaboration between networks (e.g., ASes) for SAV. The SAV rules
can be generate by the network itself. Consider an AS which provides
its own subnets with the connectivity to other ASes or the Internet.
The intra-domain SAV for the network has two goals: i) blocking the
spoofed packets originated by the subnets from entering the network
and ii) blocking the packets with the AS's prefixes as source
addresses from other networks or the Internet.
Li, et al. Expires 27 August 2023 [Page 3]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
Figure 1 shows two cases for showing the effectiveness of intra-
domain SAV. In case i, AS X sends the packets spoofing the source
addresses of AS Z to AS Y. If AS X deploys intra-domain SAV at '#',
the spoofed packets can be blocked (i.e., Goal i). In case ii, If AS
Z deploys intra-domain SAV at '#', the spoofed packets will be
blocked (i.e., Goal ii).
Case i: AS X sends the packets spoofing the
source addresses of AS Z to AS Y
Goal i: If AS X deploys intra-domain SAV at '#',
the spoofed packets can be blocked
+------+ Spoofed packets +------+
| AS X #------------------>| AS Y |
+------+ +------+
Case ii: AS Z receives the packets spoofing
Z's source addresses from AS X
Goal ii: If AS Z deploys intra-domain SAV at
'#', the spoofed packets can be blocked
+------+ Spoofed packets +------+
| AS X |------------------># AS Z |
+------+ +------+
Figure 1: An example for illustrating intra-domain SAV
There are many mechanisms for intra-domain SAV. This document
provides the gap analysis of existing intra-domain SAV mechanisms.
According to the gap analysis, the document concludes the main
problems of existing mechanisms and describes the requirements for
future intra-domain SAV mechanisms.
2. Terminology
SAV Rule: The rule that indicates the validity of a specific source
IP address or source IP prefix.
SAV Table: The table or data structure that implements the SAV rules
and is used for source address validation in the data plane.
Improper Block: The validation results that the packets with
legitimate source addresses are blocked improperly due to inaccurate
SAV rules.
Li, et al. Expires 27 August 2023 [Page 4]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
Improper Permit: The validation results that the packets with spoofed
source addresses are permitted improperly due to inaccurate SAV
rules.
3. Existing Mechanisms
Ingress filtering [RFC2827][RFC3704] is the current practice of
intra-domain SAV. This section briefly introduces the existing
intra-domain SAV mechanisms.
* ACL-based ingress filtering [RFC2827][RFC3704] is a typical
mechanism for intra-domain SAV. ACL rules can be configured for
dropping or permitting particular packets. The mechanism can be
applied at the downstream interfaces of edge routers connecting
the subnets or at the downstream interfaces of aggregation routers
[manrs-antispoofing]. The validation at downstream interfaces
will prevent local subnets from spoofing source prefixes of other
subnets. Besides, at the upstream interfaces connected to other
networks or the Internet, ACL can be enabled for blocking
disallowed source prefixes like the internal source prefixes owned
by the subnets [nist-rec]. In any application scenarios, ACL
rules should be updated in a timely manner so as to be consistent
with the most updated filtering criteria.
* Strict uRPF [RFC3704] is another suitable solution to achieve
ingress filtering in intra-domain networks. Routers deploying
strict uRPF accept a data packet only when i) the local FIB
contains a prefix encompassing the packet's source address and ii)
the corresponding outgoing interface for the prefix matches the
packet's incoming interface. Otherwise, the packet will be
blocked. Strict uRPF is usually used at downstream interfaces of
edge routers connecting the subnets.
* Loose uRPF [RFC3704] takes a looser validation approach than
strict uRPF. A packet will be accepted if there is a route entry
for the source address of the packet in the local FIB. The
incoming interface of the packet is not checked. Loose uRPF can
be enabled at any point in the network. Usually, upstream
interfaces enable loose uRPF for blocking obviously disallowed
source prefixes like non-global addresses [nist-rec].
Li, et al. Expires 27 August 2023 [Page 5]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
* Source-based RTBH filtering is another filtering tool based on
uRPF, mostly loose uRPF. Blackhole routes to specific IP
addresses can be installed on the edge routers through the iBGP
updates sent by a remote trigger router. The packets with the
specific source addresses will be dropped after the uRPF check.
Source-based RTBH filtering makes the edge routers connecting
other networks or the Internet be able to drop packets with a
specific source address or source prefix.
* Carrier Grade NAT has some operations on the source addresses of
packets but is not an anti-spoofing tool as described in
[manrs-antispoofing]. If the source address of a packet is in the
INSIDE access list, the NAT rule can translate the source address
to an address in the pool OUTSIDE. The NAT rule cannot judge
whether the source address is spoofed or not. Besides, the packet
with a spoofed source address will be forwarded directly if the
spoofed source address is not included in the INSIDE access list.
Therefore, Carrier Grade NAT cannot help block or traceback
spoofed packets, and other SAV mechanisms still need to be
deployed.
4. Gap Analysis
Existing intra-domain SAV mechanisms may improperly block the traffic
with legitimate source addresses (i.e., improper block) or improperly
permit the traffic with spoofed source addresses (i.e., improper
permit) due to their technical limitations. Significant operational
attention is required to keep intra-domain SAV accurate.
4.1. Outbound Traffic Validation
Outbound traffic validation is used at downstream interfaces of
routers to validate the packets from the connected subnets. As
described previously, ACL rules can be configured at downstream
interfaces for ingress filtering. These rules need to be updated
when the prefixes or topologies of subnets change. If rules updates
are not conducted in time, resulting in the discrepancy between ACL
configurations and routing status, ACL-based ingress filtering will
cause improper block problems or improper permit problems. However,
high operational overhead will be induced to achieve timely updates
of ACL configurations.
Strict uRPF can also be used for outbound traffic validation, but
there are improper block problems in the multi-homing scenario.
Figure 2 shows the intra-domain scenario of a multi-homed subnet. In
the figure, Subnet 1 owns prefix 10.0.0.0/15 and is attached to two
edge routers, i.e., Router 1 and Router 2. For the load balance
purposes of inbound traffic, Subnet 1 expects the inbound traffic
Li, et al. Expires 27 August 2023 [Page 6]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
destined for 10.1.0.0/16 to come only from Router 1 and the inbound
traffic destined for 10.0.0.0/16 to come only from Router 2. To this
end, Router 1 only learns the route to sub prefix 10.1.0.0/16 from
Subnet 1, while Router 2 only learns the route to the other sub
prefix 10.0.0.0/16 from Subnet 1. Then, Router 1 and Router 2
advertise the learned sub prefix to the other routers in the AS
through intra-domain routing protocols such as OSPF or IS-IS.
Finally, Router 1 learns the route to 10.0.0.0/16 from Router 3, and
Router 2 learns the route to 10.1.0.0/16 from Router 3. The FIBs on
Router 1 and Router 2 are shown in the figure. Although Subnet 1
only expects inbound traffic destined for 10.0.0.0/16 to come from
Router 2, it may send outbound traffic with source addresses of
prefix 10.0.0.0/16 to Router 1 for outbound traffic load balancing.
Similarly, Subnet 1 may send outbound traffic with source addresses
of prefix 10.1.0.0/16 to Router 2. As a result, asymmetric routing
is created.
+-------------------------------------------------------------+
| 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 / \/ 10.1.0.0/16 Router 3 |
| +----------+ +----------+ |
| | Router 1 | | Router 2 | |
| +-----+#+--+ +-+#+------+ |
| /\ / |
| Outbound traffic with \ / Inbound traffic with |
| source IP addresses \ / destination IP addresses |
| of 10.0.0.0/16 \ \/ of 10.0.0.0/16 |
| Subnet 1 |
| (10.0.0.0/15 ) |
| |
+-------------------------------------------------------------+
Figure 2: Asymmetric routing in the multi-homed subnet scenario
Li, et al. Expires 27 August 2023 [Page 7]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
Strict uRPF takes the entries in FIB for SAV. It can improperly
block the packets with legitimate source prefixes when asymmetric
routing exists. In the figure, if Router 1 applies strict uRPF at
interface '#', the SAV rule is that Router 1 only accepts packets
with source addresses of 10.1.0.0/16 from Subnet 1. Therefore, when
Subnet 1 sends packets with source addresses of 10.0.0.0/16 to Router
1, strict uRPF at Router 1 will improperly block these legitimate
packets. Similarly, when Router 2 with strict uRPF deployed receives
packets with source addresses of prefix 10.1.0.0/16 from Subnet 1, it
will also improperly block these legitimate packets. So, under
asymmetric routing, strict uRPF cannot be applied directly.
4.2. Inbound Traffic Validation
Inbound traffic validation is performed at upstream interfaces of
routers to validate the packets from other networks or the Internet.
Figure 3 shows an example of inbound SAV. In the figure, Router 3
and Router 4 deploy SAV mechanisms at interface '#' for validating
external packets. That is, there are multiple points for inbound
traffic validation.
ACL-based ingress filtering is usually used for validating inbound
traffic. By configuring specified ACL rules, disallowed source
prefixes, such as non-global addresses and the internal source
prefixes, can be blocked. As analyzed previously, ACL-based ingress
filtering requires timely updates especially for possibly dynamic
internal source prefixes. When the rules are not updated in time,
there may be improper block or improper permit problems. The ACL
rules on routers for diversified purposes (not only for filtering)
also induce operation challenges. Besides, the operational overhead
will increase significantly when there are multiple inbound
validation points as shown in Figure 3.
Source-based RTBH filtering improves the automation of installing SAV
rules on multiple edge routers. However, the configurations on the
trigger router still needs to be updated in time, which is similar to
ACL-based ingress filtering. Otherwise, there will be improper block
problems.
Loose uRPF considers FIB as a SAV table. It is more adaptive than
ACL-based ingress filtering. However, loose uRPF has limited
blocking capability, e.g., cannot "generate" SAV rules for blocking
internal prefixes. Some source address spoofing packets may be
improperly permitted.
Li, et al. Expires 27 August 2023 [Page 8]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
+ Packets with + Packets with
| spoofed p1/p2 | spoofed p1/p2
+--------------|---------------------------|----------+
| AS \/ \/ |
| +--+#+-----+ +---+#+----+ |
| | Router 3 +-------------->| Router 4 | |
| +----------+ +----------+ |
| / \ | |
| / \ | |
| \/ \/ \/ |
| +----------+ +----------+ +----------+ |
| | Router 1 | | Router 2 | | Router 5 | |
| +----------+ +----------+ +----------+ |
| \ / | |
| \ / | |
| \ / \/ |
| Subnet1(p1) Subnet2(p2) |
+-----------------------------------------------------+
Figure 3: A scenario of inbound SAV
5. Problem Statement
Accurate validation and low operational overhead are two important
design goals of intra-domain SAV mechanisms. As analyzed above,
asymmetric routing and dynamic networks are two challenging scenarios
for the two goals. In these scenarios, existing SAV mechanisms have
problems of inaccurate validation and high operational overhead.
ACL-based ingress filtering relies on configurations and thus faces
limitations in efficiency and accuracy in dynamic networks. The
limitations mainly come from the lack of automation. Operators have
to update the ACL-based filtering rules in time when the subnet's
prefix or topology changes. Otherwise, improper block or improper
permit problems may appear. Source-based RTBH filtering has the
similar gap to ACL-based ingress filtering.
Strict uRPF-based ingress filtering automatically generates SAV
tables, but may improperly block legitimate traffic under asymmetric
routing. The root cause is that strict uRPF leverages the local FIB
table to determine the incoming interface for source addresses, which
may not match the real data-plane forwarding path from the source,
due to the existence of asymmetric routes. Hence, it may mistakenly
consider a valid incoming interface as invalid, resulting in improper
block problems; or it may consider an invalid incoming interface as
valid, resulting in improper permit problems.
Li, et al. Expires 27 August 2023 [Page 9]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
Loose uRPF is also an automated mechanism, but it has improper permit
problems. The limitation comes from that the validation of loose
uRPF depends on FIB, and FIB is not enough for achieving accurate
validation.
Existing intra-domain SAV mechanisms are lacking in adaptiveness in
dynamic or asymmetric routing scenarios. If network operators want
to apply intra-domain SAV and avoid improper block, they have to
figure out which edge routers have asymmetric routing to the directly
connected subnet, and implement ACL-based ingress filtering at those
edge routers instead of strict uRPF. Identifying asymmetric routes
also imposes operational overhead on network operators.
6. Requirements for New SAV Mechanisms
This section lists the requirements which can be a guidance for
narrowing the gaps. The requirements are some practical points that
can be fully or partially fulfilled by proposing new mechanisms.
6.1. Accurate Validation
The new intra-domain SAV mechanism needs to improve the accuracy upon
existing intra-domain SAV mechanisms. It SHOULD be able to learn the
real incoming interfaces for packets originated from the subnet which
owns the corresponding source prefix. In other words, accurate SAV
SHOULD match the real data-plane forwarding path from the source and
adapt to routing changes automatically. Specially, in the case of
asymmetric routing, it MUST avoid improper block problems of strict
uRPF and have no more improper permit problems than existing uRPF-
based mechanisms (e.g., strict uRPF and loose uRPF).
There are cases where it is impossible or hard to guarantee that
every learned path is a real forwarding path. In such cases, the
learned paths MUST cover the real forwarding paths so as to avoid
improper block. By finding the least number of paths while covering
all the real forwarding paths, improper permit can be minimized.
6.2. Automatic Update
The new intra-domain SAV mechanism MUST be able to adapt to dynamic
scenarios automatically, instead of entirely relying on manual
update. At least, it MUST require less operational overhead than
existing ACL-based ingress filtering.
Li, et al. Expires 27 August 2023 [Page 10]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
6.3. Working in Incremental/Partial Deployment
The new intra-domain SAV mechanism SHOULD NOT assume pervasive
adoption. Some routers may not be able to be easily upgraded for
supporting the new SAV mechanism due to their limitations of
capabilities, versions, or vendors. The mechanism SHOULD be able to
provide protection even when it is partially deployed. The
effectiveness of protection under partial deployment SHOULD be no
worse than automated SAV mechanisms of strict uRPF and loose uRPF.
7. Intra-domain SAV Scope
The new intra-domain SAV mechanism should work in the same scenarios
as existing intra-domain SAV mechanisms. Generally, it includes all
IP-encapsulated scenarios:
* Native IP forwarding: including both global routing table
forwarding and CE site forwarding of VPN.
* IP-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): focusing on the
validation of the outer layer IP address.
* Both IPv4 and IPv6 addresses.
Scope does not include:
* Non-IP packets: including MPLS label-based forwarding and other
non-IP-based forwarding.
In addition, the new intra-domain SAV mechanism should avoid data-
plane packet modification. Existing architectures or protocols or
mechanisms can be used in the new SAV mechanism to achieve better SAV
function.
8. Security Considerations
The new intra-domain SAV mechanism MUST NOT introduce additional
security vulnerabilities or confusion to the existing intra-domain
architectures or control or management plane protocols. Similar to
the security scope of intra-domain routing protocols, intra-domain
SAV mechanism should ensure integrity and authentication of protocol
packets that deliver the required SAV information.
The new intra-domain SAV mechanism does not provide protection
against compromised or misconfigured routers that poison existing
control plane protocols. Such routers can not only disrupt the SAV
function, but also affect the entire routing domain.
Li, et al. Expires 27 August 2023 [Page 11]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
9. IANA Considerations
This document does not request any IANA allocations.
10. Acknowledgements
Many thanks to the valuable comments from: Jared Mauch, Barry Greene,
Fang Gao, Anthony Somerset, Kotikalapudi Sriram, 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, etc.
11. References
11.1. Normative References
[inter-domain]
"Source Address Validation in Inter-domain Networks Gap
Analysis, Problem Statement, and Requirements", 2023,
<https://datatracker.ietf.org/doc/draft-wu-savnet-inter-
domain-problem-statement/>.
[manrs-antispoofing]
MANRS, "MANRS Implementation Guide", 2023,
<https://www.manrs.org/netops/guide/antispoofing/>.
[nist-rec] Sriram, K. and D. Montgomery, "Resilient Interdomain
Traffic Exchange: BGP Security and DDos Mitigation", 2019,
<https://www.nist.gov/publications/resilient-interdomain-
traffic-exchange-bgp-security-and-ddos-mitigation>.
[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>.
[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 27 August 2023 [Page 12]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
[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>.
[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>.
11.2. Informative References
[cable-verify]
Cisco, "Cable Source-Verify and IP Address Security",
2021, <https://www.cisco.com/c/en/us/support/docs/
broadband-cable/cable-security/20691-source-verify.html>.
[IPSG] Cisco, "Configuring DHCP Features and IP Source Guard",
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>.
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
Validation Improvement (SAVI) Solution for DHCP",
RFC 7513, DOI 10.17487/RFC7513, May 2015,
<https://www.rfc-editor.org/info/rfc7513>.
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Li, et al. Expires 27 August 2023 [Page 13]
Internet-Draft Intra-domain SAVNET Problem Statement February 2023
Lancheng Qin
Tsinghua University
Beijing
China
Email: qlc19@mails.tsinghua.edu.cn
Mingqing Huang
Huawei
Beijing
China
Email: huangmingqing@huawei.com
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Li, et al. Expires 27 August 2023 [Page 14]