Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements
draft-ietf-savnet-intra-domain-problem-statement-08
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 "Active".
|
|
|---|---|---|---|
| Authors | Dan Li , Jianping Wu , Lancheng Qin , Mingqing(Michael) Huang , Nan Geng | ||
| Last updated | 2024-12-26 (Latest revision 2024-11-21) | ||
| Replaces | draft-li-savnet-intra-domain-problem-statement | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART IETF Last Call review
(of
-10)
by Tim Evens
On the right track
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Xueyan Song | ||
| Shepherd write-up | Show Last changed 2024-12-02 | ||
| IESG | IESG state | AD Evaluation::Revised I-D Needed | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Jim Guichard | ||
| Send notices to | song.xueyan2@zte.com.cn |
draft-ietf-savnet-intra-domain-problem-statement-08
SAVNET D. Li
Internet-Draft J. Wu
Intended status: Informational Tsinghua University
Expires: 25 May 2025 L. Qin
M. Huang
Zhongguancun Laboratory
N. Geng
Huawei
21 November 2024
Source Address Validation in Intra-domain Networks Gap Analysis, Problem
Statement, and Requirements
draft-ietf-savnet-intra-domain-problem-statement-08
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 25 May 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 25 May 2025 [Page 1]
Internet-Draft Intra-domain SAVNET Problem Statement November 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 . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 5
3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. SAV on Host-facing or Customer-facing Routers . . . . . . 7
3.1.1. Asymmetric Routing . . . . . . . . . . . . . . . . . 7
3.1.2. Hidden Prefix . . . . . . . . . . . . . . . . . . . . 9
3.2. SAV on AS Border Routers . . . . . . . . . . . . . . . . 11
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 12
5. Requirements for New SAV Mechanisms . . . . . . . . . . . . . 13
5.1. Automatic Update . . . . . . . . . . . . . . . . . . . . 13
5.2. Accurate Validation . . . . . . . . . . . . . . . . . . . 13
5.3. Working in Incremental/Partial Deployment . . . . . . . . 13
5.4. Fast Convergence . . . . . . . . . . . . . . . . . . . . 13
5.5. Necessary Security Guarantee . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Source Address Validation (SAV) is important for defending against
source address spoofing attacks. A multi-fence architecture called
Source Address Validation Architecture (SAVA) [RFC5210] was proposed
to implement SAV at three levels: access network SAV, intra-domain
SAV, and inter-domain SAV. When SAV has not been adopted by every
source/host, the multi-fence architecture helps enhance the
effectiveness of SAV across the whole Internet by preventing or
mitigating source address spoofing.
Specifically, access network SAV can ensure that a host must use the
source IP address assigned to the host. By deploying access network
SAV, hosts in the corresponding access network cannot forge a 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
Li, et al. Expires 25 May 2025 [Page 2]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
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 valid source 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 a packet from a host, the device can check the
validity of source IP address according to the bindings.
Given numerous access networks managed by different operators
throughout the world, it is difficult to require all access networks
to deploy SAV simultaneously. Therefore, intra-domain SAV and inter-
domain SAV are needed to block source-spoofed data packets from
access networks as close to the source as possible. Intra-domain SAV
and inter-domain SAV perform SAV at the granularity of IP prefixes,
which is coarser than the granularity of access network SAV (i.e., IP
address), 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. Intra-domain 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 the rest of
the Internet. Intra-domain SAV for AS X aims at achieving two goals
without collaboration with other ASes: i) blocking source-spoofed
packets originated from its host networks or customer networks using
a source address of other networks; and ii) blocking source-spoofed
packets coming from other ASes using a source address of AS X.
Figure 1 illustrates the goals and function of intra-domain SAV with
two cases. Case i shows that the host network or customer network of
AS X originates source-spoofed packets using a source address of
other networks. If AS X deploys intra-domain SAV, the spoofed
packets can be blocked by host-facing routers or customer-facing
routers of AS X (i.e., Goal i). Case ii shows that AS X receives
source-spoofed packets using a source address of AS X 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 border routers of AS X (i.e., Goal
ii).
Li, et al. Expires 25 May 2025 [Page 3]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
Case i: The host network or customer network of AS X originates
packets spoofing source addresses of other networks
Goal i: If AS X deploys intra-domain SAV,
the spoofed packets can be blocked by AS X
Spoofed packets
using source addresses
+-------------------------------+ of other networks +------+
| Host/Customer Network of AS X |---------------------->| AS X |
+-------------------------------+ +------+
Case ii: AS X receives packets spoofing source addresses of AS X
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
using source addresses
+------+ of AS X +------+
| AS X |<----------------------| AS Y |
+------+ +------+
Figure 1: An example for illustrating intra-domain SAV
The scope of intra-domain SAV 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.
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 intra-domain SAV mechanisms and describes the
requirements for future ones.
Li, et al. Expires 25 May 2025 [Page 4]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
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.
Host-facing Router: An intra-domain router facing an intra-domain
host network.
Customer-facing Router: An intra-domain router facing an intra-domain
customer network.
AS Border Router: An intra-domain router facing an external AS.
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
This section briefly introduces existing intra-domain SAV mechanisms.
Particularly, ingress filtering (i.e., BCP38 [RFC2827] and BCP84
[RFC3704]) is the best current practice for intra-domain SAV.
* ACL-based ingress filtering [RFC2827] is a typical mechanism for
intra-domain SAV. It requires that network operators manually
configure ACL rules on intra-domain routers to block or permit
data packets using specific source addresses. This mechanism can
be used on interfaces of host-facing or customer-facing routers
facing an intra-domain host/customer network to prevent the
corresponding host/customer network from spoofing source prefixes
of other networks [manrs-antispoofing]. 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
Li, et al. Expires 25 May 2025 [Page 5]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
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 another typical intra-domain SAV
mechanism. It is typically used on interfaces of host-facing or
customer-facing routers facing an intra-domain host/customer
network. Routers deploying strict uRPF accept a data packet only
when i) the local 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 pretty looser validation method which
loses the directionality. 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].
* Carrier Grade NAT has some operations on the source addresses of
packets, but it 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 determine
whether the source address is spoofed or not. In addition, the
packet using a spoofed source address will still be forwarded if
the spoofed source address is not included in the INSIDE access
list. Therefore, Carrier Grade NAT cannot help identify and block
source-spoofed data packets.
3. Gap Analysis
Towards the two goals of intra-domain SAV in Figure 1, intra-domain
SAV is commonly deployed on host-facing routers, customer-facing
routers, and AS border routers. This section elaborates the key
problems of SAV on host-facing or customer-facing routers and SAV on
AS border routers, respectively. Since existing intra-domain SAV
mechanisms either require high operational overhead or have
limitations in accuracy, they will improperly block data packets
using a legitimate source address (i.e., improper block) or
improperly permit data packets using a spoofed source address (i.e.,
improper permit).
Li, et al. Expires 25 May 2025 [Page 6]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
3.1. SAV on Host-facing or Customer-facing Routers
Towards Goal i in Figure 1, intra-domain SAV is typically deployed on
interfaces of host-facing or customer-facing routers facing an intra-
domain host/customer network to validate data packets originated from
that network, since SAV is more effective when deployed closer to the
source.
As described previously, ACL rules can be configured on such
interfaces for ingress filtering. These 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 also be used for SAV on host-facing or customer-
facing routers. It 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
Figure 2 shows asymmetric routing in a multi-homing scenario. In the
figure, Network 1 is a host/customer network of the AS. It owns
prefix 2001:db8::/32 [RFC6890] and is attached to two intra-domain
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 2001:db8:8000::/33 to come only
from Router 1 and the incoming traffic destined for the other sub-
prefix 2001:db8::/33 to come only from Router 2. To this end, Router
1 only learns the route to sub-prefix 2001:db8:8000::/33 from Network
1, while Router 2 only learns the route to the other sub-prefix
2001:db8::/33 from Network 1. Then, Router 1 and Router 2 distribute
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 2001:db8::/33 from Router 3, and Router 2 learns the
route to 2001:db8:8000::/33 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 2001:db8::/33 to come from Router 1, it may send
traffic with source addresses of prefix 2001:db8::/33 to Router 1 for
load balance of traffic originated 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 flowing direction of
traffic. Similarly, Network 1 may also send traffic with source
addresses of prefix 2001:db8:8000::/33 to Router 2, resulting in
asymmetric routing between Network 1 and Router 2. In addition to
the traffic engineering mentioned above, other factors may also cause
Li, et al. Expires 25 May 2025 [Page 7]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
similar asymmetric routing between host-facing/customer-facing
routers and host/customer networks.
+---------------------------------------------------------+
| AS |
| +----------+ |
| | Router 3 | |
| +----------+ |
| / \ |
| / \ |
| / \ |
| +----------+ +----------+ |
| | Router 1 | | Router 2 | |
| +-----+#+--+ +-+#+------+ |
| /\ / |
|Traffic with \ / Traffic with |
|source IP addresses \ / destination IP addresses|
|of 2001:db8::/33 \ \/ of 2001:db8::/33 |
| +----------------+ |
| | Host/Customer | |
| | Network 1 | |
| |(2001:db8::/32) | |
| +----------------+ |
| |
+---------------------------------------------------------+
FIB of Router 1 FIB of Router 2
Dest Next_hop Dest Next_hop
2001:db8:8000::/33 Network 1 2001:db8:8000::/33 Router 3
2001:db8::/33 Router 3 2001:db8::/33 Network 1
The legitimate traffic originated from Network 1 with source IP
addresses of 2001:db8::/33 will be improperly blocked by Router 1
if Router 1 uses strict uRPF.
Figure 2: Asymmetric routing in multi-homing scenario
Li, et al. Expires 25 May 2025 [Page 8]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
Strict uRPF takes the entries in FIB for SAV. It will improperly
block data packets which use legitimate source addresses when
asymmetric routing exists. In the figure, if Router 1 uses strict
uRPF on interface '#', the SAV rule is that Router 1 only accepts
packets with source addresses of 2001:db8:8000::/33 from Network 1.
Therefore, when Network 1 sends packets with source addresses of
2001:db8::/33 to Router 1, strict uRPF at Router 1 will improperly
block these legitimate packets. Similarly, when Router 2 uses strict
uRPF on its interface '#' and receives packets with source addresses
of prefix 2001:db8:8000::/33 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 addresses of prefix
2001:db8::/33.
3.1.2. Hidden Prefix
For special business purposes, a host/customer network will originate
data packets using a source address that is not distributed through
intra-domain routing protocol. In other words, the IP address/prefix
is hidden from intra-domain routing protocol and intra-domain
routers. In this scenario, strict uRPF on host-facing or customer-
facing routers will improperly block data packets from the host/
customer network using source addresses in a hidden prefix.
Li, et al. Expires 25 May 2025 [Page 9]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
+-------------------------+
| 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/Customer | |
| | Network 2 | |
| | (P2) | |
| +---------------+ |
| (where the edge server is located) |
+---------------------------------------+
DSR response packets from edge server in Network 2 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
The Content Delivery Networks (CDN) and Direct Server Return (DSR)
scenario is a representative example of hidden prefix. In this
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 intra-domain routing protocol and intra-domain routers in
the local AS. While this is an inter-domain scenario, we note that
DSR response packets may also be improperly blocked by strict uRPF
when edge server is located in the host/customer network. For
example, in Figure 3, assume edge server is located in Host/Customer
Li, et al. Expires 25 May 2025 [Page 10]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
Network 2 and Router 5 only learns the route to P2 from Network 2.
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 uses strict uRPF on
interface '#', the SAV rule is that Router 5 only accepts packets
with source addresses of P2 from Network 2. As a result, DSR
response packets will be blocked by strict uRPF on interface '#'. In
addition, loose uRPF on this interface will also improperly block DSR
response packets if prefix P3 is not in the FIB of Router 5.
3.2. 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.
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
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 internal source
Li, et al. Expires 25 May 2025 [Page 11]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
addresses) can be blocked at AS border routers. As mentioned above,
ACL-based ingress filtering requires manual updates when internal
source prefixes change dynamically. If 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 4.
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 on all router interfaces.
4. Problem Statement
Accurate validation and low operational overhead are two important
design goals of intra-domain SAV mechanisms. However, as analyzed
above, existing intra-domain SAV mechanisms have problems of
inaccurate validation or high operational overhead.
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. The root cause is that strict uRPF uses the
router's local FIB to determine the valid incoming interface for a
specific source address, which may not match the real incoming
direction 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 mistakenly
consider an invalid incoming interface as valid, resulting in
improper permit problems.
Loose uRPF is also an automated SAV mechanism but its SAV rules are
overly loose. Most spoofed packets will be improperly permitted by
loose uRPF.
Li, et al. Expires 25 May 2025 [Page 12]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
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. 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.
5.1. Automatic Update
The new intra-domain SAV mechanism MUST be able to automatically
adapt to network dynamics such as routing changes or prefix changes,
instead of purely relying on manual update.
5.2. Accurate Validation
The new intra-domain SAV mechanism need 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 validation.
5.3. Working in Incremental/Partial Deployment
The new intra-domain SAV mechanism SHOULD NOT assume pervasive
adoption, and some routers that intend to adopt the new mechanism may
not be able to be upgraded immediately. The new intra-domain SAV
mechanism SHOULD be able to provide incremental protection when it is
incrementally deployed. The effectiveness of the new intra-domain
SAV mechanism under incremental deployment SHOULD be no worse than
existing ones.
5.4. Fast Convergence
The new intra-domain SAV mechanism MUST adapt to prefix changes,
route changes, and topology changes in an intra-domain network, and
update SAV rules in a timely manner. In addition, it MUST consider
how to update SAV rules proactively or reactively so as to minimize
improper blocks during convergence.
Li, et al. Expires 25 May 2025 [Page 13]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
5.5. Necessary Security Guarantee
Necessary security tools SHOULD be considered in the new intra-domain
SAV mechanism. These security tools can help protect the SAV rule
generation process. Section 6 details the security scope and
considerations for the new intra-domain SAV mechanism.
6. Security Considerations
The new intra-domain SAV mechanisms should 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 messages that deliver the required SAV
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 solutions 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, etc.
9. References
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>.
Li, et al. Expires 25 May 2025 [Page 14]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
[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>.
[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>.
Li, et al. Expires 25 May 2025 [Page 15]
Internet-Draft Intra-domain SAVNET Problem Statement November 2024
[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">.
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
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 25 May 2025 [Page 16]