draft-ietf-sidrops-rpki-rov-timing.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc category="info" docName="draft-ietf-sidrops-rpki-rov-timing-05" ipr="trust200902">

<front>

  <title abbrev="RPKI ROV Timing">
  Timing Parameters in the RPKI based Route Origin Validation Supply Chain
  </title>

  <author fullname="Randy Bush" initials="R." surname="Bush">
    <organization>Internet Initiative Japan &amp; Arrcus, Inc.</organization>
    <address>
      <postal>
	<street>5147 Crystal Springs</street>
	<city>Bainbridge Island</city>
	<region>Washington</region>
	<code>98110</code>
	<country>United States of America</country>
      </postal>
      <email>randy@psg.com</email>
    </address>
  </author>

  <author fullname="Jay Borkenhagen" initials="J." surname="Borkenhagen">
    <organization>AT&amp;T</organization>
    <address>
      <postal>
	<street>200 Laurel Avenue South</street>
	<city>Middletown</city>
	<region>NJ</region>
	<code>07748</code>
	<country>United States of America</country>
      </postal>
      <email>jayb@att.com</email>
    </address>
  </author>

  <author fullname="Tim Bruijnzeels" initials="T." surname="Bruijnzeels">
    <organization>NLnet Labs</organization>
      <address>
	<postal>
	  <street></street>
	  <city></city>
	  <code></code>
	  <country></country>
	  <region></region>
	</postal>
      <phone></phone>
      <email>tim@nlnetlabs.nl</email>
      <uri>https://www.nlnetlabs.nl/</uri>
    </address>
  </author>

  <author fullname="Job Snijders" initials="J." surname="Snijders">
    <organization>Fastly</organization>
    <address>
      <postal>
        <street />
        <city>Amsterdam</city>
        <code />
        <country>Netherlands</country>
      </postal>
      <email>job@fastly.com</email>
    </address>
  </author>

  <date />

  <abstract>
    
    <t>
      This document explores, and makes recommendations for, timing of
      Resource Public Key Infrastructure publication of ROV data, their
      propagation, and their use in Relying Parties, caches, and
      routers.
    </t>
    
  </abstract>

  <note title="Requirements Language">

    <t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 <xref target="RFC2119"/> <xref
      target="RFC8174"/> when, and only when, they appear in all
      capitals, as shown here.
    </t>

  </note>

</front>

