SAVNET D. Li
Internet-Draft J. Wu
Intended status: Informational Tsinghua University
Expires: 6 February 2025 L. Qin
M. Huang
Zhongguancun Laboratory
N. Geng
Huawei
5 August 2024
Source Address Validation in Intra-domain Networks Gap Analysis, Problem
Statement, and Requirements
draft-ietf-savnet-intra-domain-problem-statement-05
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.
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 6 February 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
Li, et al. Expires 6 February 2025 [Page 1]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
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 Mechanisms . . . . . . . . . . . . . . . . . . . . . 5
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. SAV on Host-facing or Customer-facing Routers . . . . . . 6
3.2. SAV on AS Border Routers . . . . . . . . . . . . . . . . 8
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
5. Requirements for New SAV Mechanisms . . . . . . . . . . . . . 10
5.1. Automatic Update . . . . . . . . . . . . . . . . . . . . 10
5.2. Accurate Validation . . . . . . . . . . . . . . . . . . . 10
5.3. Working in Incremental/Partial Deployment . . . . . . . . 10
5.4. Fast Convergence . . . . . . . . . . . . . . . . . . . . 11
5.5. Necessary Security Guarantee . . . . . . . . . . . . . . 11
6. Intra-domain SAV Scope . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.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.
Particularly, access network SAV ensures that a host uses a valid
address assigned to the host statically or dynamically. In this way,
the host cannot use the source address of another host. There are
many mechanisms for SAV in access networks. Static ACL rules can be
manually configured for validation by specifying which source
addresses are acceptable or unacceptable. Dynamic ACL is another
efficient mechanism which is associated with authentication servers
Li, et al. Expires 6 February 2025 [Page 2]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
(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
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, intra-domain SAV and inter-
domain SAV are needed to block spoofing traffic as close to the
source as possible. Both intra-domain SAV and inter-domain SAV
usually perform validation at the granularity of IP prefixes, which
is coarser than the validation granularity of access network SAV, as
an IP prefix 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 different ASes. The SAV rules can be generated
by the AS itself. Consider an AS X which provides its host networks
or customer networks with the connectivity to other ASes. The intra-
domain SAV for AS X has two goals: i) blocking the illegitimate
packets originating from its host networks or customer networks with
spoofed source addresses; and ii) blocking the illegitimate packets
coming from other ASes which spoof the source addresses of AS X.
Figure 1 illustrates the function of intra-domain SAV with two cases.
Case i shows that AS X forwards source-spoofed packets originating
from its host networks or customer networks to other ASes (e.g., AS
Y). If AS X deploys intra-domain SAV, the source-spoofed packets
from its host networks or customer networks can be blocked by AS X
itself (i.e., Goal i). Case ii shows that AS X receives the packets
which spoof AS X's source addresses from other ASes (e.g., AS Y). If
AS X deploys intra-domain SAV, the spoofed packets from AS Y can be
blocked by AS X (i.e., Goal ii).
Li, et al. Expires 6 February 2025 [Page 3]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
Case i: AS X forwards spoofed packets originating from its
host networks or customer networks to other ASes (e.g., AS Y)
Goal i: If AS X deploys intra-domain SAV,
the spoofed packets can be blocked by AS X
+------+ Spoofed packets +------+
| AS X |------------------>| AS Y |
+------+ +------+
Case ii: AS X receives packets spoofing
AS X's source addresses from other ASes (e.g., AS Y)
Goal ii: If AS X deploys intra-domain SAV,
the spoofed packets can be blocked by AS X
+------+ Spoofed packets +------+
| AS X |<------------------| AS Y |
+------+ +------+
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.
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 and is
inferred from the SAV Information Base.
SAV Table: The table or data structure that implements the SAV rules
and is used for source address validation in the data plane.
Host-facing Router: An intra-domain router of an AS which is
connected to a host network (i.e., a layer-2 network).
Customer-facing Router: An intra-domain router of an AS which is
connected to a customer network running the routing protocol (i.e., a
layer-3 network).
AS Border Router: An intra-domain router of an AS which is connected
to other ASes.
Li, et al. Expires 6 February 2025 [Page 4]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
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.
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 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
blocking or permitting packets with specific source addresses.
This mechanism can be applied at the downstream interfaces of
host-facing routers or customer-facing routers
[manrs-antispoofing]. The validation at downstream interfaces
will prevent the corresponding host networks or customer networks
from spoofing source prefixes of other networks. In addition, at
the upstream interfaces of AS border routers, ACL can be enabled
for blocking packets with disallowed source prefixes, such as the
internal source prefixes owned by the AS [nist-rec]. In any
application scenario, ACL rules should be updated in time to be
consistent with the latest filtering criteria.
* Strict uRPF [RFC3704] is another commonly used mechanism for SAV
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 in the FIB matches the packet's
incoming interface. Otherwise, the packet will be blocked.
Strict uRPF is usually used at downstream interfaces of host-
facing routers or customer-facing routers.
* Loose uRPF [RFC3704] takes a looser validation mechanism than
strict uRPF to avoid improper block. A packet will be accepted if
the local FIB contains a prefix encompassing the packet's source
Li, et al. Expires 6 February 2025 [Page 5]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
address regardless of the interface from which the packet is
received. Upstream interfaces of AS border routers can enable
loose uRPF for blocking non-global addresses [nist-rec].
* 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. In addition, 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 are still needed.
3. Gap Analysis
Existing intra-domain SAV mechanisms either require high operational
overhead or have limitations in accuracy. They 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).
3.1. SAV on Host-facing or Customer-facing Routers
Towards the Goal i in Figure 1, intra-domain SAV is typically adopted
at downstream interfaces of host-facing or customer-facing routers to
validate packets from intra-domain host networks or customer
networks, since it is most effective closer to the edges of the
Internet. As described previously, ACL rules can be configured at
downstream interfaces for ingress filtering. These rules need to be
updated when prefixes or topologies of host networks or customer
networks change. If ACL rules are not updated in time, improper
block or improper permit may occur. To ensure the accuracy of SAV in
dynamic networks, high operational overhead will be induced to
achieve timely updates for ACL configurations.
Strict uRPF can also be used for SAV on host-facing or customer-
facing routers, but there may be improper block problem in multi-
homing and asymmetric routing scenario. Figure 2 shows such a case.
In the figure, Network 1 is a host/customer network of the AS. It
owns prefix 192.0.2.0/24 [RFC6890] and is attached to two intra-
domain edge routers, i.e., Router 1 and Router 2. For the load
balance purpose of traffic flowing to Network 1, Network 1 expects
the incoming traffic destined for the sub-prefix 192.0.2.128/25 to
come only from Router 1 and the incoming traffic destined for the
other sub-prefix 192.0.2.0/25 to come only from Router 2. To this
end, Router 1 only learns the route to sub-prefix 192.0.2.128/25 from
Li, et al. Expires 6 February 2025 [Page 6]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
Network 1, while Router 2 only learns the route to the other sub-
prefix 192.0.2.0/25 from Network 1. Then, Router 1 and Router 2
advertise the sub-prefix information to routers in the AS through
intra-domain routing protocols such as OSPF or IS-IS. Finally,
Router 1 learns the route to 192.0.2.0/25 from Router 3, and Router 2
learns the route to 192.0.2.128/25 from Router 3. The FIBs of Router
1 and Router 2 are shown in the figure. Although Network 1 does not
expect traffic destined for 192.0.2.0/25 to come from Router 1, it
may send traffic with source addresses of prefix 192.0.2.0/25 to
Router 1 for load balance of traffic originating from Network 1. As
a result, there is asymmetric routing of data packets between Network
1 and Router 1. Arrows in the figure indicate the direction of
traffic. Similarly, Network 1 may also send traffic with source
addresses of prefix 192.0.2.128/25 to Router 2, resulting in
asymmetric routing between Network 1 and Router 2.
+---------------------------------------------------------------+
| AS |
| +----------+ |
| | Router 3 | |
|FIB of Router 1 +----------+ FIB of Router 2 |
|Dest Next_hop / \ Dest Next_hop |
|192.0.2.128/25 Network 1 / \ 192.0.2.0/25 Network 1|
|192.0.2.0/25 Router 3 / \ 192.0.2.128/25 Router 3 |
| +----------+ +----------+ |
| | Router 1 | | Router 2 | |
| +-----+#+--+ +-+#+------+ |
| /\ / |
| Traffic with \ / Traffic with |
| source IP addresses \ / destination IP addresses |
| of 192.0.2.0/25 \ \/ of 192.0.2.0/25 |
| +----------------+ |
| | Host/Customer | |
| | Network 1 | |
| | (192.0.2.0/24) | |
| +----------------+ |
| |
+---------------------------------------------------------------+
The legitimate traffic originating from Network 1 with source IP
addresses of 192.0.2.0/25 will be improperly blocked by Router 1
if Router 1 uses strict uRPF.
Figure 2: Asymmetric routing in the multi-homing scenario
Strict uRPF takes the entries in FIB for SAV. It can improperly
block data packets that use legitimate source IP addresses when
asymmetric routing exists. In the figure, if Router 1 applies strict
Li, et al. Expires 6 February 2025 [Page 7]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
uRPF at interface '#', the SAV rule is that Router 1 only accepts
packets with source addresses of 192.0.2.128/25 from Network 1.
Therefore, when Network 1 sends packets with source addresses of
192.0.2.0/25 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
192.0.2.128/25 from Network 1, it will also improperly block these
legitimate packets because strict uRPF at Router 2 will only accept
packets from Network 1 using source addressses of prefix
192.0.2.0/25. Therefore, strict uRPF may cause improper block
problem in the case of asymmetric routing.
3.2. SAV on AS Border Routers
Towards the Goal ii in Figure 1, intra-domain SAV is typically
adopted at upstream interfaces of AS border routers to validate the
packets from other ASes. Figure 3 shows an example of SAV on AS
border routers. In the figure, Router 3 and Router 4 deploy SAV
mechanisms at interface '#' for validating data packets coming from
external ASes.
ACL-based ingress filtering is usually used for this purpose. By
configuring specified ACL rules, data packets that use disallowed
source addresses (e.g., non-global addresses or the internal source
prefixes) can be blocked at AS border routers. As mentioned above,
ACL-based ingress filtering requires timely updates when the routing
status changes dynamically. When the ACL rules are not updated in
time, there may be improper block or improper permit problems. 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 3.
In addition to ACL-based ingress filtering, loose uRPF is also often
used for SAV on AS border routers and is more adaptive than ACL-based
rules. But it sacrifices the directionality of SAV and has limited
blocking capability, because it allows packets with source addresses
that exist in the FIB table at all router interfaces.
Li, et al. Expires 6 February 2025 [Page 8]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
Packets with + Packets with +
spoofed P1/P2| spoofed P1/P2|
+-------------|---------------------------|---------+
| AS \/ \/ |
| +--+#+-----+ +---+#+----+ |
| | Router 3 +---------------+ Router 4 | |
| +----------+ +----+-----+ |
| / \ | |
| / \ | |
| / \ | |
| +----------+ +----------+ +----+-----+ |
| | Router 1 | | Router 2 | | Router 5 | |
| +----------+ +----------+ +----+-----+ |
| \ / | |
| \ / | |
| \ / | |
| +---------------+ +-------+-------+ |
| | Host | | Customer | |
| | Network | | Network | |
| | (P1) | | (P2) | |
| +---------------+ +---------------+ |
| |
+---------------------------------------------------+
Figure 3: An example of SAV on AS border routers
4. 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 or high operational overhead.
ACL-based SAV relies on manual configurations and thus requires high
operational overhead in dynamic networks. 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.
Li, et al. Expires 6 February 2025 [Page 9]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
Strict uRPF-based SAV can automatically update SAV rules, 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
problem; or it may consider an invalid incoming interface as valid,
resulting in improper permit problem.
Loose uRPF is also an automated SAV mechanism but its SAV rules are
overly loose. Most spoofed packets will be improperly permitted by
adopting loose uRPF.
5. Requirements for New SAV Mechanisms
This section lists the requirements which can be a guidance for
narrowing the gaps of existing intra-domain SAV mechanisms. The
requirements can be fully or partially fulfilled when designing new
intra-domain SAV mechanisms.
5.1. Automatic Update
The new intra-domain SAV mechanisms MUST be able to automatically
adapt to network dynamics such as routing change or prefix change,
instead of purely relying on manual update.
5.2. Accurate Validation
The new intra-domain SAV mechanisms needs to improve the validation
accuracy upon existing intra-domain SAV mechanisms. In a static
network, improper block MUST be avoided to guarantee that legitimate
traffic will not be blocked. Improper permit SHOULD be reduced as
much as possible so that the malicious packets with forged source
addresses can be efficiently filtered. When there are network
changes, the new mechanisms MUST update SAV rules efficiently for
keeping the high accuracy of validaiton.
5.3. Working in Incremental/Partial Deployment
The new intra-domain SAV mechanisms 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 mechanisms SHOULD be able to
provide protection even when it is partially deployed. The
effectiveness of protection for the new intra-domain SAV mechanisms
under partial deployment SHOULD be no worse than existing mechanisms.
Li, et al. Expires 6 February 2025 [Page 10]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
5.4. Fast Convergence
Network changes may cause SAV rules to be inaccurate and need to be
updated. The new intra-domain SAV mechanism MUST consider how to
update SAV rules quickly so as to minimize improper block and
improper permit impacts during convergence.
5.5. Necessary Security Guarantee
Necessary security tools SHOULD be contained in the new intra-domain
SAV mechanisms. In an insecure scenario, these security tools can
help protect the SAV rule generation process.
6. Intra-domain SAV Scope
The new intra-domain SAV mechanisms work in the same scenarios as
existing intra-domain SAV mechanisms. Generally, it includes all IP-
encapsulated scenarios:
* Native IP forwarding: including both forwarding based on global
routing table and CE site forwarding of VPN.
* IP-encapsulated Tunnel (IPsec, GRE, SRv6, etc.): focusing on the
validation of the outer layer IP address.
* Validating 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 mechanisms SHOULD avoid data-
plane packet modification. Existing architectures or protocols or
mechanisms can be used in the new SAV mechanisms to achieve better
SAV function.
7. Security Considerations
The new intra-domain SAV mechanisms 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 mechanisms SHOULD ensure integrity and authentication of protocol
packets that deliver the required SAV information.
Li, et al. Expires 6 February 2025 [Page 11]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
The new intra-domain SAV mechanisms do 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.
8. IANA Considerations
This document does not request any IANA allocations.
9. 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, etc.
10. References
10.1. Normative References
[manrs-antispoofing]
"MANRS Implementation Guide", January 2023,
<https://www.manrs.org/netops/guide/antispoofing>.
[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">.
[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>.
Li, et al. Expires 6 February 2025 [Page 12]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
[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>.
10.2. Informative References
[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>.
[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>.
[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>.
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Li, et al. Expires 6 February 2025 [Page 13]
Internet-Draft Intra-domain SAVNET Problem Statement August 2024
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Lancheng Qin
Zhongguancun Laboratory
Beijing
China
Email: qinlc@mail.zgclab.edu.cn
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 6 February 2025 [Page 14]