draft-ietf-sidrops-aspa-verification-05.txt   draft-ietf-sidrops-aspa-verification-06.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: March 14, 2021 Qrator Labs Expires: May 6, 2021 Qrator Labs
R. Bush R. Bush
Internet Initiative Japan & Arrcus Internet Initiative Japan & Arrcus
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
J. Snijders J. Snijders
NTT NTT
September 10, 2020 November 2, 2020
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-05 draft-ietf-sidrops-aspa-verification-06
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 49 skipping to change at page 1, line 49
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 March 14, 2021. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . 7
5.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 9
6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 8 6. Disavowal of Provider Authorizaion . . . . . . . . . . . . . 10
7. Siblings (Complex Relations) . . . . . . . . . . . . . . . . 9 7. Mutual Transit (Complex Relations) . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 3, line 13 skipping to change at page 3, line 13
validation. Unfortunately, strict cryptographic validation brought validation. Unfortunately, strict cryptographic validation brought
expensive computational overhead for BGP routers. BGPSec also proved expensive computational overhead for BGP routers. BGPSec also proved
vulnerable to downgrade attacks that nullify the benefits of AS_PATH vulnerable to downgrade attacks that nullify the benefits of AS_PATH
signing. As a result, to abuse the AS_PATH or any other signed signing. As a result, to abuse the AS_PATH or any other signed
transit attribute, an attacker merely needs to downgrade to 'old' transit attribute, an attacker merely needs to downgrade to 'old'
BGP-4. BGP-4.
An alternative approach was introduced with soBGP An alternative approach was introduced with soBGP
[I-D.white-sobgp-architecture]. Instead of strong cryptographic [I-D.white-sobgp-architecture]. Instead of strong cryptographic
AS_PATH validation, it created an AS_PATH security function based on AS_PATH validation, it created an AS_PATH security function based on
a shared database of ASN adjacencies. While such an approach has a shared database of AS adjacencies. While such an approach has
reasonable computational cost, the two side adjacencies don't provide reasonable computational cost, the two side adjacencies don't provide
a way to automate anomaly detection without high adoption rate - an a way to automate anomaly detection without high adoption rate - an
attacker can easily create a one-way adjacency. SO-BGP transported attacker can easily create a one-way adjacency. SO-BGP transported
data about adjacencies in new additional BGP messages, which was data about adjacencies in new additional BGP messages, which was
recursively complex thus significantly increasing adoption complexity recursively complex thus significantly increasing adoption complexity
and risk. In addition, the general goal to verify all AS_PATHs was and risk. In addition, the general goal to verify all AS_PATHs was
not achievable given the indirect adjacencies at internet exchange not achievable given the indirect adjacencies at internet exchange
points. points.
Instead of checking AS_PATH correctness, this document focuses on Instead of checking AS_PATH correctness, this document focuses on
skipping to change at page 4, line 26 skipping to change at page 4, line 26
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.
ASPA is digitally signed object that bind, for a selected AFI, a Set ASPA is digitally signed object that bind, for a selected AFI, a Set
of Provider AS numbers to a Customer AS number (in terms of BGP of Provider AS numbers to a Customer AS number (in terms of BGP
announcements not business), and are signed by the holder of the announcements not business), and are signed by the holder of the
Customer AS. An ASPA attests that a Customer AS holder (CAS) has Customer AS. An ASPA attests that a Customer AS holder (CAS) has
authorized Set of Provider ASes (SPAS) to propagate the Customer's authorized Set of Provider ASes (SPAS) to propagate the Customer's
IPv4/IPv6 announcements onward, e.g. to the Provider's upstream IPv4/IPv6 announcements onward, e.g. to the Provider's upstream
providers or peers. The ASPA record profile is described in providers or peers. The ASPA record profile is described in
[I-D.ietf-sidrops-aspa-profile]. For a selected Customer AS MAY [I-D.ietf-sidrops-aspa-profile]. For a selected Customer AS SHOULD
exist only single ASPA object. exist only single ASPA object. In this document we will use
ASPA(AS1, AFI, [AS2, ...]) as notation to represent ASPA object for
AS1 in the selected AFI.
4. Customer-Provider Verification Procedure 4. Customer-Provider Verification Procedure
This section describes an abstract procedure that checks that a pair This section describes an abstract procedure that checks that a pair
of 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 use is defined in next section. The procedure takes semantics of its use is defined in next section. The procedure takes
(AS1, AS2, ROUTE_AFI) as input parameters and returns one of three (AS1, AS2, AFI) as input parameters and returns one of three results:
results: "valid", "invalid" and "unknown". "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 cryptographically valid ASPA in a selected AFI with a 1. Retrieve all cryptographically valid ASPAs in a selected AFI with
customer value of AS1. If there is no valid ASPA record for AS1 a customer value of AS1. The union of SPAS forms the set of
the procedure exits with an outcome of "unknown." "Candidate Providers."
2. If AS2 is included in the SPAS, then the procedure exits with an 2. If the set of Candidate Providers is empty, then the procedure
outcome of "valid." exits with an outcome of "Unknown."
3. Otherwise, the procedure exits with an outcome of "invalid." 3. If AS2 is included in the Candidate Providers, then the procedure
exits with an outcome of "Valid."
Since an AS1 may have different set providers in different AFI, it 4. Otherwise, the procedure exits with an outcome of "Invalid."
Since an AS1 may have different set of providers in different AFI, it
should also have different PCAS in corresponding ASPAs. In this should also have different PCAS in corresponding ASPAs. In this
case, the output of this procedure with input (AS1, AS2, ROUTE_AFI) case, the output of this procedure with input (AS1, AS2, AFI) may
may have different output for different ROUTE_AFI values. have different output for different 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: AS_SEQUENCEs and AS_SETs, as defined in [RFC4271].
[RFC4271].
The value of each concatenated value of AS_SEQ components can be We will use index of AS_PATH segments, where Seg(0) stands for the
described as set of pairs {(AS(I), prepend(I)), (AS(I-1), segment of originating AS. We will use Seg(I).value and Seg(I).type
prepend(I-1))...}, where AS(0) stands for originating AS. In this to represent Ith segment value and type respectively.
case, the sequence {AS(I), AS(I-1),...} represents different ASNs,
that packet should pass towards the destination.
The bellow procedure is applicable only for 32-bit AS number The below procedures are 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, a literal peer, or by a RS When a route is received from a customer, a literal peer, or by a RS
at an IX, each pair (AS(I-1), AS(I)) MUST belong to customer-provider at an IX, each consecutive AS_SEQUENCE pair MUST be equal (prepend
or sibling relationship. If there are other types of relationships, policy) or belong to customer-provider or mutual transit relationship
it means that the route was leaked or the AS_PATH attribute was (Section 7). If there are other types of relationships, it means
malformed. The goal of the procedure described bellow is to check that the route was leaked or the AS_PATH attribute was malformed.
the correctness of this statement. The goal of the procedure described below is to check the correctness
of this statement.
The following diagram and procedure describes the procedure that MUST The following Python function and algorithm describes the procedure
be applied on routes with ROUTE_AFI received from a customer, peer or that MUST be applied on routes with AFI received from a customer,
RS-client: peer or RS-client:
(AS(I-1),AS(I))=Valid def check_upflow_path(self, aspath, neighbor_as, afi):
+-----+ if len(aspath) == 0:
| I++ | return Invalid
v |
+-+-----+-+
| | (AS(I-1),AS(I))=Invalid
| Valid +----------------------------+
| | |
+----+----+ |
| +----v----+
| | |
I++|(AS(I-1),AS(I))=Unknown | Invalid |
| | |
| +----+----+
+----v----+ ^
| | |
| Unknown +----------------------------+
| | (AS(I-1),(AS(I))=Invalid
+-+-----+-+
^ |
| I++ |
+-----+
(AS(I-1),AS(I))!=Invalid
1. If the closest AS in the AS_PATH is not the receiver's neighbor if aspath[-1].type == AS_SEQUENCE and aspath[-1].value != neighbor_as:
ASN then procedure halts with the outcome "invalid"; return Invalid
2. If there is a pair (AS(I-1), AS(I)), and customer-provider semi_state = Valid
verification procedure (Section 4) with parameters (AS(I-1),
AS(I), ROUTE_AFI) returns "invalid" then the procedure also halts
with the outcome "invalid";
3. If the AS_PATH has at least one AS_SET segment then procedure as1 = 0
halts with the outcome "unverifiable"; for segment in aspath:
if segment.type != AS_SEQUENCE:
as1 = 0
semi_state = Unverifiable
elif segment.type == AS_SEQUENCE:
if not as1:
as1 = segment.value
elif as1 == segment.value:
continue
else:
pair_check = verify_pair(as1, segment.value, afi)
if pair_check == Invalid:
return Invalid
elif pair_check == Unknown and semi_state == Valid:
semi_state = pair_check
as1 = segment.value
return semi_state
4. If there is a pair (AS(I-1), AS(I)), and customer-provider 1. If the the AS_PATH has zero length then procedure halts with the
verification procedure (Section 4) with parameters (AS(I-1), outcome "Invalid";
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". 2. If the first segment in the AS_PATH has type AS_SEQUENCE and its
value isn't equal to receiver's neighbor AS then procedure halts
with the outcome "Invalid";
3. If there exists I such that Seg(I-1).type and Seg(I).type equal
to AS_SEQUENCE, Seg(I-1).value != Seg(I).value and customer-
provider verification procedure (Section 4) with parameters
(Seg(I-1).value, Seg(I).value, AFI) returns "Invalid" then the
procedure also halts with the outcome "Invalid";
4. If the AS_PATH has at least one AS_SET segment then procedure
halts with the outcome "Unverifiable";
5. If there exists I such that Seg(I-1).type and Seg(I).type equal
to AS_SEQUENCE, Seg(I-1).value != Seg(I).value and customer-
provider verification procedure (Section 4) with parameters
(Seg(I-1).value, Seg(I).value, AFI) returns "Unknown" then the
procedure also halts with the outcome "Unknown";
6. 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 a Downstream follows an Upstream path. and Downstream fragments, where a Downstream follows an Upstream
If the path differs from this rule, e.g. the Downstream path is fragment. If the path differs from this rule, e.g. the Downstream
followed by Upstream path it means that the route was leaked or the fragment is followed by Upstream fragment it means that the route was
AS_PATH attribute was malformed. The first pair (AS(I-1), AS(I)) leaked or the AS_PATH attribute was malformed. The first unequal
that has an "invalid" outcome of the customer-provider verification pair of AS_SEQUENCE segments that has an "Invalid" outcome of the
procedure indicates the end of the Upstream path. All subsequent customer-provider verification procedure indicates the end of the
reverse pairs (AS(I), AS(I-1)) MUST belong to a customer-provider or Upstream fragment. All subsequent reverse pairs of AS_SEQUENCE
sibling relationship, thus can be also verified using ASPA objects. segments MUST be equal (prepend policy) or belong to a customer-
provider or mutual transit relationship Section 7, thus can be also
verified using ASPA objects.
Additional caution should be exercised when processing prefixes that Additional caution should be exercised when processing prefixes that
are received from transparent IXes, as they don't add their ASN in are received from transparent IXes, as they don't add their AS in the
the ASPATH. AS_PATH. At the same time, we can't rely on IX 'transparency' in
general since there are IXes that do add their AS and there are
control communities that give a way to explicitly add IX AS in the
path.
The following diagram and procedure describe the procedure that MUST The following Python function and procedure describe the procedure
be applied on routes with ROUTE_AFI received from a provider or a RS: that MUST be applied on routes with AFI received from a provider or a
RS:
(AS(I-1),AS(I))=Valid (AS(I),AS(I-1))=Valid def check_downflow_path(self, aspath, neighbor_as, afi, from_ix):
+-----+ +-----+ if len(aspath) == 0:
| I++ | | I++ | return Invalid
v | v |
+-+-----+-+ +-+-----+-+
| |(AS(I-1),AS(I))=Invalid| |(AS(I),AS(I-1))=Invalid
| Valid +-----------------------> Valid +---------+
| | I++ | | |
+----+----+ +----+----+ |
| | +---v-----+
I++|(AS(I-1),AS(I))=Unknown | | |
| | | Invalid |
| (AS(I-1),AS(I)=Unknown|I++ | |
| | +---+-----+
+----v----+ +----v----+ ^
| | I++ | | |
| Unknown +-----------------------> Unknown +---------+
| |(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
1. If a route is received from a provider and the closest AS in the if aspath[-1].type == AS_SEQUENCE and not from_ix and aspath[-1].value != neighbor_as:
AS_PATH is not the receiver's neighbor ASN, then the procedure return Invalid
halts with the outcome "invalid"; else:
semi_state = Valid
2. If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) with J as1 = 0
> I, and the customer-provider verification procedure (Section 4) upflow_fragment = True
returns "invalid" for both (AS(I-1), AS(I), ROUTE_AFI) and for segment in aspath:
(AS(J), AS(J-1), ROUTE_AFI), then the procedure also halts with if segment.type != AS_SEQUENCE:
the outcome "invalid"; as1 = 0
semi_state = Unverifiable
elif segment.type == AS_SEQUENCE:
if not as1:
as1 = segment.value
elif as1 == segment.value:
continue
else:
if upflow_fragment:
pair_check = verify_pair(as1, segment.value, afi)
if pair_check == Invalid:
upflow_fragment = False
elif pair_check == Unknown and semi_state == Valid:
semi_state = Unknown
else:
pair_check = verify_pair(segment.value, as1, afi)
if pair_check == Invalid:
return Invalid
elif pair_check == Unknown and semi_state == Valid:
semi_state = pair_check
as1 = segment.value
3. If the AS_PATH has at least one AS_SET segment then procedure return semi_state
halts with the outcome "unverifiable";
4. If there are two pairs (AS(I-1), AS(I)), (AS(J-1), AS(J)) with J 1. If the the AS_PATH has zero length then procedure halts with the
> I, and the customer-provider verification procedure (Section 4) outcome "Invalid";
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 the customer-provider verification procedure (Section 4) 2. If a route is received from a provider and the first segment in
doesn't return "invalid" for any (AS(I-1), AS(I)), but at least the AS_PATH has type AS_SEQUENCE and its value isn't equal to
for one (AS(I-1), AS(I)) returns "unknown", then the procedure receiver's neighbor AS, then the procedure halts with the outcome
also halts with the outcome "unknown"; "Invalid";
6. Otherwise, the procedure halts with an outcome of "valid". 3. Let's define I_MIN as the minimal index for which Seg(I-1).type
and Seg(I).type equal to AS_SEQUENCE, its values aren't equal and
the verification procedure for (Seg(I-1).value, Seg(I).value,
AFI) returns "Invalid". If I_MIN doesn't exist put the length of
AS_PATH in I_MIN variable and jump to 5.
4. If there exists J > I_MIN such that both Seg(J-1).type,
Seg(J).type equal to AS_SEQUENCE, Seg(J-1).value != Seg(J).value
and the customer-provider verification procedure (Section 4)
returns "Invalid" for (Seg(J).value, Seg(J-1).value, AFI), then
the procedure halts with the outcome "Invalid";
5. If the AS_PATH has at least one AS_SET segment then procedure
halts with the outcome "Unverifiable";
6. If there exists J > I_MIN such that both Seg(J-1).type,
Seg(J).type equal to AS_SEQUENCE, Seg(J-1).value != Seg(J).value
and the customer-provider verification procedure (Section 4)
returns "Unknown" for (Seg(J).value, Seg(J-1).value, AFI), then
the procedure halts with the outcome "Unknown";
7. If there exists I_MIN > J such that both Seg(J-1).type,
Seg(J).type equal to AS_SEQUENCE, Seg(J-1).value != Seg(J).value
and the customer-provider verification procedure (Section 4)
returns "Unknown" for (Seg(J-1).value, Seg(J).value, AFI), then
the procedure halts with the outcome "Unknown";
8. 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
[I-D.kumari-deprecate-as-set-confed-set]. [I-D.kumari-deprecate-as-set-confed-set].
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 customer, peers, providers, RS, and RS-clients. The
BGP Roles [I-D.ietf-idr-bgp-open-policy] and ROA-based Origin ASPA mechanism combined with BGP Roles [I-D.ietf-idr-bgp-open-policy]
Validation [RFC6483] provide a fully automated solution to detect and and ROA-based Origin Validation [RFC6483] can provide a fully
filter hijacks and route leaks, including malicious ones. automated solution to detect and 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 providers 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 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(AS, AFI, [0]) is a statement by the customer AS that its
that its routes should not be received by any relying party AS from routes should not be received by any relying party AS from any of its
any of its customers or peers. customers or peers.
By convention, an ASPA with a provider set of {0} should be the only By convention, an ASPA(AS, AFI, [0]) should be the only ASPA issued
ASPA issued by a given AS holder; although this is not a strict by a given AS holder in the selected AFI; although this is not a
requirement. A provider AS 0 may coexist with other provider ASes in strict requirement. An 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 in the same AFI); though in such
presence or absence of the provider AS 0 in ASPA does not alter the cases, the presence or absence of the provider AS 0 in ASPA does not
AS_PATH verification procedure. alter the AS_PATH verification procedure.
7. Siblings (Complex Relations) 7. Mutual Transit (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 corresponding ASPA records (AS1, {AS2, ...}), (AS2, In this case, two corresponding records ASPA(AS1, AFI, [AS2, ...]),
{AS1, ...}) must be created by AS1 and AS2 respectively. ASPA(AS2, AFI, [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 are
and it's highly unlikely that they support integration with the RPKI. rare 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 ASPA upstream providers other than the provider ASs listed in the ASPA
record. It is the Customer AS's duty to maintain a correct set of record. It is the Customer AS's duty to maintain a correct set of
providers in ASPA record(s). 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. The software that
provides hosting for ASPA records SHOULD support enforcement of this
rule. In the case of the transition process between different CA
registries, the ASPA records SHOULD be kept identical in all
registries.
While the ASPA is able to detect both mistakes and malicious activity While the ASPA is able to detect both mistakes and malicious activity
for routes received from customers, RS-clients, or peers, it provides for routes received from customers, RS-clients, or peers, it provides
only detection of mistakes for routes that are received from upstream only detection of mistakes for routes that are received from upstream
providers and RS(s). providers and RS(s).
Since an upstream provider becomes a trusted point, it will be able Since an upstream provider becomes a trusted point, it will be able
to 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
 End of changes. 45 change blocks. 
158 lines changed or deleted 208 lines changed or added

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