draft-ietf-sidrops-rpkimaxlen-01.txt   draft-ietf-sidrops-rpkimaxlen-02.txt 
Network Working Group Y. Gilad Network Working Group Y. Gilad
Internet-Draft S. Goldberg Internet-Draft S. Goldberg
Intended status: Best Current Practice Boston University Intended status: Best Current Practice Boston University
Expires: April 25, 2019 K. Sriram Expires: October 26, 2019 K. Sriram
USA NIST USA NIST
J. Snijders J. Snijders
NTT NTT
B. Maddison B. Maddison
Workonline Communications Workonline Communications
October 22, 2018 April 24, 2019
The Use of Maxlength in the RPKI The Use of Maxlength in the RPKI
draft-ietf-sidrops-rpkimaxlen-01 draft-ietf-sidrops-rpkimaxlen-02
Abstract Abstract
This document recommends that operators avoid using the maxLength This document recommends ways to reduce forged-origin attack surface
attribute when issuing Route Origin Authorizations (ROAs) in the by prudently limiting the address space that is included in Route
Resource Public Key Infrastructure (RPKI). These recommendations Origin Authorizations (ROAs). One recommendation is to avoid using
complement those in [RFC7115]. the maxLength attribute in ROAs except in some specific cases. The
recommendations complement and extend those in RFC 7115. The
document also discusses creation of ROAs for facilitating Distributed
Denial of Service (DDoS) mitigation services. Considerations related
to ROAs and origin validation for the case of destination-based
Remote Triggered Black Hole (RTBH) filtering are also highlighted.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 25, 2019. This Internet-Draft will expire on October 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 4
3. Forged Origin Subprefix Hijack . . . . . . . . . . . . . . . 3 3. Forged-Origin Subprefix Hijack . . . . . . . . . . . . . . . 4
4. Measurements of Today's RPKI . . . . . . . . . . . . . . . . 5 4. Measurements of Today's RPKI . . . . . . . . . . . . . . . . 6
5. Use Minimal ROAs without Maxlength . . . . . . . . . . . . . 6 5. Recommendations about Minimal ROAs and Maxlength . . . . . . 6
5.1. When a Minimal ROA Cannot Be Used? . . . . . . . . . . . 6 5.1. Creation of ROAs Facilitating DDoS Mitigation Service . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. ROAs and Origin Validation for RTBH Filtering Scenario . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The RPKI [RFC6480] uses Route Origin Authorizations (ROAs) to create The RPKI [RFC6480] uses Route Origin Authorizations (ROAs) to create
a cryptographically verifiable mapping from an IP prefix to a set of a cryptographically verifiable mapping from an IP prefix to a set of
autonomous systems (ASes) that are authorized to originate this autonomous systems (ASes) that are authorized to originate this
prefix. Each ROA contains a set of IP prefixes, and an AS number of prefix. Each ROA contains a set of IP prefixes, and an AS number of
an AS authorized originate all the IP prefixes in the set [RFC6482]. an AS authorized originate all the IP prefixes in the set [RFC6482].
The ROA is cryptographically signed by the party that holds a The ROA is cryptographically signed by the party that holds a
certificate for the set of IP prefixes. certificate for the set of IP prefixes.
skipping to change at page 2, line 46 skipping to change at page 3, line 9
[RFC6482], "When present, the maxLength specifies the maximum length [RFC6482], "When present, the maxLength specifies the maximum length
of the IP address prefix that the AS is authorized to advertise." of the IP address prefix that the AS is authorized to advertise."
Thus, rather than requiring the ROA to list each prefix the AS is Thus, rather than requiring the ROA to list each prefix the AS is
authorized to originate, the maxLength attribute provides a shorthand authorized to originate, the maxLength attribute provides a shorthand
that authorizes an AS to originate a set of IP prefixes. that authorizes an AS to originate a set of IP prefixes.
However, measurements of current RPKI deployments have found that use However, measurements of current RPKI deployments have found that use
of the maxLength in ROAs tends to lead to security problems. of the maxLength in ROAs tends to lead to security problems.
Specifically, as of June 2017, 84% of the prefixes specified in ROAs Specifically, as of June 2017, 84% of the prefixes specified in ROAs
that use the maxLength attribute, are vulnerable to a forged-origin that use the maxLength attribute, are vulnerable to a forged-origin
subprefix hijack [HARMFUL]. The forged-origin subprefix hijack, as subprefix hijack [HARMFUL]. The forged-origin prefix or subprefix
described below, can be launched against any IP prefix that is hijack involves inserting the legitimate AS (as specified in the ROA)
authorized in ROA but is not originated in BGP. The impact of such as the origin AS, and can be launched against any IP prefix/subprefix
an attack is the same as that of a subprefix hijack in the absence of that has a ROA. Consider a prefix/subprefix that has a ROA but is
ROA-based protection. unused, i.e., not announced in BGP by a legitimate AS. A forged-
origin hijack involving such a prefix/subprefix can propagate widely
throughout the Internet. On the other hand, if the prefix/subprefix
were announced by the legitimate AS, then the propagation of the
forged-origin hijack is somewhat limited because of its increased
path length relative to the legitimate announcement. Of course,
forged-origin hijacks are harmful in both cases but the extent of
harm is greater for unannounced prefixes.
For this reason, this document recommends that, whenever possible, For this reason, this document recommends that, whenever possible,
operators SHOULD use "minimal ROAs" that include only those IP operators SHOULD use "minimal ROAs" that include only those IP
prefixes that are actually originated in BGP, and no other prefixes. prefixes that are actually originated in BGP, and no other prefixes.
Operators SHOULD also avoid using the maxLength attribute in their Further, it recommends ways to reduce forged-origin attack surface by
ROAS whenever possible. One ideal place to implement these prudently limiting the address space that is included in Route Origin
recommendations is in the user interfaces for configuring ROAs: thus Authorizations (ROAs). One recommendation is to avoid using the
this document further recommends that designers and/or providers of maxLength attribute in ROAs except in some specific cases. The
such user interfaces SHOULD provide warnings to draw the user's recommendations complement and extend those in RFC 7115. The
attention to the risks of using the maxLength attribute. document also discusses creation of ROAs for facilitating Distributed
Denial of Service (DDoS) mitigation services. Considerations related
The recommendations in this document clarify and extend the following to ROAs and origin validation for the case of destination-based
recommendation from [RFC7115]: Remote Triggered Black Hole (RTBH) filtering are also highlighted.
One advantage of minimal ROA length is that the forged origin One ideal place to implement the ROA related recommendations is in
attack does not work for sub-prefixes that are not covered by the user interfaces for configuring ROAs. Thus, this document
overly long max length. For example, if, instead of further recommends that designers and/or providers of such user
10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged interfaces SHOULD provide warnings to draw the user's attention to
origin attack cannot succeed against 10.0.666.0/24. They must the risks of using the maxLength attribute.
attack the whole /16, which is more likely to be noticed because
of its size.
This best current practice requires no changes to the RPKI Best current practices described in this document require no changes
specification and will not increase the number of signed ROAs in the to the RPKI specification and will not increase the number of signed
RPKI, because ROAs already support lists of IP prefixes [RFC6482]. ROAs in the RPKI, because ROAs already support lists of IP prefixes
[RFC6482].
1.1. Requirements 1.1. Requirements
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. Suggested Reading 2. Suggested Reading
It is assumed that the reader understands BGP [RFC4271], the RPKI It is assumed that the reader understands BGP [RFC4271], RPKI
[RFC6480] Route Origin Authorizations (ROAs) [RFC6482], RPKI-based [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], RPKI-based
Prefix Validation [RFC6811], and BGPSEC [RFC8205]. Prefix Validation [RFC6811], and BGPsec [RFC8205].
3. Forged Origin Subprefix Hijack 3. Forged-Origin Subprefix Hijack
The forged-origin subprefix hijack is relevant to a scenario in which A detailed description and discussion of forged-origin subprefix
(1) the RPKI [RFC6480] is deployed, and (2) routers use RPKI origin hijack are presented here, especially considering the case when the
validation to drop invalid routes [RFC6811], but (3) BGPSEC [RFC8205] subprefix is not announced in BGP. The forged-origin subprefix
(or any similar method to validate the truthfulness of the BGP hijack is relevant to a scenario in which (1) the RPKI [RFC6480] is
AS_PATH attribute) is not deployed. deployed, and (2) routers use RPKI origin validation to drop invalid
routes [RFC6811], but (3) BGPsec [RFC8205] (or any similar method to
validate the truthfulness of the BGP AS_PATH attribute) is not
deployed.
We describe the forged-origin subprefix hijack [RFC7115] [GCHSS] We describe the forged-origin subprefix hijack [RFC7115] [GCHSS]
using a running example. using a running example.
Consider the IP prefix 168.122.0.0/16 which is allocated to an Consider the IP prefix 168.122.0.0/16 which is allocated to an
organization that also operates AS 64496. In BGP, AS 64496 organization that also operates AS 64496. In BGP, AS 64496
originates the IP prefix 168.122.0.0/16 as well as its subprefix originates the IP prefix 168.122.0.0/16 as well as its subprefix
168.122.225.0/24. Therefore, the RPKI should contain a ROA 168.122.225.0/24. Therefore, the RPKI should contain a ROA
authorizing AS 64496 to originate these two IP prefixes. That is, authorizing AS 64496 to originate these two IP prefixes. That is,
the ROA should be the ROA should be
skipping to change at page 4, line 48 skipping to change at page 5, line 19
ROA:(168.122.0.0/16-24, AS 64496) ROA:(168.122.0.0/16-24, AS 64496)
This "loose ROA" authorizes AS 64496 to originate any subprefix of This "loose ROA" authorizes AS 64496 to originate any subprefix of
168.122.0.0/16, up to length /24. That is, AS 64496 could originate 168.122.0.0/16, up to length /24. That is, AS 64496 could originate
168.122.225.0/24 as well as all of 168.122.0.0/17, 168.122.128.0/17, 168.122.225.0/24 as well as all of 168.122.0.0/17, 168.122.128.0/17,
..., 168.122.255.0/24 but not 168.122.0.0/25. ..., 168.122.255.0/24 but not 168.122.0.0/25.
However, AS 64496 only originates two prefixes in BGP: 168.122.0.0/16 However, AS 64496 only originates two prefixes in BGP: 168.122.0.0/16
and 168.122.255.0/24. This means that all other prefixes authorized and 168.122.255.0/24. This means that all other prefixes authorized
by the "loose ROA" (for instance, 168.122.0.0/24), are vulnerable to by the "loose ROA" (for instance, 168.122.0.0/24), are vulnerable to
the following forged-origin subprefix hijack [RFC7115], [GCHSS]: the following forged-origin subprefix hijack [RFC7115] [GCHSS]:
The hijacker AS 64511 sends a BGP announcement "168.122.0.0/24: AS The hijacker AS 64511 sends a BGP announcement "168.122.0.0/24: AS
64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of
AS 64496 and falsely claiming that AS 64496 originates the IP AS 64496 and falsely claiming that AS 64496 originates the IP
prefix 168.122.0.0/24. In fact, the IP prefix 168.122.0.0/24 is prefix 168.122.0.0/24. In fact, the IP prefix 168.122.0.0/24 is
not originated by AS 64496. not originated by AS 64496.
The hijacker's BGP announcement is valid according to the RPKI, since The hijacker's BGP announcement is valid according to the RPKI, since
the ROA (168.122.0.0/16-24, AS 64496) authorizes AS 64496 to the ROA (168.122.0.0/16-24, AS 64496) authorizes AS 64496 to
originate BGP routes for 168.122.0.0/24. Because AS 64496 does not originate BGP routes for 168.122.0.0/24. Because AS 64496 does not
actually originate a route for 168.122.0.0/24, the hijacker's route actually originate a route for 168.122.0.0/24, the hijacker's route
is the *only* route to the 168.122.0.0/24. Longest-prefix-match is the *only* route to the 168.122.0.0/24. Longest-prefix-match
routing ensures that the hijacker's route to the subprefix routing ensures that the hijacker's route to the subprefix
168.122.0.0/24 is always preferred over the legitimate route to 168.122.0.0/24 is always preferred over the legitimate route to
168.122.0.0/16 originated by AS 64496. Thus, the hijacker's route 168.122.0.0/16 originated by AS 64496. Thus, the hijacker's route
propagates through the Internet, the traffic destined for IP propagates through the Internet, the traffic destined for IP
addresses in 168.122.0.0/24 will be delivered to the hijacker. addresses in 168.122.0.0/24 will be delivered to the hijacker.
The forged origin *subprefix* hijack would have failed if the The forged-origin *subprefix* hijack would have failed if the
"minimal ROA" described above was used instead of the "loose ROA". "minimal ROA" described above was used instead of the "loose ROA".
If the "minimal ROA" had been used instead, the attacker would be If the "minimal ROA" had been used instead, the attacker would be
forced to launch a forged origin *prefix* hijack in order to attract forced to launch a forged-origin *prefix* hijack in order to attract
traffic, as follows: traffic, as follows:
The hijacker AS 64511 sends a BGP announcement "168.122.0.0/16: AS The hijacker AS 64511 sends a BGP announcement "168.122.0.0/16: AS
64511, AS 64496", falsely claiming that AS 64511 is a neighbor of 64511, AS 64496", falsely claiming that AS 64511 is a neighbor of
AS 64496. AS 64496.
This forged-origin *prefix* hijack is significantly less damaging This forged-origin *prefix* hijack is significantly less damaging
than the forged-origin *subprefix* hijack. With a forged-origin than the forged-origin *subprefix* hijack. AS 64496 legitimately
*prefix* hijack, AS 64496 legitimately originates 168.122.0.0/16 in originates 168.122.0.0/16 in BGP, so the hijacker AS 64511 is not
BGP, so the hijacker AS 64511 is not presenting the *only* route to presenting the *only* route to 168.122.0.0/16. Moreover, the path
168.122.0.0/16. Moreover, the path originated by AS 64511 is one hop originated by AS 64511 is one hop longer than the path originated by
longer than the path originated by the legitimate origin AS 64496. the legitimate origin AS 64496. As discussed in [LSG16], this means
As discussed in [LSG16], this means that the hijacker will attract that the hijacker will attract less traffic than he would have in the
less traffic than he would have in the forged origin *subprefix* forged-origin *subprefix* hijack, where the hijacker presents the
hijack, where the hijacker presents the *only* route to the hijacked *only* route to the hijacked subprefix.
subprefix.
In sum, a forged-origin subprefix hijack has the same impact as a In summary, a forged-origin subprefix hijack has the same impact as a
regular subprefix hijack. A forged-origin *subprefix* hijack is also regular subprefix hijack. A forged-origin *subprefix* hijack is also
more damaging than forged-origin *prefix* hijack. more damaging than forged-origin *prefix* hijack.
4. Measurements of Today's RPKI 4. Measurements of Today's RPKI
Network measurements from June 1, 2017 show that 12% of the IP Network measurements from June 1, 2017 show that 12% of the IP
prefixes authorized in ROAs have a maxLength longer than their prefix prefixes authorized in ROAs have a maxLength longer than their prefix
length. The vast majority of these (84%) of these are vulnerable to length. The vast majority of these (84%) are vulnerable to forged-
forged-origin subprefix hijacks. Even large providers are vulnerable origin subprefix hijacks. These subprefixes are not announced in BGP
to these attacks. See [GSG17] for details. by the legitimate AS. Even large providers are vulnerable to these
attacks. See [GSG17] for details.
These measurements suggest that operators commonly misconfigure the These measurements suggest that operators commonly misconfigure the
maxLength attribute, and unwittingly open themselves up to forged- maxLength attribute, and unwittingly open themselves up to forged-
origin subprefix hijacks. origin subprefix hijacks. That is, they are exposing a much larger
attack surface for forged-origin hijacks than necessary.
5. Use Minimal ROAs without Maxlength 5. Recommendations about Minimal ROAs and Maxlength
Operators SHOULD avoid using the maxLength attribute in their ROAs. Operators SHOULD avoid using the maxLength attribute in their ROAs
except in some special cases. One such exception may be when all
more specific prefixes permitted by the maxLength are actually
announced by the AS in the ROA. Another exception for use of
maxLength is when (a) the maxLength is substantially larger compared
to the specified prefix length in the ROA, and (b) a large number of
more specific prefixes in that range is announced by the AS in the
ROA. This case should occur rarely in practice (if at all).
Operator discretion is necessary in this case.
Operators SHOULD use "minimal ROAs" whenever possible. A minimal ROA Operators SHOULD use "minimal ROAs" whenever possible. A minimal ROA
contains only those IP prefixes that are actually originated by an AS contains only those IP prefixes that are actually originated by an AS
in BGP, and no other IP prefixes. (See Section 3 for an example.) in BGP, and no other IP prefixes. (See Section 3 for an example.)
This practice requires no changes to the RPKI specification and will This practice requires no changes to the RPKI specification and will
not increase the number of signed ROAs in the RPKI, because ROAs not increase the number of signed ROAs in the RPKI, because ROAs
already support lists of IP prefixes [RFC6482]. See also [GSG17] for already support lists of IP prefixes [RFC6482]. See also [GSG17] for
further discussion of why this practice will have minimal impact on further discussion of why this practice will have minimal impact on
the performance of the RPKI ecosystem. the performance of the RPKI ecosystem.
5.1. When a Minimal ROA Cannot Be Used? 5.1. Creation of ROAs Facilitating DDoS Mitigation Service
Sometimes, it is not possible to use a "minimal ROA", because an Sometimes, it is not possible to use a "minimal ROA", because an
operator wants to issue a ROA that includes an IP prefix that is operator wants to issue a ROA that includes an IP prefix that is
sometimes (but not always) originated in BGP. sometimes (but not always) originated in BGP.
In this case, the ROA SHOULD include (1) the set of IP prefixes that In this case, the ROA SHOULD include (1) the set of IP prefixes that
are always originated in BGP, and (2) the set IP prefixes that are are always originated in BGP, and (2) the set IP prefixes that are
sometimes, but not always, originated in BGP. The ROA SHOULD NOT sometimes, but not always, originated in BGP. The ROA SHOULD NOT
include any IP prefixes that the operator knows will not be include any IP prefixes that the operator knows will not be
originated in BGP. Whenever possible, the ROA SHOULD also avoid the originated in BGP. Whenever possible, the ROA SHOULD also avoid the
use of the maxlength attribute. use of the maxLength attribute.
We now extend our running example to illustrate one situation where We now extend our running example to illustrate one situation where
where it is not possible to issue a minimal ROA. where it is not possible to issue a minimal ROA.
Consider the following scenario prior to deployment of RPKI. Suppose Consider the following scenario prior to deployment of RPKI. Suppose
AS 64496 announced 168.122.0.0/16 and has a contract with a DDoS AS 64496 announced 168.122.0.0/16 and has a contract with a
mitigation service provider that holds AS 64500. Further, assume Distributed Denial of Service (DDoS) mitigation service provider that
that the DDoS mitigation service contract applies to all IP addresses holds AS 64500. Further, assume that the DDoS mitigation service
covered by 168.122.0.0/22. When a DDoS attack is detected and contract applies to all IP addresses covered by 168.122.0.0/22. When
reported by AS 64496, AS 64500 immediately originates 168.122.0.0/22, a DDoS attack is detected and reported by AS 64496, AS 64500
thus attracting all the DDoS traffic to itself. The traffic is immediately originates 168.122.0.0/22, thus attracting all the DDoS
scrubbed at AS 64500 and then sent back to AS 64496 over a backhaul traffic to itself. The traffic is scrubbed at AS 64500 and then sent
data link. Notice that, during a DDoS attack, the DDoS mitigation back to AS 64496 over a backhaul data link. Notice that, during a
service provider AS 64500 originates a /22 prefix that is longer than DDoS attack, the DDoS mitigation service provider AS 64500 originates
than AS 64496's /16 prefix, and so all the traffic (destined to a /22 prefix that is longer than AS 64496's /16 prefix, and so all
addresses in 168.122.0.0/22) that normally goes to AS 64496 goes to the traffic (destined to addresses in 168.122.0.0/22) that normally
AS 64500 instead. goes to AS 64496 goes to AS 64500 instead.
First, suppose the RPKI only had the minimal ROA for AS 64496, as First, suppose the RPKI only had the minimal ROA for AS 64496, as
described in Section 3. But, if there is no ROA authorizing AS 64500 described in Section 3. But, if there is no ROA authorizing AS 64500
to announce the /22 prefix, then the traffic-scrubbing scheme would to announce the /22 prefix, then the DDoS mitigation (and traffic
not work. That is, if AS 64500 originates the /22 prefix in BGP scrubbing) scheme would not work. That is, if AS 64500 originates
during a DDoS attack, the announcement would be invalid [RFC6811]. the /22 prefix in BGP during DDoS attacks, the announcement would be
invalid [RFC6811].
Therefore, the RPKI should have two ROAs: one for AS 64496 and one Therefore, the RPKI should have two ROAs: one for AS 64496 and one
for AS 64500. for AS 64500.
ROA:(168.122.0.0/16,168.122.225.0/24, AS 64496) ROA:(168.122.0.0/16,168.122.225.0/24, AS 64496)
ROA:(168.122.0.0/22, AS 64500) ROA:(168.122.0.0/22, AS 64500)
Neither ROA uses the maxLength attribute. But, the second ROA is not Neither ROA uses the maxLength attribute. But, the second ROA is not
"minimal" because it contains a /22 prefix that is not originated by "minimal" because it contains a /22 prefix that is not originated by
skipping to change at page 7, line 48 skipping to change at page 8, line 31
RPKI should have two ROAs: one for AS 64496 and one for AS 64500. RPKI should have two ROAs: one for AS 64496 and one for AS 64500.
ROA:(168.122.0.0/16,168.122.225.0/24, AS 64496) ROA:(168.122.0.0/16,168.122.225.0/24, AS 64496)
ROA:(168.122.0.0/22-24, AS 64500) ROA:(168.122.0.0/22-24, AS 64500)
The second ROA uses the maxLength attribute because it is designed to The second ROA uses the maxLength attribute because it is designed to
explicitly enable AS 64500 to originate *any* /24 subprefix of explicitly enable AS 64500 to originate *any* /24 subprefix of
168.122.0.0/22. 168.122.0.0/22.
As before, the second ROA is also not "minimal" because it contains As before, the second ROA is not "minimal" because it contains
prefixes that are not originated by anyone in BGP during normal prefixes that are not originated by anyone in BGP during normal
operations. As before, all IP addresses in 168.122.0.0/22 are operations. As before, all IP addresses in 168.122.0.0/22 are
vulnerable to a forged-origin subprefix hijack during normal vulnerable to a forged-origin subprefix hijack during normal
operations, when the /22 prefix is not originated. operations, when the /22 prefix is not originated.
The use of maxLength in this second ROA also comes with an additional The use of maxLength in this second ROA also comes with an additional
risk. While it permits the DDoS mitigation service at AS 64500 to risk. While it permits the DDoS mitigation service at AS 64500 to
originate prefix 168.122.0.0/24 during a DDoS attack in that space, originate prefix 168.122.0.0/24 during a DDoS attack in that space,
it also makes the *other* /24 prefixes covered by the /22 prefix it also makes the *other* /24 prefixes covered by the /22 prefix
(i.e., 168.122.1.0/24, 168.122.2.0/24, 168.122.3.0/24) vulnerable to (i.e., 168.122.1.0/24, 168.122.2.0/24, 168.122.3.0/24) vulnerable to
a forged-origin subprefix attacks. a forged-origin subprefix attacks.
6. Acknowledgments There is another entirely different way of managing ROAs for DDoS
mitigation service. In this scheme, ROAs are not pre-created for the
DDoS mitigation service but are created on the fly when the DDoS
mitigation service request is made. Further, the BGP announcements
for actuating the DDoS mitigation service will not be made until the
ROAs propagate fully through the RPKI system. Hence, there would be
a latency involved in DDoS mitigation service going into effect.
This method would be effective only if the latency is guaranteed to
be within some acceptable limit. This calls for mechanisms to be in
place for RPKI data propagation to occur very fast. Thus, this
scheme of managing ROAs for DDoS mitigation service helps with
eliminating the attack surface for prefixes requiring this service.
However, the viability of this scheme depends on future work related
to achieving fast ROA propagation in the global RPKI system.
6. ROAs and Origin Validation for RTBH Filtering Scenario
Considerations related to ROAs and origin validation [RFC6811] for
the case of destination-based Remote Triggered Black Hole (RTBH)
filtering are addressed here. In RTBH, highly specific prefixes
(greater than /24 in IPv4 and greater than /48 in IPv6; possibly even
/32 (IPv4) and /128 (IPv6)) are announced in BGP. These
announcements are tagged with a BLACKHOLE Community [RFC7999]. It is
obviously not desirable to use large maxlength or include any such
highly specific prefixes in the ROAs to accommodate destination-based
RTBH filtering. Therefore, operators SHOULD accommodate this
scenario by accepting BGP announcements tagged with BLACKHOLE
Community only if the following conditions are met: (1) the
announcement is received on a BGP session on which there is agreement
to honor BLACKHOLE Community, and (2) the prefix in the announcement
is covered by a ROA that has an AS number matching with the AS number
of the peer on that BGP session.
7. Acknowledgments
The authors would like to thank the following people for their review The authors would like to thank the following people for their review
and contributions to this document: Omar Sagga (Boston University) and contributions to this document: Omar Sagga (Boston University)
and Aris Lambrianidis (AMS-IX). and Aris Lambrianidis (AMS-IX).
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 8, line 46 skipping to change at page 10, line 15
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012, DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>. <https://www.rfc-editor.org/info/rfc6482>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013, DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>. <https://www.rfc-editor.org/info/rfc6811>.
7.2. Informative References 8.2. Informative References
[GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H. [GCHSS] Gilad, Y., Cohen, A., Herzberg, A., Schapira, M., and H.
Shulman, "Are We There Yet? On RPKI's Deployment and Shulman, "Are We There Yet? On RPKI's Deployment and
Security", in NDSS 2017, February 2017, Security", in NDSS 2017, February 2017,
<https://eprint.iacr.org/2016/1010.pdf>. <https://eprint.iacr.org/2016/1010.pdf>.
[GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "Maxlength [GSG17] Gilad, Y., Sagga, O., and S. Goldberg, "Maxlength
Considered Harmful to the RPKI", in ACM CoNEXT 2017, Considered Harmful to the RPKI", in ACM CoNEXT 2017,
December 2017, <https://eprint.iacr.org/2016/1015.pdf>. December 2017, <https://eprint.iacr.org/2016/1015.pdf>.
skipping to change at page 9, line 30 skipping to change at page 10, line 47
Interpretations of Resource Public Key Infrastructure Interpretations of Resource Public Key Infrastructure
(RPKI) Objects for Issuers and Relying Parties", RFC 6907, (RPKI) Objects for Issuers and Relying Parties", RFC 6907,
DOI 10.17487/RFC6907, March 2013, DOI 10.17487/RFC6907, March 2013,
<https://www.rfc-editor.org/info/rfc6907>. <https://www.rfc-editor.org/info/rfc6907>.
[RFC7115] Bush, R., "Origin Validation Operation Based on the [RFC7115] Bush, R., "Origin Validation Operation Based on the
Resource Public Key Infrastructure (RPKI)", BCP 185, Resource Public Key Infrastructure (RPKI)", BCP 185,
RFC 7115, DOI 10.17487/RFC7115, January 2014, RFC 7115, DOI 10.17487/RFC7115, January 2014,
<https://www.rfc-editor.org/info/rfc7115>. <https://www.rfc-editor.org/info/rfc7115>.
[RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G.
Hankins, "BLACKHOLE Community", RFC 7999,
DOI 10.17487/RFC7999, October 2016,
<https://www.rfc-editor.org/info/rfc7999>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
Authors' Addresses Authors' Addresses
Yossi Gilad Yossi Gilad
Boston University Boston University
111 Cummington St, MCS135 111 Cummington St, MCS135
Boston, MA 02215 Boston, MA 02215
 End of changes. 33 change blocks. 
93 lines changed or deleted 156 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/