SAVNET D. Li
Internet-Draft Tsinghua University
Intended status: Informational N. Geng
Expires: 4 September 2025 Huawei
L. Qin
Zhongguancun Laboratory
3 March 2025
Source Prefix Advertisement for Intra-domain SAVNET
draft-li-savnet-source-prefix-advertisement-02
Abstract
The new intra-domain source address validation (SAV) mechanism
requires improving the accuracy (especially avoiding blocking
legitimate traffic) and supporting automatic update (see
[I-D.ietf-savnet-intra-domain-problem-statement]). To this end, this
document proposes an intra-domain SAV mechanism, called source prefix
advertisement (SPA) for intra-domain SAVNET (SPA-based SAVNET for
short), to advance the technology for intra-domain SAV. SPA-based
SAVNET allows routers in an intra-domain network to exchange SPA
information. By using SPA information and routing information,
intra-domain routers can determine more accurate SAV rules in an
automatic manner.
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 4 September 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 4 September 2025 [Page 1]
Internet-Draft SPA-based SAVNET March 2025
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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview of SPA-based SAVNET . . . . . . . . . . . . . . . . 3
3. SPA Information Generation . . . . . . . . . . . . . . . . . 4
4. SPA Information Communication . . . . . . . . . . . . . . . . 5
5. SAV Rule Generation . . . . . . . . . . . . . . . . . . . . . 5
6. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. SAV on Host-facing Routers, Customer-facing Routers, and AS
Border Routers . . . . . . . . . . . . . . . . . . . . . 6
6.2. A Special Scenario: Direct Server Return (DSR) . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The main purpose of intra-domain SAV for an AS is blocking spoofing
data packets from host networks and customer networks that use a
source address of other networks and blocking spoofing data packets
from external ASes that use a source address of the local AS (see
[I-D.ietf-savnet-intra-domain-problem-statement]). However, existing
uRPF mechanisms [RFC3704] will improperly block legitimate data
packets in the case of asymmetric forwarding or asymmetric routing,
while ACL-based ingress filtering relies entirely on manual update
(see [I-D.ietf-savnet-intra-domain-problem-statement]).
Li, et al. Expires 4 September 2025 [Page 2]
Internet-Draft SPA-based SAVNET March 2025
To improve the accuracy and enable automatic update, this document
proposes an intra-domain SAV mechanism, called source prefix
advertisement (SPA) for intra-domain SAVNET (SPA-based SAVNET for
short), to advance the technology for intra-domain SAV. SPA-based
SAVNET allows routers in an intra-domain network to exchange SPA
information. By using SPA information and routing information,
intra-domain routers can determine more accurate SAV rules in an
automatic manner.
The reader is encouraged to be familiar with
[I-D.ietf-savnet-intra-domain-problem-statement] and
[I-D.ietf-savnet-intra-domain-architecture].
1.1. Terminology
SAV Rule: The rule that describes the mapping relationship between a
source address (prefix) and its valid incoming router interface(s).
SAVNET Router: An intra-domain router that deploys SPA-based SAVNET.
Host Network: An intra-domain stub network consists of hosts.
Customer Network: An intra-domain stub network consists of hosts and
routers.
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.
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. Overview of SPA-based SAVNET
The deployment scope of SPA-based SAVNET for an AS includes host-
facing routers, customer-facing routers, and AS border routers. SPA-
based SAVNET allows these routers to exchange SPA information through
the existing internal gateway protocol (IGP). By learning SPA
information from other SAVNET routers, each SAVNET router can
generate an allowlist SAV rule (i.e., "Interface-based prefix
allowlist" mode in [I-D.huang-savnet-sav-table]) or a blocklist SAV
Li, et al. Expires 4 September 2025 [Page 3]
Internet-Draft SPA-based SAVNET March 2025
rule (i.e., "Interface-based prefix blocklist" mode in
[I-D.huang-savnet-sav-table]) on the specific router interface:
* For host-facing routers, they generate an allowlist SAV rule on
interfaces facing a host network. The allowlist SAV rule exactly
covers the space of source IP addresses that are used by data
packets of the host network.
* For customer-facing routers, they generate an allowlist SAV rule
on interfaces facing a customer network. The allowlist SAV rule
exactly covers the space of source IP addresses that are used by
data packets of the customer network.
* For AS border routers, they generate a blocklist SAV rule on
interfaces facing an external AS. The allowlist SAV rule exactly
covers the space of source IP addresses that are used by data
packets of the local AS.
SPA-based SAVNET provides incremental benefits when incrementally
deployed within the deployment scope. Every SAVNET router that
adopts SPA-based SAVNET can identify spoofing data packets coming
from a host network, customer network, or an AS. By using allowlist
SAV rules, host-facing routers and customer-facing routers that adopt
SPA-based SAVNET will block spoofing data packets from host networks
and customer networks that use a source address of other networks.
By using blocklist SAV rules, AS border routers that adopt SPA-based
SAVNET will block spoofing data packets from external ASes that use a
source address of the local AS.
In the following, this document describes the protocol-independent
designs for SPA-based SAVNET, include procedures for SPA information
generation (in Section 3), SPA information communication (in
Section 4), and SAV rule generation (in Section 5). SPA information
communication can be implemented by using an existing routing
protocol. Specific protocol designs or extensions for SPA
information communication are not in the scope of this document.
3. SPA Information Generation
Each SAVNET router connected to an intra-domain stub network (e.g., a
host network or a customer network) generates SPA information. The
content of SPA information mainly includes two parts:
* Source Prefix List (SPL): This list includes prefixes learned from
the router's local routes towards the stub network. Specifically,
each Dest Prefix in the router's RIB that has an outgoing
interface towards the stub network will be included. If there is
no asymmetric route between the SAVNET router and the stub
Li, et al. Expires 4 September 2025 [Page 4]
Internet-Draft SPA-based SAVNET March 2025
network, the generated SPL should cover the source IP address
space used by data packets of the stub network. However, if the
asymmetric route exists, the generated SPL may include only a
portion of the source IP address space of the stub network.
* Stub Network Identifier (SNI): This identifier indicates the
identity of a stub network. Every intra-domain stub network must
have a unique SNI value. Each prefix in the SPL is labeled with
the SNI value of the corresponding stub network.
4. SPA Information Communication
After generating SPA information, each SAVNET router will provide its
SPA information to other SAVNET routers. SPA information
communication can be implemented by using the IGP (e.g., OSPF, IS-IS,
or IBGP). During the propagation of IGP messages, SAVNET routers can
learn both routing information and SPA information.
5. SAV Rule Generation
After receiving SPA information from other SAVNET router, SAVNET
routers generate allowlist SAV rules or blocklist SAV rules on
specific router interfaces.
The detailed procedure for allowlist generation is as follows:
1. Considering all stub network connected to the router, create a
set of SNI values of these stub network. Call it Set A.
2. Considering all SPA information, for each SNI value in Set A,
create a set of unique source prefixes that have the same SNI
value. Include these prefixes into the allowlist SAV rule at
router interfaces facing the stub network which has the same SNI
value.
The detailed procedure for blocklist generation is as follows:
1. Extract unique prefixes from SPA information and routing
information learned from the IGP.
2. Include these prefixes into the blocklist SAV rule at router
interfaces facing an external AS.
6. Use Case
Li, et al. Expires 4 September 2025 [Page 5]
Internet-Draft SPA-based SAVNET March 2025
6.1. SAV on Host-facing Routers, Customer-facing Routers, and AS Border
Routers
SPA-based SAVNET is used on host-facing Routers, customer-facing
Routers, and AS border routers in an intra-domain network. It is a
general intra-domain SAV mechanism that apply to different network
topologies (e.g., mesh topology or tree topology) or routing
scenarios (e.g., asymmetric routing or symmetric routing). The
network operator can incrementally deploy SPA-based SAVNET in his/her
AS to gradually improve the defense against source address spoofing
attacks.
Figure 1 shows an example. Customer Network is multi-homed to
Routers A and B. Host Network is single-homed to Router C. Routers
D and E are connected to external ASes. Data packets from Customer
Network can use source addresses in prefixes P1 and P2. Data packets
from Host Network can use source addresses in prefix P3. P' is the
source IP address space for intra-domain router IPs and link IPs.
Assume there is an asymmetric forwarding behavior or an asymmetric
route between Router A, Router B, and Customer Network due to traffic
engineering and load balance. For example, Router A forwards only
data packets with destination addresses in prefix P1 to Customer
Network while forwards others to Router B. Router B forwards only
data packets with destination addresses in prefix P2 to Customer
Network while forwards others to Router A. However, Customer Network
will sends data packets with source addresses in prefixes P1 and P2
to both routers. In this case, as described in
[I-D.ietf-savnet-intra-domain-problem-statement], strict uRPF on
Router A's Interface # will improperly block data packets with source
addresses in prefix P2, and strict uRPF on Router A's Interface #
will improperly block data packets with source addresses in prefix
P2, and strict uRPF on Router B's Interface # will improperly block
data packets with source addresses in prefix P1.
Li, et al. Expires 4 September 2025 [Page 6]
Internet-Draft SPA-based SAVNET March 2025
+----------------------------------+
| Other ASes |
+----------------------------------+
| |
+--------------|-----------------------------|--------+
| AS | | |
| +-----#----+ +-----#----+ |
| | Router D | -----------------| Router E | |
| +----------+ +----------+ |
| | | |
| | | |
| | | |
| +----------+ +----------+ |
| | Router F | | Router G | |
| +----------+ +----------+ |
| / \ | |
| / \ | |
| / \ | |
| +----------+ +----------+ +----------+ |
| | Router A |---| Router B +----------+ Router C | |
| +----#-----+ +-------#--+ +-----#----+ |
| \ / | |
| \ / | |
| \ / | |
| +--------------+ +--------------+ |
| | Customer | | Host | |
| | Network | | Network | |
| | (P1 and P2) | | (P3) | |
| +--------------+ +--------------+ |
+-----------------------------------------------------+
SAV Rules generated by SPA-based SAVNET:
- Allowlist at Router A's Interface #: [P1, P2]
- Allowlist at Router B's Interface #: [P1, P2]
- Allowlist at Router C's Interface #: [P3]
- Blocklist at Router D's Interface #: [P1, P2, P3, P']
- Blocklist at Router E's Interface #: [P1, P2, P3, P']
Figure 1: An example of the most recommended use case of SPA-
based SAVNET
Li, et al. Expires 4 September 2025 [Page 7]
Internet-Draft SPA-based SAVNET March 2025
When deploying SPA-based SAVNET in this AS, SAVNET Routers A, B, and
C will provide SPA information to other SAVNET routers. By using the
received SPA information, Routers A and B will include both prefixes
P1 and P2 in the allowlist at the Interface #, because both prefixes
have the SNI value of Customer Network, even if the prefix that
routers A and B learn from the local route to Customer Network may be
different. Router C will include prefix P3 in the allowlist at its
Interface #. Routers D and E will include all internal prefixes in
the blocklist at their Interfaces #.
By using the generated allowlist SAV rules or blocklist SAV rules,
SPA-based SAVNET effectively blocks spoofing data packets from host
networks and customer networks that use a source address of other
networks and blocks spoofing data packets from external ASes that use
a source address of the local AS, while avoiding blocking legitimate
data packets.
6.2. A Special Scenario: Direct Server Return (DSR)
In the case of DSR, the content server in a stub network will send
data packets using source addresses of the anycast server in another
AS (see [I-D.ietf-savnet-intra-domain-problem-statement]). To avoid
blocking these special data packets, these specially used source
addresses must be added into the allowlist SAV rule at interfaces
facing a stub network where the content server locates. Since
routers as well as current routing architecture do not have this
information, this may requires manual configuration.
7. Security Considerations
The security considerations described in
[I-D.ietf-savnet-intra-domain-problem-statement] and
[I-D.ietf-savnet-intra-domain-architecture] also applies to this
document.
8. IANA Considerations
This document has no IANA actions.
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 4 September 2025 [Page 8]
Internet-Draft SPA-based SAVNET March 2025
[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>.
[I-D.huang-savnet-sav-table]
Huang, M., Cheng, W., Li, D., Geng, N., Liu, Chen, L., and
C. Lin, "General Source Address Validation Capabilities",
Work in Progress, Internet-Draft, draft-huang-savnet-sav-
table-08, 10 December 2024,
<https://datatracker.ietf.org/doc/html/draft-huang-savnet-
sav-table-08>.
[I-D.ietf-savnet-intra-domain-problem-statement]
Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source
Address Validation in Intra-domain Networks Gap Analysis,
Problem Statement, and Requirements", Work in Progress,
Internet-Draft, draft-ietf-savnet-intra-domain-problem-
statement-12, 21 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-problem-statement-12>.
[I-D.ietf-savnet-intra-domain-architecture]
Li, D., Wu, J., Qin, L., Geng, N., and L. Chen, "Intra-
domain Source Address Validation (SAVNET) Architecture",
Work in Progress, Internet-Draft, draft-ietf-savnet-intra-
domain-architecture-01, 14 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-architecture-01>.
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Li, et al. Expires 4 September 2025 [Page 9]
Internet-Draft SPA-based SAVNET March 2025
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Lancheng Qin
Zhongguancun Laboratory
Beijing
China
Email: qinlc@mail.zgclab.edu.cn
Li, et al. Expires 4 September 2025 [Page 10]