BGP mengumumkan reachability, tetapi sebuah route advertisement tidak membuktikan bahwa Autonomous System yang menjadi origin memiliki otorisasi untuk mengumumkan prefix tersebut. Resource Public Key Infrastructure, atau RPKI, menambahkan data otorisasi resource bertanda tangan yang dapat diubah menjadi record untuk validasi origin pada router.

Pemeriksaan ini sengaja memiliki cakupan sempit. Prefix dan origin AS pada rute dibandingkan dengan validated ROA payloads, yang umum disebut VRP. Hasilnya dapat digunakan oleh kebijakan routing, tetapi tidak mengautentikasi setiap AS di dalam AS_PATH dan tidak mengubah BGP menjadi protokol validasi path.

ROA menjadi input validasi lokal

Route Origin Authorization mengikat resource alamat IP dengan AS yang diizinkan menjadi origin rute untuk resource tersebut. Setelah RPKI relying party memvalidasi objek bertanda tangan yang relevan, router dapat menerima VRP dari cache lokal.

Sebuah VRP memuat prefix, origin ASN, dan panjang prefix maksimum. Validasi origin dengan demikian bekerja memakai data yang sudah divalidasi, bukan langsung memperlakukan file ROA yang diterima sebagai kebijakan router.

RFC 6811 mendefinisikan perbandingan inti. VRP mencakup sebuah rute ketika prefix rute sama dengan atau lebih spesifik daripada prefix VRP. Kecocokan juga mensyaratkan panjang prefix rute tidak melebihi panjang maksimum VRP dan origin ASN rute sama dengan ASN pada VRP.

Perbedaan tersebut membuat maxLength relevan terhadap keamanan. Nilai yang luas mengotorisasi pengumuman more-specific sampai panjang tersebut. RFC 9319 merekomendasikan pembatasan otorisasi itu dan menghindari maxLength kecuali kebutuhan operasional memang membenarkannya.

Tiga status menggambarkan hasil perbandingan

Validasi origin menghasilkan tiga status:

Valid
  setidaknya satu VRP cocok dengan rute

Invalid
  setidaknya satu VRP mencakup rute, tetapi tidak ada yang cocok

NotFound
  tidak ada VRP yang mencakup prefix rute

Invalid tidak berarti signature kriptografis pada BGP UPDATE gagal. Status ini berarti rute bertentangan dengan data otorisasi origin tervalidasi yang tersedia secara lokal: origin ASN dapat berbeda, prefix yang diumumkan dapat terlalu spesifik, atau keduanya.

NotFound juga berbeda. Status ini berarti kumpulan VRP lokal tidak memiliki otorisasi yang mencakup rute tersebut. Status ini bukan padanan Invalid dan bukan hasil otorisasi positif.

Sebuah rute juga dapat dicakup oleh beberapa VRP. Satu VRP yang cocok sudah cukup untuk menghasilkan status Valid, meskipun VRP lain yang mencakup rute tidak cocok.

Status validasi dan kebijakan routing merupakan dua hal terpisah

Algoritme validasi menetapkan status; kebijakan operator menentukan tindakan terhadap status itu. RFC 8481 menegaskan bahwa kebijakan tidak boleh diterapkan hanya karena validasi origin tersedia. Filtering atau perubahan preference memerlukan konfigurasi eksplisit.

Panduan operasional RFC 7115 merekomendasikan agar pengumuman Invalid secara normal tidak digunakan, sambil mengakui adanya kebutuhan operasional khusus yang dapat memerlukan pengecualian. Dokumen tersebut juga membedakan NotFound dari Invalid, hal yang penting saat deployment bertahap dan ketika data RPKI belum lengkap atau sedang berubah.

Pemisahan ini mencegah sinyal keamanan yang berguna diam-diam menjadi keputusan routing tanpa dokumentasi. Operator juga dapat memperkenalkan validasi, memeriksa dampaknya, kemudian menerapkan kebijakan yang sesuai dengan jaringannya.

Perubahan data RPKI dapat mengubah status rute

RPKI merupakan data terdistribusi. Cache mengambil dan memvalidasi konten repository dari waktu ke waktu, sehingga dua cache dapat memiliki pandangan berbeda untuk sementara. RFC 7115 menyebut sifat sinkronisasi longgar ini secara eksplisit.

Ketika mapping prefix-ke-AS tervalidasi ditambahkan, dihapus, atau diubah, rute yang terdampak perlu divalidasi kembali. Karena itu, sebuah rute dapat berpindah antara Valid, Invalid, dan NotFound tanpa menerima pengumuman BGP baru.

Sifat tersebut memiliki konsekuensi operasional. Monitoring perlu membedakan perubahan routing dari perubahan data validasi, sementara deployment kebijakan perlu memperhitungkan kesehatan cache dan freshness data. Pandangan lokal yang stale atau tidak lengkap dapat mengubah klasifikasi meskipun rutenya sendiri tidak berubah.

Validasi origin tidak memvalidasi path

Validasi origin RPKI memeriksa AS yang mengklaim sebagai origin prefix. Mekanisme ini tidak memverifikasi bahwa urutan autonomous system di dalam AS_PATH merupakan jalur propagasi yang autentik.

RFC 6811 menyatakan batas tersebut secara langsung. Penyerang yang mampu membentuk rute dengan origin AS yang diotorisasi dapat lolos dari pemeriksaan origin meskipun bagian path lainnya menyesatkan. Mekanisme lain diperlukan untuk validasi path secara kriptografis.

Batas ini tidak membuat validasi origin menjadi sepele. Kesalahan origin yang tidak disengaja dan banyak pengumuman forged-origin menghasilkan ketidakcocokan prefix-ke-origin yang memang dapat diklasifikasikan oleh RPKI. Kontrol ini bernilai karena klaimnya spesifik, bukan karena menyelesaikan seluruh masalah keamanan BGP.

Validasi export memiliki detail origin tersendiri

Validasi origin juga dapat diterapkan pada rute yang dikirim ke neighbor. RFC 8893 menetapkan detail penting untuk kebijakan export: validasi harus mempertimbangkan effective origin AS setelah transformasi outbound yang dapat mengubah apa yang akan dilihat neighbor.

Operasi seperti penghapusan private AS atau penanganan confederation dapat mengubah effective origin. Menggunakan kembali klasifikasi yang dihitung sebelum transformasi tersebut dapat menghasilkan status untuk representasi rute yang berbeda.

Pemeriksaan ingress dan egress memakai model otorisasi yang sama, tetapi rute yang diklasifikasikan harus sesuai dengan keadaan rute pada titik kebijakan terkait.

Otorisasi yang ketat menjaga presisi sinyal

Validasi origin RPKI paling tepat ketika ROA menyatakan routing intent yang benar-benar diperlukan operator. Otorisasi panjang prefix yang terlalu luas memperbesar kumpulan pengumuman yang dapat memperoleh status Valid. Otorisasi yang tidak tersedia membuat routing intent terkait tidak hadir dalam data validasi lokal.

Deployment yang presisi memadukan cakupan ROA yang cermat, relying-party cache yang sehat, kebijakan router yang eksplisit, dan monitoring terhadap transisi status. Setiap komponen memiliki tugas yang berbeda.

Batas utamanya tetap sederhana: validasi origin RPKI menjawab apakah data otorisasi resource tervalidasi mengizinkan kombinasi prefix dan origin AS yang diamati. Kebijakan routing bertindak atas jawaban tersebut. AS path sendiri tetap berada di luar klaim itu.

Cybersecurity RPKI BGP Routing Security Network Security