Intra-domain Source Address Validation (SAVNET) Architecture
draft-li-savnet-intra-domain-architecture-05
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 "Replaced".
|
|
|---|---|---|---|
| Authors | Dan Li , Jianping Wu , Lancheng Qin , Nan Geng , Li Chen , Mingqing(Michael) Huang , Fang Gao | ||
| Last updated | 2023-10-23 (Latest revision 2023-10-20) | ||
| 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-intra-domain-architecture-05
SAVNET D. Li
Internet-Draft J. Wu
Intended status: Informational L. Qin
Expires: 25 April 2024 Tsinghua University
N. Geng
Huawei
L. Chen
Zhongguancun Laboratory
M. Huang
Huawei
F. Gao
Zhongguancun Laboratory
23 October 2023
Intra-domain Source Address Validation (SAVNET) Architecture
draft-li-savnet-intra-domain-architecture-05
Abstract
This document proposes the intra-domain SAVNET architecture, which
achieves accurate source address validation (SAV) in an intra-domain
network by an automatic way. Compared with uRPF-like SAV mechanisms
that only depend on routers' local routing information, SAVNET
routers generate SAV rules by using both local routing information
and SAV-specific information exchanged among routers, resulting in
more accurate SAV validation in asymmetric routing scenarios.
Compared with ACL rules that require manual efforts to accommodate to
network dynamics, SAVNET routers learn the SAV rules automatically in
a distributed way.
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 April 2024.
Li, et al. Expires 25 April 2024 [Page 1]
Internet-Draft Intra-domain SAVNET Architecture October 2023
Copyright Notice
Copyright (c) 2023 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Intra-domain SAVNET Architecture . . . . . . . . . . . . . . 5
3.1. Roles of SAVNET Routers . . . . . . . . . . . . . . . . . 5
3.1.1. Source Entity . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Validation Entity . . . . . . . . . . . . . . . . . . 5
3.2. SAV-related Information . . . . . . . . . . . . . . . . . 6
3.2.1. Local Routing Information . . . . . . . . . . . . . . 6
3.2.2. SAV-specific Information . . . . . . . . . . . . . . 6
3.2.3. SAV-specific Information Communication Mechanism . . 7
3.3. SAV Rule Generation . . . . . . . . . . . . . . . . . . . 7
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Case 1: Validating Outbound Packets from a Multi-homed
Subnet at Edge Routers . . . . . . . . . . . . . . . . . 9
4.2. Use Case 2: Validating Inbound Packets from Other ASes at
Border Routers . . . . . . . . . . . . . . . . . . . . . 10
5. Meeting the Design Requirements of Intra-domain SAVNET . . . 11
5.1. Accurate Validation . . . . . . . . . . . . . . . . . . . 12
5.2. Automatic Update . . . . . . . . . . . . . . . . . . . . 12
5.3. Incremental/Partial Deployment . . . . . . . . . . . . . 12
5.4. Convergence . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Manageability Considerations . . . . . . . . . . . . . . . . 15
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Li, et al. Expires 25 April 2024 [Page 2]
Internet-Draft Intra-domain SAVNET Architecture October 2023
1. Introduction
Source address validation (SAV) is important for mitigating source
address spoofing and thus contributes to the Internet security. In
the Source Address Validation Architecture (SAVA) [RFC5210], SAV is
divided into three checking levels, i.e., access-network SAV, intra-
domain SAV, and inter-domain SAV. When an access network does not
deploy SAV (such as SAVI [RFC7039][RFC7513], Cable Source Verify
[cable-verify], and IP Source Guard [IPSG]), intra-domain SAV helps
block spoofed packets from an access network as close to the source
as possible [I-D.ietf-savnet-intra-domain-problem-statement].
The main purpose of the intra-domain SAV mechanism for an AS A, is to
protect the outgoing packets of a subnet of AS A from forging their
source addresses as other subnets' addresses or other ASes'
addresses, as well as protect the incoming packets to AS A from
forging their source addresses as AS A's addresses. The main task of
the intra-domain SAV mechanism is to generate the correct mapping
relationship between a source address (prefix) and the valid incoming
interface(s), called SAV rules. The core challenge of the intra-
domain SAV mechanism is how to efficiently and accurately learn the
mapping relationship. Although many existing intra-domain SAV
mechanisms (such as ACL-based filtering [RFC2827], strict uRPF
[RFC3704], and loose uRPF [RFC3704]) have been proposed, they suffer
from either inaccurate mapping in asymmetric routing scenraios, or
high operational overhead in dynamic networks. The key cause is that
exsiting mechanisms generate the SAV rules by a router's local
routing information or by manual inputs. In
[I-D.ietf-savnet-intra-domain-problem-statement], five requirements
for a new intra-domain SAVNET architecture are proposed.
This document introduces the intra-domain SAVNET architecture to meet
the five requirements. The key idea of intra-domain SAVNET is to
generate SAV rules in routers based on SAV-specific information
exchanged among routers, instead of depending on local routing
information like in existing mechanisms. It achieves accurate SAV
validation, because the SAV-specific information exchanged among
routers carry necessary information for asymmetric routing scenraio
which cannot be learned by local routing information. It achieves
automatic SAV rule update, because the SAV-specific information
exchange is triggered when there is topology change or prefix change.
In the incremental/partial deployment scenario where only part of
intra-domain routers support the intra-domain SAVNET, some SAV-
specific information for building the complete SAV rules will be
missing. In this case, local routing information can still be used
to fill the gap.
Li, et al. Expires 25 April 2024 [Page 3]
Internet-Draft Intra-domain SAVNET Architecture October 2023
1.1. 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. Terminology
Local Routing Information: The information in a router's local RIB or
FIB that can be used to infer SAV rules.
SAV-specific Information: The information specialized for SAV rule
generation, which is exchanged among routers.
SAV-related Information: The information used by a router to make SAV
decisions. For intra-domain SAV, SAV-related information includes
both local routing information and SAV-specific information.
SAV-specific Information Communication Mechanism: The mechanism for
exchanging SAV-specific information between routers. It can be a
either a new protocol or an extension to an existing protocol.
SAV Information Base: A table or data structure in a router which
stores SAV-specific information and local routing information.
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.
SAVNET Router: A router which runs intra-domain SAVNET.
SAVNET Agent: The agent in a SAVNET router that is responsible for
communicating SAV-specific information, processing SAV-related
information, and generating SAV rules.
Edge Router: An intra-domain router for an AS that is directly
connected to a subnet of the AS.
Border Router: An intra-domain router for an AS that is connected to
other ASes. A router in an AS can be both an edge router and a
border router, if it is connected to both the AS's subnets and other
ASes.
Li, et al. Expires 25 April 2024 [Page 4]
Internet-Draft Intra-domain SAVNET Architecture October 2023
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.
3. Intra-domain SAVNET Architecture
Figure 1 shows the overview of intra-domain SAVNET architecture. A
SAVNET router can be an edge router, a border router, both an edge
router and a border router, or other routers (i.e., neither an edge
router nor a border router). Every SAVNET router has a SAVNET Agent
that is responsible for actions related to SAV.
3.1. Roles of SAVNET Routers
A SAVNET router can act as one or two roles in the intra-domain
SAVNET architecture, namely, source entity to send its SAV-specific
information to other SAVNET routers, or/and validation entity to
receive SAV-specific information from other SAVNET routers.
3.1.1. Source Entity
When a SAVNET router acts as source entity, the information sender of
its SAVNET Agent sends its SAV-specific information to other SAVNET
routers that act as validation entity. For example, an edge router
acting as source entity can obtain its SAV-specific information about
the connected subnets and send out this information through
communication channel.
3.1.2. Validation Entity
When a SAVNET router acts as validation entity, the information
receiver of its SAVNET Agent receives SAV-specific information from
other routers that act as source entity. Then, its SAVNET Agent
processes the received SAV-specific information as well as its local
routing information to generate SAV rules. For example, an edge
router or a border router acting as validation entity can generate
SAV rules and use SAV rules to perform SAV on inbound or outbound
packets.
Li, et al. Expires 25 April 2024 [Page 5]
Internet-Draft Intra-domain SAVNET Architecture October 2023
+---------------------+ +-------------------------------------+
| Source Entity | | Validation Entity |
| (Router A) | | (Router B) |
| | | |
| +-----------------+ | | +-----------------+ +---------+ |
| | SAVNET Agent | | Communication | | SAVNET Agent <-----+ RIB/FIB | |
| | +-------------+ | | Channel | | +-------------+ | +---------+ |
| | | Information +-----------------------> Information | | Local Routing |
| | | Sender | | |(SAV-specific | | | Receiver | | Information |
| | +-------------+ | | Information ) | | +-------------+ | |
| +-----------------+ | | +-----------------+ |
| | | |
+---------------------+ +-------------------------------------+
Figure 1: Intra-domain SAVNET architecture
3.2. SAV-related Information
3.2.1. Local Routing Information
Local routing information is used for computing packet forwarding
rules, which is stored in the local RIB/FIB. Although it is not
specialized for SAV, it is widely used to infer SAV rules in existing
uRPF-based SAV mechanisms, such as strict uRPF and loose uRPF. A
SAVNET router acting as validation entity can directly obtain local
routing information from the router's RIB/FIB, when the corresponding
SAV-specific information is missing.
3.2.2. SAV-specific Information
SAV-specific information is specialized for SAV. A SAVNET router
acting as source entity can obtain local SAV-specific information
based on local routing information and local interface
configurations. A SAVNET router acting as validation entity can
obtain SAV-specific information of other SAVNET routers that act as
source entity through the SAV communication channel.
By learning the SAV-specific information from source entity,
validation entity can generate more accurate SAV rules than solely
using its local routing information, which lead to more accurate SAV.
For example, a router that is directly connected to subnets can act
as source entity and inform the other routers of its locally known
source prefixes of its subnets. Other routers acting as validation
entity can finally consolidate such SAV-specific information and
local routing information to obtain the complete source prefixes of
intra-domain subnets.
Li, et al. Expires 25 April 2024 [Page 6]
Internet-Draft Intra-domain SAVNET Architecture October 2023
3.2.3. SAV-specific Information Communication Mechanism
The SAV-specific communication mechanism is for building the
communication channel and propagating SAV-specific information from
source entity to validation entity. Since there is no off-the-shelf
mechanism to achieve this function, a new SAV-specific communication
mechanism is needed. It can be a new protocol or an extension to an
existing protocol. This document does not present the details of the
protocol design or protocol extensions. In the following, we
describe the necessary features of SAV-specific communication
mechanism.
The SAV-specific communication mechanism SHOULD define the data
structure or format of SAV-specific information, and the operations
of communication (such as communication channel establishment and
communication channel termination). In addition, the mechanism
SHOULD require source entity to inform validation entity of the
updates of SAV-specific information in a timely manner, so that
validation entity can update SAV rules based on the latest
information.
In order to ensure the convergence and security of the communication,
the session of the SAV-specific communication mechanism SHOULD meet
the following requirements:
* The session can be a long-time session or a temporary one, but it
SHOULD provide sufficient assurance of transmission reliability
and timeliness, so that validation entity can update its SAV rules
in time.
* Authentication can be conducted before session establishment.
Authentication is optional but the ability of authentication
SHOULD be available.
3.3. SAV Rule Generation
Figure 2 shows the SAV rule generation process of the SAVNET router
acting as validation entity. The SAV Information Manager of SAVNET
Agent consolidates SAV-specific information from Information Receiver
and local routing information from RIB/FIB into the SAV Information
Base. Then, it sends the consolidated information to the SAV Rule
Generator. The SAV Rule Generator will generate SAV rules (e.g.,
tuples like <prefix, interface set, validity state>) based on the
consolidated information.
SAV Information Manager also provides the support of diagnosis.
Operators can look up the information in SAV Information Base for
monitoring or troubleshooting purpose.
Li, et al. Expires 25 April 2024 [Page 7]
Internet-Draft Intra-domain SAVNET Architecture October 2023
+--------------------------------------------------------+
| SAVNET Agent |
| |
| SAV-specific information Local routing information |
| from Information Receiver from RIB/FIB |
| | | |
| | | |
| +---v-------------------v----+ |
| | SAV Information Manager | |
| | +------------------------+ | |
| | | SAV Information Base | | |
| | +------------------------+ | |
| +----------------------------+ |
| | |
| | SAV-related information |
| | |
| +-------------v--------------+ |
| | SAV Rule Generator | |
| | +------------------------+ | |
| | | SAV Rules | | |
| | +------------------------+ | |
| +----------------------------+ |
+--------------------------------------------------------+
Figure 2: Workflow of SAV rule generation
As mentioned in Section 3, validation entity can be either an edge
router or a border router. According to the definition of intra-
domain SAV proposed in
[I-D.ietf-savnet-intra-domain-problem-statement], the edge router is
responsible for validating packets received from the connected subnet
and blocking those with source addresses of other subnets. While the
border router is responsible for validating packets received from
other ASes and blocking those with source addresses in internal
source prefixes. Therefore, the working mechanisms of SAVNET Agents
of edge router and border router are different, especially in the
incremental/partial deployment scenario.
For an edge router acting as validation entity, it should first
combine the local routing information and the SAV-specific
information to obtain the complete source prefixes of each connected
subnet. Then, it binds the source prefixes of the subnet to its
interface connected to the subnet, and conduct SAV at this interface.
Packets arriving at the interface will be considered invalid and
should be blocked, if their source addresses do not belong to the
subnet. In the incremental/partial deployment scenario where not all
edge routers connected to the same subnets deploy SAV-specific
information communication mechanism, an edge router acting as
Li, et al. Expires 25 April 2024 [Page 8]
Internet-Draft Intra-domain SAVNET Architecture October 2023
validation entity may not be able to identify complete source
prefixes of the subnet. To avoid improper block problems in this
case, validation entity is recommended to use less strict SAV rules.
For example, it can choose to only block packets with non-global or
non-routable source addresses by using its local routing information.
For a border router acting as validation entity, it should combine
the local routing information and the SAV-specific information to
collect all internal source prefixes, i.e., the source prefixes of
all internal subnets. Then, it binds the internal source prefixes to
the interfaces connected to other ASes and conducts SAV at these
interfaces. Packets arriving at these interfaces will be considered
invalid and should be blocked, if their source addresses belong to
internal source prefixes. In the incremental/partial deployment
scenario where not all edge routers in the intra-domain network
deploy SAV-specific information communication mechanism, a border
router acting as validation entity may not be able to get complete
internal source prefixes. In this scenario, the border router can
still block inbound packets with source addresses belonging to the
learned internal source prefixes. In addition, if the border router
also implements inter-domain SAVNET, its intra-domain SAVNET Agent
SHOULD send the intra-domain SAV-specific information to its inter-
domain SAVNET Agent, helping the inter-domain SAVNET Agent generate
inter-domain SAV rules or inter-domain SAV-specific information.
4. Use Cases
This section uses two use cases to illustrate that intra-domain
SAVNET can achieve more accurate and efficient SAV than existing
intra-domain SAV mechanisms, both in the inbound and outbound
directions.
4.1. Use Case 1: Validating Outbound Packets from a Multi-homed Subnet
at Edge Routers
Figure 3 shows an asymmetric routing in the multi-homed subnet
scenario. This scenario has been proposed in
[I-D.ietf-savnet-intra-domain-problem-statement]. Subnet 1 has
prefix 10.0.0.0/15 and is attached to two edge routers, i.e., Router
1 and Router 2. Due to the inbound load balance strategy of Subnet
1, Router 1 only learns the route to sub prefix 10.1.0.0/16 from
Subnet 1, while Router 2 only learns the route to the other sub
prefix 10.0.0.0/16 from Subnet 1. After that, Router 1 or Router 2
learns the route to the other sub prefix through the intra-domain
routing protocol. The FIBs of Router 1 and Router 2 are shown in the
figure. Assume Subnet 1 may send outbound packets with source
addresses in sub prefix 10.0.0.0/16 to Router 1 for outbound load
balance.
Li, et al. Expires 25 April 2024 [Page 9]
Internet-Draft Intra-domain SAVNET Architecture October 2023
+-------------------------------------------------------------+
| AS |
| +----------+ |
| | Router 3 | |
| FIB on Router 1 +----------+ FIB on Router 2 |
| Dest Next_hop /\ \ Dest Next_hop |
| 10.1.0.0/16 Subnet 1 / \ 10.0.0.0/16 Subnet 1 |
| 10.0.0.0/16 Router 3 / \/ 10.1.0.0/16 Router 3 |
| +----------+ +----------+ |
| | Router 1 | | Router 2 | |
| +-----+#+--+ +-+#+------+ |
| /\ / |
| Outbound traffic with \ / Inbound traffic with |
| source IP addresses \ / destination IP addresses |
| of 10.0.0.0/16 \ \/ of 10.0.0.0/16 |
| Subnet 1 |
| (10.0.0.0/15 ) |
| |
+-------------------------------------------------------------+
Figure 3: A use case of outbound SAV
In this case, as described in
[I-D.ietf-savnet-intra-domain-problem-statement], strict uRPF at
Router 1 will improperly block legitimate packets with source
addresses in prefix 10.0.0.0/16 from Subnet 1 at interface '#',
because it only accepts packets with source addresses in prefix
10.1.0.0/16 from Router 1's interface '#' according to its local
routing information.
If intra-domain SAVNET is implemented in the network, Router 2 can
inform Router 1 that prefix 10.0.0.0/16 also belongs to Subnet 1 by
sending SAV-specific information to Router 1. Then, by combining
both local routing information and received SAV-specific information,
Router 1 learns that Subnet 1 owns both prefix 10.1.0.0/16 and prefix
10.0.0.0/16. Therefore, Router 1 will accept packets with source
addresses in prefix 10.1.0.0/16 and prefix 10.0.0.0/16 at interface
'#', so improper block can be avoided.
4.2. Use Case 2: Validating Inbound Packets from Other ASes at Border
Routers
Figure 4 shows the inbound SAV scenario which is proposed in
[I-D.ietf-savnet-intra-domain-problem-statement]. Router 3 and
Router 4 perform intra-domain SAV at interface '#' to block inbound
packets with spoofed internal source addresses.
Li, et al. Expires 25 April 2024 [Page 10]
Internet-Draft Intra-domain SAVNET Architecture October 2023
+ Packets with + Packets with
| spoofed P1/P2 | spoofed P1/P2
+--------------|---------------------------|----------+
| AS \/ \/ |
| +--+#+-----+ +---+#+----+ |
| | Router 3 +-------------->| Router 4 | |
| +----------+ +----------+ |
| / \ | |
| / \ | |
| \/ \/ \/ |
| +----------+ +----------+ +----------+ |
| | Router 1 | | Router 2 | | Router 5 | |
| +----------+ +----------+ +----------+ |
| \ / | |
| \ / | |
| \ / \/ |
| Subnet 1(P1) Subnet 2(P2) |
+-----------------------------------------------------+
Figure 4: A use case of inbound SAV
As described in [I-D.ietf-savnet-intra-domain-problem-statement], if
Router 3 and Router 4 deploy ACL-based ingress filtering, the
operator needs to manually generate and update ACL rules at Router 3
and Router 4 when internal source prefixes change. The operational
overhead of manually maintaining and updating ACL rules will be
extremely high, especially when there are multiple inbound validation
points.
If intra-domain SAVNET is implemented in the network, Router 1,
Router 2, and Router 5 will inform Router 3 and Router 4 of the
source prefixes of Subnet 1 and Subnet 2 by sending SAV-specific
information. The SAV-specific information communication will be
triggered if topology or prefix changes. For example, if Subnet 2
has a new source prefix P3, Router 5 will inform Router 3 and Router
4 of the new source prefix of Subnet 2 immediately. After receiving
SAV-specific information from other routers, Router 3 and Router 4
can identify internal source prefixes and detect their changes. In
this way, Router 3 and Router 4 can automatically generate and update
SAV rules at interface '#' to block inbound packets with internal
source addresses.
5. Meeting the Design Requirements of Intra-domain SAVNET
Intra-domain SAVNET architecture is proposed to meet the five design
requirements proposed in
[I-D.ietf-savnet-intra-domain-problem-statement].
Li, et al. Expires 25 April 2024 [Page 11]
Internet-Draft Intra-domain SAVNET Architecture October 2023
5.1. Accurate Validation
In the asymmetric routing scenario shown in Figure 3, the edge router
cannot identify the complete source prefixes of the connected subnet
only using the router's local routing information. As a result,
strict uRPF has improper block problems in the case of asymmetric
routing, because it only uses local routing information to generate
SAV rules.
Intra-domain SAVNET uses SAV-specific information and requires
routers to exchange SAV-specific information among each other. The
SAVNET router acting as validation entity can combine SAV-specific
information with local routing information to generate accurate SAV
rules. The use case in Figure 3 has shown that intra-domain SAVNET
can achieve more accurate SAV validation compared with strict uRPF in
asymmetric routing scenarios.
5.2. Automatic Update
In real intra-domain networks, the topology or prefixes of networks
may change dynamically. The SAV mechanism MUST automatically update
the SAV rules as the network changes. However, ACL-based SAV
mechanism requires manual efforts to accommodate to network dynamics,
resulting in high operational overhead.
Intra-domain SAVNET allows SAVNET routers to exchange the changes of
SAV-specific information among each other automatically. After
receiving updated SAV-specific information from source entity, SAVNET
routers acting as validation entity can generate and update their SAV
rules accordingly. The use case in Section 4.2 has shown that intra-
domain SAVNET can achieve automatic update.
5.3. Incremental/Partial Deployment
Although an intra-domain network mostly has one administration,
incremental/partial deployment may still exist due to phased
deployment or multi-vendor supplement. In phased deployment
scenarios, SAV-specific information of non-deploying routers is not
available, so SAVNET routers acting as validation entity may not
obtain some needed SAV-specific information.
As described in Section 3.3, the architecture can adapt to
incremental/partial deployment. If complete SAV-specific information
cannot be learned by only SAV-specific information, local routing
information can be used to fill the gap. To mitigate the impact of
phased deployment, it is also RECOMMENDED that edge routers connected
to the same subnet can simultaneously adopt intra-domain SAVNET so
that the complete source prefixes of the subnet can be obtained by
Li, et al. Expires 25 April 2024 [Page 12]
Internet-Draft Intra-domain SAVNET Architecture October 2023
other routers. For example, in Figure 3, Router 1 and Router 2 are
recommended to be upgraded to SAVNET routers together so that the two
routers can obtain complete source prefixes of Subnet 1 and generate
accurate SAV rules.
In addition, SAVNET routers acting as validation entity are
RECOMMENDED to support flexible validation modes and perform SAV
filtering incrementally to smooth the transition from partial to full
deployment.
* Validation entity is RECOMMENDED to support flexible validation
modes such as interface-based prefix allowlist, interface-based
prefix blocklist, and prefix-based interface allowlist
[I-D.huang-savnet-sav-table]. The first two modes are interface-
scale, and the last one is device-scale. Under incremental/
partial deployment, validation entity SHOULD take on the proper
validation mode according to the deploying of source entity. For
example, if validation entity is able to get the complete set of
legitimate source prefixes arriving at a given interface,
interface-based prefix allowlist can be enabled at the given
interface, and improper block will not exist.
* Validation entity is RECOMMENDED to performed SAV-invalid
filtering incrementally. The router can first take conservative
actions on the validated data packets. That is to say, the router
will not directly discard packets with invalid results in the
beginning of deployment. It can conduct sampling action for
measurement analysis at first, and then conducts rate-limiting
action or redirecting action for packets with invalid results.
These conservative actions will not result in serious consequences
if some legitimate packets are mistakenly considered invalid,
while still providing protection for the network. Finally,
filtering action is enabled only after confirming that there are
no improper block problems.
5.4. Convergence
When the SAV-specific information or local routing information
changes, the SAVNET Agent MUST be able to detect the changes in time
and update SAV rules with the latest information. Otherwise,
outdated SAV rules may cause legitimate packets to be blocked or
spoofed packets to be accepted.
Intra-domain SAVNET requires routers to update SAV-specific
information and SAV rules in a timely manner. Since SAV-specific
information is originated from source entity, it requires that the
source entity MUST timely send the updated SAV-specific information
to validation entity. Consider that both routing information and
Li, et al. Expires 25 April 2024 [Page 13]
Internet-Draft Intra-domain SAVNET Architecture October 2023
SAV-specific information of a subnet are originated and advertised to
other routers in the network by the edge router connected to the
subnet, SAV-specific information SHOULD have a similar propagation
speed as routing information. Therefore, the converging speed of
intra-domain SAVNET is also similar as routing protocol.
5.5. Security
Typically, routers in an intra-domain network can trust each other
because they would not compromise intra-domain control-plane
architectures and protocols.
However, in some unlikely cases, some routers may do harm to other
routers within the same domain. Operators SHOULD be aware of
potential threats involved in deploying the architecture. Some
potential threats and solutions are as follows:
* Entity impersonation.
- Potential solution: Mutual authentication SHOULD be conducted
before session establishment between two entities.
- Gaps: Impersonation may still exist due to credential theft,
implementation flaws, or entity being compromised. Some other
security mechanisms can be taken to make such kind of
impersonation difficult. Besides, the entities SHOULD be
monitored so that misbehaved entities can be detected.
* Message blocking.
- Potential solution: Acknowledgement mechanisms MUST be provided
in the session between a sender and a receiver, so that message
losses can be detected.
- Gaps: Message blocking may be a result of DoS/DDoS attack, man-
in-the-middle (MITM) attack, or congestion induced by traffic
burst. Acknowledgement mechanisms can detect message losses
but cannot avoid message losses. MITM attacks cannot be
effectively detected by acknowledgement mechanisms.
* Message alteration.
- Potential solution: An authentication field can be carried by
each message so as to ensure message integrity.
- Gaps: More overhead of control plane and data plane will be
induced.
Li, et al. Expires 25 April 2024 [Page 14]
Internet-Draft Intra-domain SAVNET Architecture October 2023
* Message replay.
- Potential solution: Authentication value can be computed by
adding a sequence number or timestamp as input.
- Gaps: More overhead of control plane and data plane will be
induced.
To meet the security requirement, the above security threats SHOULD
be considered when designing the new intra-domain SAV mechanism.
6. Manageability Considerations
The architecture provides a general framework for communicating SAV-
specific information between routers and generating SAV rules based
on SAV-specific information and local routing information. Protocol-
independent mechanisms SHOULD be provided for operating and managing
SAV-related configurations. For example, a YANG data model for SAV
configuration and operation is necessary for the ease of management.
SAV may affect the normal forwarding of data packets. The diagnosis
approach and necessary logging information SHOULD be provided. SAV
Information Base SHOULD store some information that may not be useful
for SAV rule generation but is helpful for management.
The SAV-specific information communication mechanism SHOULD have
monitoring and troubleshooting functions, which are necessary for
efficiently operating the architecture.
7. Privacy Considerations
An intra-domain network is mostly operated by a single organization
or company, and the advertised SAV-specific information is used
within the network. Therefore, the architecture will not import
critical privacy issues in usual cases.
8. IANA Considerations
This document has no IANA requirements.
9. Acknowledgements
Many thanks to the valuable comments from: Igor Lubashev, Alvaro
Retana, Aijun Wang, Joel Halpern, Jared Mauch, Kotikalapudi Sriram,
Rüdiger Volk, Jeffrey Haas, Xiangqing Chang, Changwang Lin, etc.
10. References
10.1. Normative References
Li, et al. Expires 25 April 2024 [Page 15]
Internet-Draft Intra-domain SAVNET Architecture October 2023
[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-02, 17 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-problem-statement-02>.
[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, and L. Chen,
"Source Address Validation Table Abstraction and
Application", Work in Progress, Internet-Draft, draft-
huang-savnet-sav-table-01, 6 March 2023,
<https://datatracker.ietf.org/doc/html/draft-huang-savnet-
sav-table-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>.
10.2. Informative References
[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>.
[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>.
Li, et al. Expires 25 April 2024 [Page 16]
Internet-Draft Intra-domain SAVNET Architecture October 2023
[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>.
[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>.
[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>.
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
Tsinghua University
Beijing
China
Email: qlc19@mails.tsinghua.edu.cn
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Li, et al. Expires 25 April 2024 [Page 17]
Internet-Draft Intra-domain SAVNET Architecture October 2023
Li Chen
Zhongguancun Laboratory
Beijing
China
Email: lichen@zgclab.edu.cn
Mingqing Huang
Huawei
Beijing
China
Email: huangmingqing@huawei.com
Fang Gao
Zhongguancun Laboratory
Beijing
China
Email: gaofang@zgclab.edu.cn
Li, et al. Expires 25 April 2024 [Page 18]