[RTG-DIR] Routing Directorate Last Call Review for draft-ietf-sidrops-rpkimaxlen-11 - "The Use of maxLength in the RPKI"

["Acee Lindem (acee)" <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see ​

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-sidrops-rpkimaxlen-11
Reviewer: Acee Lindem
Review Date: 7/14/2022
IETF LC End Date: 7/20/2022
Intended Status: Best Current Practice

Summary:

This document is basically ready for publication, but has nits that
should be considered prior to publication.

The document provides recommendations for the limiting the use of
maxLength in RPKI Route Origin Authorizations. The documents also
provides the motivation of limiting the attack surface for
Forged-Origin Subprefix Hijacks. It is well-written and easy to
understand.

Major Issues: None

Minor Issues: None on this draft - one to consider in IDR.

  The terms for BLACKHOLE Community and RTHB don't conform to
  the current IETF guidelines for inclusive language.

Nits:

   1. The usage of enclosing "*"s arounds words seems arbitrary. For
      example: *prefix*, *subprefix*, *only*, *any*, and *other*.
      Please explain this non-standard usage.

   2. I'd use "sub-prefix" rather than "subprefix". As in, for example,
      https://datatracker.ietf.org/doc/html/rfc7695 I didn't put this
      in the diff since there were so many instances.

   3. Define ROV on first use - see in diff.

Suggested changes for readability in diff below.

Thanks,
Acee

*** draft-ietf-sidrops-rpkimaxlen-11.txt.orig        2022-07-13 12:29:14.000000000 -0400
--- draft-ietf-sidrops-rpkimaxlen-11.txt    2022-07-13 17:16:01.000000000 -0400
***************
*** 123,130 ****

     However, measurements of RPKI deployments have found that the use of
     the maxLength in ROAs tends to lead to security problems.  In
!    particular, measurements taken in June 2017 showed that 84% of the
!    prefixes specified in ROAs that use the maxLength attribute, were
     vulnerable to a forged-origin subprefix hijack [HARMFUL].  The
     forged-origin prefix or subprefix hijack involves inserting the
     legitimate AS as specified in the ROA as the origin AS in the
--- 123,130 ----

     However, measurements of RPKI deployments have found that the use of
     the maxLength in ROAs tends to lead to security problems.  In
!    particular, measurements taken in June 2017 showed that of the
!    prefixes specified in ROAs that use the maxLength attribute, 84% were
     vulnerable to a forged-origin subprefix hijack [HARMFUL].  The
     forged-origin prefix or subprefix hijack involves inserting the
     legitimate AS as specified in the ROA as the origin AS in the
***************
*** 367,373 ****
     Another exception is where: (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 are announced by the
!    AS in the ROA.  This case should occur rarely in practice (if at
     all).  Operator discretion is necessary in this case.

     This practice requires no changes to the RPKI specification and need
--- 367,373 ----
     Another exception is where: (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 are announced by the
!    AS in the ROA.  In practice, this case should occur rarely (if at
     all).  Operator discretion is necessary in this case.

     This practice requires no changes to the RPKI specification and need
***************
*** 380,386 ****
     perform a review of such objects, especially where they make use of
     the maxLength attribute, to ensure that the set of included prefixes
     is "minimal" with respect to the current BGP origination and routing
!    policies, and replace the published ROAs as necessary.  Such an
     exercise SHOULD be repeated whenever the operator makes changes to
     either policy.

--- 380,386 ----
     perform a review of such objects, especially where they make use of
     the maxLength attribute, to ensure that the set of included prefixes
     is "minimal" with respect to the current BGP origination and routing
!    policies Published ROAs SHOULD be replaced as necessary.  Such an
     exercise SHOULD be repeated whenever the operator makes changes to
     either policy.

***************
*** 403,409 ****
     a "scrubbing center".

     In order to ensure that such ad-hoc routing changes are effective,
!    there should exist a ROA validating the new route.  However a
     difficulty arises due to the fact that newly created objects in the
     RPKI are made visible to relying parties considerably more slowly
     than routing updates in BGP.
--- 403,409 ----
     a "scrubbing center".

     In order to ensure that such ad-hoc routing changes are effective,
!    a ROA validating the new route should exist.  However a
     difficulty arises due to the fact that newly created objects in the
     RPKI are made visible to relying parties considerably more slowly
     than routing updates in BGP.
***************
*** 412,418 ****
     validates the ad-hoc route, and instead create it "on-the-fly" as
     required.  However, this is practical only if the latency imposed by
     the propagation of RPKI data is guaranteed to be within acceptable
!    limits in the circumstances.  For time-critical interventions such as
     responding to a DDoS attack, this is unlikely to be the case.

     Thus, the ROA in question will usually need to be created well in
--- 412,418 ----
     validates the ad-hoc route, and instead create it "on-the-fly" as
     required.  However, this is practical only if the latency imposed by
     the propagation of RPKI data is guaranteed to be within acceptable
!    limits for the circumstances.  For time-critical interventions such as
     responding to a DDoS attack, this is unlikely to be the case.

     Thus, the ROA in question will usually need to be created well in
***************
*** 451,457 ****


     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
     DDoS attack, the DDoS mitigation service provider AS 64500 originates
     a /22 prefix that is longer than AS 64496's /16 prefix, and so all
     the traffic (destined to addresses in 192.168.0.0/22) that normally
--- 451,457 ----


     traffic to itself.  The traffic is scrubbed at AS 64500 and then sent
!    back to AS 64496 over a backhaul link.  Notice that, during a
     DDoS attack, the DDoS mitigation service provider AS 64500 originates
     a /22 prefix that is longer than AS 64496's /16 prefix, and so all
     the traffic (destined to addresses in 192.168.0.0/22) that normally
***************
*** 523,545 ****
     originate prefix 192.168.0.0/24 during a DDoS attack in that space,
     it also makes the *other* /24 prefixes covered by the /22 prefix
     (i.e., 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24) vulnerable to
!    a forged-origin subprefix attacks.

  5.2.  Defensive de-aggregation in response to prefix hijacks

     In responding to certain classes of prefix hijack, in particular, the
     forged-origin subprefix hijack described above, it may be desirable
!    for the victim to perform "defensive de-aggregation", i.e. to begin
     originating more-specific prefixes in order to compete with the
!    hijack routes for selection as the best path in networks that are not
     performing RPKI-based route origin validation [RFC6811].

     In some topologies, where at least one AS on every path between the
!    victim and hijacker filters ROV invalid prefixes, it may be the case
!    that the existence of a minimal ROA issued by the victim prevents the
!    defensive more-specific prefixes being propagated to the networks
!    topologically close to the attacker, thus hampering the effectiveness
!    of this response.

     Nevertheless, this document recommends that where possible, network
     operators publish minimal ROAs even in the face of this risk.  This
--- 523,545 ----
     originate prefix 192.168.0.0/24 during a DDoS attack in that space,
     it also makes the *other* /24 prefixes covered by the /22 prefix
     (i.e., 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24) vulnerable to
!    forged-origin subprefix attacks.

  5.2.  Defensive de-aggregation in response to prefix hijacks

     In responding to certain classes of prefix hijack, in particular, the
     forged-origin subprefix hijack described above, it may be desirable
!    for the victim to perform "defensive de-aggregation", i.e., to begin
     originating more-specific prefixes in order to compete with the
!    hijacked routes for selection as the best path in networks that are not
     performing RPKI-based route origin validation [RFC6811].

     In some topologies, where at least one AS on every path between the
!    victim and hijacker filters Route Origin Validation (ROV) invalid
!    prefixes, it may be the case that the existence of a minimal ROA
!    issued by the victim prevents the defensive more-specific prefixes
!    from being propagated to the networks topologically close to the
!    attacker, thus hampering the effectiveness of the response.

     Nevertheless, this document recommends that where possible, network
     operators publish minimal ROAs even in the face of this risk.  This
***************
*** 563,569 ****


     *  Other methods for reducing the size of such neighborhoods are
!       available to potential victims, such as establishing direct eBGP
        adjacencies with networks from whom the defensive routes would
        otherwise be hidden.

--- 563,569 ----


     *  Other methods for reducing the size of such neighborhoods are
!       available to potential victims, such as establishing direct EBGP
        adjacencies with networks from whom the defensive routes would
        otherwise be hidden.

***************
*** 596,602 ****

  7.  Operational Considerations

!    The recommendations set out in this document, in particular, those in
     Section 5, involve trade-offs between operational agility and
     security.

--- 596,602 ----

  7.  Operational Considerations

!    The recommendations specified in this document, in particular, those in
     Section 5, involve trade-offs between operational agility and
     security.

***************
*** 607,614 ****

     Even in the case of routing changes that are planned in advance,
     existing procedures may need to be updated to incorporate changes to
!    issued ROAs, and additional time allowed for those changes to
!    propagate.



--- 607,614 ----

     Even in the case of routing changes that are planned in advance,
     existing procedures may need to be updated to incorporate changes to
!    issued ROAs, and may require additional time allowed for those changes
!    to propagate.



***************
*** 627,633 ****

     This document makes recommendations regarding the use of RPKI-based
     origin validation as defined in [RFC6811], and as such introduces no
!    additional security considerations beyond those set out therein.

  9.  IANA Considerations

--- 627,633 ----

     This document makes recommendations regarding the use of RPKI-based
     origin validation as defined in [RFC6811], and as such introduces no
!    additional security considerations beyond those specified therein.

  9.  IANA Considerations

***************
*** 638,644 ****
     The authors would like to thank the following people for their review
     and contributions to this document: Omar Sagga and Aris Lambrianidis.
     Thanks are also due to Matthias Waehlisch, Ties de Kock, and Amreesh
!    Phokeer for comments and suggestions.

  11.  References

--- 638,645 ----
     The authors would like to thank the following people for their review
     and contributions to this document: Omar Sagga and Aris Lambrianidis.
     Thanks are also due to Matthias Waehlisch, Ties de Kock, and Amreesh
!    Phokeer for comments and suggestions. Thanks to Acee Lindem for the
!    Routing Directorate review.

  11.  References