draft-ietf-sidrops-aspa-verification-01.txt   draft-ietf-sidrops-aspa-verification-02.txt 
Network Working Group A. Azimov Network Working Group A. Azimov
Internet-Draft Yandex Internet-Draft Yandex
Intended status: Standards Track E. Bogomazov Intended status: Standards Track E. Bogomazov
Expires: January 9, 2020 Qrator Labs Expires: May 7, 2020 Qrator Labs
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
J. Snijders J. Snijders
NTT NTT
July 8, 2019 November 4, 2019
Verification of AS_PATH Using the Resource Certificate Public Key Verification of AS_PATH Using the Resource Certificate Public Key
Infrastructure and Autonomous System Provider Authorization Infrastructure and Autonomous System Provider Authorization
draft-ietf-sidrops-aspa-verification-01 draft-ietf-sidrops-aspa-verification-02
Abstract Abstract
This document defines the semantics of an Autonomous System Provider This document defines the semantics of an Autonomous System Provider
Authorization object in the Resource Public Key Infrastructure to Authorization object in the Resource Public Key Infrastructure to
verify the AS_PATH attribute of routes advertised in the Border verify the AS_PATH attribute of routes advertised in the Border
Gateway Protocol. Gateway Protocol.
Requirements Language Requirements Language
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Anomaly Propagation . . . . . . . . . . . . . . . . . . . . . 3 2. Anomaly Propagation . . . . . . . . . . . . . . . . . . . . . 3
3. Autonomous System Provider Authorization . . . . . . . . . . 4 3. Autonomous System Provider Authorization . . . . . . . . . . 4
4. Customer-Provider Verification Procedure . . . . . . . . . . 4 4. Customer-Provider Verification Procedure . . . . . . . . . . 4
5. AS_PATH Verification . . . . . . . . . . . . . . . . . . . . 5 5. AS_PATH Verification . . . . . . . . . . . . . . . . . . . . 5
5.1. Upstream Paths . . . . . . . . . . . . . . . . . . . . . 5 5.1. Upstream Paths . . . . . . . . . . . . . . . . . . . . . 5
5.2. Downstream Paths . . . . . . . . . . . . . . . . . . . . 6 5.2. Downstream Paths . . . . . . . . . . . . . . . . . . . . 6
5.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 8
6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 7 6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 8
7. Siblings (Complex Relations) . . . . . . . . . . . . . . . . 7 7. Siblings (Complex Relations) . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Border Gateway Protocol (BGP) was designed without mechanisms to The Border Gateway Protocol (BGP) was designed without mechanisms to
validate BGP attributes. Two consequences are BGP Hijacks and BGP validate BGP attributes. Two consequences are BGP Hijacks and BGP
Route Leaks [RFC7908]. BGP extensions are able to partially solve Route Leaks [RFC7908]. BGP extensions are able to partially solve
these problems. For example, ROA-based Origin Validation [RFC6483] these problems. For example, ROA-based Origin Validation [RFC6483]
can be used to detect and filter accidental mis-originations, and can be used to detect and filter accidental mis-originations, and
[I-D.ietf-grow-route-leak-detection-mitigation] can be used to detect [I-D.ietf-grow-route-leak-detection-mitigation] can be used to detect
accidental route leaks. While these upgrades to BGP are quite accidental route leaks. While these upgrades to BGP are quite
skipping to change at page 4, line 19 skipping to change at page 4, line 19
Resource allocation structure. Resource certificates are X.509 Resource allocation structure. Resource certificates are X.509
certificates that conform to the PKIX profile [RFC5280], and to the certificates that conform to the PKIX profile [RFC5280], and to the
extensions for IP addresses and AS identifiers [RFC3779]. A resource extensions for IP addresses and AS identifiers [RFC3779]. A resource
certificate is a binding by an issuer of IP address blocks and certificate is a binding by an issuer of IP address blocks and
Autonomous System (AS) numbers to the subject of a certificate, Autonomous System (AS) numbers to the subject of a certificate,
identified by the unique association of the subject's private key identified by the unique association of the subject's private key
with the public key contained in the resource certificate. The RPKI with the public key contained in the resource certificate. The RPKI
is structured so that each current resource certificate matches a is structured so that each current resource certificate matches a
current resource allocation or assignment. current resource allocation or assignment.
ASPAs are digitally signed objects that bind a selected AFI Provider ASPAs are digitally signed objects that bind, for a selected AFI, a
AS number to a Customer AS number (in terms of BGP announcements not Set of Provider AS numbers to a Customer AS number (in terms of BGP
business), and are signed by the holder of the Customer AS. An ASPA announcements not business), and are signed by the holder of the
attests that a Customer AS holder (CAS) has authorized a particular Customer AS. An ASPA attests that a Customer AS holder (CAS) has
Provider AS (PAS) to propagate the Customer's IPv4/IPv6 announcements authorized Set of Provider ASes (SPAS) to propagate the Customer's
onward, e.g. to the Provider's upstream providers or peers. The ASPA IPv4/IPv6 announcements onward, e.g. to the Provider's upstream
record profile is described in [I-D.ietf-sidrops-aspa-profile]. providers or peers. The ASPA record profile is described in
[I-D.ietf-sidrops-aspa-profile].
4. Customer-Provider Verification Procedure 4. Customer-Provider Verification Procedure
This section describes an abstract procedure that checks that pair of This section describes an abstract procedure that checks that a pair
ASNs (AS1, AS2) is included in the set of signed ASPAs. The of ASNs (AS1, AS2) is included in the set of signed ASPAs. The
semantics of its usage is defined in next section. The procedure semantics of its use is defined in next section. The procedure takes
takes (AS1, AS2, ROUTE_AFI) as input parameters and returns three (AS1, AS2, ROUTE_AFI) as input parameters and returns one of three
types of results: "valid", "invalid" and "unknown". results: "valid", "invalid" and "unknown".
A relying party (RP) must have access to a local cache of the A relying party (RP) must have access to a local cache of the
complete set of cryptographically valid ASPAs when performing complete set of cryptographically valid ASPAs when performing
customer-provider verification procedure. customer-provider verification procedure.
1. Retrieve all cryptographically valid ASPAs in a selected AFI with 1. Retrieve all cryptographically valid ASPAs in a selected AFI with
a customer value of AS1. This selection forms the set of a customer value of AS1. The union of SPAS forms the set of
"candidate ASPAs." "Candidate Providers."
2. If the set of candidate ASPAs is empty, then the procedure exits 2. If the set of Candidate Providers is empty, then the procedure
with an outcome of "unknown." exits with an outcome of "unknown."
3. If there is at least one candidate ASPA where the provider field 3. If AS2 is included in the set of Candidate Providers, then the
is AS2, then the procedure exits with an outcome of "valid." procedure exits with an outcome of "valid."
4. Otherwise, the procedure exits with an outcome of "invalid." 4. Otherwise, the procedure exits with an outcome of "invalid."
Since an AS1 may have different set providers in different AFI, it Since an AS1 may have different set providers in different AFI, it
should also have different set of corresponding ASPAs. In this case, should also have different PCAS in corresponding ASPAs. In this
the output of this procedure with input (AS1, AS2, ROUTE_AFI) may case, the output of this procedure with input (AS1, AS2, ROUTE_AFI)
have different output for different ROUTE_AFI values. may have different output for different ROUTE_AFI values.
5. AS_PATH Verification 5. AS_PATH Verification
The AS_PATH attribute identifies the autonomous systems through which The AS_PATH attribute identifies the autonomous systems through which
an UPDATE message has passed. AS_PATH may contain two types of an UPDATE message has passed. AS_PATH may contain two types of
components: ordered AS_SEQes and unordered AS_SETs, as defined in components: ordered AS_SEQes and unordered AS_SETs, as defined in
[RFC4271]. [RFC4271].
The value of each concatenated value of AS_SEQ components can be The value of each concatenated value of AS_SEQ components can be
described as set of pairs {(AS(I), prepend(I)), (AS(I-1), described as set of pairs {(AS(I), prepend(I)), (AS(I-1),
prepend(I-1))...}. In this case, the sequence {AS(I), AS(I-1),...} prepend(I-1))...}, where AS(0) stands for originating AS. In this
represents different ASNs, that packet should pass towards the case, the sequence {AS(I), AS(I-1),...} represents different ASNs,
destination. that packet should pass towards the destination.
The bellow procedure is applicable only for 32-bit AS number The bellow procedure is applicable only for 32-bit AS number
compatible BGP speakers. compatible BGP speakers.
5.1. Upstream Paths 5.1. Upstream Paths
When a route is received from a customer, literal peer or by RS at When a route is received from a customer, literal peer or by RS at
IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider or IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider or
sibling relationship. If there are other types of relationships, it sibling relationship. If there are other types of relationships, it
means that the route was leaked or the AS_PATH attribute was means that the route was leaked or the AS_PATH attribute was
malformed. The goal of the described bellow procedure is to check malformed. The goal of the described bellow procedure is to check
the correctness of this statement. the correctness of this statement.
If a route from ROUTE_AFI address family is received from a customer, The following diagram and procedure describes the procedure that MUST
peer ot RS-client, its AS_PATH MUST be verified as follows: be applied on routes with ROUTE_AFI received from a customer, peer or
RS-client:
(AS(I-1),AS(I))=Valid
+-----+
| |
v |
+---------+
| | (AS(I-1),AS(I))=Invalid
| Valid +----------------------------+
| | |
+---------+ |
| +----v----+
| | |
|(AS(I-1),AS(I))=Unknown | Invalid |
| | |
| +---------+
+----v----+ ^
| | |
| Unknown +----------------------------+
| | (AS(I-1),(AS(I))=Invalid
+---------+
^ |
| |
+-----+
(AS(I-1),AS(I))!=Invalid
1. If the closest AS in the AS_PATH is not the receiver's neighbor 1. If the closest AS in the AS_PATH is not the receiver's neighbor
ASN then procedure halts with the outcome "invalid"; ASN then procedure halts with the outcome "invalid";
2. If there is a pair (AS(I-1), AS(I)), and customer-provider 2. If there is a pair (AS(I-1), AS(I)), and customer-provider
verification procedure (Section 4) with parameters (AS(I-1), verification procedure (Section 4) with parameters (AS(I-1),
AS(I), ROUTE_AFI) returns "invalid" then the procedure also halts AS(I), ROUTE_AFI) returns "invalid" then the procedure also halts
with the outcome "invalid"; with the outcome "invalid";
3. If the AS_PATH has at least one AS_SET segment then procedure 3. If the AS_PATH has at least one AS_SET segment then procedure
halts with the outcome "unverifiable"; halts with the outcome "unverifiable";
4. Otherwise, the procedure halts with an outcome of "valid". 4. If there is a pair (AS(I-1), AS(I)), and customer-provider
verification procedure (Section 4) with parameters (AS(I-1),
AS(I), ROUTE_AFI) returns "unknown" then the procedure also halts
with the outcome "unknown";
5. Otherwise, the procedure halts with an outcome of "valid".
5.2. Downstream Paths 5.2. Downstream Paths
When route is received from provider or RS it may have both Upstream When route is received from provider or RS it may have both Upstream
and Downstream paths. The first pair (AS(I-1), AS(I)) that has and Downstream paths, where Downstream follows Upstream path. If the
path differs from this rule, e.g. the Downstream path is followed by
Upstream path it means that the route was leaked or the AS_PATH
attribute was malformed. The first pair (AS(I-1), AS(I)) that has
"invalid" outcome of customer-provider verification procedure "invalid" outcome of customer-provider verification procedure
indicates the end of Upstream path. All subsequent reverse pairs indicates the end of Upstream path. All subsequent reverse pairs
(AS(J), AS(J-1)) MUST belong to customer-provider or sibling (AS(I), AS(I-1)) MUST belong to customer-provider or sibling
relationship, thus can be also verified with ASPA objects. If there relationship, thus can be also verified with ASPA objects.
are other types of relationships, it means that the route was leaked.
Additional caution should be done while processing prefixes that are Additional caution should be done while processing prefixes that are
received from transparent IXes since they don't add their ASN in the received from transparent IXes since they don't add their ASN in the
ASPATH. ASPATH.
If a route from ROUTE_AFI address family is received from a customer The following diagram and procedure describes the procedure that MUST
or RS, its AS_PATH MUST be verified as follows: be applied on routes with ROUTE_AFI received from a provider or RS:
(AS(I-1),AS(I))=Valid (AS(I),AS(I-1))=Valid
+-----+ +-----+
| | | |
v | v |
+-+-----+-+ +-+-----+-+
| |(AS(I-1),AS(I))=Invalid| |(AS(I),AS(I-1))=Invalid
| Valid +-----------------------> Valid +---------+
| | | | |
+----+----+ +----+----+ |
| | +---v-----+
|(AS(I-1),AS(I))=Unknown | | |
| | | Invalid |
| (AS(I),AS(I-1)=Unknown| | |
| | +---+-----+
+----v----+ +----v----+ ^
| | | | |
| Unknown +-----------------------> Unknown +---------+
| |(AS(I-1),AS(I))=Invalid| |(AS(I),AS(I-1))=Invalid
+-+-----+-+ +-+-----+-+
^ | ^ |
| | | |
+-----+ +-----+
(AS(I-1),AS(I))!=Invalid (AS(I),AS(I-1))!=Invalid
1. If route is received from provider and the closest AS in the 1. If route is received from provider and the closest AS in the
AS_PATH is not the receiver's neighbor ASN then procedure halts AS_PATH is not the receiver's neighbor ASN then procedure halts
with the outcome "invalid"; with the outcome "invalid";
2. If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) where J 2. If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) with J
> I, and customer-provider verification procedure (Section 4) > I, and customer-provider verification procedure (Section 4)
returns "invalid" for both (AS(I-1), AS(I), ROUTE_AFI) and returns "invalid" for both (AS(I-1), AS(I), ROUTE_AFI) and
(AS(J), AS(J-1), ROUTE_AFI), then the procedure also halts with (AS(J), AS(J-1), ROUTE_AFI), then the procedure also halts with
the outcome "invalid"; the outcome "invalid";
3. If the AS_PATH has at least one AS_SET segment then procedure 3. If the AS_PATH has at least one AS_SET segment then procedure
halts with the outcome "unverifiable"; halts with the outcome "unverifiable";
4. Otherwise, the procedure halts with an outcome of "valid". 4. If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) with J
> I, and customer-provider verification procedure (Section 4)
returns "invalid" for (AS(I-1), AS(I), ROUTE_AFI) and "unknown"
for (AS(J), AS(J-1), ROUTE_AFI), then the procedure also halts
with the outcome "unknown";
5. If customer-provider verification procedure (Section 4) doesn't
return "invalid" for any (AS(I-1), AS(I)), but at least for one
(AS(I-1), AS(I)) returns "unknown", then the procedure also halts
with the outcome "unknown";
6. Otherwise, the procedure halts with an outcome of "valid".
5.3. Mitigation 5.3. Mitigation
If the output of the AS_PATH verification procedure is "invalid" the If the output of the AS_PATH verification procedure is "invalid" the
route MUST be rejected. route MUST be rejected.
If the output of the AS_PATH verification procedure is 'unverifiable' If the output of the AS_PATH verification procedure is 'unverifiable'
it means that AS_PATH can't be fully checked. Such routes should be it means that AS_PATH can't be fully checked. Such routes should be
treated with caution and SHOULD be processed the same way as treated with caution and SHOULD be processed the same way as
"invalid" routes. This policy goes with full correspondence to "invalid" routes. This policy goes with full correspondence to
skipping to change at page 7, line 8 skipping to change at page 8, line 41
The above AS_PATH verification procedure is able to check routes The above AS_PATH verification procedure is able to check routes
received from customers and peers. The ASPA mechanism combined with received from customers and peers. The ASPA mechanism combined with
BGP Roles [I-D.ietf-idr-bgp-open-policy] and ROA-based Origin BGP Roles [I-D.ietf-idr-bgp-open-policy] and ROA-based Origin
Validation [RFC6483] provide a fully automated solution to detect and Validation [RFC6483] provide a fully automated solution to detect and
filter hijacks and route leaks, including malicious ones. filter hijacks and route leaks, including malicious ones.
6. Disavowal of Provider Authorizaion 6. Disavowal of Provider Authorizaion
An ASPA is a positive attestation that an AS holder has authorized An ASPA is a positive attestation that an AS holder has authorized
its provider to redistribute received routes to the provider's its providers to redistribute received routes to the provider's
providers and peers. This does not preclude the provider AS from providers and peers. This does not preclude the provider ASes from
redistribution to its other customers. By creating an ASPA where the redistribution to its other customers. By creating an ASPA with
provider AS is 0, the customer indicates that no provider should providers set of {0}, the customer indicates that no provider should
further announce its routes. Specifically, AS 0 is reserved to further announce its routes. Specifically, AS 0 is reserved to
identify provider-free networks, Internet exchange meshes, etc. identify provider-free networks, Internet exchange meshes, etc.
An ASPA with a provider AS of 0 is a statement by the customer AS An ASPA with a providers set of {0} is a statement by the customer AS
that the its routes should not be received by any relying party AS that its routes should not be received by any relying party AS from
from any of its customers or peers. any of its customers or peers.
By convention, an ASPA with a provider AS of 0 should be the only By convention, an ASPA with providers set of {0} should be the only
ASPA issued by a given AS holder; although this is not a strict ASPA issued by a given AS holder; although this is not a strict
requirement. A provider 0 ASPA may coexist with ASPAs that have requirement. A provider AS 0 may coexist with other provider ASes in
different provider AS values; though in such cases, the presence or the same ASPA (or other ASPA records); though in such cases, the
absence of the provider AS 0 ASPA does not alter the AS_PATH presence or absence of the provider AS 0 in ASPA does not alter the
verification procedure. AS_PATH verification procedure.
7. Siblings (Complex Relations) 7. Siblings (Complex Relations)
There are peering relationships which can not be described as There are peering relationships which can not be described as
strictly simple peer-peer or customer-provider; e.g. when both strictly simple peer-peer or customer-provider; e.g. when both
parties are intentionally sending prefixes received from each other parties are intentionally sending prefixes received from each other
to their peers and/or upstreams. to their peers and/or upstreams.
In this case, two symmetric ASPAs records {(AS1, AS2), (AS2, AS1)} In this case, two corresponding ASPA records (AS1, {AS2, ...}), (AS2,
must be created by AS1 and AS2 respectively. {AS1, ...}) must be created by AS1 and AS2 respectively.
8. Security Considerations 8. Security Considerations
The proposed mechanism is compatible only with BGP implementations The proposed mechanism is compatible only with BGP implementations
that can process 32-bit ASNs in the ASPATH. This limitation should that can process 32-bit ASNs in the ASPATH. This limitation should
not have a real effect on operations - such legacy BGP routers a rare not have a real effect on operations - such legacy BGP routers a rare
and it's highly unlikely that they do support integration with RPKI. and it's highly unlikely that they do support integration with RPKI.
ASPA issuers should be aware of the verification implication in ASPA issuers should be aware of the verification implication in
issuing an ASPA - an ASPA implicitly invalidates all routes passed to issuing an ASPA - an ASPA implicitly invalidates all routes passed to
upstream providers other than the provider ASs listed in the upstream providers other than the provider ASs listed in the
collection of ASPAs. It is the Customer AS's duty to maintain a collection of ASPAs. It is the Customer AS's duty to maintain a
correct set of ASPAs. correct set of providers in ASPA.
While it's not restricted, but it's highly recommended maintaining
for selected Customer AS a single ASPA object that covers all its
providers. Such policy should prevent race conditions during ASPA
updates that might affect prefix propagation.
While the ASPA is capable to detect both mistake and malicious While the ASPA is capable to detect both mistake and malicious
activity for routes received from customers, RS-clients or peers, it activity for routes received from customers, RS-clients or peers, it
provides only detection of mistakes for routes that are received from provides only detection of mistakes for routes that are received from
upstream providers and RS(s). upstream providers and RS(s).
Since upstream provider becomes a trusted point, it will be able to Since upstream provider becomes a trusted point, it will be able to
send hijacked prefixes of its customers or send hijacked prefixes send hijacked prefixes of its customers or send hijacked prefixes
with malformed AS_PATHs back. While it may happen in theory, it's with malformed AS_PATHs back. While it may happen in theory, it's
doesn't seem to be a real scenario: normally customer and provider doesn't seem to be a real scenario: normally customer and provider
 End of changes. 26 change blocks. 
64 lines changed or deleted 136 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/