<middle>

  <section anchor="intro" title="Introduction">
    
    <t>
      This document explores, and makes recommendations for, timing of
      Resource Public Key Infrastructure (RPKI) publication of ROV data,
      their propagation, and their use in Relying Parties (RP), caches,
      and routers.
    </t>

    <t>
      The RPKI ROA supply chain from CAs to when they reach routers has
      the following structure:
    </t>
    <t>
      <list style="hanging">

	<t hangText="Cerification Authorities:">
	  The authoritative data of the RPKI are meant to be published
	  by a distributed set of Certification Authorities (CAs) at the
	  IANA, RIRs, NIRs, and ISPs (see <xref target="RFC6481"/>).
	</t>

	<t hangText="Publication Points:">
	  The CAs publish their authoritative data in publicly
	  accessible repositories which have a Publication Point (PP)
	  for each CA.  A CA may publish directly at a PP or may use the
	  RPKI Publication Protocol <xref target="RFC8181"/>.
	</t>

	 <t hangText="Relying Parties:">
	   Relying Parties are a local (to the routers) set of one or
	   more collected and verified caches of RPKI data which the RPs
	   collect from the PPs.
	 </t>
	 
	 <t>
	   Currently RPs can pull from other RPs, thereby allowing a
	   somewhat complex topology.
	 </t>

	 <t hangText="Routers:">
	   Validating routers fetch data from local RP caches using the
	   RPKI to Router Protocol, <xref target="RFC8210"/> and <xref
	   target="I-D.ietf-sidrops-8210bis"/>.  Routers are clients of
	   the caches.  Validating routers MUST have a trust
	   relationship with, and a trusted transport channel to, any
	   RP(s) they use.  <xref target="I-D.ietf-sidrops-8210bis"/>
	   specifies mechanisms for a router to assure itself of the
	   authenticity of the cache(s) and to authenticate itself to
	   cache(s).
	 </t>
      </list>
    </t>

    <t>
      As Resource Public Key Infrastructure based Route Origin
      Validation (ROV) becomes deployed in the Internet, the quality of
      the routing control plane, and hence timely and accurate delivery
      of packets in the data plane, increasingly depend on prompt and
      accurate propagation of the RPKI data from the originating
      Certification Authorities (CAs), to Relying Parties (RPs), to
      Border Gateway Protocol (BGP) speaking routers.
    </t>

    <t>
      Origin Validation based on stale ROAs allows accidental or
      intentional mis-origination; announcement of a prefix by an AS
      which does not have the authority to do so.  Delays in ROA
      propagation to ROV in routers might cause loss of good traffic.
      Therefore minimizing propagation time of data from CAs to routers
      is important.
    </t>

    <t>
      Before the data can start on the CA to router supply chain, the
      resource holder (operator) MUST create, modify, or delete the
      relevant ROA(s) through the CA's operational interface(s).  The
      operator is responsible for anticipating their future needs for
      ROAs, be aware of the propagation time from creating ROAs to
      effect on routing, and SHOULD create, delete, or modify ROAs
      sufficiently in advance of any needs in the routing system.
    </t>
    
    <t>
      There are questions of how frewwww3quently a CA publishes, how often an
      RP pulls, and how often routers pull from their RP(s).  Overall,
      the router(s) SHOULD react within an hour of ROA publication.  In
      pessimistic circumstances, it could be two hours.
    </t>

    <t>
      For CAs publishing to PPs, a few seconds to a minute seems easily
      achieved with reasonable software.  See <xref target="publish"/>.
    </t>

    <t>
      Relying Party validating caches periodically retrieve data from CA
      publication points.  RPs using rsync to poll publication points
      every ten minutes would be a burden today, given the load it would
      put on publication services, cf. one notorious repository which
      was structured against specification.  RPs using RRDP impose less
      load.  As the infrastructure moves from rsync to RRDP <xref
      target="I-D.ietf-sidrops-prefer-rrdp"/>, RRDP is designed for
      quite frequent polling as long as Relying Parties use the
      If-Modified-Since (see <xref target="RFC7232"/>) header and there
      is a caching infrastructure.  For rsync, an hour would be the
      longest acceptable window and half an hour the shortest.  See
      <xref target="rp-pull"/>.
    </t>

    <t>
      For BGP speaking router(s) pulling from the RP(s), five minutes to
      an hour is a wide window.  But, the RPKI-Rtr protocol does have
      the Serial Notify PDU, the equivalent of DNS Notify <xref
      target="RFC1996"/>, where the cache tells the router that it has
      new data.  See <xref target="router-pull"/>.
    </t>

    <t>
      We discuss each of these in more detail below.
    </t>

   </section>

   <section anchor="related" title="Related Work">

    <t>It is assumed that the reader understands BGP, <xref
    target="RFC4271"/>, the RPKI <xref target="RFC6480"/>, RPKI
    Manifests <xref target="RFC6486"/>, Route Origin Authorizations
    (ROAs), <xref target="RFC6482"/>, the RPKI Repository Delta Protocol
    (RRDP) <xref target="RFC8182"/>, The Resource Public Key
    Infrastructure (RPKI) to Router Protocol <xref
    target="I-D.ietf-sidrops-8210bis"/>, RPKI-based Prefix Validation,
    <xref target="RFC6811"/>, and Origin Validation Clarifications,
    <xref target="RFC8481"/>.</t>

  </section>

  <section anchor="publish" title="Certification Authority Publishing">
    
    <t>
     One constraint on publication timing can be ensuring the CRL and
     Manifest (<xref target="RFC6486"/>) are consistent with each other
     and with respect to the other repository data.  With both rsync and
     RRDP protocols, the publication point MUST be consistent before it
     becomes current and is published.
    </t>

    <t>
      Operators should beware that there may be implementation dependent
      delays between instructing their CAs to create and/or update ROAs
      and the publication of these changes in the PPs.
    </t>

  </section>

  <section anchor="rp-pull" title="Relying Party Fetching">
    
    <t>
     rsync puts a load on RPKI publication point servers.  Therefore
     relying party caches have been discouraged from fetching more
     frequently than on the order of a half hour.  Times as long as a
     day were even suggested.  We specify that RPs using rsync SHOULD
     pull from CA publication points every 30 to 60 minutes.
    </t>
    
    <t>
      With RRDP (<xref target="RFC8182"/>), such constraints can be less
      relevant.  <xref target="RFC8182"/> makes clear that polling as
      frequently as once a minute is acceptable if and only if Relying
      Parties use the If-Modified-Since header and there is caching.
      Absent use of the If-Modified-Since header, the RRDP polling
      interval MUST NOT be more frequent than ten minutes.  Use of the
      If-Modified-Since header is strongly RECOMMENDED.
    </t>
    
    <t>
      Migration from rsync to RRDP in <xref
      target="I-D.ietf-sidrops-prefer-rrdp"/> is recommended.  During
      dual RRDP/rsync operation, should an RP need to fall over from
      RRDP to rsync, a uniformly distributed jittered delay with a mean
      of half the rsync interval SHOULD be used; so clients falling over
      to rsync are as spread out as they would be if they used rsync
      initallly.
    </t>
    
    <t>
      A number of timers are embedded in the X.509 RPKI data which
      should also be considered.  E.g., CRL publication commitments,
      expiration of EE certificates pointing to Manifests, and the
      Manifests themselves.  Some CA operators commonly indicate new CRL
      information should be available in the next 24 hours.  These 24
      hour sliding timers, when combined with fetching RPKI data once a
      day, would expose failure windows, especially in the face of
      transient network issues between the CA and RP.  To ameliorate
      this, RPs SHOULD update from CAs at least as frequently as once an
      hour.
    </t>

    <t>
      In summary, the following timing constraints SHOULD be applied to
      data update: RPs SHOULD update from CAs at least once an hour.  To
      avoid excess load, RPs SHOULD NOT update via rsync more frequently
      than every 30 minutes.  RPs using RRDP SHOULD NOT need to update
      more frequently than every 10 minutes.  Some form of timing jitter
      MUST be applied to ensure load distribution across the community.
      RPs SHOULD NOT force data fetch to be on the hour or similar times.
      Publication Points SHOULD deploy RRDP services which honor
      If-Modified-Since.
    </t>

    <t>
      In general, CAs should have Manifest, CRL, and other "baked in"
      timers have an expiry of a few days to allow relying party
      operators to go away for a long weekend and not fear for their
      control plane.
    </t>
    
  </section>

  <section anchor="router-pull" title="Router Updating">
    
    <t>
     The rate of change of ROA data is estimated to remain small, on the
     order of a few ROAs a minute, but with bursts.  Therefore, the
     routers may update from the (presumed local) relying party cache(s)
     quite frequently.  Note that <xref
     target="I-D.ietf-sidrops-8210bis"/> recommends a polling interval
     of one hour.  This polling timing is conservative because caches
     can send a Serial Notify PDU to tell routers when there are new
     data to be fetched.  As the RP cache and the router belong to the
     same operator, routers are free to hammer the RPs as frequently as
     they wish.
    </t>
    
    <t>
      A router SHOULD respond with a Serial Query when it receives a
      Serial Notify from a cache.  If a router can not respond
      appropriately to a Serial Notify, then it MUST send a periodic
      Serial Query no less frequently than once an hour.
    </t>
    
  </section>

  <section anchor="router-effect" title="Effect on Routing">
    
    <t>
      Once a router has received an End of Data PDU from a cache, the
      effect on Route Origin Validation MUST be a matter of seconds to a
      minute.  The router MAY allow incoming VRPs to affect Origin
      Validation as they arrive instead of waiting for the End of Data
      PDU.  See <xref target="I-D.ietf-sidrops-8210bis"/> for some
      cautions regarding the arrival and processing sequence of VRPs.
    </t>
    
  </section>

  <section anchor="alt-tech" title="Alternative Technologies">
    
    <t>
      Should the supply chain include components or technologies other
      than those in IETF documents, the end effect SHOULD be the same;
      the router(s) SHOULD react to invalid AS origins within the same
      overall time constraint, one hour, two at most, from ROA creation
      at the CA publication point to effect in the router.
    </t>
    
  </section>
  
  <section anchor="op-expect" title="Operational Expectations">
    <t>
      Assuming the above recommendations, in worst conditions such as an
      RPKI-rtr Notify PDU being ignored, it may take up to two hours for
      a new ROA to propagate from creation at the CA to BGP speaking
      routers.  Therefore it is RECOMMENDED that planned changes in ROAs
      take this propagation time into consideration.  E.g. if a new
      route is to be announced in BGP, the operators SHOULD create the
      ROA around three hours before BGP announcement, or it may not
      propagate globally.
    </t>

  </section>

