
<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body style="background-color: rgb(255, 255, 255); color: rgb(0, 0,

    0); font-family: Tahoma; font-size: 16px;" text="#000000"

    bgcolor="#FFFFFF">

    <br>

    <br>

    <div class="moz-cite-prefix">On 1/Oct/18 10:26, John Curran wrote:<br>

      <br>

    </div>

    <blockquote type="cite"

      cite="mid:000253A6-5470-49B6-B506-321714E2BF25@arin.net"

      style="border-left: 2px solid #009900 !important; border-right:

      2px solid #009900 !important; padding: 0px 15px 0px 15px; margin:

      8px 2px; color: rgb(0, 0, 0) !important; color: rgb(0, 0, 0)

      !important; background-color: null !important; color: null

      !important;"><br>

      <pre wrap="">Of course, this presumes correct routing configuration by the ISP when setting up RPKI route validation; while one would hope that the vast majority handle this situation correctly, there is no assurance that will be true without exception. If RPKI routing validation is widely deployed, tens of thousands of ISPs will be setting up such a configuration, with customer impact during an RPKI CA outage occurring for those who somehow failure to fall back to using NotFound routes.  If only a small percentage get this wrong, it will still represent dozens of ISPs going dark as a result. </pre>

    </blockquote>

    <br>

    It is equally important to understand how vendors have interpreted

    the RFC for default treatment of RPKI data.<br>

    <br>

    When we started testing IOS and IOS XE back in 2014/2015, we hit an

    issue where Cisco were automatically applying policy to RPKI state

    without configuration from the operator. This was fixed in later

    code, but goes to show that one should not assume that vendors are

    always doing the right thing, or at the very least, fully understand

    what their view on RPKI might be on the wider Internet, in real

    production.<br>

    <br>

    So before deploying network-wide, I encourage operators to test what

    their equipment will do when RPKI is enabled but without any manual

    policy applied.<br>

    <br>

    <br>

    <blockquote type="cite"

      cite="mid:000253A6-5470-49B6-B506-321714E2BF25@arin.net"

      style="border-left: 2px solid #009900 !important; border-right:

      2px solid #009900 !important; padding: 0px 15px 0px 15px; margin:

      8px 2px; color: rgb(0, 0, 0) !important; color: rgb(0, 0, 0)

      !important; background-color: null !important; color: null

      !important;">

      <pre wrap="">Indeed… Hence the question of liability during a RIR CA outage, should the liability for misconfigured ISPs (those handful of ISPs who do not properly fall back to using state NotFound routes) be the responsibility of each ISP, or perhaps those who announce ROAs, or should be with the RIR?</pre>

    </blockquote>

    <br>

    Any equipment misconfigurations should be the responsibility of the

    operator.<br>

    <br>

    Responsibility for ROA's should lie with the resource holder, in

    ensuring that not only is the information true, but that also all

    announced prefixes are covered by a ROA.<br>

    <br>

    An RIR CA outage would, in my mind, be the responsibility of the

    RIR. But this comes back to my question of how this handled with an

    "all resource" TA.<br>

    <br>

    Mark.<br>

  </body>

</html>