RPKI and BGP Route Origin Validation
Validasi Asal Rute RPKI dan BGP
Bagaimana Infrastruktur Kunci Publik Sumber Daya mencegah pembajakan rute — mencakup rantai kepercayaan ROA, status validasi, protokol RTR, dan posisi penerapan saat ini.
1. Mengapa BGP Tidak Memiliki Validasi Asal Asli
BGP dirancang untuk internet kooperatif di mana semua peserta dipercaya. Sebuah router menerima pesan UPDATE dan menyebarkannya tanpa verifikasi kriptografi bahwa AS asal benar-benar berwenang untuk mengumumkan prefiks IP tersebut. Artinya, AS apa pun — karena kesalahan konfigurasi atau niat jahat — dapat mengumumkan prefiks orang lain, dan pengumuman tersebut dapat disebarkan secara global dalam hitungan menit.
Insiden penting yang mempercepat penerapan RPKI:
- 2008 - Telekomunikasi Pakistan:PTCL secara tidak sengaja mengumumkan awalan yang lebih spesifik untuk ruang alamat YouTube (208.65.153.0/24), memblokir YouTube secara global selama ~2 jam sebelum penyedia hulu menarik rute tersebut.
- 2010 - Telekomunikasi Tiongkok:China Telecom menghasilkan ~50.000 awalan milik jaringan militer, pemerintah, dan komersial AS selama ~18 menit. Apakah disengaja atau tidak, tidak pernah dikonfirmasi.
- 2018 — Pembajakan DNS Amazon Route 53:Seorang penyerang menggunakan BGP untuk membajak 205.251.196.0/24 (Amazon DNS), mengalihkan lalu lintas dompet mata uang kripto untuk mencuri dana. Serangan tersebut menggunakan UPDATE BGP dari eNet (AS10297).
- 2019 — Lalu lintas Eropa dialihkan melalui China Telecom:Lalu lintas seluler Eropa (termasuk Vodafone dan Swisscom Swiss) dialihkan melalui China Telecom selama kurang lebih 2 jam karena kebocoran rute BGP.
2. Hierarki Kepercayaan RPKI
RPKI (RFC 6480) membangun hierarki sertifikat X.509 yang mencerminkan bagaimana ruang alamat IP didelegasikan:
- IANAmemegang jangkar kepercayaan akar. Ia menerbitkan sertifikat sumber daya ke lima RIR (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), yang masing-masing mencakup ruang alamatnya.
- RIRmenerbitkan sertifikat kepada anggotanya (ISP, perusahaan) untuk ruang alamat yang dimiliki anggota tersebut.
- Anggotamenerbitkan sertifikat Entitas Akhir (EE) dan menandatanganinyaOtorisasi Asal Rute(ROA) — pengesahan yang ditandatangani memberi wewenang kepada ASN tertentu untuk membuat awalan tertentu.
Verifikator mengunduh hierarki objek yang ditandatangani ini dari lima repositori RIR (ditambah repositori yang didelegasikan), memvalidasi rantai sertifikat, dan membuat tabel payload ROA (VRP) yang divalidasi. Router kemudian menanyakan cache RPKI lokal melaluiProtokol RTR (RFC 8210) untuk mendapatkan tabel ini dan melakukan validasi asal pada UPDATE BGP yang masuk.
3. Otorisasi Asal Rute (ROA)
ROA (RFC 6482) adalah objek bertanda tangan yang berisi tiga bidang:
- ASN: Sistem Otonom yang diberi wewenang untuk membuat awalan.
- Awalan: Awalan IP (IPv4 atau IPv6) yang diotorisasi.
- panjang maksimal: Panjang awalan maksimum yang boleh diumumkan oleh ASN. Jika tidak ditentukan, hanya awalan persisnya yang diizinkan. Jika disetel ke, katakanlah, 24 untuk awalan /20, ASN juga dapat mengumumkan hal yang lebih spesifik antara /20 dan /24.
Satu ROA dapat mengotorisasi beberapa prefiks untuk ASN yang sama, namun satu ROA tidak dapat mengotorisasi beberapa ASN untuk satu prefiks. Untuk mengizinkan ASN sekunder (misalnya, penyedia transportasi umum atau CDN) untuk membuat awalan Anda, buat ROA terpisah untuk ASN tersebut.
4. Status Validasi
Ketika router menerima UPDATE BGP, ia melakukan validasi asal (RFC 6811) terhadap tabel VRP lokalnya:
| Negara | Kondisi | Perlakuan Preferensi Lokal yang khas |
|---|---|---|
| Sah | Setidaknya satu ROA mencakup awalan (awalan ⊆ awalan ROA DAN panjang awalan ≤ maxLength) DAN ASN ROA cocok dengan ASN asal UPDATE BGP | +20 atau lebih disukai (umum) |
| Tidak sah | Setidaknya satu ROA mencakup awalan, namun tidak ada ROA penutup yang memiliki ASN yang cocok dan maxLength ≥ panjang awalan yang diumumkan | Setel preferensi lokal 0 atau hapus (pilihan operator; RFC 6811 merekomendasikan mengizinkan tetapi menandai) |
| Tidak Ditemukan | Tidak ada ROA yang mencakup awalan yang diumumkan | Tidak berubah (diperlakukan seperti sebelum RPKI ada) |
Wawasan utama:Tidak sahmerupakan bukti yang lebih kuat mengenai suatu masalah dibandingkanTidak Ditemukan. NotFound berarti pemilik awalan belum membuat ROA. Tidak valid berarti ada ROA yang menyatakan ASN inibukandiotorisasi — sinyal kuat adanya kesalahan konfigurasi atau pembajakan.
5. Protokol RTR
Router tidak memvalidasi rantai sertifikat X.509 sendiri — hal ini akan memakan biaya komputasi yang mahal dan memerlukan penyimpanan cache RPKI yang lengkap. Sebaliknya, yang berdedikasivalidator RPKI(Routinator, OctoRPKI, Fort, rpki-client) mengunduh dan memvalidasi repositori RPKI lengkap dan mengekspor Payload ROA Tervalidasi (VRP) yang dihasilkan ke router melalui protokol RTR (RFC 8210).
RTR menggunakan TCP (port 323 yang ditetapkan IANA; validator seperti Routinator default ke port 3323 untuk menghindari memerlukan hak akses root) dengan mekanisme sinkronisasi tambahan: validator mengirimkan nomor seri, dan router hanya meminta delta sejak sinkronisasi terakhirnya. Hal ini menjaga bandwidth tetap rendah bahkan untuk tabel VRP besar (saat ini ~400.000+ entri IPv4 secara global).
6. Penerapan dan Statistik
Pada awal tahun 2026, penerapan RPKI telah mencapai skala yang signifikan:
- Lebih dari 50% prefiks IPv4 yang dirutekan secara global memiliki setidaknya satu ROA yang mencakup (naik dari ~10% pada tahun 2019).
- Mayoritas ISP Tier-1 dan Tier-2 sekarang melakukan Validasi Asal Rute dan menghilangkan atau menurunkan prioritas rute yang tidak valid.
- MANRS (Norma yang Disepakati Bersama untuk Keamanan Perutean) mensyaratkan pembuatan RPKI ROA sebagai prasyarat untuk keanggotaan dan menerbitkan dasbor kesesuaian per-AS.
Statistik langsung:Pemantau NIST RPKI, ROV++, Statistik RPKI APNIC.
7. Melampaui ROV: ASPA dan BGPsec
Validasi Asal Rute RPKI hanya memverifikasi bahwaasal ASNberwenang mengumumkan awalan. Itu tidak memvalidasi AS_PATH — penyerang masih dapat membuat AS_PATH palsu dengan AS asal yang sah di akhir. Dua standar IETF membahas hal ini:
- BGPsec (RFC 8205): Setiap AS di jalur secara kriptografis menandatangani UPDATE, menciptakan lacak balak yang tidak dapat dipatahkan. Mengharuskan semua AS transit untuk mendukung BGPsec — sebuah hambatan penerapan yang signifikan. Jarang diterapkan pada tahun 2026.
- ASPA(Otorisasi Penyedia Sistem Otonom,draft-ietf-sidrops-aspa-profile): AS menandatangani objek yang mencantumkan penyedia hulu resminya. Verifikator dapat mendeteksi jalur bebas lembah yang tidak valid (misalnya, pelanggan mengumumkan rute seolah-olah pelanggan adalah penyedia). Lebih mudah diterapkan dibandingkan BGPsec dan mendapatkan daya tarik pada tahun 2025–2026.
Referensi
- RFC 6480— Infrastruktur untuk Mendukung Perutean Internet Aman (ikhtisar RPKI)
- RFC 6482— Profil untuk Otorisasi Asal Rute (ROA)
- RFC 6811— Validasi Asal Awalan BGP
- RFC 8210— RPKI ke Protokol Router, Versi 1 (RTR)
- RFC 8416— Manajemen Sumber Daya Nomor Internet Lokal yang Disederhanakan dengan RPKI (SLURM — penggantian lokal)
- RFC 9286— Manifes untuk Infrastruktur Kunci Publik Sumber Daya (RPKI)
- RFC 8205— Spesifikasi Protokol BGPsec
- MANRS— Norma yang Disepakati Bersama untuk Keamanan Perutean
- Portal RPKI Cloudflare— pencarian ROA langsung