Bicone Source Address Validation
draft-li-sidrops-bicone-sav-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dan Li , Lancheng Qin , Li Chen , Libin Liu | ||
| Last updated | 2024-01-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-sidrops-bicone-sav-00
SIDROPS D. Li
Internet-Draft L. Qin
Intended status: Best Current Practice Tsinghua University
Expires: 14 July 2024 L. Chen
L. Liu
Zhongguancun Laboratory
11 January 2024
Bicone Source Address Validation
draft-li-sidrops-bicone-sav-00
Abstract
The primary design goal of source address validation (SAV) is
avoiding improper block (i.e., blocking legitimate traffic) while
maintaining directionality, especially in partial deployment
scenarios (see [I-D.ietf-savnet-inter-domain-problem-statement] and
[RFC8704]). Existing advanced SAV solutions typically generate
ingress SAV allowlist filters by using information related to
customer cone. This document analyzes potential improper block
problems of solely using allowlist filters. To minimize improper
block, this document proposes Bicone SAV, which enhances the SAV
technology by additionally using blocklist filters generated based on
information related to provider cone.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 July 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 14 July 2024 [Page 1]
Internet-Draft Bicone SAV January 2024
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Improper Block Problems of Solely Using An Allowlist . . . . 3
4. Generating A Blocklist Using Information Related to Provider
Cone . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Using Both Allowlist and Blocklist Filters . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Source address spoofing is one of the most serious security threats
to today's Internet. It serves as a main attack vector for
Distributed Denial of Service (DDoS) attacks and is commonly used in
reflective DDoS attacks. To mitigate source address spoofing, many
source address validation (SAV) solutions (e.g., BCP38 [RFC2827] and
BCP84 [RFC3704] [RFC8704]) have been proposed. The primary design
goal of SAV solutions is avoiding improper block (i.e., blocking
legitimate traffic) while maintaining directionality, especially in
partial deployment scenarios (see
[I-D.ietf-savnet-inter-domain-problem-statement] and [RFC8704]).
However, previous SAV solutions cannot meet the design goal due to
technical limitations (see
[I-D.ietf-savnet-intra-domain-problem-statement] and
[I-D.ietf-savnet-inter-domain-problem-statement]).
Existing advanced SAV solutions (e.g., EFP-uRPF [RFC8704]) typically
generate ingress SAV allowlist filters by using information related
to customer cone. Specifically, they aim to generate an allowlist on
an interface facing a customer or lateral peer AS by identifying
prefixes in the customer's or lateral peer AS's customer cone.
Li, et al. Expires 14 July 2024 [Page 2]
Internet-Draft Bicone SAV January 2024
However, solely using an allowlist may cause legitimate traffic to be
blocked if the allowlist fails to cover all prefixes in a customer
cone. This document analyzes potential improper block problems of
solely using allowlist filters, and proposes Bicone SAV to minimize
improper block. Bicone SAV focuses on generating robust ingress SAV
filters for an interface facing a customer or lateral peer AS. In
addition to applying an allowlist like existing advanced SAV
solutions, Bicone SAV applies a blocklist generated by identifying
prefixes in the provider cone.
The reader is encouraged to be familiar with [RFC8704],
[I-D.ietf-sidrops-aspa-profile], [RFC6482], and
[I-D.ietf-sidrops-aspa-verification].
1.1. 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. Terminology
Provider cone: the set of ASes an AS can reach by using only
customer-to-provider links.
3. Improper Block Problems of Solely Using An Allowlist
The basic idea of existing advanced SAV solutions is generating an
allowlist by using information related to a customer's (or lateral
peer's) customer cone. Specifically, they identify prefixes in a
customer's (or lateral peer's) customer cone and only accepts data
packets with source addresses belonging to these prefixes on the
interface facing that customer (or lateral peer). This is because
data packets received from a customer or lateral peer should use
source addresses belonging to prefixes in the customer's or lateral
peer's customer cone unless there is a route leak [RFC7908].
EFP-uRPF (BCP84 [RFC8704]) generates allowlists by using BGP UPDATE
messages related to the customer cone. However, if a multi-homed AS
in the customer cone limits the propagation of its prefixes, EFP-uRPF
may miss these prefixes in the allowlist, resulting in improper
block. Section 3.3 of [RFC8704] has given such an example of limited
propagation of prefixes where a multi-homed customer AS attaches
NO_EXPORT to all prefixes announced to one transit provider.
Figure 1 illustrates a similar scenario of limited propagation of
prefixes in customer cone. Since AS1 attaches NO_EXPORT to routes
Li, et al. Expires 14 July 2024 [Page 3]
Internet-Draft Bicone SAV January 2024
for P1 and P2 announced to AS2, routes for P1 and P2 are not
propagated on the AS2-AS4 interface. Because AS4 never receives
routes for P1 and P2 from its customer AS2, both EFP-uRPF Algorithm A
and Algorithm B at AS4 will block legitimate data packets received on
AS4-AS2 interface with source addresses in P1 or P2.
P1[AS5 AS3 AS1]
P2[AS5 AS3 AS1]
+---------+ (P2P/P2C) +---------+
| AS4 |<----------+ AS5 |
+---------+ +---------+
/\ /\
P1 and P2 not / / P1[AS3 AS1]
propagated / / P2[AS3 AS1]
(C2P) / / (C2P)
+---------+ +---------+
| AS2 | | AS3 |
+---------+ +---------+
/\ /\
P1[AS1] NO_EXPORT \ / P1[AS1]
P2[AS1] NO_EXPORT \ / P2[AS1]
(C2P) \ / (C2P)
+---------+
| AS1 |
+---------+
P1, P2 (prefixes originated)
Figure 1: An example of limited propagation of prefixes in the
customer cone
Some more recent SAV solutions (e.g., BAR-SAV
[I-D.ietf-sidrops-bar-sav]) additionally use Autonomous System
Provider Authorization (ASPA) [I-D.ietf-sidrops-aspa-profile] and
Route Origin Authorization (ROA) [RFC6482] to generate a more robust
allowlist. However, since registering ASPAs and ROAs is optional for
network operators, ASPAs and ROAs will be partially deployed for a
long time. When some ASPAs and ROAs are missing, the SAV solution
will still fail to discover all prefixes in a customer's or lateral
peer's customer cone, leading to improper block.
Overall, considering the complexity of inter-domain routing, existing
SAV solutions which solely use an allowlist may fail to identify all
prefixes in a customer's (or lateral peer's) customer cone. In this
case, the generated allowlist may result in improper block. To
minimize improper block, Bicone SAV additionally generates a
blocklist on an interface facing a customer or lateral peer by using
BGP UPDATE messages, ASPAs, and ROAs that are related to the provider
cone.
Li, et al. Expires 14 July 2024 [Page 4]
Internet-Draft Bicone SAV January 2024
In the following, Section 4 describes how to generate the blocklist
and Section 5 describes how to perform more robust ingress SAV
filtering by using both allowlist and blocklist filters.
4. Generating A Blocklist Using Information Related to Provider Cone
Bicone SAV enhances the robustness of SAV through using a blocklist
on an interface facing a customer or lateral peer. The provider cone
of an AS is defined as the set of ASes an AS can reach by using only
customer-to-provider links. Considering prefixes associated with
ASes in the provider cone should not be used as source addresses in
data packets received from any customer or lateral peer AS unless
there is a route leak [RFC7908]. The blocklist should contain
prefixes belonging to the provider cone.
To generate a blocklist, an AS first identifies ASes in its provider
cone by using ASPAs and AS-PATH in BGP UPDATE messages. Then, it
discovers prefixes belonging to these ASes in provider cone and
includes those prefixes in the blocklist. Data packets received from
customers or lateral peers with source addresses in the blocklist
should be blocked.
Note that if an AS cannot identify all ASes in the provider cone when
ASPAs are partially deployed, the generated blocklist will not
include all prefixes in the provider cone. In this case, the
generated blocklist can still block spoofing traffic received from
customers and lateral peers with source addresses in the blocklist.
Therefore, Bicone SAV provides immediate incremental benefits to
early adopters.
A detailed description of blocklist generation procedure is as
follows:
1. Create the set of all directly connected Provider ASNs. Call it
AS-set Z(1).
2. Create the set of all unique AS_PATHs in Adj-RIBs-In of all
interfaces facing Providers.
3. For each unique AS_PATH with N (N>1) ASNs, i.e., [ASN_{1},
ASN_{2}, ..., ASN_{i}, ASN_{i+1}, ..., ASN_{N}] where ASN_{i} is
the ith ASN in AS_PATH and the first ASN (i.e., ASN_{1}) is a
directly connected Provider ASN. If all unique AS_PATHs have
been processed, go to Step 8.
4. Let i = N
5. Decrement i to i-1.
Li, et al. Expires 14 July 2024 [Page 5]
Internet-Draft Bicone SAV January 2024
6. If ASN_{i} authorizes ASN_{i+1} as a Provider in ASN_{i}'s ASPA,
ASNs from ASN_{1} to ASN_{i+1} (i.e., ASN_{1}, ASN_{2}, ...,
ASN_{i}, and ASN_{i+1}) are included in AS-set Z(1) and go to
Step 3.
7. If i == 1, go to Step 3. Else, go to Step 5.
8. Let k = 1.
9. Increment k to k+1.
10. Create AS-set Z(k) of ASNs that are not in AS-set Z(k-1) but are
authorized as Providers in ASPAs of any ASN in AS-set Z(k-1).
11. If AS-set Z(k) is null, then set k_max = k-1 and go to Step 12.
Else, form the union of AS-set Z(k) and AS-set Z(k-1) as AS-set
Z(k) and go to Step 9.
12. Select all ROAs in which the authorized origin ASN is in AS-set
Z(k_max). Form the union of the sets of prefixes in the
selected ROAs. Call it Prefix-set P1.
13. Using the routes in Adj-RIBs-In of all interfaces facing
Providers, create a set of prefixes originated by any ASN in AS-
set Z(k_max). Call it Prefix-set P2.
14. Form the union of Prefix-set P1 and Prefix-set P2. Apply this
union set as a blocklist on every interface facing a Customer or
Lateral Peer.
5. Using Both Allowlist and Blocklist Filters
Although using a blocklist helps reduce improper block when an
allowlist does not include all prefixes in a customer's or lateral
peer's customer cone, it may also block legitimate traffic in the CDN
and DSR scenario as existing SAV solutions do (see
[I-D.ietf-savnet-inter-domain-problem-statement] and
[I-D.ietf-sidrops-bar-sav]). To minimize improper block, it is
recommended to use both allowlist and blocklist filters. The
allowlist is generated by discovering as many prefixes in the
customer's or lateral peer's customer cone as possible (see [RFC8704]
and [I-D.ietf-sidrops-bar-sav]) and the blocklist is generated by
discovering as many prefixes in the provider cone as possible (see
Section 4).
A detailed description of SAV procedure is as follows:
Li, et al. Expires 14 July 2024 [Page 6]
Internet-Draft Bicone SAV January 2024
1. Check if source addresses of data packets received from a
customer or lateral peer are included in the corresponding
allowlist. If so, these data packets are accepted. If not, go
to Step 2.
2. Check if source addresses of data packets received from a
customer or lateral peer are included in the corresponding
blocklist. If so, these data packets are blocked. If not, these
data packets should be accepted to avoid improper block.
If an AS can make sure the generated allowlist covers all prefixes in
a customer's or lateral peer's customer cone, it does not need to use
a blocklist on that corresponding interface and can only accept data
packets received on that interface with source addresses in the
allowlist.
6. Security Considerations
The security considerations described in [RFC8704],
[I-D.ietf-sidrops-bar-sav], [I-D.ietf-sidrops-aspa-profile],
[RFC6482], and [I-D.ietf-sidrops-aspa-verification] also applies to
this document.
7. IANA Considerations
This document has no IANA requirements.
8. References
8.1. Normative References
[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>.
[I-D.ietf-sidrops-aspa-profile]
Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley,
R., and B. Maddison, "A Profile for Autonomous System
Provider Authorization", Work in Progress, Internet-Draft,
draft-ietf-sidrops-aspa-profile-17, 7 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-profile-17>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
Li, et al. Expires 14 July 2024 [Page 7]
Internet-Draft Bicone SAV January 2024
[I-D.ietf-sidrops-aspa-verification]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
J., and K. Sriram, "BGP AS_PATH Verification Based on
Autonomous System Provider Authorization (ASPA) Objects",
Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
verification-16, 29 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-verification-16>.
[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>.
8.2. Informative References
[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>.
[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-02, 17 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
intra-domain-problem-statement-02>.
[I-D.ietf-savnet-inter-domain-problem-statement]
Wu, J., Li, D., Liu, L., Huang, M., and K. Sriram, "Source
Address Validation in Inter-domain Networks Gap Analysis,
Problem Statement, and Requirements", Work in Progress,
Internet-Draft, draft-ietf-savnet-inter-domain-problem-
statement-02, 22 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
inter-domain-problem-statement-02>.
Li, et al. Expires 14 July 2024 [Page 8]
Internet-Draft Bicone SAV January 2024
[I-D.ietf-sidrops-bar-sav]
Sriram, K., Lubashev, I., and D. Montgomery, "Source
Address Validation Using BGP UPDATEs, ASPA, and ROA (BAR-
SAV)", Work in Progress, Internet-Draft, draft-ietf-
sidrops-bar-sav-02, 12 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
bar-sav-02>.
[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
and B. Dickson, "Problem Definition and Classification of
BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
2016, <https://www.rfc-editor.org/info/rfc7908>.
Authors' Addresses
Dan Li
Tsinghua University
Beijing
China
Email: tolidan@tsinghua.edu.cn
Lancheng Qin
Tsinghua University
Beijing
China
Email: qlc19@mails.tsinghua.edu.cn
Li Chen
Zhongguancun Laboratory
Beijing
China
Email: lichen@zgclab.edu.cn
Libin Liu
Zhongguancun Laboratory
Beijing
China
Email: liulb@zgclab.edu.cn
Li, et al. Expires 14 July 2024 [Page 9]