Source Prefix Advertisement for Intra-domain SAVNET
draft-li-savnet-source-prefix-advertisement-01
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.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dan Li , Nan Geng , Lancheng Qin | ||
| Last updated | 2024-10-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-savnet-source-prefix-advertisement-01
SAVNET D. Li
Internet-Draft Tsinghua University
Intended status: Standards Track N. Geng
Expires: 23 April 2025 Huawei
L. Qin
Zhongguancun Laboratory
20 October 2024
Source Prefix Advertisement for Intra-domain SAVNET
draft-li-savnet-source-prefix-advertisement-01
Abstract
This document proposes the Source Prefix Advertisement (SPA)
technology for intra-domain SAVNET, called SPA-based SAVNET. SPA-
based SAVNET allows routers in an intra-domain network to exchange
SAV-specific information through SPA messages. Compared with
existing intra-domain SAV mechanisms RFC2827 [RFC3704], SPA-based
SAVNET can generate more accurate and robust SAV rules on intra-
domain routers in an automatic way. This document introduces the
content of SPA messages and the process of generating SAV rules. SPA
messages can be transmitted by a new protocol or an extension to an
existing protocol. Protocol designs and extensions are not in the
scope of this document.
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 23 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 23 April 2025 [Page 1]
Internet-Draft SPA-based SAVNET October 2024
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 . . . . . . . . . . . . . . . . 4
3. Source Prefix Advertisement Procedure . . . . . . . . . . . . 4
3.1. SPA Message Generation . . . . . . . . . . . . . . . . . 4
3.2. SPA Message Communication . . . . . . . . . . . . . . . . 5
3.3. SAV Rule Generation . . . . . . . . . . . . . . . . . . . 6
4. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. The Most Recommended Use Case . . . . . . . . . . . . . . 7
4.2. An Alternative Use Case . . . . . . . . . . . . . . . . . 9
4.3. Two Corner Use Cases . . . . . . . . . . . . . . . . . . 9
4.3.1. Direct Server Return (DSR) . . . . . . . . . . . . . 9
4.3.2. Multi-homed Stub Network . . . . . . . . . . . . . . 9
5. Convergence Considerations . . . . . . . . . . . . . . . . . 10
6. Incremental Deployment Considerations . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The main purpose of the intra-domain SAV for an AS A, is to block
spoofing data packets from a host network or a customer network that
use source addresses of other networks, as well as block spoofing
data packets from other ASes that use source addresses of AS A (see
[I-D.ietf-savnet-intra-domain-problem-statement]). However, existing
intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84
[RFC3704]) have problems of high operational overhead or inaccurate
validation. Specifically, ACL-based ingress filtering (BCP38
[RFC2827]) requires manual operations to configure and update SAV
rules, and strict uRPF (BCP84 [RFC3704]) may improperly block
legitimate data packets in the scenario of routing asymmetry. To
improve the accuracy upon existing intra-domain SAV mechanisms and
Li, et al. Expires 23 April 2025 [Page 2]
Internet-Draft SPA-based SAVNET October 2024
enable automatic update, intra-domain SAVNET architecture requires
SAVNET routers to automatically generate SAV rules by using SAV-
specific information [I-D.ietf-savnet-intra-domain-architecture].
This document proposes the Source Prefix Advertisement (SPA)
technology for intra-domain SAVNET, called SPA-based SAVNET.
Following the intra-domain SAVNET architecture, SPA-based SAVNET
allows SAVNET routers in an intra-domain network to signal SAV-
specific information through SPA messages. By using SAV-specific
information, SAVNET routers can generate more accurate and robust SAV
rules in an automatic way. This document introduces the content of
SPA messages and the process of generating SAV rules. SPA messages
can be transmitted by a new protocol or an extension to an existing
protocol. Protocol designs and extensions are not in the scope of
this document.
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-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.
Single-homed Stub Network: A stub network that is belonging to or
connected to only one AS.
Multi-homed Stub Network: A stub network that is belonging to or
connected to multiple ASes.
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.
Li, et al. Expires 23 April 2025 [Page 3]
Internet-Draft SPA-based SAVNET October 2024
2. Overview of SPA-based SAVNET
SPA-based SAVNET requires SAVNET routers to signal SAV-specific
information through SPA message communication. The SAV-specific
information contains the necessary information that improves the
accuracy of SAV rules and cannot be learned from existing routing
information. By using SAV-specific information, SAVNET routers can
generate allowlist SAV rules (i.e., "Interface-based prefix
allowlist" mode in [I-D.huang-savnet-sav-table]) or blocklist SAV
rules (i.e., "Interface-based prefix blocklist" mode in
[I-D.huang-savnet-sav-table]) on specific router interfaces.
The SAVNET router can be an intra-domain router facing a stub network
(e.g., a host network and a customer network) or facing an external
AS. Specifically, to block spoofing data packets from a host network
or a customer network that use source addresses of other networks,
SPA-based SAVNET can generate an allowlist on interfaces facing a
host network or a customer network. The allowlist contains source
prefixes of the corresponding network, because data packets from the
network can only use source addresses belonging to the network unless
there is a special case such as Direct Server Return (DSR). To block
spoofing data packets from other ASes that use source addresses of
the local AS, SPA-based SAVNET can generate a blocklist on interfaces
facing an external AS, containing source prefixes of the local AS.
In the following, Section 3 introduces content of the SPA message and
procedure of SAV rule generation. Section 4 introduces the most
recommended use case, an alternative use case, and two corner use
cases of SPA-based SAVNET, respectively.
3. Source Prefix Advertisement Procedure
Source Prefix Advertisement (SPA) procedure includes three main
steps: SPA message generation, SPA message communication, and SAV
rule generation.
3.1. SPA Message Generation
A SPA message contains two main types of information:
* Source Prefix: This information contains source prefixes learned
from the router's local routes to its stub network, i.e., the
locally-known source prefixes of the stub network. Specifically,
each Dest Prefix in RIB that has an outgoing interface towards the
stub network will be considered as a source prefix of the stub
network. Note that in the case of asymmetric routes, the locally-
known source prefixes may be only a part of all source prefixes of
the stub network.
Li, et al. Expires 23 April 2025 [Page 4]
Internet-Draft SPA-based SAVNET October 2024
* Stub Network Identifier: For each source prefix contained in the
SPA message, it is binded with a Stub Network Identifier (SNI).
The SNI is used to identify which stub network owns the source
prefix. Prefixes belonging to the same stub network MUST have an
identical and unique SNI value. Different stub networks MUST have
different SNI values. The SNI is the key SAV-specific information
used by SPA-based SAVNET when generating allowlists or blocklists.
Source prefixes contained in a SPA message indicate source addresses
that can only be used by data packets received from the stub network.
Therefore, only SAVNET routers facing a single-homed stub network
(but there can be multiple links between the intra-domain network and
the stub network) will generate SPA messages.
3.2. SPA Message Communication
After generating SPA messages, the SAVNET router will provide its SPA
messages to other SAVNET routers in the same intra-domain network.
Figure 1 shows an example of SPA message communication. Routers A
and B are host-facing routers facing the same single-homed stub
network. Router C is an AS border router (ASBR) facing an external
AS. Routers A and B can automatically exchange their SPA messages to
ensure that they learn the full source prefixes of the stub network,
even if there is an asymmetric route. Router A or B can
automatically provide its SPA message to Router C, informing Router C
which source addresses cannot be used by data packets from an
external AS.
Li, et al. Expires 23 April 2025 [Page 5]
Internet-Draft SPA-based SAVNET October 2024
+------------+
| Other ASes |
+-----+------+
|
+-------------------|--------------------+
| +----+-----+ AS |
| | Router C | |
| +----------+ |
| /\ /\ |
| / \ |
| SPA message / \ SPA message |
| of Router A/ \of Router B |
| / SPA message \ |
| / of Router A \ |
| +----------+ ---------> +----------+ |
| | Router A | | Router B | |
| +------+---+ <--------- +--+-------+ |
| \ SPA message / |
| \ of Router B / |
| \ / |
| +--------------+ |
| | Stub Network | |
| +--------------+ |
+----------------------------------------+
Figure 1: An example of SPA message communication
Implementation consideration: Since the SPA message contains source
prefixes of a stub network, SPA message communication can be
implemented by using existing intra-domain routing protocols (e.g.,
OSPF, IS-IS, iBGP). When distributing the IP information of the stub
network through the intra-domain routing protocol, the SAVNET router
can bind the SNI with the IP information. This document focuses on
the protocol-independent design of SPA-based SAVNET. Protocol
designs and extensions are not in the scope of this document.
3.3. SAV Rule Generation
After receiving SPA messages from other SAVNET router, each SAVNET
router will generate allowlists or blocklists on specific interfaces:
Li, et al. Expires 23 April 2025 [Page 6]
Internet-Draft SPA-based SAVNET October 2024
* Allowlist generation procedure: A SAVNET router facing a stub
network can generate an allowlist on the corresponding interface
by using its own SPA message as well as SPA messages of other
SAVNET routers (if any) facing the same stub network. All source
prefixes in SPA messages with the SNI of its stub network will be
added into the allowlist. The stub network can be a host network,
a customer network, a stub OSPF area, or a stub AS. When using an
allowlist on an interface facing a stub network, it must ensure
that the stub network is not multi-homed to another AS.
* Blocklist generation procedure: A SAVNET router can generate a
blocklist by using SPA messages from other SAVNET routers. All
source prefixes in SPA messages will be added into the blocklist.
The blocklist is recommended to be used on interfaces facing an
external AS or facing a stub network that is multi-homed to
multiple ASes.
4. Use Case
4.1. The Most Recommended Use Case
SPA-based SAVNET is highly recommended to be deployed at host-facing
routers, customer-facing routers, and AS border routers. It is
because that these routers are closer to the source and thus will be
more effective in identifying and discarding source-spoofed data
packets. SPA-based SAVNET generates allowlists on interfaces facing
a host network, a customer network, or a stub AS, and generates
blocklists on interfaces facing a non-stub AS.
Figure 2 shows an example of the most recommended use case. SPA-
based SAVNET is deployed at Routers A, B, and C. The stub network 1
or 2 can be a host network, a customer network, or a stub AS. Stub
network 1 is single-homed to the intra-domain network but multi-
connected to Routers A and B. Stub network 1 is single-homed to the
intra-domain network and single-connected to Router B. Router C is
connected to an external non-stub AS. Stub network 1 has two source
prefixes P1 and P2. Due to traffic engineering and load balance,
Router A only learns the route to prefix P1 from its Interface '#'
and Router B only learns the route to prefix P2 from its Interface
'#'. The SNI value of stub network 1 is set as 1, and the SNI value
of stub network 2 is set as 2.
Li, et al. Expires 23 April 2025 [Page 7]
Internet-Draft SPA-based SAVNET October 2024
+---------------+
| Non-stub ASes |
+---------------+
|
+----------------------------|------------------------------+
| +----#-----+ |
| | Router C | |
| +----------+ |
| ^ |
| SPA message | SPA message |
| of Router A | of Router B |
| | |
| +-----------------+-----------------+ |
| | Other intra-domain routers | |
| +---+----------------------------+--+ |
| ^ | | ^ |
|SPA message | | SPA message SPA message | | SPA message |
|of Router A | | of Router B of Router A | | of Router B |
| | v v | |
| +----------+ +----------+ |
| | Router A | | Router B | |
| +------#---+ +--#---X---+ |
| \ / \ |
| \ / \ |
| \ / \ |
| +----------------+ +----------------+|
| | Stub Network 1 | | Stub Network 2 ||
| +----------------+ +----------------+|
| (Source prefixes: (Source prefixes: |
| P1 and P2) P3) |
+-----------------------------------------------------------+
SPA message of Router A:
[Source Prefix: P1, SNI: 1]
SPA message of Router B:
{[Source Prefix: P2, SNI: 1], [Source Prefix: P3, SNI: 2]}
Figure 2: An example of the most recommended use case of SPA-
based SAVNET
Router A generates a SPA message containing source prefix P1 with a
SNI value of 1. Router B generates a SPA message containing source
prefix P2 with a SNI value of 1, and source prefix P3 with a SNI
value of 1. After that, Router A or Router B provides its SPA
message to other SAVNET routers. Router A or Router B finally
generates an allowlist on its Interface '#' containing source
prefixes P1 and P2, because both source prefixes have the SNI value
Li, et al. Expires 23 April 2025 [Page 8]
Internet-Draft SPA-based SAVNET October 2024
of stub network 1. In addition, Router B generates an allowlist on
its Interface 'X' containing source prefix P3 because only prefix P3
has the SNI value of stub network 2. Router C finally generates a
blocklist on its Interface '#' containing all source prefixes of all
SPA messages, i.e., prefixes P1, P2, and P3.
By using the allowlist or blocklist on different router interfaces,
the intra-domain network can effectively prevent spoofing data
packets from entering the intra-domain network while avoiding
improper blocks. Routers A and B will only allow data packets from
stub network 1 with source addresses in prefixes P1 and P2. Router B
will only allow data packets from stub network 2 with source
addresses in prefix P3. Router C will block data packets from
external ASes with source addresses in prefixes P1, P2, and P3.
4.2. An Alternative Use Case
SPA-based SAVNET can also be used on Area Border Routers (ABR) in
inter-area cases. For example, if the stub network in Figure 2 is a
stub OSPF area, SPA-based SAVNET can also generate an allowlist on
interfaces facing the stub OSPF area and thus only allow data packets
using source addresses belonging to the stub OSPF area. However, it
is less effective than deploying SPA-based SAVNET on interfaces
facing a host network, a customer network, or a stub AS, because
allowlists on ABRs are coarser. As a result, deploying SPA-based
SAVNET on ABRs is an alternative rather than the most recommended use
case.
4.3. Two Corner Use Cases
4.3.1. 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 should be added into allowlists on interfaces facing a stub
network where the content server locates.
4.3.2. Multi-homed Stub Network
As mentioned in Section 3, if a stub network is multi-homed to other
ASes, SPA-based SAVNET must not generate SPA messages for this stub
network and must not use an allowlist on the interface facing this
stub network. It is because the router facing this stub network may
only learns a part of source prefixes of the stub network.
Therefore, it is recommended to use a blocklist in this case.
Li, et al. Expires 23 April 2025 [Page 9]
Internet-Draft SPA-based SAVNET October 2024
5. Convergence Considerations
The propagation speed of SPA messages is a key factor affecting
convergence. Consider that routing information and SAV-specific
information can be originated and advertised through a similar way,
SAV-specific information SHOULD at least have a similar propagation
speed as routing information. When designing SPA message
communication methods, routing protocol-based methods should be
preferred.
6. Incremental Deployment Considerations
In the most recommended use case, SPA-based SAVNET is deployed on all
host-facing routers, customer-facing routers, and AS border routers.
When SPA-based SAVNET has not been deployed in all of these required
routers simultaneously, SPA-based SAVNET supports incremental
deployment by providing incremental benefits.
For allowlist generation, if the SAVNET router faces a stub network
with only one link to the intra-domain network, it can generate an
accurate allowlist on the corresponding interface without SPA
messages of other routers. If the SAVNET router faces a stub network
with multiple links to the intra-domain network, it only needs SPA
messages of other routers facing the same stub network to generate a
complete allowlist.
For blocklist generation, if the SAVNET router only learns partial
internal prefixes, the generated blocklist can still be used to
prevent spoofing data packets using source addresses in these
prefixes from entering the intra-domain network.
As a result, when SPA-based SAVNET is partially deployed on the
required routers, it can still block spoofing data packets on SAVNET
routers.
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
Li, et al. Expires 23 April 2025 [Page 10]
Internet-Draft SPA-based SAVNET October 2024
9.1. Normative References
[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-06, 12 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-problem-statement-06>.
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[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-07, 25 August 2024,
<https://datatracker.ietf.org/doc/html/draft-huang-savnet-
sav-table-07>.
Li, et al. Expires 23 April 2025 [Page 11]
Internet-Draft SPA-based SAVNET October 2024
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
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 23 April 2025 [Page 12]