Network Working Group G. Huston
Internet-Draft G. Michaelson
Intended status: Informational APNIC
Expires: September 22, 2016 C. Martinez
LACNIC
T. Bruijnzeels
RIPE NCC
A. Newton
ARIN
A. Aina
AFRINIC
March 21, 2016
RPKI Validation Reconsidered
draft-ietf-sidr-rpki-validation-reconsidered-03
Abstract
This document proposes and alternative to the certificate validation
procedure specified in RFC6487 that reduces aspects of operational
fragility in the management of certificates in the RPKI.
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 http://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 September 22, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Huston, et al. Expires September 22, 2016 [Page 1]
Internet-Draft RPKI Validation March 2016
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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Certificate Validation in the RPKI . . . . . . . . . . . . . 2
3. Operational Considerations . . . . . . . . . . . . . . . . . 3
4. An Amended RPKI Certification Validation Process . . . . . . 4
4.1. Changes to existing standards . . . . . . . . . . . . . . 4
4.2. An example . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
This document proposes and alternative to the certificate validation
procedure specified in RFC6487 that reduces aspects of operational
fragility in the management of certificates in the RPKI.
2. Certificate Validation in the RPKI
As currently defined in section 7.2 of [RFC6487], validation of PKIX
certificates that conform to the RPKI profile relies on the use of a
path validation process where each certificate in the validation path
is required to meet the certificate validation criteria.
These criteria require in particular that the resources on each
certificate in the validation path are "encompassed" by the resources
on the issuing certificate. The first certificate in the path is
required to be a trust anchor, and its resources are considered valid
by definition.
For example, in the following sequence:
Huston, et al. Expires September 22, 2016 [Page 2]
Internet-Draft RPKI Validation March 2016
Certificate 1 (trust anchor):
Issuer TA, Subject TA, Resources 192.0.2.0/24, AS64496-AS64500
Certificate 2:
Issuer TA, Subject CA1, Resources 192.0.2.0/24, AS64496-AS64500
Certificate 3:
Issuer CA1, Subject CA2, Resources 192.0.2.0/24, AS64496-AS64500
ROA 1:
Embedded Certificate 4 (EE certificate):
Issuer CA2, Subject R1, Resources 192.0.2.0/24
Prefix 192.0.2.0/24, Max Length 24, ASN 64496
All certificates in this scenario are considered valid in that the
resources on each certificate are encompassed by the issuing
certificate. The roa "ROA1" is also considered valid here in this
regard - the prefix is encompassed by the embedded EE certificate.
3. Operational Considerations
Resource allocations can change in the RPKI. And this can lead to
situations where an "over-claiming" certificate is introduced.
Consider the following sequence:
Certificate 1 (trust anchor):
Issuer TA, Subject TA, Resources 192.168.2.0/24, AS64496-AS64500
Certificate 2:
Issuer TA, Subject CA1, Resources 192.168.2.0/24
Certificate 3:
Issuer CA1, Subject CA2, Resources 192.168.2.0/24, AS64496-AS64500
ROA 1:
Embedded Certificate 4 (EE certificate):
Issuer CA2, Subject R1, Resources 192.168.2.0/24
Prefix 192.168.2.0/24, Max Length 24, ASN 64496
Here Certificate 2 from the previous example was re-issued by TA to
CA1 and certain AS resources were removed. However, CA1 failed to
re-issue a new Certificate 3 to CA2. As a result Certificate 3 is
now over-claiming and considered invalid, and by recursion ROA1
issued by CA2 is also invalid.
Huston, et al. Expires September 22, 2016 [Page 3]
Internet-Draft RPKI Validation March 2016
It should be noted that CA2 is not claiming any resources on ROA1
that it cannot receive on a new Certificate 3. If CA1 would only re-
issue a Certificate 3 without the AS resources to CA2, then ROA1
would be considered valid without the need for any further action by
CA2.
[RFC6492] describes the protocol for provisioning resource
certificates. In this protocol new resource certificates are always
issued by request of a child. If that protocol were strictly
followed then CA1 would have known that its resource set was about to
shrink, and it would have known that it issued some of those
resources to its child CA2.
The protocol currently lacks normative wording on how CAs should deal
with this situation, but one can imagine amending the protocol with
normative instructions that would require CA1 to refuse to request a
certificate with a shrunk resource set until all of its children
would have requested new shrunk certificates where applicable. And
that would forbid any parent CA to pro-actively re-issue a
certificate with shrunk resource set before receiving a certificate
re-issuance request from its child CA.
In practice such a model is unworkable for the CA higher in the path,
because it has no control over if and when it can shrink a
certificate for its children. Therefore higher level CAs will pro-
actively re-issue shrunk resource certificates when resources are no
longer validly held by a child.
The question here is whether the impact of such a re-issuance should
be limited to just the resources that seem to be under dispute
between TA and CA1, or all resources issued to CA2.
4. An Amended RPKI Certification Validation Process
4.1. Changes to existing standards
The following is a amended specification of certificate validation as
described in section 7.2 item number 6 of certificate validation in
[RFC6487] that describes the validation of resources in the RPKI
path:
The Relying Party MUST keep a set of verified resources for the
certificate independent of the RFC3779 extension itself, that is
built up using the following approach:
For any of the resource extensions that use the "inherit"
element as described in sections 2.2.3.5 and 3.2.3.3 of
[RFC3779], the corresponding resources of this type should be
Huston, et al. Expires September 22, 2016 [Page 4]
Internet-Draft RPKI Validation March 2016
taken from the parent certificate, where this issuer is the
subject.
For any other resources the intersection of the quoted
resources on this certificate and the parent certificate is
kept. If any resources were found on this certificate that
were not present on the parent certificate a warning SHOULD be
issued to help operators rectify this situation.
If the the set of verified resources obtained this way is empty,
then the certificate MUST be considered invalid.
Note that if this approach would be used in the example we cite in
section 3 of this document, Certificate 3 would have a verified
resource set that contains only "192.0.2.0/24", and a warning would
be issued with regards to resources "AS64496-AS64500". ROA1 would be
considered valid because the quoted prefix was also part of the
verified resource set of the embedded Certificate 4.
4.2. An example
Consider the following example under the amended approach:
Huston, et al. Expires September 22, 2016 [Page 5]
Internet-Draft RPKI Validation March 2016
Certificate 1 (trust anchor):
Issuer TA, Subject TA, Resources 192.168.2.0/24, AS64496-AS64500
Verified resources: 192.168.2.0/24, AS64496-AS64500
Warnings: none
Certificate 2:
Issuer TA, Subject CA1, Resources 192.168.2.0/24
Verified resources: 192.168.2.0/24
Warnings: none
Certificate 3:
Issuer CA1, Subject CA2, Resources 192.168.2.0/24, AS64496-AS64500
Verified resources: 192.168.2.0/24
Warnings: overclaim for AS64496-AS64500
ROA 1:
Embedded Certificate 4 (EE certificate):
Issuer CA2, Subject R1, Resources 192.168.2.0/24
Verified resources: 192.168.2.0/24
Warnings: none
Prefix 192.168.2.0/24, Max Length 24, ASN 64496
ROA1 is considered valid because the prefix matches the verified
resources on the embedded EE certificate.
ROA 2:
Embedded Certificate 5 (EE certificate):
Issuer CA2, Subject R2, Resources 192.168.3.0/24
Verified resources: none
Warnings: overclaim for 192.168.3.0/24
Prefix 192.168.3.0/24, Max Length 24, ASN 64496
ROA2 is considered invalid because the prefix does not
match the verified resources on the embedded EE certificate.
The amended approach cannot lead to ROAs showing up as valid
for resources that are not verified on the full path from the
Trust Anchor down to the ROA.
Huston, et al. Expires September 22, 2016 [Page 6]
Internet-Draft RPKI Validation March 2016
5. Security Considerations
The problem described in section 3 of this document has not occurred
to date. So one could consider this a low probability problem today.
However the potential impact on routing security would be high if the
inconsistency occurred near the apex of the RPKI hierarchy and would
invalidate the entirety of the sub-tree located below the point of
this inconsistency.
The proposed process does not change the probability of this problem,
but it limits the impact to just the resources that are under
dispute. As far as the authors can see there are no real new
problems introduced by this approach.
It should be noted that although this is a problem with a low
probability today this is largely due to the fact that most current
RPKI systems use their own Trust Anchor and do not support any large
number of delegated CAs. If this changes and the issuance and
publication of a certificate, by the parent, and its use, by a child,
are handled by different organisations more commonly, then the
probability of this problem will increase.
6. IANA Considerations
No updates to the registries are suggested by this document.
7. Acknowledgements
TBA.
8. Normative References
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004,
<http://www.rfc-editor.org/info/rfc3779>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<http://www.rfc-editor.org/info/rfc6487>.
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
Protocol for Provisioning Resource Certificates",
RFC 6492, DOI 10.17487/RFC6492, February 2012,
<http://www.rfc-editor.org/info/rfc6492>.
Huston, et al. Expires September 22, 2016 [Page 7]
Internet-Draft RPKI Validation March 2016
Authors' Addresses
Geoff Huston
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane, QLD 4101
Australia
Phone: +61 7 3858 3100
Email: gih@apnic.net
George Michaelson
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane, QLD 4101
Australia
Phone: +61 7 3858 3100
Email: ggm@apnic.net
Carlos M. Martinez
Latin American and Caribbean IP Address Regional Registry
Rambla Mexico 6125
Montevideo 11400
Uruguay
Phone: +598 2604 2222
Email: carlos@lacnic.net
Tim Bruijnzeels
RIPE Network Coordination Centre
Singel 258
Amsterdam 1016 AB
The Netherlands
Email: tim@ripe.net
Andrew Lee Newton
American Registry for Internet Numbers
3635 Concorde Parkway
Chantilly, VA 20151
USA
Email: andy@arin.net
Huston, et al. Expires September 22, 2016 [Page 8]
Internet-Draft RPKI Validation March 2016
Alain Aina
African Network Information Centre (AFRINIC)
11th Floor, Raffles Tower
Cybercity, Ebene
Mauritius
Phone: +230 403 51 00
Email: aalain@afrinic.net
Huston, et al. Expires September 22, 2016 [Page 9]