draft-ietf-sidrops-aspa-verification-03.txt   draft-ietf-sidrops-aspa-verification-04.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: September 10, 2020 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
November 4, 2019 March 9, 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-03 draft-ietf-sidrops-aspa-verification-04
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 May 7, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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, for a selected AFI, a ASPA is digitally signed object that bind, for a selected AFI, a Set
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]. [I-D.ietf-sidrops-aspa-profile]. For a selected Customer AS MAY
exist only single ASPA object.
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, ROUTE_AFI) as input parameters and returns one of three
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 cryptographically valid ASPA in a selected AFI with a
a customer value of AS1. The union of SPAS forms the set of customer value of AS1. If there is no valid ASPA record for AS1
"Candidate Providers." the procedure exits with an outcome of "unknown."
2. If the set of Candidate Providers is empty, then the procedure 2. If AS2 is included in the SPAS, then the procedure exits with an
exits with an outcome of "unknown." outcome of "valid."
3. If AS2 is included in the set of Candidate Providers, then the 3. Otherwise, the procedure exits with an outcome of "invalid."
procedure exits with an outcome of "valid."
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 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, ROUTE_AFI)
may 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
skipping to change at page 9, line 31 skipping to change at page 9, line 31
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 support integration with the 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 ASPA
collection of ASPAs. It is the Customer AS's duty to maintain a record. It is the Customer AS's duty to maintain a correct set of
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.
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).
 End of changes. 12 change blocks. 
19 lines changed or deleted 18 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/