Intra-domain Source Address Validation (SAVNET) Architecture
draft-li-savnet-intra-domain-architecture-03
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 , Mingqing(Michael) Huang , Li Chen , Nan Geng , Lancheng Qin , Fang Gao | ||
| Last updated | 2023-07-25 (Latest revision 2023-05-04) | ||
| 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-03
SAVNET D. Li
Internet-Draft J. Wu
Intended status: Informational Tsinghua University
Expires: 26 January 2024 M. Huang
Huawei
L. Chen
Zhongguancun Laboratory
N. Geng
Huawei
L. Qin
Tsinghua University
F. Gao
Zhongguancun Laboratory
25 July 2023
Intra-domain Source Address Validation (SAVNET) Architecture
draft-li-savnet-intra-domain-architecture-03
Abstract
This document proposes an intra-domain SAVNET architecture. Devices
in the intra-domain network can communicate with each other and
advertise SAV-specific information. SAV-specific information
explicitly or implicitly indicates the accurate incoming directions
of source addresses. With the advertised information, devices can
generate accurate SAV rules automatically. Under the incremental/
partial deployment of the architecture, routing information can be
used as a supplement of SAV-specific information for SAV rule
generation.
The architecture primarily introduces the SAV-specific information,
architectural components, and the collaborations between them.
Future intra-domain SAV mechanisms/protocols can be developed based
on the architecture. Concrete protocol extensions or implementations
are not the focus 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/.
Li, et al. Expires 26 January 2024 [Page 1]
Internet-Draft Intra-domain SAVNET Architecture July 2023
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 26 January 2024.
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SAV-Specific Information . . . . . . . . . . . . . . . . . . 6
4. Intra-domain SAVNET Architecture . . . . . . . . . . . . . . 6
4.1. Communication Channel . . . . . . . . . . . . . . . . . . 7
4.2. SAV-Specific Protocol . . . . . . . . . . . . . . . . . . 8
4.3. SAV Agent . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Use Case 1: Validating Packets from a Multi-homed Subnet at
Edge Routers . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Use Case 2: Validating Packets from Other Networks at
Border Routers . . . . . . . . . . . . . . . . . . . . . 12
6. Connectivity Models . . . . . . . . . . . . . . . . . . . . . 13
6.1. Example 1: Multiple Source Entities to One Validation
Entity . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Example 2: One Source Entity to Multiple Validation
Entities . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Example 3: One Acting as both Source and Validation
Entity . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Convergence Considerations . . . . . . . . . . . . . . . . . 14
8. Incremental/Partial Deployment Considerations . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Manageability Considerations . . . . . . . . . . . . . . . . 17
Li, et al. Expires 26 January 2024 [Page 2]
Internet-Draft Intra-domain SAVNET Architecture July 2023
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Source address validation (SAV) is important for mitigating source
address spoofing and contributing 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
(such as SAVI [RFC7039][RFC7513], Cable Source Verify [cable-verify],
and IP Source Guard [IPSG]), intra-domain SAV helps block spoofed
packets from the access network as close to the source as possible.
The concept of intra-domain SAV in this document keeps consistent
with that in [I-D.ietf-savnet-intra-domain-problem-statement].
The main task of SAV mechanisms is to generate SAV rules for checking
the validity of source addresses of data packets. The information of
source addresses/prefixes and their incoming directions makes up the
SAV rules. How to efficiently and accurately learn the information
is the core challenge for SAV mechanisms. There are many intra-
domain SAV mechanisms available such as ACL-based filtering
[RFC2827], strict uRPF [RFC3704], and loose uRPF [RFC3704]. SAV
rules are generated by either routing information or manual
configurations. However, they are faced with the problems of high
operational overhead and inaccurate validation in some scenarios
[I-D.ietf-savnet-intra-domain-problem-statement].
An intra-domain architecture is proposed in this document to address
the above issues. Consider that routing information is not accurate
enough for SAV rule generation. SAV-specific information is defined
which can provide more accurate incoming directions of source
addresses. For example, a route indicates that the next-hop of
address P1 is Intf. 1, while the packets with source address of P1
come from Intf. 2. SAV-specific information can be used to indicate
the real incoming interface of the address and replace the reverse
route looking up.
Under the architecture, devices can communicate with each other and
share SAV-specific information besides routing information. Accurate
SAV rules on devices can be automatically generated based on the
learned SAV-related information. When the architecture is partially
or incrementally deployed, complete SAV-specific information may not
Li, et al. Expires 26 January 2024 [Page 3]
Internet-Draft Intra-domain SAVNET Architecture July 2023
be available. Devices can leverage routing information for
generating SAV rules. By default, SAV-specific information has a
higher priority than routing information in case of information
conflicts.
This document presents the high-level designs for future intra-domain
SAV mechanisms. The definitions of SAV-specific information,
architectural components, and the collaborations between them are the
focus of the document. The main purpose is to provide a conceptual
framework and guidance for the development of intra-domain SAV
mechanisms, allowing implementers to adapt and implement the
architecture based on their specific requirements and network
environments. The protocols or protocol extensions for implementing
the architecture are not in the scope of this document.
1.1. Terminology
SAV Rule: The rule that indicates the validity of a specific source
IP address or source IP prefix.
SAV Table: The table or data structure that implements the SAV rules
and is used for source address validation.
SAV-related Information: Any information that is useful for getting
or generating SAV rules.
SAV-specific Information: The information specialized for SAV that
explicitly or implicitly indicates the accurate incoming directions
of source addresses.
SAV-specific Protocol: The protocols or protocol extensions for
delivering SAV-specific information.
SAV Agent: The component that stores SAV-related information,
consolidates the information, and outputs SAV rules to the SAV table.
SAV Information Base: A table or data structure for storing SAV-
related information.
False Positive: The validation results that the packets with
legitimate source IP addresses are considered "invalid" due to
inaccurate SAV rules.
False Negative: The validation results that the packets with spoofed
source IP addresses are considered "valid" due to inaccurate SAV
rules.
Li, et al. Expires 26 January 2024 [Page 4]
Internet-Draft Intra-domain SAVNET Architecture July 2023
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. Design Goals
The intra-domain SAVNET architecture is to enhance the intra-domain
SAV and aims to achieve the following goals:
* Automatic Update. The devices after initial configurations can
adapt to dynamic routing changes automatically, so that the
operational overhead can be controlled.
* Accurate Validation. The real incoming interfaces of source
prefixes need to be completely learned, and false positive can be
avoided. By trying to exclude non-real incoming interfaces from
the valid interface group, false negative can be reduced.
* Working in Incremental/Partial Deployment. The architecture
should be no worse than existing mechanisms under incremental/
partial deployment.
Existing SAV mechanisms mostly rely on routing information for
automatically generating SAV rules. However, route decides the
outgoing interface of source address while SAV focuses on the
incoming interface. Therefore, in some cases, routing information
cannot support accurate rule generation. The information
specifically useful to accurate SAV is required. Manually
configuring such information on devices is not practical especially
in large-scale and dynamic networks.
To achieve the above goals, the architecture proposes to allow
devices to advertise SAV-specific information automatically. The
SAV-specific information will provide more accurate incoming
directions of source addresses than routing information. Devices
receiving the information will be able to generate accurate SAV
rules. Since the updates of SAV-specific information will be
advertised proactively, the generated SAV rules can be automatically
updated. By properly utilizing routing information, the architecture
can also work in incremental/partial deployment
Li, et al. Expires 26 January 2024 [Page 5]
Internet-Draft Intra-domain SAVNET Architecture July 2023
3. SAV-Specific Information
SAV-related information represents any information that is useful for
getting or generating SAV rules. There are largely two kinds of SAV-
related information: routing information and SAV-specific
information.
Routing information is used for forwarding rule computation, which
mostly stored in RIB/FIB. It is not specialized for SAV but can be
used to some extent for SAV. Existing SAV mechanisms like strict
uRPF and loose uRPF conduct SAV solely based on routing information.
SAV-specific information is specialized for SAV, which explicitly or
implicitly indicates the accurate incoming directions of source
addresses. Compared to using routing information, the accuracy of
SAV rules can be improved through SAV-specific information. The
false positive problems can be avoided and the false negative
problems can be reduced.
SAV-specific information can be various kinds of information on
devices. Some examples are as follows:
* Forwarding information, e.g., preferred paths or forwarding next-
hops. A device may need to consolidate forwarding information
from multiple devices so as to discover real incoming directions
of source addresses.
* Prefix information like hidden prefixes. Hidden prefixes may not
appear in routing information but are carried as source addresses
by legitimate data packets.
* SAV rules like <prefix, valid interfaces> entries. Devices can
directly advertise SAV rules to other devices.
4. Intra-domain SAVNET Architecture
The proposed architecture is shown in Figure 1. In the architecture,
there is a communication channel connecting two entities, i.e.,
Source Entity and Validation Entity. Source Entity is the
information source and provides SAV-related information to Validation
Entity. Validation Entity receives the information, generates SAV
rules, and conducts validation. An entity can be a router, a server,
or some other SAV-equipped devices. A device can act as a Source
Entity, a Validation Entity, or both of them.
Source Speaker resides in Source Entity is responsible to communicate
with Validation Speaker in Validation Entity through the
communication channel. The communication channel may consist of
Li, et al. Expires 26 January 2024 [Page 6]
Internet-Draft Intra-domain SAVNET Architecture July 2023
several sessions for transmitting SAV-related information including
routing information and SAV-specific information. In order to
transmit SAV-specific information in the channel, a new SAV-specific
protocol should be developed to carry the SAV-specific information.
The SAV-specific protocol should define the data structure or format
for communicating the SAV-specific information and the operations and
timing for originating, processing, propagating, and terminating the
messages which carry the information.
Under the incremental/partial deployment, not all devices support
advertising SAV-specific information. So, complete SAV-specific
information will not be available for the devices acting as
Validation Entity. In the stage of incremental/partial deployment,
routing information can be used as a supplement of SAV-specific
information for SAV rule generation. That is why the advertisement
of routing information is also included in the architecture.
SAV Agent in Validation Entity stores SAV-related information from
Validation Receiver, consolidates the different types of information
from all sources, and outputs SAV rules to the SAV table. The
concrete structure of SAV Agent will be introduced later.
+-------------------+ +-------------------+
| Source Entity |Communication| Validation Entity |
| +---------------+ | Channel | +---------------+ |
| | Source +-----------------+ Validation | |
| | Speaker | | | | Receiver | |
| +-------+-------+ | | +-------+-------+ |
| | | | | |
| | | | | |
| +-------+-------+ | | +-------+-------+ |
| | SAV-related | | | | SAV | |
| | Information | | | | Agent | |
| +---------------+ | | +---------------+ |
+-------------------+ +-------------------+
Figure 1: The intra-domain SAVNET architecture
4.1. Communication Channel
The communication channel is constructed between the Source Speaker
and Validation Receiver. The primary purpose of the channel is for
Source Entity to advertise SAV-related information to Validation
Entity. In the architecture, the communication channel can transmit
both routing information and SAV-specific information through
different sessions. These sessions can belong to different
protocols:
Li, et al. Expires 26 January 2024 [Page 7]
Internet-Draft Intra-domain SAVNET Architecture July 2023
* Routing protocol. OSPF, IS-IS, BGP, etc.
* SAV-specific protocol. This is newly defined in the document.
The SAV-specific protocol represents the protocols for advertising
SAV-specific information. They can be new protocols or protocol
extensions (e.g., routing protocol extensions).
* Management protocol. The protocols such as YANG, FlowSpec, or
management protocols for SAV can be used. Management protocols
for SAV can be new protocols or protocol extensions.
As shown in Figure 1, Source Speaker resides in Source Entity, and
Validation Receiver is in Validation Entity. Either Source Speaker
or Validation Receiver is an abstracted interface which represents a
union of multiple protocol speakers/receivers as illustrated in
Figure 2. These protocol speakers/receivers can advertise/receive
the messages carrying SAV-related information.
+--------------------+
| Speaker/Receiver |
| +----------------+ |
| |Management <------------
| |Speaker/Receiver| | |
| +----------------+ | |
| +----------------+ | ---> Interact
| |Routing Protocol<--------------> with other
| |Speaker/Receiver| | ---> speakers
| +----------------+ | |
| +----------------+ | |
| |SAV-specific | | |
| |Protocol <------------
| |Speaker/Receiver| |
| +----------------+ |
+--------------------+
Figure 2: Source speaker or validation receiver
4.2. SAV-Specific Protocol
The SAV-specific protocol is for propagating SAV-specific information
from Source Entity to Validation Entity. The need for the SAV-
specific protocol arises from the facts that there is no existing
mechanism which can support the perception and propagation of SAV-
specific information between devices. Hence, a unified SAV-specific
protocol is needed to establish communication between different
devices for the exchange of SAV-specific information. This document
does not present how to implement such a protocol and will only
describe the necessary features of it.
Li, et al. Expires 26 January 2024 [Page 8]
Internet-Draft Intra-domain SAVNET Architecture July 2023
The SAV-specific protocol SHOULD define the SAV-specific information
to be communicated, the data structure or format to communicate the
information, and the operations and timing for originating,
processing, propagating, and terminating the messages which carry the
information. The protocol SHOULD advertise the updates of SAV-
specific information in a timely manner so that Validation Entity can
update SAV rules correspondingly.
A session of the protocol can be established by manual configurations
of operators or an automatic mechanism. The concrete manner of
constructing a session depends on the actual protocol
implementations, but the following requirements SHOULD be satisfied:
* 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 local rules
in time.
* Authentication can be conducted before session establishment.
Authentication is optional but the ability of authentication
SHOULD be available.
The connectivity models between Source Speaker and Validation
Receiver are various. Section 6 shows some examples of connectivity
models.
4.3. SAV Agent
Figure 3 shows SAV Agent. SAV Information Manager in SAV Agent
parses the messages received by Validation Receiver. The SAV-related
information carried in the messages will be stored in SAV Information
Base. The information of Source Speaker, protocols, timestamp, and
other useful things will also be recorded together. The recorded
information will be disseminated to SAV Rule Generator. SAV rules
(e.g., tuples like <prefix, interface set, validity state>) will be
generated and stored in SAV Table [I-D.huang-savnet-sav-table].
Besides rule generation, SAV Information Base also provides the
support of diagnosis. Operators can look up the information in the
base for protocol monitoring or troubleshooting.
Li, et al. Expires 26 January 2024 [Page 9]
Internet-Draft Intra-domain SAVNET Architecture July 2023
Messages from
Validation Receiver
|
+---------------|---------------+
| SAV Agent | |
| +-------------\/------------+ |
| | SAV Information Manager | |
| | +-----------------------+ | |
| | | SAV Information Base | | |
| | +-----------------------+ | |
| +-------------+-------------+ |
| | |
| SAV-related | information |
| | |
| +-------------\/------------+ |
| | SAV Rule Generator | |
| | +-----------------------+ | |
| | | SAV Table | | |
| | +-----------------------+ | |
| +---------------------------+ |
+-------------------------------+
Figure 3: SAV agent
It can be noticed that SAV Information Base stores SAV-related
information from different Source Entities and different protocol
speakers. When SAV Rule Generator generates rules based on the
stored information, rule conflicts may appear. For example, for a
given prefix, the information from different entities or speakers may
indicate a different list of valid incoming interfaces.
To solve the problem of rule conflicts, each Source Entity or
protocol speaker can be set with a priority. So, the SAV-related
information from the entity or protocol speaker is also tagged with a
priority. In general, since SAV-specific information is specialized
for SAV and helps generate more accurate SAV rules than routing
information, SAV-specific information has a higher priority than
routing information. When rule conflicts exist, the rule based on
the information with a higher priority will override that based on
the information with a lower priority. If two conflicted rules are
based on the information with the same priority, they can be merged
to one rule (i.e., taking a union set). When the settings of
priority change, the affected information MUST be reprocessed for
updating rules.
Consider that one Validation Entity receives the information about
prefix P1 from one Source Entity through two protocol speakers.
Based on the information from speaker 1, the rule is <P1, {intf1},
Li, et al. Expires 26 January 2024 [Page 10]
Internet-Draft Intra-domain SAVNET Architecture July 2023
valid>. While based on the information from speaker 2, the rule is
<P1, {intf2}, valid>. Next, consider two cases of priority settings.
In case 1, speaker 1 has a higher priority than speaker 2. Then, the
rule of <P1, {intf1}, valid> will be finally stored in SAV Table. In
case 2, two speakers have the same priority. Then, <P1, {intf1,
intf2}, valid> is the output rule.
How to generate SAV rules SHOULD be designed in future SAV mechanisms
that implement the architecture.
5. Use Cases
This section will present two use cases to show why the architecture
can work better than existing SAV mechanisms. Figure 4 shows an
example of intra-domain SAV. In the figure, Subnet1 and Subnet3 are
single-homed to Router1 and Router2, respectively. Subnet2 is multi-
homed to Router1 and Router2. Router3 connects to the Internet
through two external interfaces. A typical deployment of existing
SAV mechanisms is: Strict uRPF is deployed on interface '#' for
validating packets from subnets, and ACL rules are configured at
external interface '*' for blocking internal source addresses from
the Internet.
5.1. Use Case 1: Validating Packets from a Multi-homed Subnet at Edge
Routers
Consider a scenario of asymmetric routing where Subnet2 advertises IP
address P1 to Router2 instead of Router1 but sends packets with
source address P1 to Router1. In the scenario, strict uRPF on
Router1 will improperly block legitimate packets from Subnet2 at
Intf.2.
If the proposed architecture is deployed in the network, Router2 can
advertise the SAV-specific information (i.e., Subnet2 has address P1)
to Router1. Then, Router1 will not block P1 at Intf. 2, so improper
block is avoided.
Li, et al. Expires 26 January 2024 [Page 11]
Internet-Draft Intra-domain SAVNET Architecture July 2023
+-----------------------------------------+
| Internet |
+-----------------------------------------+
| |
| |
+-------------+------+--------------------+
| AS | | |
| Intf.5| |Intf.6 |
| ┌─*──────*─┐ |
| │ Router 3 │ |
| └──────────┘ |
| / \ |
| / \ |
| / \ |
| ┌──────────┐ ┌──────────┐ |
| │ Router 1 │ │ Router 2 │ |
| └──#─────#─┘ └─#─────#──┘ |
|Intf.1|Intf.2\ Intf.3/ \Intf.4 |
| | \ / \ |
| | \ / \ |
| Subnet1 Subnet2 Subnet3 |
| |
+-----------------------------------------+
Figure 4: An example of intra-domain SAV
5.2. Use Case 2: Validating Packets from Other Networks at Border
Routers
Consider that ACL rules are manually maintained at external
interfaces to block internal addresses belonging to Subnet1, Subnet2,
and Subnet3. There may be operational challenges when there are many
external interfaces and the internal addresses are dynamic.
If the proposed architecture is deployed in the network, Router1 and
Router2 will advertise the internal addresses of connected subnets to
Router3. Then, Router3 can automatically update filtering rules at
external interfaces.
The above to use cases are simple. The detailed operations (such as
identifying, formatting, propagating, parsing, etc.) on SAV-specific
information SHOULD be defined in the implementations of the
architecture.
Li, et al. Expires 26 January 2024 [Page 12]
Internet-Draft Intra-domain SAVNET Architecture July 2023
6. Connectivity Models
This section presents some examples of connectivity models of the
architecture. A combination of these models is also suitable to the
architecture.
6.1. Example 1: Multiple Source Entities to One Validation Entity
One Validation Entity can collect SAV-related information from
multiple Source Entities as shown in Figure 5. For each Source
Entity, Validation Entity maintains a communication channel for
receiving messages.
+-----------------+
| Source Entity 1 |---------
+-----------------+ \
\
+-----------------+ \ +-------------------+
| Source Entity 2 |-------------| Validation Entity |
+-----------------+ / +-------------------+
... /
+-----------------+ /
| Source Entity n |---------
+-----------------+
Figure 5: Example 1: Multiple source entities to one validation
entity
6.2. Example 2: One Source Entity to Multiple Validation Entities
One Source Entity can provide information for multiple Validation
Entities as shown in Figure 6. Source Entity will maintain a
communication channel with each Validation Entity.
By combining Example 1 and Example 2, it can be seen that the
connectivity model can also be "multiple Source Entities to multiple
Validation Entities".
Li, et al. Expires 26 January 2024 [Page 13]
Internet-Draft Intra-domain SAVNET Architecture July 2023
+---------------------+
----------| Validation Entity 1 |
/ +---------------------+
/
+---------------+/ +---------------------+
| Source Entity |-------------| Validation Entity 2 |
+---------------+\ +---------------------+
\ ...
\ +---------------------+
----------| Validation Entity n |
+---------------------+
Figure 6: Example 2: One source entity to multiple validation
entities
6.3. Example 3: One Acting as both Source and Validation Entity
As mentioned previously, a device can be both Source and Validation
Entity. In Figure 7, the middle entity is such a device. It can
receive information messages from the top Source Entity and can
advertise information messages to the bottom Validation Entity. The
middle entity can also relay the messages from the top Source Entity
to the bottom Validation Entity, which is just like routing
information spreading.
+-------------------+
| Source Entity |
+-------------------+
|
+-------------------+
| Validation&Source |
| Entity |
+-------------------+
|
+-------------------+
| Validation Entity |
+-------------------+
Figure 7: Example 3: One acting as both source and validation entity
7. Convergence Considerations
Network topologies may change sometimes and result in the change of
SAV-related information. Convergence of the architecture is needed.
Source Entity MUST advertise the updates of SAV-related information
to Validation Entity in time. Then, Validation Entity MUST update
local SAV rules immediately. Even so, there will still be delay of
message delivery (sometimes re-transmission delay due to packet loss)
Li, et al. Expires 26 January 2024 [Page 14]
Internet-Draft Intra-domain SAVNET Architecture July 2023
and information processing. Therefore, during the convergence
process, the SAV rules for checking packets are possibly inaccurate,
which may result in severe false positive or too much false negative.
Existing routing information-based SAV mechanisms like strict uRPF is
also faced with convergence problem. Inaccurate validation may
appear during the convergence of routing, which is inevitable in
practice. However, the proposed architecture involves SAV-specific
Protocols that are especially for SAV. The convergence process can
be slowed down due to the existence of SAV-specific Protocols.
The protocol for implementing the architecture MUST carefully
consider the convergence problems, so that normal packet forwarding
won't be impacted too much. There are some potential work directions
for dealing with convergence problems:
* Taking full use of routing information. Routing information
usually provides most of the SAV-related information for rule
generation, and SAV-specific information is relatively a small set
of information for supplementing missed information. Therefore,
most of SAV rules can be updated during routing convergence if
routing information is fully taken for rule generation.
* Advertising and processing the information first that will
probably result in false positive. This is because false positive
is more harmful to the network than false negative. It is
reasonable to allocate more resources for eliminating false
positive first.
8. Incremental/Partial Deployment Considerations
Although an intra-domain network mostly has one administration,
incremental/partial deployment may still exist due to phased
deployment or the limitations coming from multi-vendor supplement.
Under incremental/partial deployment, if complete SAV-specific
information is unavailable, SAV rules can be generated by combing
available SAV-specific information and routing information.
Li, et al. Expires 26 January 2024 [Page 15]
Internet-Draft Intra-domain SAVNET Architecture July 2023
The implementation of 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, the device of Validation Entity
SHOULD take on the proper validation mode according to the deploying
of Source Entities. 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 false positive will not exist.
In addition, the SAV filtering at the router can be also performed
incrementally. The router can first take conservative actions on the
validated data packets. That is to say, the router will not directly
discard packet with an invalid result 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 under false positive validation results, while
still providing protection for the network. Finally, filtering
action is enabled only after confirming that there are no false
positives.
9. Security Considerations
In many cases, an intra-domain network can be considered as a trusted
domain. There will be no threats within the domain.
However, in some other cases, devices within the domain do not trust
each other. Operators SHOULD be aware of potential threats involved
in deploying the architecture. Typically, the 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.
Li, et al. Expires 26 January 2024 [Page 16]
Internet-Draft Intra-domain SAVNET Architecture July 2023
- Potential solution: Acknowledgement mechanisms MUST be provided
in the session between a speaker 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.
* 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.
When implementing the architecture in an extended protocol, the
existing security mechanisms of the protocol can be taken.
10. Manageability Considerations
The architecture provides a general design for collecting SAV-related
information and generating accurate SAV rules. 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 rule generation but is helpful for management.
Messages carrying SAV-related information come from different
protocol speakers. Each corresponding protocol SHOULD have
monitoring and troubleshooting mechanisms, which is necessary for
efficiently operating the architecture.
Li, et al. Expires 26 January 2024 [Page 17]
Internet-Draft Intra-domain SAVNET Architecture July 2023
11. Privacy Considerations
The advertised SAV-related information mainly indicates the incoming
directions of source prefixes. Devices under the architecture will
learn more forwarding information of data packets.
An intra-domain network is mostly operated by a single organization
or company, and the advertised information is only used within the
network. Therefore, the architecture does not import critical
privacy issues in usual cases.
The architecture makes the forwarding information in the network
clearer, which can be helpful for network management such as fault
diagnosis and traffic visualization.
12. IANA Considerations
This document has no IANA requirements.
13. 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.
14. References
14.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-01, 4 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-problem-statement-01>.
[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 26 January 2024 [Page 18]
Internet-Draft Intra-domain SAVNET Architecture July 2023
[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>.
14.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>.
[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
Li, et al. Expires 26 January 2024 [Page 19]
Internet-Draft Intra-domain SAVNET Architecture July 2023
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Mingqing Huang
Huawei
Beijing
China
Email: huangmingqing@huawei.com
Li Chen
Zhongguancun Laboratory
Beijing
China
Email: lichen@zgclab.edu.cn
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
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 26 January 2024 [Page 20]