Source Prefix Advertisement for Intra-domain SAVNET
draft-li-savnet-source-prefix-advertisement-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Dan Li , Nan Geng , Lancheng Qin | ||
| Last updated | 2024-07-08 | ||
| RFC stream | (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-00
SAVNET D. Li
Internet-Draft Tsinghua University
Intended status: Standards Track N. Geng
Expires: 9 January 2025 Huawei
L. Qin
Zhongguancun Laboratory
8 July 2024
Source Prefix Advertisement for Intra-domain SAVNET
draft-li-savnet-source-prefix-advertisement-00
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. By using SAV-specific
information carried in SPA messages, 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 using SPA messages. 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 9 January 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 9 January 2025 [Page 1]
Internet-Draft SPA-based SAVNET July 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 . . . . . . . . . . . . . . . . . . 4
2. Goal of SPA-based SAVNET . . . . . . . . . . . . . . . . . . 4
3. Source Prefix Advertisement Procedure . . . . . . . . . . . . 6
3.1. SPA Message Generation . . . . . . . . . . . . . . . . . 6
3.2. SPA Message Communication . . . . . . . . . . . . . . . . 7
3.3. SAV Rule Generation . . . . . . . . . . . . . . . . . . . 7
4. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Convergence Considerations . . . . . . . . . . . . . . . . . 10
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The purpose of intra-domain source address validation (SAV) is to
prevent outgoing data packets from an intra-domain subnet (e.g., a
host network or a customer network) from forging source addresses of
other intra-domain subnets or other ASes, and to prevent incoming
data packets from external ASes from forging source addresses of the
local AS. To this end, intra-domain SAV should focus on SAV at edge
routers (i.e., host-facing routers or customer-facing routers), and
AS border routers (see [I-D.ietf-savnet-intra-domain-architecture]).
Specifically, edge routers should block data packets from the
connected host network or customer network with a spoofed source IP
address not belonging to that network. AS border routers should
block data packets from other ASes with a spoofed source IP address
belonging to the local AS.
Existing intra-domain SAV solutions (e.g., BCP38 [RFC2827] and BCP84
[RFC3704]) have problems of high operational overhead or inaccurate
validation (see [I-D.ietf-savnet-intra-domain-problem-statement]).
Li, et al. Expires 9 January 2025 [Page 2]
Internet-Draft SPA-based SAVNET July 2024
Specifically, ACL-based ingress filtering (BCP38 [RFC2827]) requires
manual operations to configure and update the SAV rules, while uRPF-
based solutions (BCP84 [RFC3704]) may improperly block legitimate
data packets in the scenario of routing asymmetry. To improve the
accuracy upon existing intra-domain SAV solutions and 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
focuses on SAV at edge routers and AS border routers in an intra-
domain network. It allows SAVNET routers within an intra-domain
network to communicate SAV-specific information through SPA messages.
SAVNET routers will not communicate SAV-specific information with
routers/devices in intra-domain subnets and other ASes. 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 using SPA messages. 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.
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 of an AS which is
connected to an intra-domain host network (i.e., a layer-2 network).
Customer-facing Router: An intra-domain router of an AS which is
connected to an intra-domain customer network running the routing
protocol (i.e., a layer-3 network).
Edge router: A host-facing router or a customer-facing router.
AS Border Router: An intra-domain router of an AS which is connected
to other ASes.
Subnet: An intra-domain host network or an intra-domain customer
network.
Li, et al. Expires 9 January 2025 [Page 3]
Internet-Draft SPA-based SAVNET July 2024
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. Goal of SPA-based SAVNET
Figure 1 shows an intra-domain network that adopts SPA-based SAVNET.
Router 1 and Router 2 are edge routers that enable SAV at the
interfaces facing to a subnet. Router 3 is an AS border router that
enables SAV at the interfaces facing to an AS.
This document defines four types of interfaces that should enable
SPA-based SAVNET:
* Single-homing interface. The interface of an edge router that
faces to a singled-homed subnet. For example, Intf.1 in Figure 1
is a "Single-homing interface".
* Complete multi-homing interface. For an edge router facing to a
multi-homed subnet, if all routers facing to the multi-homed
subnet are in the same AS, the interface facing to this subnet is
"Complete multi-homing interface". In this case, the multi-homed
subnet is called complete multi-homed subnet. For example, Intf.2
and Intf.3 in Figure 1 are "Complete multi-homing interfaces".
* Incomplete multi-homing interface. For an edge router facing to a
multi-homed subnet, if some other routers facing to the multi-
homed subnet are in other ASes, the interface facing to this
subnet is "Incomplete multi-homing interface". In this case, the
multi-homed subnet is called incomplete multi-homed subnet. For
example, Intf.4 in Figure 1 is "Incomplete multi-homing
interface".
* Internet interface. The interface of an AS border router that
faces to another AS. Generally, a network usually has multiple
"Internet interfaces" for load balancing or backup. For example,
Intf.5 and Intf.6 in Figure 1 are "Internet interfaces".
Li, et al. Expires 9 January 2025 [Page 4]
Internet-Draft SPA-based SAVNET July 2024
+-----------------------------------------+
| Other ASes |
+-----------------------------------------+
| | |
| | |
+-------------|------|----------------|---+
| AS | | | |
| Intf.5| |Intf.6 | |
| +-*------*-+ | |
| | Router 3 | | |
| +----------+ | |
| / \ | |
| / \ | |
| / \ | |
| +----------+ +----------+ | |
| | Router 1 | | Router 2 | | |
| +--#-----#-+ +-#-----*--+ | |
|Intf.1| \Intf.2 /Intf.3 \Intf.4 | |
| | \ / \ | |
| | \ / \ | |
| Subnet1 Subnet2 Subnet3 |
| (P1) (P2, P3) (P4,P5) |
+-----------------------------------------+
Routers 1 and 2 are edge routers
Router 3 is an AS border router
Intf '#' enables prefix allowlist
Intf '*' enables prefix blocklist
Figure 1: An intra-domain network that adopts SPA-based SAVNET
The goal of SPA-based SAVNET is to automatically generate prefix
allowlist or blocklist for the four types of interfaces:
* Single-homing interface. SPA-based SAVNET generates a prefix
allowlist (i.e., "Interface-based prefix allowlist" mode in
[I-D.huang-savnet-sav-table]) at each "Single-homing interface".
The prefix allowlist should contain all source prefixes of the
connected subnet and blocks data packets from that subnet with
source addresses not belonging to these source prefixes. In
Figure 1, the prefix allowlist for Intf. 1 should contain the
source prefix of Subnet1 (i.e., prefix P1).
* Complete multi-homing interface. Same as "Single-homing
interface", SPA-based SAVNET generates a prefix allowlist at each
"Complete multi-homing interface", containing all source prefixes
of the connected subnet. In Figure 1, the prefix allowlists for
Intf. 2 or Intf. 3 should include the source prefixes of Subnet2
Li, et al. Expires 9 January 2025 [Page 5]
Internet-Draft SPA-based SAVNET July 2024
(i.e., prefixes P2 and P3). By using the prefix allowlist,
Routers 1 and 2 can accurately block spoofing data packets from
Subnet2 using source IP addresses not in prefixes P2 and P3.
* Incomplete multi-homing interface. For an "Incomplete multi-
homing interface", if there is a asymmetric routing among the
connected subnet and its multiple provider networks, it is hard to
identify all source prefixes of the subnet without communication
between the multiple provider networks. Therefore, SPA-based
SAVNET generates a prefix blocklist (i.e., "Interface-based prefix
blocklist" mode in [I-D.huang-savnet-sav-table]) at each
"Incomplete multi-homing interface". The prefix blocklist should
include all source prefixes belonging to the subnets connected to
"Single-homing interfaces" and "Complete multi-homing interfaces".
In Figure 1, the prefix blocklist of Intf. 4 should contain the
source prefixes of Subnet1 and Subnet2 (i.e., prefixes P1, P2, and
P3).
* Internet interface. Same as "Incomplete multi-homing interface",
SPA-based SAVNET generates a prefix blocklist at each "Internet
interface", containing all source prefixes belonging to the
subnets connected to "Single-homing interfaces" and "Complete
multi-homing interfaces". In Figure 1, the prefix blocklist of
Intf. 5 and Intf. 6 should contain the source prefixes of Subnet1
and Subnet2 (i.e., prefixes P1, P2, and P3).
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
An edge router with a "Single-homing interface" or "Complete multi-
homing interface" will generate SPA messages containing four main
types of information:
* Source Prefix: This information contains source prefixes of its
single-homed subnet or complete multi-homed subnet that are
learned through the router's local routes to that subnet.
Specifically, each Dest Prefix in RIB that records the interface
facing to the subnet as an outgoing interface will be considered
as a source prefix of the subnet. For each source prefix, SPA
message records three indicators which are introduced in the
following.
Li, et al. Expires 9 January 2025 [Page 6]
Internet-Draft SPA-based SAVNET July 2024
* Multi-homing Interface Group Type (MIIG-Type): This indicates the
type of the interface that learns the prefix. MIIG-Type MUST be
one of the four types mentioned above.
* Multi-homing Interface Group Tag (MIIG-Tag): This is used to
identify the subnet that owns the prefix. The prefixes belonging
to the same subnet MUST have the identical MIIG-Tag value.
Different subnets MUST have different MIIG-tag values.
* (Only) Source Flag: This indicates whether the prefix is owned by
one subnet. By default, the flag is set because source IP
addresses used in data packets originated from a subnet should
belong to the subnet in most cases. However, for anycast
addresses/prefixes or direct server return (DSR) addresses/
prefixes, the flag should be unset (possibly manually).
3.2. SPA Message Communication
After generating SPA messages, the edge router will send its SPA
messages to other edge routers and AS border routers. 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.
3.3. SAV Rule Generation
The following describes how to generate SAV rules on the above four
types of interfaces.
* For a "Single-homing interface", the router can generate a prefix
allowlist by using its own SPA messages without SPA messages from
other routers. The prefix allowlist contains source prefixes of
the single-homed subnet that are learned through the router's
local routes to that subnet.
* For a "Complete multi-homing interface", the router generates the
prefix allowlist by using both its own SPA messages and SPA
messages from other routers facing to the same complete multi-
homed subnet. All source prefixes in these SPA messages with the
"MIIG-Tag" of the complete multi-homed subnet will be added into
the prefix allowlist.
* For an "Incomplete multi-homing interface" or "Internet
interface", the router generates a prefix blocklist. It processes
its own SPA messages and SPA messages from other routers.
Prefixes in these SPA messages with MIIG-Types of "Single-homing
interface" or "Complete Multi-homing interface" and with Source
Flag being set will be added into the prefix blocklist. Prefixes
Li, et al. Expires 9 January 2025 [Page 7]
Internet-Draft SPA-based SAVNET July 2024
with Source Flag being unset will not be added into the blocklist
because the prefix is multi-source and the "Incomplete multi-
homing interface" or "Internet interface" may receive legitimate
data packets using this prefix as source IP addresses.
Note that, SPA-based SAVNET can also work if the subnet is a stub AS.
The source prefixes of the stub AS can be considered as the internal
prefixes of the local AS when using SPA-based SAVNET.
4. Use Case
Figure 2 shows a use case of SPA-based SAVNET in an intra-domain
network. Intf.1 of Router 1 is a "Single-homing interface" facing to
Subnet1 which has prefix P1. Intf.2 of Router 1 and Intf.3 of Router
2 are "Complete multi-homing interfaces" facing to Subnet2 which has
prefixes P2 and P3. Due to traffic engineering and load balance,
Router 1 only learns the route to prefix P2 from Intf.2, while Router
2 only learns the route to prefix P3 from Intf.3. Intf.4 of Router 2
is an "Incomplete multi-homing interface" facing to Subnet 3 which
has prefixes P4 and P5. Intf.5 and Intf.6 of Router 3 are "Internet
interfaces" facing to other ASes.
Li, et al. Expires 9 January 2025 [Page 8]
Internet-Draft SPA-based SAVNET July 2024
+-------------------------------------------+
| Other ASes |
+----------------+------+----------------+--+
| | |
| | |
+----------------|------|----------------|--+
| AS | | | |
| Intf.5+ +Intf.6 | |
| +-+*+----+*+-+ | |
| | Router 3 | | |
| [P1,SI, /\--------/\-+ [P1,SI, | |
| Sub1,SRC] / / \ \ Sub1,SRC] | |
| [P2,CI, / /[P3,CI, \ \ [P2,CI, | |
| Sub2,SRC] / / Sub2,SRC] \ \ Sub2,SRC] | |
| +------\/----+ +-----\/-----+ | |
| | Router 1 | | Router 2 | | |
| +--+#+---+#+-+ +-+#+---+*+--+ | |
| Intf.1| \Intf.2 /Intf.3 \Intf.4 | |
| | \ / \ | |
| | \ / \ | |
| Subnet1 Subnet2 Subnet3 |
| (P1) (P2, P3) (P4,P5) |
+-------------------------------------------+
Routers 1 and 2 are edge routers
Router 3 is an AS border router
Intf '#' enables prefix allowlist
Intf '*' enables prefix blocklist
Figure 2: A use case of SPA-based SAVNET
Router 1 generates SPA messages for source prefixes (i.e., prefixes
P1 and P2) learned from its local routes to Subnet 1 and Subnet 2.
For prefix P1, the MIIG-Type is "Single-homing interface", the MIIG-
Tag is "Subnet1", and the Source Flag is set (i.e., [P1, SI, Sub1,
SRC]). For prefix P2, the MIIG-Type is "Complete multi-homing
interface", the MIIG-Tag is "Subnet2", and the Source Flag is set
(i.e., [P2, CI, Sub2, SRC]). After generating SPA messages, Router 1
sends its SPA messages to Routers 2 and 3.
Router 2 generates SPA messages for prefix P3. The MIIG-Type is
"Complete multi-homing interface", the MIIG-Tag is "Subnet2", and the
Source Flag is set (i.e., [P3, CI, Sub2, SRC]). After that, it sends
its SPA messages to Routers 1 and 3.
As described in Section 3.3, Routers 1, 2, and 3 generate SAV rules
after receiving SPA messages from other routers. For Router 1, it
generates a prefix allowlist at Intf.1 containing prefix P1 by using
Li, et al. Expires 9 January 2025 [Page 9]
Internet-Draft SPA-based SAVNET July 2024
its own SPA message [P1, SI, Sub1, SRC]. By using its own SPA
message [P2, CI, Sub2, SRC] and Router 2's SPA messages [P3, CI,
Sub2, SRC], it generates a prefix allowlist at Intf.2 containing
prefixes P2 and P3. For Router 2, it generates a prefix allowlist at
Intf.2 containing prefixes P2 and P3 by using its own SPA message
[P3, CI, Sub2, SRC] and Router 1's SPA message [P2, CI, Sub2, SRC].
At Intf.4, Intf.5, or Intf.6, Router 2 or Router 3 generates a prefix
blocklist containing prefixes P1, P2, and P3 by using all SPA
messages of Router 1 and Router 2.
By using prefix allowlist or blocklist at different interfaces, the
intra-domain network can prevent data packets using spoofing source
addresses from entering the network while avoiding improper block.
Intf.1 will only accept data packets from Subnet 1 with source
addresses in prefix P1. Intf.2 and Intf.3 will only accept data
packets from Subnet 2 with source addresses in prefixes P2 and P3.
Intf.4, Intf.5, and Intf.6 will block data packets from Subnet 3 or
other ASes with source addresses in prefixes P1, P2, and P3.
5. Convergence Considerations
The propagation speed of SAV-specific is a key factor affecting the
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. Deployment Considerations
SPA-based SAVNET can support incremental deployment by providing
incremental benefits. In the scenario of incremental deployment, a
router can only receive SPA messages from edge routers that deploy
SPA-based SAVNET. For a router with a "Single-homing interface", it
can generate accurate SAV rules at that interface without SPA
messages from other routers. For a router with a "Complete multi-
homing interface", it only needs SPA messages from other edge routers
connected to the same subnet, but not from all edge routers. For a
router with a "Incomplete multi-homing interface" or "Internet
interface", if it only learns partial internal prefixes by processing
SPA messages, the generated SAV rule can still prevent spoofing
traffic using source addresses in those prefixes from entering the
intra-domain network. In addition, the router can use routing
information to learn more internal prefixes.
Li, et al. Expires 9 January 2025 [Page 10]
Internet-Draft SPA-based SAVNET July 2024
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
[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-03, 13 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-problem-statement-03>.
[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-00, 12 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-architecture-00>.
[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>.
Li, et al. Expires 9 January 2025 [Page 11]
Internet-Draft SPA-based SAVNET July 2024
[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-05, 3 March 2024,
<https://datatracker.ietf.org/doc/html/draft-huang-savnet-
sav-table-05>.
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 9 January 2025 [Page 12]