draft-ietf-sidrops-rpkimaxlen-02.txt   draft-ietf-sidrops-rpkimaxlen-03.txt 
Network Working Group Y. Gilad Network Working Group Y. Gilad
Internet-Draft S. Goldberg Internet-Draft Hebrew University of Jerusalem
Intended status: Best Current Practice Boston University Intended status: Best Current Practice S. Goldberg
Expires: October 26, 2019 K. Sriram Expires: April 25, 2020 Boston University
K. Sriram
USA NIST USA NIST
J. Snijders J. Snijders
NTT NTT
B. Maddison B. Maddison
Workonline Communications Workonline Communications
April 24, 2019 October 23, 2019
The Use of Maxlength in the RPKI The Use of Maxlength in the RPKI
draft-ietf-sidrops-rpkimaxlen-02 draft-ietf-sidrops-rpkimaxlen-03
Abstract Abstract
This document recommends ways to reduce forged-origin attack surface This document recommends ways to reduce forged-origin attack surface
by prudently limiting the address space that is included in Route by prudently limiting the address space that is included in Route
Origin Authorizations (ROAs). One recommendation is to avoid using Origin Authorizations (ROAs). One recommendation is to avoid using
the maxLength attribute in ROAs except in some specific cases. The the maxLength attribute in ROAs except in some specific cases. The
recommendations complement and extend those in RFC 7115. The recommendations complement and extend those in RFC 7115. The
document also discusses creation of ROAs for facilitating Distributed document also discusses creation of ROAs for facilitating Distributed
Denial of Service (DDoS) mitigation services. Considerations related Denial of Service (DDoS) mitigation services. Considerations related
skipping to change at page 1, line 44 skipping to change at page 1, line 45
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 October 26, 2019. This Internet-Draft will expire on April 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 3, line 29 skipping to change at page 3, line 29
forged-origin hijacks are harmful in both cases but the extent of forged-origin hijacks are harmful in both cases but the extent of
harm is greater for unannounced prefixes. 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.
Further, it recommends ways to reduce forged-origin attack surface by Further, it recommends ways to reduce forged-origin attack surface by
prudently limiting the address space that is included in Route Origin prudently limiting the address space that is included in Route Origin
Authorizations (ROAs). One recommendation is to avoid using the Authorizations (ROAs). One recommendation is to avoid using the
maxLength attribute in ROAs except in some specific cases. The maxLength attribute in ROAs except in some specific cases. The
recommendations complement and extend those in RFC 7115. The recommendations complement and extend those in [RFC7115]. The
document also discusses creation of ROAs for facilitating Distributed document also discusses creation of ROAs for facilitating Distributed
Denial of Service (DDoS) mitigation services. Considerations related Denial of Service (DDoS) mitigation services. Considerations related
to ROAs and origin validation for the case of destination-based to ROAs and origin validation for the case of destination-based
Remote Triggered Black Hole (RTBH) filtering are also highlighted. Remote Triggered Black Hole (RTBH) filtering are also highlighted.
One ideal place to implement the ROA related recommendations is in One ideal place to implement the ROA related recommendations is in
the user interfaces for configuring ROAs. Thus, this document the user interfaces for configuring ROAs. Thus, this document
further recommends that designers and/or providers of such user further recommends that designers and/or providers of such user
interfaces SHOULD provide warnings to draw the user's attention to interfaces SHOULD provide warnings to draw the user's attention to
the risks of using the maxLength attribute. the risks of using the maxLength attribute.
skipping to change at page 4, line 22 skipping to change at page 4, line 22
A detailed description and discussion of forged-origin subprefix A detailed description and discussion of forged-origin subprefix
hijack are presented here, especially considering the case when the hijack are presented here, especially considering the case when the
subprefix is not announced in BGP. The forged-origin subprefix subprefix is not announced in BGP. The forged-origin subprefix
hijack is relevant to a scenario in which (1) the RPKI [RFC6480] is hijack is relevant to a scenario in which (1) the RPKI [RFC6480] is
deployed, and (2) routers use RPKI origin validation to drop invalid deployed, and (2) routers use RPKI origin validation to drop invalid
routes [RFC6811], but (3) BGPsec [RFC8205] (or any similar method to routes [RFC6811], but (3) BGPsec [RFC8205] (or any similar method to
validate the truthfulness of the BGP AS_PATH attribute) is not validate the truthfulness of the BGP AS_PATH attribute) is not
deployed. deployed.
We describe the forged-origin subprefix hijack [RFC7115] [GCHSS] The forged-origin subprefix hijack [RFC7115] [GCHSS] is described
using a running example. here 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
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)
skipping to change at page 7, line 18 skipping to change at page 7, line 18
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 The running example is now extended to illustrate one situation where
where it is not possible to issue a minimal ROA. 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 AS 64496 announced 168.122.0.0/16 and has a contract with a
Distributed Denial of Service (DDoS) mitigation service provider that Distributed Denial of Service (DDoS) mitigation service provider that
holds AS 64500. Further, assume that the DDoS mitigation service holds AS 64500. Further, assume that the DDoS mitigation service
contract applies to all IP addresses covered by 168.122.0.0/22. When contract applies to all IP addresses covered by 168.122.0.0/22. When
a DDoS attack is detected and reported by AS 64496, AS 64500 a DDoS attack is detected and reported by AS 64496, AS 64500
immediately originates 168.122.0.0/22, thus attracting all the DDoS immediately originates 168.122.0.0/22, thus attracting all the DDoS
traffic to itself. The traffic is scrubbed at AS 64500 and then sent traffic to itself. The traffic is scrubbed at AS 64500 and then sent
back to AS 64496 over a backhaul data link. Notice that, during a back to AS 64496 over a backhaul data link. Notice that, during a
skipping to change at page 11, line 12 skipping to change at page 11, line 12
DOI 10.17487/RFC7999, October 2016, DOI 10.17487/RFC7999, October 2016,
<https://www.rfc-editor.org/info/rfc7999>. <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 Hebrew University of Jerusalem
111 Cummington St, MCS135 Rothburg Family Buildings, Edmond J. Safra Campus
Boston, MA 02215 Jerusalem 9190416
USA Israel
EMail: yossigi@bu.edu EMail: yossigi@cs.huji.ac.il
Sharon Goldberg Sharon Goldberg
Boston University Boston University
111 Cummington St, MCS135 111 Cummington St, MCS135
Boston, MA 02215 Boston, MA 02215
USA USA
EMail: goldbe@cs.bu.edu EMail: goldbe@cs.bu.edu
Kotikalapudi Sriram Kotikalapudi Sriram
 End of changes. 9 change blocks. 
16 lines changed or deleted 17 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/