<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>RPKI on Nalar</title>
    <link>https://nalar.dev/tags/rpki/</link>
    <description>Recent content in RPKI on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 23 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/rpki/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>BGPsec Signs the AS Path Hop by Hop</title>
      <link>https://nalar.dev/bgpsec-signs-the-as-path-hop-by-hop/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/bgpsec-signs-the-as-path-hop-by-hop/</guid>
      <description>&lt;p&gt;BGP route origin authorization protects one narrow statement: which AS may originate a prefix. It does not cryptographically protect every AS hop that appears after the origin. BGPsec, standardized in RFC 8205, addresses that separate boundary by carrying signed path information in BGP UPDATE messages.&lt;/p&gt;&#xA;&lt;p&gt;The mechanism changes more than the validation rule. A BGPsec UPDATE uses &lt;code&gt;BGPsec_PATH&lt;/code&gt; instead of the conventional &lt;code&gt;AS_PATH&lt;/code&gt;, and participating ASes extend a chain of Secure_Path and Signature Segments as the route moves between BGPsec-capable external peers.&lt;/p&gt;</description>
    </item>
    <item>
      <title>RPKI ASPA Authorizes Transit Relationships for AS_PATH Checks</title>
      <link>https://nalar.dev/rpki-aspa-authorizes-transit-relationships-for-as-path-checks/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/rpki-aspa-authorizes-transit-relationships-for-as-path-checks/</guid>
      <description>&lt;p&gt;A valid route origin says little about the relationships represented by the rest of an AS_PATH. A prefix can originate from an authorized AS and still travel through a sequence that conflicts with expected customer-to-provider structure. Autonomous System Provider Authorization, or ASPA, adds a signed RPKI object for that second problem.&lt;/p&gt;&#xA;&lt;p&gt;As of September 2026, ASPA is still specified in active IETF Internet-Drafts rather than a published RFC. The current ASPA profile draft defines the signed object, while the current verification draft defines procedures for applying validated ASPA data to BGP AS_PATHs. That status matters operationally: fields and procedures remain subject to change until the specifications complete the standards process.&lt;/p&gt;</description>
    </item>
    <item>
      <title>RPKI Origin Validation Checks BGP Prefix Authority</title>
      <link>https://nalar.dev/rpki-origin-validation-checks-bgp-prefix-authority/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/rpki-origin-validation-checks-bgp-prefix-authority/</guid>
      <description>&lt;p&gt;BGP announces reachability, but a route advertisement by itself does not prove that the originating Autonomous System is authorized to originate the prefix. Resource Public Key Infrastructure, or RPKI, adds signed resource authorization data that can be converted into records a router uses for origin validation.&lt;/p&gt;&#xA;&lt;p&gt;The resulting check is deliberately narrow. It compares the route prefix and origin AS with validated ROA payloads, commonly called VRPs. The result can feed routing policy, but it does not authenticate every AS in &lt;code&gt;AS_PATH&lt;/code&gt; and does not turn BGP into a path-validation protocol.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
