Internet DRAFT - draft-li-savnet-intra-domain-architecture
draft-li-savnet-intra-domain-architecture
Network Working Group D. Li
Internet-Draft J. Wu
Intended status: Standards Track Tsinghua University
Expires: 13 September 2023 M. Huang
Huawei
L. Chen
Zhongguancun Laboratory
N. Geng
Huawei
L. Qin
Tsinghua University
F. Gao
Zhongguancun Laboratory
12 March 2023
Intra-domain Source Address Validation (SAVNET) Architecture
draft-li-savnet-intra-domain-architecture-01
Abstract
Intra-domain source address validation (SAV) plays an important role
in defending against source address spoofing attacks in intra-domain
networks. This document proposes an intra-domain source address
validation (intra-domain SAVNET) architecture. Under the
architecture, a router can automatically generate accurate SAV rules
based on the SAV-related information from multiple information
sources. This document does not specify protocols or protocol
extensions, instead focusing on architectural components and their
functionalities in an intra-domain SAVNET deployment.
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/.
Li, et al. Expires 13 September 2023 [Page 1]
Internet-Draft Intra-domain SAVNET Architecture March 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 13 September 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Intra-domain SAVNET Architecture . . . . . . . . . . . . . . 5
4.1. SAV Information Base Manager . . . . . . . . . . . . . . 6
4.2. RPDP and RPDP Speaker . . . . . . . . . . . . . . . . . . 7
5. Partial Deployment . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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 as close to the source as possible.
Li, et al. Expires 13 September 2023 [Page 2]
Internet-Draft Intra-domain SAVNET Architecture March 2023
There are some intra-domain SAV mechanisms available. However,
existing intra-domain SAV mechanisms have the problems of inaccurate
validation under asymmetric routing and high operational overhead in
dynamic networks [draft-li-savnet-intra-domain-problem-statement].
To solve the problems above, this document proposes an intra-domain
source address validation (intra-domain SAVNET) architecture. Under
the architecture, routers can collaborate to discover real incoming
interfaces of source prefixes adaptive to routing status, and the
packets from all directions can be validated, which yields
improvements on source address protection.
This document focuses on the high-level architecture designs and does
not specify protocols or protocol extensions.
2. Terminology
SAV Rule: The rule that indicates the valid incoming interfaces for a
specific source prefix or that indicates the valid source prefixes
for a specific interface.
SAV Table: The table or data structure that implements the SAV rules
and is used for source address validation in the data plane.
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.
SIB: SAV information base that is for storing SAV-related information
collected from different information sources.
SMP: SIB management protocol that represents any protocols for
managing data in SIB.
RPDP: Real path discovering protocol, generally referring to the
extension of existing routing protocols. The RPDP messages can
explicitly or implicitly indicate the real incoming interfaces of
some specified source prefixes.
3. Design Goals
The intra-domain SAVNET architecture is to enhance the intra-domain
SAV and aims to achieve the following goals:
Li, et al. Expires 13 September 2023 [Page 3]
Internet-Draft Intra-domain SAVNET Architecture March 2023
* Accurate validation. The real incoming interfaces of source
prefixes need to be completely learned, and improper block can be
avoided. By trying to exclude non-real incoming interfaces from
the valid interface group, improper permit can be reduced.
* Low operational overhead. The routers after initial
configurations can adapt to dynamic routing changes automatically,
so that the operational overhead can be controlled.
* Working in partial deployment. Routers need to do SAV for both
external packets (from subnets or the Internet) and internal
packets (forwarded by other routers). On the one hand, edge (or
border) routers take SAV for external packets including those from
both the subnets and the Internet. On the other hand, edge
routers and non-edge routers take SAV for internal packets, which
is necessary in partial deployment cases. Under partial
deployment, edge routers may not be able to block all the spoofed
external packets. SAV for internal packets is to filter the
malicious packets mixed in internal packets.
To achieve the goal of accurate validation, a router cannot generate
SAV rules based on only local RIB/FIB because asymmetric routing
exists, and purely relying on manual SAV rule configurations for
guaranteeing accurate validation is not practical. The key challenge
is how to make a router automatically discover real incoming
interfaces of source prefixes of both external and internal packets.
Consider that the real incoming interfaces are determined by the
forwarding rules of other routers in the network and cannot be
entirely obtained locally. To address the key challenge, the intra-
domain architecture includes a real path discovery protocol (RPDP) by
extending existing routing protocols. Routers will propagate SAV-
related data by sending RPDP messages adaptive to forwarding rules.
These messages will be received by other routers. By combining the
information from manual configurations, RIB/FIB, and protocol
messages, accurate SAV rules for both external and internal packets
can be generated.
Other design goals, such as low data plane overhead and easy
implementation, are also important, but out of the scope of this
document. They should be considered in specific protocols or
protocol extensions of SAVNET.
Li, et al. Expires 13 September 2023 [Page 4]
Internet-Draft Intra-domain SAVNET Architecture March 2023
4. Intra-domain SAVNET Architecture
The intra-domain SAVNET architecture is depicted from the perspective
of a router. Figure 1 shows the architecture which consists of a few
components. Among these components, the three of SAV Information
Base (SIB) manager, RPDP speaker, and SAV table are specialized for
SAV. The other components are existing ones but are required for SAV
rule generation.
+------------------------------------------+
| Other Protocol Speakers |
+------------------------------------------+
/\
| Protocol Messages
+-----------------------------------------------------+
| Router | |
| \/ |
| +-------------------------------------------------+ |
| | Routing +------------------------+ | |
| | Protocol | RPDP Speaker | | |
| | Speaker +------------------------+ | |
| +-------------------------------------------------+ |
| |Routing /\Routing |SAV |
| |Information |Table |Information |
| |Dissemination | |Dissemination |
| |Messages | |Messages |
| \/ | \/ |
| +--------------------+ +----------------------+ |
| | | |+--------------------+| |
| | Routing | ||SAV Information Base|| |
| | Information |-->|+--------------------+| |
| | Base | | SAV Information Base | |
| | | | Manager | |
| +--------------------+ +----------------------+ |
| |SAV Rules |
| \/ |
| +-----------+ |
| | SAV Table | |
| +-----------+ |
+-----------------------------------------------------+
/\ Manual Configurations
|
+----------------------+
| CLI, YANG, SMP, etc. |
+----------------------+
Figure 1: The intra-domain SAVNET Architecture
Li, et al. Expires 13 September 2023 [Page 5]
Internet-Draft Intra-domain SAVNET Architecture March 2023
4.1. SAV Information Base Manager
SIB manager is the core component for SAV rule generation in the
architecture. The component collects SAV-related information from
multiple information sources, stores the information in SIB after
consolidation, and outputs SAV rules based on the stored information.
SAV rules indicate the valid incoming interfaces of source prefixes,
which can be represented by <Prefix, Interface> pairs.
As described previously, collecting SAV-related information purely
from local routing information and manual configuration is not enough
or practical for learning accurate <Prefix, Interface> pairs. The
protocol called RPDP in the document is designed as the third
information source which provides accurate SAV information.
Therefore, in the architecture, there are total of three information
sources, which are listed as follows:
* Manual Configuration: The routers should support SAV-related
configurations. The configurations may be from CLI, YANG, SIB
management protocol (SMP), etc. SMP mentioned herein represents
any protocols designed for managing data in SIB.
* Routing Information Base: RIB stores routing information learned
from routing protocols. It has been used in some existing SAV
mechanisms.
* RPDP Messages: Routers will send RPDP messages according to local
forwarding rules. The real incoming interfaces of source prefixes
can be learned from the received messages.
Although there are multiple information sources, one can choose some
of them (e.g., RIB and RPDP speaker) for SAV instead of using all of
them. When more than one information sources are used, data
conflicts may exist. To address the issue, priorities can be set to
the sources. For the items with data conflicts, the items from the
source of higher priority will be preferred. For the items without
data conflicts, a union of the items will be taken. For example,
suppose that manual configuration has the highest priority. When the
information from RIB indicates that Interface 1 is the valid incoming
interface of source prefix P1, the operators can manually configure
Interface 1 as the invalid interface of P1.
By consolidating the information from different sources, SAV manager
will get the pairs of <Prefix, Interface> for all prefixes, which are
stored in SAV information base. Figure 2 illustrates SAV information
base. In the figure, each source prefix (including the default
prefix, i.e., 0.0.0.0) has one or more valid incoming interfaces.
The information sources for a pair of <Prefix, Interface> are also
Li, et al. Expires 13 September 2023 [Page 6]
Internet-Draft Intra-domain SAVNET Architecture March 2023
recorded. For example, P1 has two incoming interfaces of Interface 1
and Interface 3. Any other interfaces except Interface 1 and 3 will
be considered invalid for P1. In the example, Interface 3 for P1 is
discovered by only RPDP, which may appear in asymmetric routing
cases.
An SAV table can be generated based on SAV information base. The SAV
rules in the table will be installed into the data plane for
validating the packets from all directions. The working modes and
usage suggestions of SAV table can be found in
[draft-huang-savnet-sav-table].
+----------------------------------------------------------+
| Source Prefix | Incoming Interface | Information Sources |
+---------------+--------------------+---------------------+
| P1 | Interface 1 | b,c |
| P1 | Interface 3 | b |
| P2 | Interface 2 | b,c |
| P3 | Interface 4 | a |
| ... | ... | ... |
| default | Interface 4 | a |
+----------------------------------------------------------+
* a: Manual Config, b: RIB, c: RPDP
Figure 2: An illustration of SAV information base
4.2. RPDP and RPDP Speaker
The RPDP is for automatically discovering real incoming interfaces of
source prefixes. Particularly, the RPDP needs to extend existing
routing protocols. The RPDP speaker is responsible for dealing with
message interactions of the RPDP, and it naturally resides in the
routing protocol speaker. The RPDP messages are carried by newly
defined TLVs or messages of routing protocols.
Through the RPDP speaker, routers can send RPDP messages explicitly
or implicitly indicating the real incoming interfaces of some
specified source prefixes. A router receiving RPDP messages can
resolve the SAV-related information for rule generation. Thus, there
exists cooperation between routers. The followings are some kinds of
SAV-related information that can be propagated by RPDP:
* Source prefixes with a configured tag. A router can construct a
message containing some source prefixes (e.g., the prefixes
matching a routing policy) as well as a configured tag. The
routers whose interfaces are configured the same tag value, will
receive the tagged source prefixes and will consider the
interfaces with the same tag value as the real incoming interfaces
Li, et al. Expires 13 September 2023 [Page 7]
Internet-Draft Intra-domain SAVNET Architecture March 2023
of these source prefixes. Note that, some initial manual
configurations are needed such as tag configuration and prefix
matching policy configuration. After the initial configurations,
the routers can adapt to prefix changes automatically.
* Source prefixes which are propagated through real forwarding
paths. A router can construct a message containing some source
prefixes and one of the locally reachable destination prefixes.
The message will be sent to the nexthop through which the
destination prefix is reachable according to the local forwarding
rules. The routers receiving the message from an interface will
bind the interface with the source prefixes. Then, the message
will be sent out by looking up the local forwarding rules of the
destination prefix. A router may have lots of locally reachable
destination prefixes and needs to send messages for each of the
destination prefixes so that all the real incoming interfaces can
be discovered. To reduce the communication overhead, a message
can contain multiple destination prefixes who have the same
nexthop. Note that, any factors that affect forwarding should be
considered during the message propagation.
* Forwarding information. A router can advertise the local
forwarding information (e.g., route redirection) that may result
in asymmetric routing. Then, other routers will conduct path
computations and then get the real forwarding paths of source
prefixes.
In the architecture, the RPDP speaker will get routing table from the
RIB and policy routing information from the policy-based routing.
These kinds of information will be useful for the RPDP speaker
constructing and sending RPDP messages. After receiving RPDP
messages, the speaker will disseminate SAV information to the SIB
manager component.
The RPDP speaker should sense the adaptiveness of local source
prefixes, forwarding rules, and SAV-related configurations (e.g.,
tags), etc. The adaptiveness should be notified to related routers
through RPDP messages in time.
5. Partial Deployment
Since an intra-domain network mostly has one administration, it is
possible to deploy SAVNET on all routers. Under full deployment,
only edge routers need to enable SAV for validating external packets.
However, partial deployment may still exist due to phased deployment
or the limitations coming from multi-vendor supplement. In such
cases, the SAV for internal packets are needed, which is supported by
the intra-domain SAVNET architecture.
Li, et al. Expires 13 September 2023 [Page 8]
Internet-Draft Intra-domain SAVNET Architecture March 2023
There are another kind of cases where the SAV for internal packets
are necessary. Sometimes, the software of some edge routers has been
upgraded for supporting SAVNET, but these routers are not able to do
SAV due to the limited data plane capability. In such cases, these
edges routers can still run SAVNET protocols to help other routers
accurately validating external and internal packets.
The architecture does not require to be deployed in the whole network
like an AS. It also works when an area of the network supports the
architecture. A more detailed analysis on partial deployment may be
provided in the future version of the document.
6. Security Considerations
The security considerations should be provided in the protocol
extension documents.
7. Privacy Considerations
An intra-domain network is mostly operated by a single organization
or company, so the architecture does not import privacy issues in
most cases. There should be an analysis on privacy in the protocol
extension documents.
8. IANA Considerations
This document has no IANA requirements.
9. References
9.1. Normative References
[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", 15 December 2022.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[cable-verify]
Cisco, "Cable Source-Verify and IP Address Security",
2021, <https://www.cisco.com/c/en/us/support/docs/
broadband-cable/cable-security/20691-source-verify.html>.
Li, et al. Expires 13 September 2023 [Page 9]
Internet-Draft Intra-domain SAVNET Architecture March 2023
[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.
[IPSG] Cisco, "Configuring DHCP Features and IP Source Guard",
2016, <https://www.cisco.com/c/en/us/td/docs/switches/lan/
catalyst2960/software/release/12-
2_53_se/configuration/guide/2960scg/swdhcp82.html>.
[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>.
Authors' Addresses
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, et al. Expires 13 September 2023 [Page 10]
Internet-Draft Intra-domain SAVNET Architecture March 2023
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 13 September 2023 [Page 11]
