Inter-domain Source Address Validation (SAVNET) Architecture
draft-wu-savnet-inter-domain-architecture-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
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 "Active".
|
|
|---|---|---|---|
| Authors | Jianping Wu , Dan Li , Mingqing(Michael) Huang , Li Chen , Nan Geng , Libin Liu , Lancheng Qin | ||
| Last updated | 2023-03-13 | ||
| 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-wu-savnet-inter-domain-architecture-01
Network Working Group J. Wu
Internet-Draft D. Li
Intended status: Standards Track Tsinghua University
Expires: 14 September 2023 M. Huang
Huawei
L. Chen
Zhongguancun Laboratory
N. Geng
Huawei
L. Liu
Zhongguancun Laboratory
L. Qin
Tsinghua University
13 March 2023
Inter-domain Source Address Validation (SAVNET) Architecture
draft-wu-savnet-inter-domain-architecture-01
Abstract
Source 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.
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/.
Wu, et al. Expires 14 September 2023 [Page 1]
Internet-Draft Inter-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 14 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Inter-domain SAVNET Architecture . . . . . . . . . . . . . . 5
4.1. SAV Information Base . . . . . . . . . . . . . . . . . . 6
4.2. Collaborative Messages . . . . . . . . . . . . . . . . . 9
4.3. SAV Information Manager . . . . . . . . . . . . . . . . . 9
5. Partial Deployment . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
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 [RFC3704][RFC8704] provides some SAV solutions, such
as uRPF-based mechanisms, the existing SAV mechanisms have
limitations in terms of validation accuracy and operational overhead
Wu, et al. Expires 14 September 2023 [Page 2]
Internet-Draft Inter-domain SAVNET Architecture March 2023
[draft-wu-savnet-inter-domain-problem-statement]. 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.
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.
Wu, et al. Expires 14 September 2023 [Page 3]
Internet-Draft Inter-domain SAVNET Architecture March 2023
3. Design Goals
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.
Wu, et al. Expires 14 September 2023 [Page 4]
Internet-Draft Inter-domain SAVNET Architecture March 2023
4. Inter-domain SAVNET Architecture
+----------------------+
| Other ASes |
+----------------------+
|Collaborative
|Messages
+-----------------------------------------------------------------+
| |YANG |CLI |SMP |RIB |ROA |ASPA | AS |
| \/ \/ \/ \/ \/ \/ \/ |
| +---------------+ +------------------+ +----------------------+ |
| | Manual | | Passive Acquired | | Active Collaboration | |
| | Configuration | | Information | | Information | |
| +---------------+ +------------------+ +----------------------+ |
| | | | |
| \/ \/ \/ |
| +-------------------------------------------------------------+ |
| | +---------------------------------------------------------+ | |
| | | SAV Information Base | | |
| | +---------------------------------------------------------+ | |
| | SAV Information Base Manager | |
| +-------------------------------------------------------------+ |
| | |
| \/ |
| +---------------------------------------------------------+ |
| | SAV Table | |
| +---------------------------------------------------------+ |
+-----------------------------------------------------------------+
Figure 1: The inter-domain SAVNET Architecture
Figure 1 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.
Wu, et al. Expires 14 September 2023 [Page 5]
Internet-Draft Inter-domain SAVNET Architecture March 2023
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.
4.1. SAV Information Base
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.
+-----+------+------------------+---------+---------------------------+
|Index|Prefix|AS-level Interface|Direction| Information Source |
+-----+------+------------------+---------+---------------------------+
| 0 | P1 | X.1 |Provider | Collaborative Message, |
| | | | |RPKI ASPA Obj. and ROA Obj.|
+-----+------+------------------+---------+---------------------------+
| 1 | P1 | X.2 |Provider | RIB |
+-----+------+------------------+---------+---------------------------+
| 2 | P2 | X.2 |Provider | Manual Configuration |
+-----+------+------------------+---------+---------------------------+
| 3 | P3 | X.3 | Peer | Collaborative Message, |
| | | | |Routing Information Message|
+-----+------+------------------+---------+---------------------------+
| 4 | P4 | X.4 |Customer |Collaborative Message, RIB |
+-----+------+------------------+---------+---------------------------+
| 5 | P4 | X.5 |Customer | RIB |
+-----+------+------------------+---------+---------------------------+
| 6 | P5 | X.5 |Customer |Routing Information Message|
+-----+------+------------------+---------+---------------------------+
Figure 2: An Example for the SAV Information Base
Wu, et al. Expires 14 September 2023 [Page 6]
Internet-Draft Inter-domain SAVNET Architecture March 2023
+------------+ +------------+
| AS 1(P1) +-------+ AS 2(P2) |
+-------/\---+ +--/\--------+
\ /
(C2P) \ / (C2P)
\ X.1 X.2 /
+------------+ (P2P) +-------------+
| AS X +-----------+ AS 3 (P3) |
+-/\------/\-+ X.3 +-------------+
X.4 | X.5 \
| \
| \ (C2P)
| +------------+
| | AS 5(P5) |
| +-/\---------+
| /
(C2P) | /
+-------------+
| AS 4 (P4) |
+-------------+
Figure 3: AS Topology
In order to provide a clear illustration of the SIB, Figure 2 depicts
an example of an SIB established in AS X. As shown in Figure 3, 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 Figure 2, 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.
Wu, et al. Expires 14 September 2023 [Page 7]
Internet-Draft Inter-domain SAVNET Architecture March 2023
* 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.
+---------------------------------------+--------+
| SAV Information Source |Priority|
+---------------------------------------+--------+
| Manual Configuration | 1 |
+---------------------------------------+--------+
| Collaborative Message | 2 |
+---------------------------------------+--------+
| RPKI ROA Objects and ASPA Objects | 3 |
+---------------------------------------+--------+
| Routing Information Message | 4 |
+---------------------------------------+--------+
| Routing Information Base | 5 |
+---------------------------------------+--------+
Figure 4: Priority Ranking for the SAV Information Sources
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. Figure 4 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,
Wu, et al. Expires 14 September 2023 [Page 8]
Internet-Draft Inter-domain SAVNET Architecture March 2023
inter-domain SAVNET may use the SAV-related information from all
sources (e.g., the rows with index 0, 1, and 2 in Figure 2) 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 Figure 2). 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.
4.2. Collaborative Messages
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.
4.3. SAV Information Manager
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.
Wu, et al. Expires 14 September 2023 [Page 9]
Internet-Draft Inter-domain SAVNET Architecture March 2023
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.
+------------------------------------+
| Source Prefix | Incoming Interface |
+---------------+--------------------+
| P1 | 1 |
| P2 | 2 |
| P3 | 3 |
+------------------------------------+
Figure 5: An Example of SAV table
Figure 5 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 [draft-huang-savnet-sav-table]. 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 [draft-huang-savnet-sav-table]). 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 [draft-huang-savnet-sav-table]). 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.
Wu, et al. Expires 14 September 2023 [Page 10]
Internet-Draft Inter-domain SAVNET Architecture March 2023
5. Partial Deployment
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.
6. Security Considerations
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:
Wu, et al. Expires 14 September 2023 [Page 11]
Internet-Draft Inter-domain SAVNET Architecture March 2023
* 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.
7. Privacy Considerations
This document should not affect the privacy of the Internet.
8. IANA Considerations
This document has no IANA requirements.
9. Contributors
Igor Lubashev
Akamai Technologies
145 Broadway
Cambridge , MA 02142
United States of America
Email: ilubashe@akamai.com
Many thanks to Igor Lubashev for the significantly helpful revision
suggestions.
Wu, et al. Expires 14 September 2023 [Page 12]
Internet-Draft Inter-domain SAVNET Architecture March 2023
10. Normative References
[draft-huang-savnet-sav-table]
Huang, M., Cheng, W., Li, D., Geng, N., Liu, M., and L.
Chen, "Source Address Validation Table Abstraction and
Application", 2023, <https://datatracker.ietf.org/doc/
draft-huang-savnet-sav-table/>.
[draft-wu-savnet-inter-domain-problem-statement]
Wu, J., Li, D., Liu, L., Huang, M., and N. Geng, "Source
Address Validation in Inter-domain Networks Gap Analysis,
Problem Statement, and Requirements", 2023,
<https://datatracker.ietf.org/doc/draft-wu-savnet-inter-
domain-problem-statement/>.
[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>.
[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
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Mingqing Huang
Huawei
Beijing
China
Wu, et al. Expires 14 September 2023 [Page 13]
Internet-Draft Inter-domain SAVNET Architecture March 2023
Email: huangmingqing@huawei.com
Li Chen
Zhongguancun Laboratory
Beijing
China
Email: lichen@zgclab.edu.cn
Nan Geng
Huawei
Beijing
China
Email: gengnan@huawei.com
Libin Liu
Zhongguancun Laboratory
Beijing
China
Email: liulb@zgclab.edu.cn
Lancheng Qin
Tsinghua University
Beijing
China
Email: qlc19@mails.tsinghua.edu.cn
Wu, et al. Expires 14 September 2023 [Page 14]