Intra-domain Source Address Validation (SAVNET) Architecture
draft-li-savnet-intra-domain-architecture-00
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 , Fang Gao , Nan Geng , Tianran Zhou | ||
| Last updated | 2022-10-24 | ||
| 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-00
Network Working Group D. Li
Internet-Draft J. Wu
Intended status: Standards Track L. Qin
Expires: 27 April 2023 Tsinghua University
F. Gao
Zhongguancun Laboratory
N. Geng
T. Zhou
Huawei
24 October 2022
Intra-domain Source Address Validation (SAVNET) Architecture
draft-li-savnet-intra-domain-architecture-00
Abstract
Intra-domain source address validation (SAV) plays an important role
in defending against source address spoofing attacks in intra-domain
networks. However, existing intra-domain SAV mechanisms have the
problems of inaccurate validation, high operational overhead, and
limited protection. To overcome these problems and improve intra-
domain SAV, this document proposes an overall architecture of source
address validation in intra-domain network (named as Intra-domain
SAVNET). Intra-domain SAVNET discovers the real data-plane
forwarding path via hop-by-hop message propagation and helps intra-
domain routers generate accurate SAV tables.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 8174 [RFC8174].
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."
Li, et al. Expires 27 April 2023 [Page 1]
Internet-Draft Intra-domain SAVNET Architecture October 2022
This Internet-Draft will expire on 27 April 2023.
Copyright Notice
Copyright (c) 2022 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Goals of Intra-domain SAVNET . . . . . . . . . . . . . . . . 4
4. Control-plane Architecture . . . . . . . . . . . . . . . . . 5
4.1. Process for SAV Rule Generation . . . . . . . . . . . . . 5
4.2. Process for Source Prefix Identification . . . . . . . . 10
4.2.1. Source Prefix Identification for Interface
Addresses . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Source Prefix Identification for Single-homed
Subnet . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. Source Prefix Identification for Multi-homed
Subnet . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Message Type . . . . . . . . . . . . . . . . . . . . . . 12
4.3.1. SPD Message . . . . . . . . . . . . . . . . . . . . . 12
4.3.2. SPA Message . . . . . . . . . . . . . . . . . . . . . 12
4.3.3. Extended SPA message . . . . . . . . . . . . . . . . 13
5. Data-plane Architecture . . . . . . . . . . . . . . . . . . . 13
5.1. SAV Table Format . . . . . . . . . . . . . . . . . . . . 14
5.2. Data-plane SAV Operation . . . . . . . . . . . . . . . . 14
6. Accuracy Consideration . . . . . . . . . . . . . . . . . . . 15
6.1. Factors that Affect Source Prefix Identification . . . . 15
6.2. Factors that Affect Source Path Discovery . . . . . . . . 16
6.2.1. FIB Forwarding . . . . . . . . . . . . . . . . . . . 16
6.2.2. ACL Redirection . . . . . . . . . . . . . . . . . . . 16
6.2.3. Tunneling Technology . . . . . . . . . . . . . . . . 17
7. Convergence Consideration . . . . . . . . . . . . . . . . . . 17
7.1. Source Prefix Change . . . . . . . . . . . . . . . . . . 18
7.2. Forwarding Path Change . . . . . . . . . . . . . . . . . 18
7.3. FRR Deployment . . . . . . . . . . . . . . . . . . . . . 19
8. Incremental Deployment . . . . . . . . . . . . . . . . . . . 19
Li, et al. Expires 27 April 2023 [Page 2]
Internet-Draft Intra-domain SAVNET Architecture October 2022
9. Security Consideration . . . . . . . . . . . . . . . . . . . 20
10. Normative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
Source address validation (SAV) is important to mitigate source
address spoofing and contribute to the Internet security. Source
Address Validation Architecture (SAVA) [RFC5210] divides SAV into
three checking levels, i.e., access-network SAV, intra-domain SAV,
and inter-domain SAV. When an access network does not deploy SAV at
the source (e.g., SAVI), intra-domain SAV helps block spoofed packets
as close to the source as possible. However, existing intra-domain
SAV mechanisms have the problems of inaccurate validation, high
operational overhead, and limited
protection[draft-li-savnet-intra-domain-problem-statement], resulting
in legitimate packets being discarded or spoofed packets being
permitted. To effectively prevent intra-domain source address
spoofing and facilitate the deployment of SAV, a new intra-domain SAV
mechanism is required to achieve accurate SAV, acceptable overhead,
and all-direction protection.
For this purpose, this document provides an architecture to generate
accurate SAV tables on routers in intra-domain networks. In Intra-
domain Source Address Validation (Intra-domain SAVNET) architecture,
every router originates individual control-plane messages to its
neighbors, carrying information used for SAV table generation. Upon
receiving a message, the router can identify a valid incoming
interface for the related source address prefixes. After that, it
will further propagate this information to generate SAV tables at
other routers, or terminate the propagation.
This document also describes basic considerations related to intra-
domain SAVNET, including accuracy, convergence, incremental
deployment, and security. This document does not describe how to
implement intra-domain SAVNET using existing routing protocols, which
will be defined in other documents.
2. Terminology
SAV rule: The rule that defines valid incoming interfaces for the
specific source prefix.
SAV table: The data structure that stores SAV rules on the data
plane.
Li, et al. Expires 27 April 2023 [Page 3]
Internet-Draft Intra-domain SAVNET Architecture October 2022
Improper block: The packets with legitimate source IP addresses are
blocked improperly due to inaccurate SAV rules.
Improper permit: The packets with spoofed source IP addresses are
accepted due to inaccurate SAV rules.
SPA message: Source Prefix Advertisement message, the message (in
intra-domain SAVNET architecture) for a router advertising its source
prefixes and router ID to all the other routers in the intra-domain
network.
SPD message: Source Path Discovery message, the message (in intra-
domain SAVNET architecture) for discovering real data-plane
forwarding paths. Through it, a router notifies the valid incoming
direction for its source prefixes to other routers on the data-plane
forwarding path.
3. Goals of Intra-domain SAVNET
To make improvements to existing intra-domain SAV, intra-domain
SAVNET aims to achieve the following goals:
* Validating the authenticity of the source address for traffic
received from all directions (including traffic received from
directly connected subnets and neighboring routers).
* Ensuring the accuracy of SAV rules and avoiding improper block as
well as improper permit. At least, avoiding improper block and
minimize improper permit.
* Reducing the operation and implementation cost for SAV deployment.
As described in [draft-li-savnet-intra-domain-problem-statement],
existing intra-domain SAV mechanism, i.e. ingress
filtering[RFC2827][RFC3704], cannot meet the above goals.
Specifically, ingress filtering is typically deployed on edge routers
and only performs SAV for traffic received from directly connected
subnets, making it completely vulnerable to spoofed traffic received
from other directions. Besides, ingress filtering mechanisms, such
as ACL-based SAV and strict uRPF, either require manual configuration
or suffer from severe improper block in the case of asymmetric
routing, which cannot meet both the requirements of low cost and high
accuracy simultaneously.
Li, et al. Expires 27 April 2023 [Page 4]
Internet-Draft Intra-domain SAVNET Architecture October 2022
To address the problems of existing intra-domain SAV mechanisms,
intra-domain SAVNET requires routers to exchange information used for
SAV through control-plane protocols and generates SAV tables strictly
following real data-plane forwarding paths. The cost of intra-domain
SAV includes the communication cost for SAV table generation and the
storage and querying cost of SAV table. These costs should be
reduced to a reasonable level under current equipment hardware and
software conditions.
4. Control-plane Architecture
To achieve the goals in Section 3, the basic procedures of intra-
domain SAVNET is to discover the real data-plane forwarding path from
the source via hop-by-hop path discovery, and generate SAV rules in
routers along the path. Overall, six different operations will be
conducted in the procedures:
* Source prefix identification: A router identifies its local source
prefixes (including source prefixes of its subnets and its
interface addresses)
* Source prefix advertisement: A router generates SPA messages and
propagates them to other intra-domain routers.
* SPD origination: A router generates original SPD messages to
neighboring routers.
* SPD relaying: A router generates relaying SPD messages after
receiving an SPD message.
* SPD termination: A router terminates the received SPD message.
* SAV rule generation: A router generates SAV rules after
identifying the source prefixes of its subnets or receiving an SPD
message from a neighboring router.
4.1. Process for SAV Rule Generation
The process for SAV rule generation is briefly described as follows:
Li, et al. Expires 27 April 2023 [Page 5]
Internet-Draft Intra-domain SAVNET Architecture October 2022
a. Each router A first conducts the operation of source prefix
identification to identify its local source prefixes and
generates SAV rules for its directly connected subnets (if any).
Specifically, for each directly connected subnet N, it generates
the SAV rule <source prefixes of subnet N, interface X>, where
interface X is the interface connected to the subnet. The
process of source prefix identification will be introduced in
Section 4.2.
b. Router A advertises its local source prefixes and its router ID
by sending SPA messages to other routers within the AS. Finally,
routers can learn the mapping relationship between router IDs and
intra-domain source prefixes.
c. Router A conducts the operation of SPD origination. It sends one
SPD message to every next-hop neighboring router according to its
local FIB (Forwarding Information Base), carrying two fields:
* Origin router ID: the router ID of itself (i.e., A);
* Propagation scope: the destination prefixes which take the
neighboring router as the next hop from local FIB.
d. When the neighboring Router B receives the SPD message at
interface I, it first conducts the operation of SAV rule
generation. Router B gets the source prefixes corresponding to
the origin router ID A based on mapping relationship information
learned in step b, and determines interface I as a valid incoming
interface for source prefixes of Router A. In other words, it
generates the SAV rule <source prefixes of Router A, interface
I>.
e. After that, Router B checks the destination prefixes in the
propagation scope field of the received SPD message against its
local FIB. If the propagation scope only contains its local
source prefixes, Router B conducts the operation of SPD
termination. Otherwise, Router B conducts the operation of SPD
relaying: It groups these destination prefixes according to their
next-hop routers. For each next-hop Router C, Router B generates
a relaying SPD message to C. The new propagation scope field
contains the corresponding destination prefixes which take Router
C as the next hop. The origin router ID in every relaying SPD
message should keep the same as the received message.
f. The other routers that receive SPD messages will do the same
processing as in step d and step e.
Li, et al. Expires 27 April 2023 [Page 6]
Internet-Draft Intra-domain SAVNET Architecture October 2022
g. The above steps will be executed periodically or when any source
prefix or routing state changes. Periodical or triggered SPA and
SPD messages aim to update SAV rules on the affected routers.
Particularly, to reduce the communication cost, only the changed
information should be propagated again in the triggered update
messages. Intra-domain SAVNET does not explicitly notify routers
to withdraw invalid SAV rules, but uses an aging mechanism. The
SAV rule will expire if it is not refreshed in the next
periodical update process. The aging mechanism helps improve the
resilience and avoid improper block in the case of transient
route behaviors, since the SAV table does not delete the
"invalid" SAV rule immediately.
+-----------+
----------------------------------| Router 1 #---+P1
| +-----+-----+
| | msg 1:
| | origin_router_ID=[R1],
| | propagation_scope=[P2,P3,
| msg 1.1: | P4,P5,P6]
| origin_router_ID=[R1], \/
+-----+-----+ propagation_scope=[P6] +-----#-----+
| Router 6 #<--------------------------+ Router 2 +---+P2
+-----+-----+ ----------------------+-----+-----+
| | msg 1.2: | msg 1.3:
+ | origin_router_ID=[R1], | origin_router_ID=[R1],
P6 | propagation_scope=[P3,P5] | propagation_scope=[P4,P5]
\/ \/
+-----#-----+ +-----#-----+
P3---+ Router 3 | P4---+ Router 4 |
+-----+-----+ +-----+-----+
| msg 1.2.1: | msg 1.3.1:
| origin_router_ID=[R1], | origin_router_ID=[R1],
| propagation_scope=[P5] | propagation_scope=[P5]
\/ |
+-----#-----+ |
P5--- + Router 5 # <--------------------
+-----------+
- P1, P2, P3, P4, P5, and P6 are the source prefixes of
Router 1, 2, 3, 4, 5, and 6, respectively.
- R1, R2, R3, R4, R5, and R6 are the router IDs of
Router 1, 2, 3, 4, 5, and 6, respectively.
- '#' means the valid incoming interface for the
data-plane packets with source addresses of P1.
- The FIB of Router 1:
+---------------------------------------+
Li, et al. Expires 27 April 2023 [Page 7]
Internet-Draft Intra-domain SAVNET Architecture October 2022
+ Dest. Prefix | Next hop +
+---------------------------------------+
+ P2 | Router 2 +
+ P3 | Router 2 +
+ P4 | Router 2 +
+ P5 | Router 2 +
+ P6 | Router 2 +
+---------------------------------------+
- The FIB of Router 2:
+---------------------------------------+
+ Dest. Prefix | Next hop +
+---------------------------------------+
+ P1 | Router 1 +
+ P3 | Router 3 +
+ P4 | Router 4 +
+ P5 | Router 3/4 +
+ P6 | Router 6 +
+---------------------------------------+
- The FIB of Router 3:
+---------------------------------------+
+ Dest. Prefix | Next hop +
+---------------------------------------+
+ P1 | Router 2 +
+ P2 | Router 2 +
+ P4 | Router 2 +
+ P5 | Router 5 +
+ P6 | Router 2 +
+---------------------------------------+
Figure 1: The process for SAV rule generation
Figure 1 illustrates the process for SAV rule generation by taking
the process of generating SAV rules for source prefix P1 as an
example. There are six routers in the intra-domain network. Each
router is connnected to a subnet.
Li, et al. Expires 27 April 2023 [Page 8]
Internet-Draft Intra-domain SAVNET Architecture October 2022
Router 1 first identifies its source prefix P1 (we omit the interface
addresses for brevity) and generates the SAV rule <P1, interface
'#'>. Then, it conducts the operation of source address
advertisement and advertises prefix P1 and its router ID R1 to other
routers. After that, as shown in Figure 1, Router 1 conducts the
operation of SPD origination to notify other routers of the valid
incoming direction for prefix P1. From the FIB of Router 1, P2, P3,
P4, P5, P6 take Router 2 as the next hop, so Router 1 generates an
original SPD message to Router 2, with R1 in the origin router ID
field and P2, P3, P4, P5, P6 in the propagation scope field.
Although Router 6 is also a neighboring router of Router 1, Router 1
does not send any SPD message to Router 6 because no prefix takes
Router 6 as the next hop from the FIB for Router 1.
When Router 2 receives the SPD message from Router 1 at interface
'#', it identifies the source prefix P1 for router ID R1 based on
previous SPA messages, and specifies interface '#' as the valid
incoming interface for prefix P1. Then, Router 2 checks the
destination prefixes in the propagation scope field against its local
FIB. P2 is the source prefix of Router 2, so P2 is directly deleted
from the propagation scope. From the FIB of Router 2 (note that
Router 2 has multiple paths to P5), P3 and P5 take Router 3 as the
next hop; P4 and P5 take Router 4 as the next hop; P6 takes Router 6
as the next hop. Therefore, Router2 conducts the operation of SPD
relaying and generates an individual relaying SPD message to Router
3, 4, 6, respectively. The relaying SPD message destined to each
next-hop router carries corresponding destination prefixes in the new
propagation field. The origin router ID in every relaying SPD
message keeps the same as the received SPD message.
When Router 3 or Router 4 receives the relaying SPD message from
Router 2, it first generates the SAV rule <P1, interface '#'> and
then generates a relaying SPD message to Router 5 because P5 takes
Router 5 as the next hop in its FIB.
When Router 6 receives the relaying SPD message from Router 2, it
generates the SAV rule <P1, interface '#'> but conducts the operation
of SPD termination because the propagation scope only contains P6
which is the source prefix of itself. Similarly, upon receiving the
relaying SPD message from Router 3 or Router 4, Router 5 generates
the SAV rule <P1, interface '#'> and then conducts the operation of
SPD termination. It is noted that Router 5 finally determines two
valid incoming interfaces for source prefix P1 because it receives
two SPD messages with an origin router ID of R1 from different
interfaces.
Li, et al. Expires 27 April 2023 [Page 9]
Internet-Draft Intra-domain SAVNET Architecture October 2022
In the end, all routers accurately learn the valid incoming
interfaces for source prefix P1. The process of generating SAV rules
for other source prefixes is similar. In intra-domain SAVNET, with
the exception of some special cases, such as multipath routing,
routers usually receive only one SPD message originated from each
origin router.
4.2. Process for Source Prefix Identification
The local source prefixes of a router include its interface addresses
and the source prefixes of its subnets.
4.2.1. Source Prefix Identification for Interface Addresses
To identify router interface addresses, the router can obtain these
prefixes directly from local interface configuration information.
4.2.2. Source Prefix Identification for Single-homed Subnet
To identify source prefixes of a single-homed subnet, the router can
easily identify the source prefixes through local routes to the
subnet (such as direct interface routes, configured static routes, or
dynamic routes imported from the subnet).
4.2.3. Source Prefix Identification for Multi-homed Subnet
However, as described in
[draft-li-savnet-intra-domain-problem-statement], the router may not
identify complete source prefixes of a multi-homed subnet through
local routes to the subnet in the case of routing asymmetry. Hence,
an extended SPA message is introduced to exchange local route
information between the multiple access routers to get the complete
source prefixes.
Li, et al. Expires 27 April 2023 [Page 10]
Internet-Draft Intra-domain SAVNET Architecture October 2022
+--------------------------------------------------------------------+
| AS |
| |
| [10.1.0.0/16]+[tag n] |
| +----------+ -----------------------------------> +----------+ |
| | Router A | Extended SPA messages | Router B | |
| +-------#--+ <----------------------------------+ +--#-------+ |
| | [10.0.0.0/16]+[tag n] | |
| | | |
| | | |
| | | |
| | +----------+ | |
| +---------------+ Subnet N +-------------------+ |
| +----------+ |
| (10.0.0.0/15 ) |
+--------------------------------------------------------------------+
- Asymmetric routing:
1) Router A only learns 10.1.0.0/16 from its local route to Subnet N
2) Router A only learns 10.0.0.0/16 from its local route to Subnet N
- Interfaces '#' in Router A and Router B are configured with tag n.
Figure 2: Source prefix identification for multi-homed subnet in an asymmetric routing scenario.
Figure 2 shows the process of source prefix identification for the
multi-homed subnet in an asymmetric routing scenario:
a. In intra-domain SAVNET architecture, each multi-homed subnet is
assigned a unique tag value and all router interfaces connected
to the same multi-homed subnet are configured with the
corresponding tag value. Assume Subnet N is assigned the tag n.
Interfaces '#' in Router A and Router B are both configured with
tag n.
b. Each of the multiple access routers (e.g., Router A) will
generate extended SPA messages to advertise the prefixes learned
through its local routes to the multi-homed subnet and the
corresponding tag value. For example, Router A will generate
extended SPA messages to other intra-domain routers carrying
prefix 10.1.0.0/16 (which is identified through its local route
to Subnet N) and tag n.
c. When Router B receives an extended SPA message carrying the same
tag value as the tag value of its directly connected Subnet N, it
considers the prefix (i.e., 10.1.0.0/16) in the extended SPA
message as part of the source prefixes of Subnet N.
Li, et al. Expires 27 April 2023 [Page 11]
Internet-Draft Intra-domain SAVNET Architecture October 2022
d. Router B finally integrates the prefix 10.1.0.0/16 learned in
step c with the prefix 10.0.0.0/16 learned from its local routes
to Subnet N for the complete source prefix 10.0.0.0/15 of Subnet
N. Similarly, Router A also identifies the complete source
prefix 10.0.0.0/15 of Subnet N after receiving an extended SPA
message originated from Router B.
4.3. Message Type
4.3.1. SPD Message
SPD message is used to discover the real forwarding data-plane path
from the source and generate SAV rules in routers along the path. As
shown in Figure 3, the SPD message consists of two main fields:
* Origin Router ID: This field contains the router ID of the origin
router and remains unchanged.
* Propagation Scope: This field contains a list of destination
prefixes which take the neighboring router as the next hop (from
FIB) and changes hop by hop.
/ +-----------------------+
+-----------------------+ / | Dest Prefix 1 |
| Origin Router ID | / +-----------------------+
+-----------------------+ / | Dest Prefix 2 |
| Propagation Scope | +-----------------------+
+-----------------------+ \ | ...... |
\ +-----------------------+
\ | Dest Prefix n |
\ +-----------------------+
Figure 3: SPD message format
4.3.2. SPA Message
SPA message is used to advertise the relationship between source
prefixes and router IDs. As shown in Figure 4, the SPA message has
two main fields:
* Origin Router ID: This field contains the router ID of the origin
router.
* Source Prefix List: This field contains a list of local source
prefixes of the origin router.
Li, et al. Expires 27 April 2023 [Page 12]
Internet-Draft Intra-domain SAVNET Architecture October 2022
/ +-----------------------+
+-----------------------+ / | Source Prefix 1 |
| Origin Router ID | / +-----------------------+
+-----------------------+ / | Source Prefix 2 |
| Source Prefix List | +-----------------------+
+-----------------------+ \ | ...... |
\ +-----------------------+
\ | Source Prefix n |
\ +-----------------------+
Figure 4: SPA message format
4.3.3. Extended SPA message
The extended SPA message is used for source prefix identification for
multi-homed subnet. As described in Section 4.2.3 and shown in
Figure 5, the extended SPA message has three main fields:
* Origin Router ID: This field contains the router ID of the origin
router.
* Tag: This field contains a tag value configured for a connected
subnet.
* Source Prefix List: This field contains a list of source prefixes
learned through local routes to the connected subnet whose tag is
filled in the Tag field.
+-----------------------+
| Origin Router ID | / +-----------------------+
+-----------------------+ / | Source Prefix 1 |
| Tag | / +-----------------------+
+-----------------------+ / | Source Prefix 2 |
| Source Prefix List | +-----------------------+
+-----------------------+ \ | ...... |
\ +-----------------------+
\ | Source Prefix n |
\ +-----------------------+
Figure 5: The extended SPA message format
5. Data-plane Architecture
Li, et al. Expires 27 April 2023 [Page 13]
Internet-Draft Intra-domain SAVNET Architecture October 2022
5.1. SAV Table Format
The format and organization way of the SAV table are similar to the
FIB table . As shown in Figure 6, the SAV table consists of two
parts: source prefix and incoming interface.
+------------------------------------------+
+ Source prefix | Incoming interface +
+------------------------------------------+
+ P1 | Intf.1 +
+ P2 | Intf.2, Intf.3 +
+ P3 | Intf.4 +
+------------------------------------------+
Figure 6: SAV table structure
5.2. Data-plane SAV Operation
When performing SAV for received data-plane packets, the router looks
up every packet's source address against its local SAV table, and
gets one of three validity states: "valid", "invalid" or "unknown".
"Valid" means that there is a source prefix in SAV table covering the
source address, and the corresponding valid incoming interfaces cover
the incoming interface of the packet. "Invalid" means there is a
source prefix in SAV table covering the source address, but the
incoming interface of the packet does not match the valid incoming
interfaces. "Unknown" means there is no source prefix in SAV table
covering the source address.
The router takes different actions based on the validity state of the
packet. If the state is "valid", the source address is considered as
a legitimate source address and the packet is permitted. If the
state is "invalid", the source address is considered as a spoofed
address and the packet is blocked. If the state is "unknown", the
packet is processed according to the validation mode configured on
the incoming interface. Intra-domain SAVNET allows the router to
configure individual validation modes for packets received from
different interfaces:
* Prefix Allowlist Mode: Prefix Allowlist Mode is only adopted when
the SAV table has determined all acceptable source prefixes for
the specific interface. For packets received from the interface
configured with Prefix Allowlist Mode, only "valid" packets are
accepted, while "invalid" and "unknown" packets are discarded.
The router usually configures this validation mode on the
interface connected to a local subnet. This mode corresponds to
"Mode 1" in [draft-huang-savnet-sav-table].
Li, et al. Expires 27 April 2023 [Page 14]
Internet-Draft Intra-domain SAVNET Architecture October 2022
* Interface Allowlist Mode: Interface Allowlist Mode is typically
adopted when the SAV table does not determine all acceptable
source prefixes for the specific interface. For packets received
from the interface configured with Interface Allowlist Mode,
"valid" and "unknown" packets are both accepted, while only
"invalid" packets are discarded. This mode corresponds to "Mode
3" in [draft-huang-savnet-sav-table].
More details about the SAV table can be found in
[draft-huang-savnet-sav-table].
6. Accuracy Consideration
The most important goal of intra-domain SAVNET is to improve
accuracy, i.e., avoid improper block problems and try best to reduce
improper permit problems. The key factors that can affect the
accuracy of intra-domain SAVNET mainly come from two aspects, i.e.
source prefix identification and source path discovery:
* Source prefix identification should cover all local source
prefixes. Otherwise, the Interface Allowlist Mode must be
adopted.
* Source path discovery should strictly discover the real data-plane
forwarding path. To ensure the accuracy of SAV rules, any factor
that can affect forwarding should be considered.
6.1. Factors that Affect Source Prefix Identification
Factors that should be considered in the process of source prefix
identification have been provided in Section 4.2. However, it is
still possible that the router can not recognize its complete local
source prefixes. For example, if a multi-homed subnet is connected
to two edge routers in different ISPs (Internet Service Provider),
the two edge routers are unable to exchange individual local source
prefix information through the routing protocol. Therefore, the two
edge router are unable to identify the complete source prefixes of
the multi-homed subnet in the case of routing asymmetry. It is also
difficult for a boundary router to fully identify source prefixes
that can be accepted from the interface connected to another
autonomous system, due to the existence of default route or
asymmetric route. To avoid improperly blocking legitimate traffic in
above cases, the router must adopt Interface Allowlist Mode when
validating traffic received from the specific interface.
Li, et al. Expires 27 April 2023 [Page 15]
Internet-Draft Intra-domain SAVNET Architecture October 2022
6.2. Factors that Affect Source Path Discovery
6.2.1. FIB Forwarding
FIB forwarding is the most common scenario in which intra-domain
SAVNET finds a single next-hop interface based on the destination
prefix, i.e., determining the next hop for forwarding based on
destination ip-prefix.
ECMP (Equal-cost multi-path routing) or UCMP (Unequal-cost multi-path
routing) is a special case for FIB forwarding. To achieve multi-path
routing, hashing functions are usually taken, which map packet header
field values (e.g., source/destination IP, source/destination port,
protocol type) to candidate next hops. Packets with the same
destination IP address may be forwarded to different next hops. In
this case, SPD messages must be sent to all these next hops, thus
generating SAV rules in routers on each ECMP/UCMP path.
6.2.2. ACL Redirection
ACL redirection can redirect traffic to a specific next hop, making
the forwarding behavior inconsistent with the FIB. In this case,
routers must take the configuration information of ACL redirection
into consideration when generating original and relaying SPD
messages.
Advanced ACL redirection rules typically match source IP, destination
IP, source port, destination port, or protocol type. When conducting
the operation of SPD message origination, the router needs to check
its local source prefixes and the destination prefixes in local FIB
against its ACL redirection rules:
* If the source prefix matches the ACL redirection rule, it adds all
destination prefixes in local FIB into the propagation scope of
the original SPD message sent to the redirected next hop.
* If the destination prefix matches the ACL redirection rule, it
adds the matched destination prefix into the propagation scope of
the original SPD message sent to the redirected next hop.
* If there is an ACL redirection rule that does not check source IP
and the destination IP, but checks only other fields, packets with
any source IP address or destination IP address has the
possibility to match this redirection rule. In this case, the
router needs to add all destination prefixes in local FIB into the
propagation scope of the original SPD message sent to the
redirected next hop.
Li, et al. Expires 27 April 2023 [Page 16]
Internet-Draft Intra-domain SAVNET Architecture October 2022
Similarly, when conducting the operation of SPD message relaying, the
router should also check the source prefixes of the origin router and
the destination prefixes in the propagation scope field against its
ACL redirection rules:
* If the source prefix matches, it adds all destination prefixes
carried in the received SPD message into the propagation scope of
the relaying SPD message sent to the redirected next hop.
* If the destination prefix matches, it adds the matched destination
prefix into the propagation scope of the relaying SPD message sent
to the redirected next hop.
* If there is an ACL redirection rule that does not check source IP
and the destination IP, but checks only other fields, it adds all
destination prefixes carried in the received SPD message into the
propagation scope of the relaying SPD message sent to the
redirected next hop.
6.2.3. Tunneling Technology
Tunnel technologies, such as MPLS, SR, and GRE, are usually used to
control the forwarding behavior. In the preliminary idea, intra-
domain SAVNET performs data-plane SAV only on routers before and
after the tunnel. The ingress router will directly send an SPD
message to the corresponding egress router based on local control-
plane information of tunnel technology. Upon receiving the SPD
message, the egress router will further generate relaying SPD
messages by checking the propagation scope against local FIB.
However, if there is a need to perform data-plane SAV for IP prefixes
used inside the IP-encapsulation tunnel (such as SRv6 and GRE), the
SPD message needs to be propagated from the ingress router to the
egress router hop by hop, thus generating SAV rules on routers inside
the tunnel.
7. Convergence Consideration
The factors influencing the accuracy of intra-domain SAVNET may
change with time. Such changes can lead to improper block or
improper permit problems. The SAV rules generated through intra-
domain SAVNET should be updated in time so as to keep consistent with
routing states. The convergence of intra-domain SAVNET is important
for the SAV architecture working well in dynamic networks.
A simple method is to generate new SPA and SPD messages periodically.
An aging mechanism can also be used for deleting invalid SAV rules.
That is, SAV rules will expire after a period of time. However,
Li, et al. Expires 27 April 2023 [Page 17]
Internet-Draft Intra-domain SAVNET Architecture October 2022
these solutions may take much time before eliminating improper block
and improper permit problems. Some fast convergence mechanisms are
necessary to achieve consistency of intra-domain SAVNET in time.
Except the aging process works as the basic mechanism, here are some
preliminary ideas for different cases:
7.1. Source Prefix Change
When source prefix changes, a router must generate new SPA messages
immediately upon discovering its local source prefixes change.
7.2. Forwarding Path Change
Since intra-domain SAVNET generates SAV rules following the real
data-plane forwarding path, SAV rules need to be updated when the
forwarding path changes. To achieve fast convergence, routers need
to generate triggered SPD messages to update SAV rules on other
routers as soon as possible. The process of triggered update is as
follows:
a. Initially, each Router A records the information (the origin
router ID and the propagation scope) of each received SPD message
locally. With this information, Router A knows which origin
routers have reached a specific destination prefix through
itself.
b. When Router A notices that the next hop to a destination prefix P
changes, Router A generates a triggered SPD message. Different
from the periodical SPD message, the triggered SPD message
carries not only the router ID of Router A but also router IDs of
other origin routers that previously reached the destination
prefix through Router A. The propagation scope of the triggered
SPD message only contains the destination prefix P. If those
origin routers do not change the next hop to destination prefix
P, they do not need to generate any triggered SPD messages.
c. When receiving a triggered SPD message at interface '#', Router B
identifies the interface '#' as the valid incoming interface for
source prefixes of all router IDs carried in the SPD message. It
then conducts the operation of SPD relaying or SPD termination
following the description in Section 4.1.
Li, et al. Expires 27 April 2023 [Page 18]
Internet-Draft Intra-domain SAVNET Architecture October 2022
When updating, there may still be a gap between the change of FIB
table and the update of SAV rules. The gap is inevitable, but the
triggered update mechanism of intra-domain SAVNET can enable the
fastest convergence of SAV rule generation. Moreover, the triggered
update mechanism requires as few routers as possible to participate
in the update process, which significantly reduces the protocol
overhead.
7.3. FRR Deployment
For the scenarios where fast reroute (FRR) is deployed, routers will
send SPD messages to the backup forwarding paths in advance, and the
backup SAV rules can be installed for fast convergence when failure
happens.
8. Incremental Deployment
In the intra-domain network, it is difficult to require all routers
to support intra-domain SAVNET simultaneously, because routers can
have different versions and capabilities. The incremental deployment
of intra-domain SAVNET must be considered.
In general, routers in the access layer are used to connect users to
the network and have relatively low capability. Routers in the
aggregation layer provides policy-based connectivity between access
and core layers. Routers in the core layer are mainly used for
routing selection and high-speed forwarding. Therefore, routers in
aggregation and core layers usually have higher capability,
performance, and reliability. In incremental deployment condition,
it is highly recommended to preferentially deploy intra-domain SAVNET
at routers in the aggregation and core layers to achieve more
effective SAV.
For example, in OSPF protocol, non-backbone areas need to pass
through the backbone area (i.e., Area 0) for communication. If
intra-domain SAVNET cannot be implemented on all intra-domain routers
at the same time, it is suggested to implement intra-domain SAVNET in
Area 0 as the first step, achieving wider protection scope with the
same implementation cost. Specifically, when only deploying intra-
domain SAVNET in Area 0, every ABR (Area Border Router) can originate
SPA and SPD messages on behalf of the directly connected non-backbone
area. In this way, every deployed router learns the valid incoming
interfaces for source addresses of individual non-backbone areas, and
thus preventing source address spoofing between different non-
backbone areas. Similarly, IS-IS protocol also divides backbone area
(i.e., Level 2) and non-backbone area (i.e., Level 1). In
Li, et al. Expires 27 April 2023 [Page 19]
Internet-Draft Intra-domain SAVNET Architecture October 2022
incremental deployment condition, it is recommended to implement
intra-domain SAVNET in Level 2 at the beginning. By starting from
the backbone area and expanding the deployment area hop by hop in the
non-backbone area, the overall defense capability against source
address spoofing provided by intra-domain SAVNET becomes stronger.
9. Security Consideration
As described in [draft-li-savnet-intra-domain-problem-statement],
similar to the security scope of intra-domain routing protocols
intra-domain SAVNET should ensure integrity and authentication of
protocol messages that deliver the required SAV information, but does
not provide protection against compromised or misconfigured routers
that poison existing control-plane protocols. Since intra-domain
SAVNET will be implemented by using or extending existing routing
protocols, it can use the security mechanism of existing routing
protocols to achieve this goal. Specific protocol extensions and
security designs will be included in a separate protocol extension
draft.
10. Normative References
[draft-huang-savnet-sav-table]
Huang, M., Zhou, T., Geng, N., Li, D., Chen, L., and J.
Wu, "Source Address Validation Table Abstraction and
Application", 24 October 2022.
[draft-li-savnet-intra-domain-problem-statement]
Li, D., Wu, J., Qin, L., Huang, M., and N. Geng, "Source
Address Validation in Intra-domain Networks (Intra-domain
SAVNET) Gap Analysis, Problem Statement and Requirements",
22 October 2022.
[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>.
Li, et al. Expires 27 April 2023 [Page 20]
Internet-Draft Intra-domain SAVNET Architecture October 2022
[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>.
[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>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
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
Fang Gao
Zhongguancun Laboratory
Beijing
China
Email: gaofang@zgclab.edu.cn
Li, et al. Expires 27 April 2023 [Page 21]
Internet-Draft Intra-domain SAVNET Architecture October 2022
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Tianran Zhou
Huawei
Beijing
China
Email: zhoutianran@huawei.com
Li, et al. Expires 27 April 2023 [Page 22]