Inter-domain Source
Address Validation (SAVNET) ArchitectureTsinghua UniversityBeijingChinajianping@cernet.edu.cnTsinghua UniversityBeijingChinatolidan@tsinghua.edu.cnHuaweiBeijingChinahuangmingqing@huawei.comZhongguancun LaboratoryBeijingChinalichen@zgclab.edu.cnHuaweiBeijingChinagengnan@huawei.comZhongguancun LaboratoryBeijingChinaliulb@zgclab.edu.cnTsinghua UniversityBeijingChinaqlc19@mails.tsinghua.edu.cnSource address validation (SAV) is critical to preventing attacks
based on source IP address spoofing.
The proposed inter-domain SAVNET architecture enables an AS to generate
SAV rules based on SAV-related information from multiple sources.
This architecture integrates existing SAV mechanisms and offers
ample design space for new SAV mechanisms.
The document focuses on architectural components and SAV-related
information in an inter-domain SAVNET deployment, without specifying
any protocols or protocol extensions.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.Attacks based on source IP address spoofing, such as reflective DDoS and
flooding attacks, continue to pose significant challenges to Internet security.
To mitigate such attacks in inter-domain networks, source address validation (SAV)
is essential.Although BCP84 provides some
SAV solutions, such as uRPF-based mechanisms, the existing SAV mechanisms have
limitations in terms of validation accuracy and operational overhead
.
These mechanisms generate SAV rules based only on the Routing Information Base (RIB)
of the local AS. In cases of asymmetric routing, the generated rules may not match
the incoming direction of packets originating from a specific source address,
leading to improper block or improper permit problems. Consequently, despite the deployment
of SAV, an AS may still suffer from source address spoofing attacks from other ASes.To address the limitations of existing SAV mechanisms, this document proposes
an inter-domain source address validation architecture (SAVNET) that provides a
framework for developing new SAV mechanisms. The inter-domain SAVNET architecture enables
an AS to generate precise SAV rules by leveraging SAV-related information from
various sources, including Manual Configurations, RPKI ROA Objects and ASPA Objects,
and Collaborative Messages from other ASes.
This information consists of legitimate or nearly legitimate
prefixes of the ASes, ensuring that the source addresses of the ASes providing
such information are also protected.
By incorporating this additional information, SAVNET enhances the accuracy
of SAV rules beyond those generated solely based on the local RIB.This document focuses on high-level architecture designs and
does not specify protocols or protocol extensions.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.The inter-domain SAVNET architecture aims to enhance SAV accuracy and
facilitate partial deployment with low operational overhead. Achieving
high accuracy requires deployment at all peer, customer, and provider interfaces
of the ASes, while avoiding improper block and reducing as much improper permit as possible.
To this end, the overall goal can be broken down into the following aspects:
An AS with peer and customer interfaces should accurately and completely
learn the source prefixes and corresponding incoming peer or customer interfaces
that match the real forwarding paths.
The AS should then permit all learned valid source prefixes and block any unknown
ones at peer or customer interfaces, to avoid improper block and
reduce improper permit at these interfaces.
An AS with provider interfaces, particularly a multi-homed AS, should
accurately and completely learn the source prefixes
of other ASes that have deployed SAVNET, along with the corresponding
incoming provider interfaces. The AS should then permit all the learned
valid prefixes and any other unknown ones, and block all other learned
valid prefixes associated with other interfaces at its corresponding provider interface,
to avoid improper block and reduce improper permit.
The inter-domain SAVNET architecture should adapt to dynamic networks
and asymmetric routing scenarios automatically.
The inter-domain SAVNET architecture should provide sufficient protection
for the source prefixes of those ASes that deploy it even if only a portion
of Internet implements the architecture.
To achieve the above goals, relying solely on local RIB data to generate
SAV rules (such as FP-uRPF and EFP-uRPF) is insufficient.
Additional SAV-related information must be taken into account to accurately
learn the source prefixes and their incoming interfaces. This information can
be obtained locally, configured manually, or even propagated or advertised by
other ASes. Therefore, the inter-domain SAVNET architecture consolidates
SAV-related information from multiple sources and generates SAV rules automatically
to achieve the aforementioned goals.Some other design goals (such as low operational overhead and easy implementation, etc.)
are also very important and should be considered in specific protocols or protocol extensions
and are out of scope for this document. shows the overview of inter-domain SAVNET architecture.
Inter-domain SAVNET architecture collects SAV-related information from multiple sources,
which can be categorized into
three types: Manual Configuration, Passive Acquired Information, and
Active Collaboration Information.
SAVNET uses the SAV-related information to maintain the
SAV Information Base (SIB).
Then, based on the SIB, it generates SAV rules to fill out the
SAV table in the dataplane.Manual Configuration can be conducted by network operators
using YANG, command-line interface (CLI), and SIB Management Protocol (SMP),
such as remote triggered black hole (RTBH) and FlowSpec.
The Passive Acquired Information can
be ontained within an AS and may come from RIB, Routing Information Messages,
or RPKI ROA objects and ASPA objects.
Active Collaboration Information contains Real Forwarding Paths and
is transmitted using Collaborative Messages from other ASes.We note that inter-domain SAVNET architecture does not
require all the information sources to generate SAV rules.
All of them, including the Collaborative Messages,
in SAVNET are optional depending on the availability of them and operational needs.
The SAV Information Base Manager (SIM) and SAV table
are necessary to generate SAV rules and perform SAV.SAV Information Base (SIB) is consolidated by the SAV Information
Base Manager according to the SAV-related information from
various sources.
In SIB, each row records the index, the prefix, the prefix's valid incoming
interface, the prefix's incoming direction, and the corresponding information source.In order to provide a clear illustration of the SIB, depicts
an example of an SIB established in AS X. As shown in ,
AS X has five interfaces, each connected to a different AS.
Specifically, X.1 is connected to AS 1, X.2 to AS 2, X.3 to AS 3, X.4 to AS 4,
and X.5 to AS 5. The arrows in the figure represent the commercial relationships
between ASes, with AS 1 and AS 2 serving as providers for AS X,
AS X as the lateral peer of AS 3, AS X as the provider for AS 4 and AS 5,
and AS 5 as the provider for AS 4.For example, in , the row with index 0 indicates the prefix P1's
valid incoming interface is X.1, the ingress direction of P1 is AS X's Provider AS,
and these information is from the Collaborative Messages and RPKI ASPA Objects and ROA Objects.
Note that the SAV-related information may have multiple sources and the SIB records them all.In sum, the SIB can be consolidated according to the SAV-related information
from the following information sources:
Manual Configuaration: the SIB can obtain SAV-related configurations from
the Manual Configurations of network operators, such as YANG, command-line interface (CLI),
and remote configurations using the SIM, such as RTBH.
Collaborative Message: the SIB can obtain the real forwarding
paths from the processed Collaborative Messages from other ASes.
RPKI ROA Objects and ASPA Objects: the SIB can obtain the topological information from the
RPKI ROA objects and RPKI ASPA objects over the local Routing Instance.
The detailed solutions for collecting these information are out of scope for this document.
Routing Information Message: the SIB can obtain the prefixes and their advertised
routes from the Routing Information Messages.
Routing Information Base (RIB): the SIB can obtain the prefixes and their permissible
routes including the optional ones from the RIB.
The SIB may be maitained according to the SAV-related information
from all the above information sources or part of them.
It records the sources of the SAV information explicitly and can
be compressed to reduce its size.
Inter-domain SAVNET architecture can allow operators to specify how
to use the SAV-related information in the SIB by manual configurations.
In fact, the SAV information sources also give the indications
about how to use the SAV-related information from them.Notably, the information sources are not equivalent, and finer-grained information
sources, such as Collaborative Messages, can help generate more accurate SAV rules
to reduce improper permit or improper block.
proposes the priority ranking for the SAV information
sources in the SIB. Inter-domain SAVNET can generate SAV rules based on the
priorities of SAV information sources.
For example, for the provider interfaces which can use loose SAV rules,
inter-domain SAVNET may use the SAV-related information
from all sources (e.g., the rows with index 0, 1, and 2 in )
to generate rules, and for the customer interfaces which need more strict SAV rules,
SAVNET may only use the ones (e.g., the row with index 4 and 6 in ).
Here, for the row with index 6, inter-domain SAVNET uses it to generate
SAV rules since only SAV-related information from the Routing Information Message
is available for the prefix P5.The Collaborative Messages propagate or originate the real
forwarding paths of prefixes between the Collaborative Protocol Speakers.
The Collaborative Protocol Speaker within an AS can obtain the next hop
of the corresponding prefixes based on the routing table from the local
RIB, and use the Collaborative Messages to carry the next hop of the
corresponding prefixes and propagate them between ASes.The Collaborative Protocol Speaker can generate the real forwarding
paths of prefixes. It does this by connecting to the Collaborative Protocol
Speakers in other ASes, receiving, processing, generating, or terminating
Collaborative Messages.
The Collaborative Protocol Speaker establishes connection with other
Collaborative Protocol Speakers in other ASes to exchange Collaborative Messages.
Then, it obtains the ASN, the prefixes, and their incoming AS direction for the SIB.Besides, the preferred AS paths of an AS and the prefixes may change
over time due to route changes.
The Collaborative Protocol Speaker should launch Collaborative Messages to
adapt to the route changes in a timely manner.
In particular, inter-domain SAVNET should deal with the route changes carefully
since improper block may be induced when the packet forwading path changes
while the Collaborative Messages are not processed in time.
The detailed design for dealing with the route changes is out of scope for this document.SAV Information Manager (SIM) consolidates SAV-related information
from multiple sources and generate SAV rules.
It uses the SAV-related information to initiate or update the SIB, and generates
SAV rules to fill out the SAV table according to the SIB.
The collection methods of SAV-related information depend on the deployment
and implementation of the inter-domain SAV mechanisms and are out of scope for this document.Based on the SIB, SIM generates SAV rules to fill out the SAV table, which consists
of the <Prefixes, Interface> couples, and represents the legitimate prefixes
for each incoming interface.
Note that the interfaces in SIB are logical AS-level interfaces, they need to be converted
to the physical interfaces of border routers within the corresponding AS. shows an example of the SAV table.
The packets coming from other ASes will be validated by the SAV table.
The router looks up each packet's source address in 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 of the packet and the valid incoming
interfaces covering the actual incoming interface of the packet.
According to the SAV principle, "Valid" packets will be forwarded.
"Invalid" means there is a source prefix in SAV table covering the
source address, but the incoming interface of the packet does not
match any valid incoming interface so that such packets will be
dropped. "Unknown" means there is no source prefix in SAV table
covering the source address. The packet with "unknown" addresses can
be dropped or permitted, which depends on the choice of operators.The SAV table can be enabled at provider, peer, or customer
interfaces. Different interfaces can take on proper SAV table modes
defined in . For customer
interfaces, if all the customer ASes have advertised complete source
prefixes and SAV Protocol Messages, Prefix Allowlist Mode can be
applied ("Mode 1" in ).
This mode drops any packets whose source addresses are not included in
the allowlist of the customer interfaces. If the legitimate source
prefixes arriving at the interfaces are not complete, the Interface
Blocklist Mode can be taken ("Mode 2" in ). This latter mode checks
whether specific source prefixes coming from the invalid
interfaces. The packets with unknown prefixes will be forwarded
normally. Thus, they are safer than Prefix Allowlist Mode.Since it is impossible to deploy inter-domain SAVNET in all ASes
simultaneously, inter-domain SAVNET must support partial
deployment. In inter-domain SAVNET architecture, the manual configuration,
topological information, and the known prefixes can be obtained locally. Even
for the real forwarding path information, it does not suppose that all
ASes deploy the Collaborative Protocol Speakers, as a
Collaborative Protocol Speaker can easily find an AS which deploys
another Collaborative Protocol Speaker and establishes
logical neighboring relationship with the AS.Overall, ASes which
deploys inter-domain SAVNET cannot spoof each other, and non-deployed
ASes cannot send spoofed packets to the deployed ASes by forging their
source addresses. With the merger of different
ASes where the inter-domain SAVNET is deployed, the "deployed
area" will gradually expand, and the defense capability against source
address spoofing will gradually increase. Moreover, if multiple
"deployed areas" can be logically connected (by crossing the
"non-deployed areas"), these "deployed areas" can form a logic alliance
to protect their addresses from being forged.In inter-domain SAVNET architecture, the Collaborative Protocol
Speaker generates and propagates Collaborative Messages
among different ASes. To prevent a malicious AS from generating incorrect
or forged Collaborative Messages,
the Collaborative Protocol Speakers need to perform security
authentication on each received Collaborative Message.
Security threats to inter-domain SAVNET come from two
aspects: session security and content security.
Session security means that the identities of both parties in
a session can be verified and the integrity of the session content
can be ensured. Content security means that the authenticity and
reliability of the session content can be verified, i.e., the
forged Collaborative Message can be identified.The threats to session security include:
Session identity impersonation: A malicious router masquerades as
a peer of another router to establish a session with the router.
Session integrity destroying: A malicious intermediate router
between two peering routers destroys the content of the relayed
Collaborative Message.
The threats to content security include:
Message alteration: A malicious router forges any part of a
Collaborative Message, for example, using a
spoofed ASN or AS Path.
Message injection: A malicious router injects a "legitimate"
Collaborative Message and sends it to the
corresponding next-hop AS, such as replay attacks.
Path deviation: A malicious router sends a
Collaborative Message
to a wrong next-hop AS which conflicts with the AS Path.
Overall, inter-domain SAVNET faces security threats similar to those
of BGP. To enhance session security, inter-domain SAVNET may use the
same session authentication mechanisms as BGP, i.e., performing session
authentication based on MD5, TCP-AO, or Keychain. To enhance content
security, existing BGP security mechanisms (e.g., RPKI, BGPsec, and
ASPA) can also help address content security threats to inter-domain
SAVNET. But until these mechanisms are widely deployed, an independent
security mechanism for inter-domain SAVNET is needed. In the preliminary
idea, each origin AS calculates a digital signature for each AS path and
adds these digital signatures into the Collaborative Message.
When a Collaborative Protocol Speaker receives a
Collaborative Message, it can check the digital
signature to identify the authenticity of this message.
Specific security designs will be included in a separate draft.This document should not affect the privacy of the Internet.This document has no IANA requirements.Akamai Technologies 145 Broadway Cambridge MA 02142 United States of Americailubashe@akamai.comMany thanks to Igor Lubashev for the significantly helpful revision suggestions.Source Address Validation Table Abstraction and
ApplicationHuaweiBeijingChinahuangmingqing@huawei.comChina MobileBeijingChinachengweiqiang@chinamobile.comTsinghua UniversityBeijingChinatolidan@tsinghua.edu.cnHuaweiBeijingChinagengnan@huawei.comHuaweiBeijingChinaliumingxing7@huawei.comZhongguancun LaboratoryBeijingChinaLichen@zgclab.edu.cnSource Address Validation in Inter-domain Networks Gap Analysis, Problem Statement, and RequirementsTsinghua UniversityBeijingChinajianping@cernet.edu.cnTsinghua UniversityBeijingChinatolidan@tsinghua.edu.cnZhongguancun LaboratoryBeijingChinaliulb@zgclab.edu.cnHuaweiBeijingChinahuangmingqing@huawei.comHuaweiBeijingChinagengnan@huawei.com