<section anchor="Security" title="Security Considerations">
    
    <t>
     Despite common misconceptions and marketing, Route Origin
     Validation is not a magic security protocol.  It is intended to
     catch operational errors, and is easily gamed and attacked through,
     for example, AS Path manipulation.  It is one tool in the prudent
     operator's kit, and a good one.
    </t>
    
    <t>
     If an attacker can add, delete, or modify RPKI data, either in
     repositories or in flight, they can affect routing and thereby
     steer or damage traffic.  The RPKI system design does much to deter
     these attacks.  But the 'last mile' from the cache to the router
     uses transport, as opposed to object, security and is vulnerable.
     This is discussed in <xref target="I-D.ietf-sidrops-8210bis"/>.
    </t>
    
    <t>
      Similarly, if an attacker can delay prompt propagation of RPKI
      data on the supply chain described in this document, they can
      affect routing, and therefore traffic flow, to their advantage.
    </t>
    
  </section>

  <section anchor="IANA" title="IANA Considerations">
    
    <t>
      None
    </t>
    
  </section>

</middle>

<back>
    
  <references title="Normative References">
    <?rfc include="reference.RFC.1996.xml"?>
    <?rfc include="reference.RFC.2119.xml"?>
    <?rfc include="reference.RFC.4271.xml"?>
    <?rfc include="reference.RFC.6481.xml"?>
    <?rfc include="reference.RFC.6486.xml"?>
    <?rfc include="reference.RFC.6482.xml"?>
    <?rfc include="reference.RFC.6811.xml"?>
    <?rfc include="reference.RFC.7232.xml"?>
    <?rfc include="reference.RFC.8174.xml"?>
    <?rfc include="reference.RFC.8181.xml"?>
    <?rfc include="reference.RFC.8182.xml"?>
    <?rfc include="reference.RFC.8210.xml"?>
    <?rfc include="reference.RFC.8481.xml"?>
    <?rfc include="reference.I-D.ietf-sidrops-8210bis.xml"?>
    </references>

  <references title="Informative References">
    <?rfc include="reference.RFC.6480.xml"?>
    <?rfc include="reference.I-D.ietf-sidrops-prefer-rrdp.xml"?>
    </references>

  <section anchor="Acknowledgements" title="Acknowledgements">
      
    <t>
      The authors wish to thank George Michaelson, Massimiliano Stucchi
      and Ties de Kock.
    </t>
    
  </section>

</back>

</rfc>