draft-ietf-sidr-adverse-actions-01.txt   draft-ietf-sidr-adverse-actions-02.txt 
SIDR S. Kent SIDR S. Kent
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational D. Ma Intended status: Informational D. Ma
Expires: January 26, 2017 ZDNS Expires: February 5, 2017 ZDNS
July 25, 2016 August 4, 2016
Adverse Actions by a Certification Authority (CA) or Repository Manager Adverse Actions by a Certification Authority (CA) or Repository Manager
in the Resource Public Key Infrastructure (RPKI) in the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-adverse-actions-01 draft-ietf-sidr-adverse-actions-02
Abstract Abstract
This document analyzes actions by or against a CA or independent This document analyzes actions by or against a CA or independent
repository manager in the RPKI that can adversely affect the Internet repository manager in the RPKI that can adversely affect the Internet
Number Resources (INRs) associated with that CA or its subordinate Number Resources (INRs) associated with that CA or its subordinate
CAs. The analysis is based on examination of the data items in the CAs. The analysis is based on examination of the data items in the
RPKI repository, as controlled by a CA (or independent repository RPKI repository, as controlled by a CA (or independent repository
manager) and fetched by Relying Parties (RPs). The analysis is manager) and fetched by Relying Parties (RPs). The analysis is
performed from the perspective of an affected INR holder. The performed from the perspective of an affected INR holder. The
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 26, 2017. This Internet-Draft will expire on February 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 31 skipping to change at page 2, line 31
2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Certificate Revocation List . . . . . . . . . . . . . . . 11 2.3. Certificate Revocation List . . . . . . . . . . . . . . . 11
2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 16 2.5. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 16
2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 17 2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 17
3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 18 3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 18
3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . 20
3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 20 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 21 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . 21
4. Security considerations . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22 7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 24 7.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
In the context of this document, any change to the Resource Public In the context of this document, any change to the Resource Public
Key Infrastructure (RPKI) [RFC6480] that results in a diminution of Key Infrastructure (RPKI) [RFC6480] that diminishes the set of
the set of Internet Numeric Resources (INRs) associated with an INR Internet Numeric Resources (INRs) associated with an INR holder, and
holder contrary to the holder's wishes is termed "adverse". that is contrary to the holder's wishes, is termed "adverse". An
action that results in an adverse charge (as defined above), may be
the result of an attack on a CA [RFC7132], an error by a CA, or an
error by or an attack on a repository operator. Note that the CA
that allocated the affected INRs may be acting in accordance with
established policy, and thus the change may be contractually
justified, even though viewed as adverse by the INR holder. This
document examines the implications of adverse actions with respect to
INRs irrespective of the cause of the actions.
Additionally, when a ROA or router certificate is created that Additionally, when a ROA or router certificate is created that
"competes" with an existing ROA or router certificate (respectively), "competes" with an existing ROA or router certificate (respectively),
the creation of the new ROA or router certificate may be adverse. (A the creation of the new ROA or router certificate may be adverse. (A
newer ROA competes with an older ROA if the newer ROA points to a newer ROA competes with an older ROA if the newer ROA points to a
different ASN, contains the same or a more specific prefix, and is different ASN, contains the same or a more specific prefix, and is
issued by a different CA. A newer router certificate competes with issued by a different CA. A newer router certificate competes with
an older router certificate if the newer one contains the same ASN a an older router certificate if the newer one contains the same ASN a
different public key, and is issued by a different CA.) Note that different public key, and is issued by a different CA.) Note that
transferring resources, or changing of upstream providers may yield transferring resources, or changing of upstream providers may yield
competing ROAs and/or router certificates, under some circumstances. competing ROAs and/or router certificates, under some circumstances.
Thus not all instances of competition are adverse actions. Thus not all instances of competition are adverse actions.
The SIDR WG is exploring proposals to address mistakes by RPKI As noted above, adverse changes to RPKI data may arise due to several
Certification Authorities (CAs) and to accommodate INR transfers. types of causes. A CA may make a mistake in managing the RPKI
Mistakes are not the only way that adverse changes to RPKI data can objects it signs, or it may be subject to an attack. If an attack
arise. A CA or repository operator might be subject to an attack allows an adversary to use the private key of that CA to sign RPKI
[RFC7132]. For a CA, if an attack allows an adversary to use the objects, then the effect is analogous to the CA making mistakes.
private keys of that CA to sign RPKI objects, then the effect is There is also the possibility that a CA or repository operator may be
analogous to the CA making mistakes. There is also the possibility subject to legal measures that compel them to make adverse changes to
that a CA or repository operator may be subject to legal measures RPKI data. In many cases, such actions may be hard to distinguish
that compel them to generate "bogus" signed objects or remove from mistakes or attacks, other than with respect to the time
legitimate repository data. In many cases, such actions may be hard required to remedy the adverse action. (Presumably the CA will take
to distinguish from non-malicious mistakes, other than with respect remedial action when a mistake or an attack is detected, so the
to the time required to remedy the adverse action. Thus this effects are similar in these cases. If a CA has been legally
document examines the implications of adverse actions with respect to compelled to effect an adverse change, remediation will likely not be
INRs irrespective of the cause of the actions. Standards for swift.)
transfer of INRs are being explored in [I-D.ymbk-sidr-transfer].
That work also motivates exploration of the impact of both legitimate
transfers and botched transfer attempts on the RPKI.
This document analyzes the various types of actions by a CA (or This document analyzes the various types of actions by a CA (or
independent repository manager) that can adversely affect the INRs independent repository operator) that can adversely affect the INRs
associated with that CA, as well as the INRs of subordinate CAs. The associated with that CA, as well as the INRs of subordinate CAs. The
analysis is based on examination of the data items in the RPKI analysis is based on examination of the data items in the RPKI
repository, as controlled by a CA (or independent repository manager) repository, as controlled by a CA (or independent repository
and fetched by Relying Parties (RPs). The analysis is done from the operator) and fetched by Relying Parties (RPs). The analysis is done
perspective of an affected INR holder. from the perspective of an affected INR holder.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Analysis of RPKI Repository Objects 2. Analysis of RPKI Repository Objects
This section enumerates the RPKI repository system objects and This section enumerates the RPKI repository system objects and
skipping to change at page 21, line 44 skipping to change at page 21, line 44
here includes those in Scenarios A, B, and C. Mistakes by the INR here includes those in Scenarios A, B, and C. Mistakes by the INR
holder, acted upon by the parent CA, can cause any of the actions holder, acted upon by the parent CA, can cause any of the actions
noted in Section 2. Actions unilaterally undertaken by the parent CA noted in Section 2. Actions unilaterally undertaken by the parent CA
also can have the same effect. A successful attack against the also can have the same effect. A successful attack against the
parent CA can effect all of the modification, revocation, or parent CA can effect all of the modification, revocation, or
injection actions noted in Section 2. An attack against the parent injection actions noted in Section 2. An attack against the parent
CA can also effect all of the deletion, suppression, or corruption CA can also effect all of the deletion, suppression, or corruption
actions noted in Section 2 (because the parent CA is managing the INR actions noted in Section 2 (because the parent CA is managing the INR
holder's publication point). holder's publication point).
4. Security considerations 4. Security Considerations
This informational document describes a threat model for the RPKI, This informational document describes a threat model for the RPKI,
focusing on mistakes by or attacks against CAs and independent focusing on mistakes by or attacks against CAs and independent
repository managers. It is intended to provide a basis for the repository managers. It is intended to provide a basis for the
design of future RPKI security mechanisms that seek to address the design of future RPKI security mechanisms that seek to address the
concerns associated with such actions. concerns associated with such actions.
The analysis in this document identifies a number of circumstances in The analysis in this document identifies a number of circumstances in
which attacks or errors can have significant impacts on routing. One which attacks or errors can have significant impacts on routing. One
ought not interpret this as a condemnation of the RPKI. It is only ought not interpret this as a condemnation of the RPKI. It is only
skipping to change at page 22, line 23 skipping to change at page 22, line 23
technology exhibits its own set of security problems, which are technology exhibits its own set of security problems, which are
discussed in [RFC7682]. discussed in [RFC7682].
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Acknowledgements 6. Acknowledgements
The authors thank Richard Hansen and David Mandelberg for their The authors thank Richard Hansen and David Mandelberg for their
extensive review, feedback and editorial assistance. extensive review, feedback and editorial assistance. Thanks also go
to Daiming Li for her editorial assistance.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-sidr-bgpsec-overview] [I-D.ietf-sidr-bgpsec-overview]
Lepinski, M. and S. Turner, "An Overview of BGPsec", Lepinski, M. and S. Turner, "An Overview of BGPsec",
draft-ietf-sidr-bgpsec-overview-08 (work in progress), draft-ietf-sidr-bgpsec-overview-08 (work in progress),
June 2016. June 2016.
skipping to change at page 24, line 26 skipping to change at page 24, line 26
Procedure for the Resource Public Key Infrastructure Procedure for the Resource Public Key Infrastructure
(RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
2013, <http://www.rfc-editor.org/info/rfc6916>. 2013, <http://www.rfc-editor.org/info/rfc6916>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security",
RFC 7132, DOI 10.17487/RFC7132, February 2014, RFC 7132, DOI 10.17487/RFC7132, February 2014,
<http://www.rfc-editor.org/info/rfc7132>. <http://www.rfc-editor.org/info/rfc7132>.
7.2. Informative References 7.2. Informative References
[I-D.ymbk-sidr-transfer]
Austein, R., Bush, R., Huston, G., and G. Michaelson,
"Resource Transfer in the Resource Public Key
Infrastructure", draft-ymbk-sidr-transfer-01 (work in
progress), July 2015.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622, "Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999, DOI 10.17487/RFC2622, June 1999,
<http://www.rfc-editor.org/info/rfc2622>. <http://www.rfc-editor.org/info/rfc2622>.
[RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. [RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C.
Alaettinoglu, "Using RPSL in Practice", RFC 2650, Alaettinoglu, "Using RPSL in Practice", RFC 2650,
DOI 10.17487/RFC2650, August 1999, DOI 10.17487/RFC2650, August 1999,
<http://www.rfc-editor.org/info/rfc2650>. <http://www.rfc-editor.org/info/rfc2650>.
 End of changes. 12 change blocks. 
38 lines changed or deleted 39 lines changed or added

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