draft-ietf-sidrops-aspa-verification-02.txt   draft-ietf-sidrops-aspa-verification-03.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: May 7, 2020 Qrator Labs Expires: May 7, 2020 Qrator Labs
R. Bush
Internet Initiative Japan & Arrcus
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
J. Snijders J. Snijders
NTT NTT
November 4, 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-02 draft-ietf-sidrops-aspa-verification-03
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 5, line 27 skipping to change at page 5, line 27
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))...}, where AS(0) stands for originating AS. In this prepend(I-1))...}, where AS(0) stands for originating AS. In this
case, the sequence {AS(I), AS(I-1),...} represents different ASNs, case, the sequence {AS(I), AS(I-1),...} represents different ASNs,
that packet should pass towards the 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, a literal peer, or by a RS
IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider or at an IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider
sibling relationship. If there are other types of relationships, it or sibling relationship. If there are other types of relationships,
means that the route was leaked or the AS_PATH attribute was it 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 procedure described bellow is to check
the correctness of this statement. the correctness of this statement.
The following diagram and procedure describes the procedure that MUST The following diagram and procedure describes the procedure that MUST
be applied on routes with ROUTE_AFI received from a customer, peer or be applied on routes with ROUTE_AFI received from a customer, peer or
RS-client: RS-client:
(AS(I-1),AS(I))=Valid (AS(I-1),AS(I))=Valid
+-----+ +-----+
| | | I++ |
v | v |
+---------+ +-+-----+-+
| | (AS(I-1),AS(I))=Invalid | | (AS(I-1),AS(I))=Invalid
| Valid +----------------------------+ | Valid +----------------------------+
| | | | | |
+---------+ | +----+----+ |
| +----v----+ | +----v----+
| | | | | |
|(AS(I-1),AS(I))=Unknown | Invalid | I++|(AS(I-1),AS(I))=Unknown | Invalid |
| | | | | |
| +---------+ | +----+----+
+----v----+ ^ +----v----+ ^
| | | | | |
| Unknown +----------------------------+ | Unknown +----------------------------+
| | (AS(I-1),(AS(I))=Invalid | | (AS(I-1),(AS(I))=Invalid
+---------+ +-+-----+-+
^ | ^ |
| | | I++ |
+-----+ +-----+
(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";
skipping to change at page 6, line 50 skipping to change at page 6, line 50
4. If there is a pair (AS(I-1), AS(I)), and customer-provider 4. 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 "unknown" then the procedure also halts AS(I), ROUTE_AFI) returns "unknown" then the procedure also halts
with the outcome "unknown"; with the outcome "unknown";
5. Otherwise, the procedure halts with an outcome of "valid". 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, where Downstream follows Upstream path. If the and Downstream paths, where a Downstream follows an Upstream path.
path differs from this rule, e.g. the Downstream path is followed by If the path differs from this rule, e.g. the Downstream path is
Upstream path it means that the route was leaked or the AS_PATH followed by Upstream path it means that the route was leaked or the
attribute was malformed. The first pair (AS(I-1), AS(I)) that has AS_PATH attribute was malformed. The first pair (AS(I-1), AS(I))
"invalid" outcome of customer-provider verification procedure that has an "invalid" outcome of the customer-provider verification
indicates the end of Upstream path. All subsequent reverse pairs procedure indicates the end of the Upstream path. All subsequent
(AS(I), AS(I-1)) MUST belong to customer-provider or sibling reverse pairs (AS(I), AS(I-1)) MUST belong to a customer-provider or
relationship, thus can be also verified with ASPA objects. sibling relationship, thus can be also verified using ASPA objects.
Additional caution should be done while processing prefixes that are Additional caution should be exercised when processing prefixes that
received from transparent IXes since they don't add their ASN in the are received from transparent IXes, as they don't add their ASN in
ASPATH. the ASPATH.
The following diagram and procedure describes the procedure that MUST The following diagram and procedure describe the procedure that MUST
be applied on routes with ROUTE_AFI received from a provider or RS: be applied on routes with ROUTE_AFI received from a provider or a RS:
(AS(I-1),AS(I))=Valid (AS(I),AS(I-1))=Valid (AS(I-1),AS(I))=Valid (AS(I),AS(I-1))=Valid
+-----+ +-----+ +-----+ +-----+
| | | | | I++ | | I++ |
v | v | v | v |
+-+-----+-+ +-+-----+-+ +-+-----+-+ +-+-----+-+
| |(AS(I-1),AS(I))=Invalid| |(AS(I),AS(I-1))=Invalid | |(AS(I-1),AS(I))=Invalid| |(AS(I),AS(I-1))=Invalid
| Valid +-----------------------> Valid +---------+ | Valid +-----------------------> Valid +---------+
| | | | | | | I++ | | |
+----+----+ +----+----+ | +----+----+ +----+----+ |
| | +---v-----+ | | +---v-----+
|(AS(I-1),AS(I))=Unknown | | | I++|(AS(I-1),AS(I))=Unknown | | |
| | | Invalid | | | | Invalid |
| (AS(I),AS(I-1)=Unknown| | | | (AS(I-1),AS(I)=Unknown|I++ | |
| | +---+-----+ | | +---+-----+
+----v----+ +----v----+ ^ +----v----+ +----v----+ ^
| | | | | | | I++ | | |
| Unknown +-----------------------> Unknown +---------+ | 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
+-+-----+-+ +-+-----+-+ +-+-----+-+ +-+-----+-+
^ | ^ | ^ | ^ |
| | | | | I++ | | I++ |
+-----+ +-----+ +-----+ +-----+
(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 a route is received from a 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 the procedure
with the outcome "invalid"; halts with the outcome "invalid";
2. If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) with 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 the 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. If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) with J 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) > I, and the customer-provider verification procedure (Section 4)
returns "invalid" for (AS(I-1), AS(I), ROUTE_AFI) and "unknown" 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 for (AS(J), AS(J-1), ROUTE_AFI), then the procedure also halts
with the outcome "unknown"; with the outcome "unknown";
5. If customer-provider verification procedure (Section 4) doesn't 5. If the customer-provider verification procedure (Section 4)
return "invalid" for any (AS(I-1), AS(I)), but at least for one doesn't return "invalid" for any (AS(I-1), AS(I)), but at least
(AS(I-1), AS(I)) returns "unknown", then the procedure also halts for one (AS(I-1), AS(I)) returns "unknown", then the procedure
with the outcome "unknown"; also halts with the outcome "unknown";
6. Otherwise, the procedure halts with an outcome of "valid". 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
skipping to change at page 9, line 5 skipping to change at page 9, line 5
providers and peers. This does not preclude the provider ASes from providers and peers. This does not preclude the provider ASes from
redistribution to its other customers. By creating an ASPA with redistribution to its other customers. By creating an ASPA with
providers set of {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 providers set 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 its routes should not be received by any relying party AS from that its routes should not be received by any relying party AS from
any of its customers or peers. any of its customers or peers.
By convention, an ASPA with providers set of {0} should be the only By convention, an ASPA with a provider 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 AS 0 may coexist with other provider ASes in requirement. A provider AS 0 may coexist with other provider ASes in
the same ASPA (or other ASPA records); though in such cases, the the same ASPA (or other ASPA records); though in such cases, the
presence or absence of the provider AS 0 in ASPA does not alter the presence or absence of the provider AS 0 in ASPA does not alter the
AS_PATH 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
skipping to change at page 9, line 27 skipping to change at page 9, line 27
to their peers and/or upstreams. to their peers and/or upstreams.
In this case, two corresponding ASPA records (AS1, {AS2, ...}), (AS2, In this case, two corresponding ASPA records (AS1, {AS2, ...}), (AS2,
{AS1, ...}) 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 support integration with the 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 providers in ASPA. correct set of providers in ASPA record(s).
While it's not restricted, but it's highly recommended maintaining While it's not restricted, but it's highly recommended maintaining
for selected Customer AS a single ASPA object that covers all its for selected Customer AS a single ASPA object that covers all its
providers. Such policy should prevent race conditions during ASPA providers. Such policy should prevent race conditions during ASPA
updates that might affect prefix propagation. updates that might affect prefix propagation.
While the ASPA is capable to detect both mistake and malicious While the ASPA is able to detect both mistakes and malicious activity
activity for routes received from customers, RS-clients or peers, it for routes received from customers, RS-clients, or peers, it provides
provides only detection of mistakes for routes that are received from only detection of mistakes for routes that are received from upstream
upstream providers and RS(s). providers and RS(s).
Since upstream provider becomes a trusted point, it will be able to Since an upstream provider becomes a trusted point, it will be able
send hijacked prefixes of its customers or send hijacked prefixes to 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
have a signed agreement and such policy violation should have legal have a signed agreement and such policy violation should have legal
consequences or customer can just drop relation with such provider consequences or customer can just drop relation with such a provider
and remove corresponding ASPA record. and remove the corresponding ASPA record.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank authors of [RFC6483] since its text was The authors wish to thank authors of [RFC6483] since its text was
used as an example while writing this document. The also authors used as an example while writing this document. The also authors
wish to thank Iljitsch van Beijnum for giving a hint about Downstream wish to thank Iljitsch van Beijnum for giving a hint about Downstream
paths. paths.
10. References 10. References
skipping to change at page 12, line 9 skipping to change at page 12, line 9
Alexander Azimov Alexander Azimov
Yandex Yandex
Email: a.e.azimov@gmail.com Email: a.e.azimov@gmail.com
Eugene Bogomazov Eugene Bogomazov
Qrator Labs Qrator Labs
Email: eb@qrator.net Email: eb@qrator.net
Randy Bush
Internet Initiative Japan & Arrcus
Email: randy@psg.com
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
Email: keyur@arrcus.com Email: keyur@arrcus.com
Job Snijders Job Snijders
NTT Communications NTT Communications
Theodorus Majofskistraat 100 Theodorus Majofskistraat 100
Amsterdam 1065 SZ Amsterdam 1065 SZ
The Netherlands The Netherlands
 End of changes. 30 change blocks. 
52 lines changed or deleted 59 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/