Perintah dan konteks yang berlaku
Pewawancara menjelaskan sebuah prefiks yang diumumkan oleh AS yang salah dan menanyakan bagaimana Anda menentukan apakah pengumuman tersebut diotorisasi oleh pemegang alamat. Jelaskan RPKI, Route Origin Authorizations (ROA), dan BGP Prefix Origin Validation (ROV), sembari menyatakan bahwa ROV memvalidasi AS asal (origin AS) dan bukan keseluruhan AS_PATH. Topik ini relevan untuk posisi di bidang jaringan, CDN, platform cloud, dan infrastruktur.
Apa yang sedang diuji oleh pewawancara
Jawaban yang kuat dimulai dengan "AS mana yang diotorisasi untuk menginisiasi prefiks mana," alih-alih menyebut RPKI sebagai BGP terenkripsi. Kandidat harus menjelaskan bagaimana VRP dibandingkan dengan prefiks rute BGP dan origin AS untuk menghasilkan status Valid, Invalid, atau NotFound; bagaimana kebijakan (policy) menggunakan status-status tersebut; mengapa cache bisa tidak konsisten; dan mengapa memfilter Invalid masih dapat menyebabkan dampak kerusakan tambahan (collateral damage). Jawaban "RPKI mencegah semua pembajakan" menunjukkan bahwa kandidat belum memahami batasannya.
Pertanyaan klarifikasi di awal
- Apakah kita melindungi asal prefiks atau memvalidasi AS_PATH secara lengkap? ROV hanya menjawab yang pertama.
- Apakah kita sedang mendiskusikan publikasi ROA, validasi router, atau pemfilteran kebijakan masuk (inbound policy filtering)? Semuanya merupakan titik kendali yang berbeda.
- Apakah kita memiliki cache ROA redundan dan kebijakan pemadaman cache yang jelas? Pemadaman cache seharusnya tidak membuat setiap rute tiba-tiba menjadi Invalid.
- Apakah prioritasnya adalah keamanan, keterjangkauan (reachability), atau kecepatan rollback? Pemfilteran ketat membutuhkan jendela pemeliharaan (change window) dan observabilitas.
Jawaban 30 detik
"Saya akan meminta pemegang prefiks memublikasikan ROA yang mengotorisasi origin AS dan panjang prefiks maksimum (maximum prefix length). Sebuah validator memproses objek bertanda tangan menjadi VRP, dan BGP speaker membandingkan prefiks rute serta origin AS di sisi paling kanan ASPATH: mencakup dan cocok menghasilkan Valid, mencakup tetapi tidak cocok menghasilkan Invalid, dan tidak ada VRP yang mencakup menghasilkan NotFound. Kebijakan dapat menolak Invalid dan menangani NotFound secara terpisah, tetapi ini melindungi asal, bukan setiap lompatan (hop) ASPATH. Sebelum peluncuran, saya akan memeriksa cakupan ROA, kebaruan cache, rollback, dan keterjangkauan karena cache terdistribusi dapat bersifat tidak konsisten untuk sementara waktu."
Jawaban mendalam langkah demi langkah
- Definisikan otorisasi. ROA adalah objek bertanda tangan digital yang mengikat prefiks IP, panjang prefiks maksimum, dan origin AS yang diotorisasi. Ini menentukan siapa yang boleh mengumumkan prefiks tertentu; ROA tidak menandatangani setiap atribut BGP.
- Bangun data validasi. RPKI bergantung pada sertifikat sumber daya (resource certificates), objek bertanda tangan, dan repositori terdistribusi. Validator mengambil dan memverifikasinya secara berkala untuk membangun VRP lokal; BGP speaker menggunakan cache lokal daripada melakukan validasi sertifikat penuh untuk setiap rute.
- Hitung tiga status. Sebuah rute berstatus Valid ketika sebuah VRP mencakup prefiksnya dan cocok dengan origin AS-nya; Invalid ketika ada VRP yang mencakup tetapi tidak ada yang cocok; dan NotFound ketika tidak ada VRP yang mencakup prefiks tersebut. Rute yang lebih spesifik (more-specific) tetap harus memenuhi batas panjang maksimum ROA.
- Hubungkan dengan kebijakan. Kebijakan masuk dapat mencocokkan status: umumnya menolak Invalid, mencatat log atau menurunkan tingkat kepercayaan untuk NotFound, dan menerima Valid. Buat kebijakan dapat dibatalkan (reversible) agar ROA yang salah atau masalah cache tidak menimbulkan pemadaman besar.
- Pahami batasan cache. RFC 6811 menjelaskan RPKI global sebagai tampilan terdistribusi yang konsisten secara longgar (loosely consistent); cache dapat berbeda untuk sementara karena diperbarui pada waktu yang berbeda. Pantau stempel waktu VRP, sesi cache, dan distribusi status daripada langsung mencap sebuah peringatan rute sebagai serangan.
- Jelaskan batasan perlindungan. ROV dapat memitigasi asal yang salah dan beberapa pembajakan rute; NIST mendeskripsikannya sebagai platform berbasis standar untuk mengurangi kesalahan konfigurasi dan serangan berbahaya terkait. ROV tidak membuktikan bahwa AS perantara berperilaku benar dan tidak dapat menghentikan setiap kebocoran rute (route leak) dengan sendirinya.
- Rencanakan peluncuran yang aman. Mulai dalam mode observasi, periksa Invalid dan NotFound, lalu aktifkan penolakan untuk sebagian kecil tetangga (neighbors). Sebelum setiap perubahan, verifikasi panjang maksimum ROA, pengumuman redundan, dan perintah rollback. Setelah itu, pantau keterjangkauan, volume Invalid, kesehatan cache, dan penundaan peringatan.
Contoh jawaban berkualitas tinggi
"Saya akan membagi masalah ini menjadi otorisasi, validasi, dan kebijakan. Pemegang prefiks memublikasikan ROA yang menyebutkan origin AS yang diizinkan dan panjang prefiks maksimum. Validator RPKI memeriksa objek bertanda tangan dan menghasilkan VRP; BGP speaker membandingkan setiap prefiks yang diterima dengan origin AS dari ASPATH. Mencakup dan cocok adalah Valid, mencakup tetapi tidak cocok adalah Invalid, dan tidak ada objek yang mencakup adalah NotFound. Router dapat menolak Invalid dan memperlakukan NotFound sebagai pilihan kebijakan terpisah, tetapi itu tidak memvalidasi seluruh ASPATH atau menyelesaikan setiap kebocoran rute. Saya akan meluncurkan ini dalam mode observasi, memverifikasi cakupan ROA dan panjang maksimum, memantau kebaruan cache serta keterjangkauan, lalu mengaktifkan pemfilteran secara bertahap dengan rencana rollback."
Kesalahan umum
- Gejala → "RPKI memvalidasi seluruh AS_PATH." Mengapa gagal → Penentuan status RFC 6811 hanya membandingkan cakupan prefiks dan origin AS. Perbaikan → Sebut ROV sebagai validasi asal dan sebutkan kontrol terpisah untuk integritas jalur (path integrity).
- Gejala → "Rute tanpa ROA adalah berbahaya/jahat." Mengapa gagal → NotFound berarti tidak ada data yang mencakup, bukan berarti pengumuman tersebut palsu. Perbaikan → Perlakukan NotFound dan Invalid sebagai input kebijakan yang berbeda.
- Gejala → "Pemadaman cache membuat setiap rute menjadi Invalid." Mengapa gagal → Cache terdistribusi bisa saja tidak tersedia atau usang; pemfilteran tiba-tiba dapat memperluas insiden. Perbaikan → Jelaskan pemeriksaan kesehatan cache, penanganan data usang yang aman, dan rollback.
- Gejala → "Mengatur sembarang panjang maksimum ROA." Mengapa gagal → Terlalu pendek akan membatalkan pengumuman more-specific yang sah; terlalu panjang memperluas otorisasi secara berlebihan. Perbaikan → Tentukan maxLength dari kumpulan pengumuman rute yang sebenarnya.
Pertanyaan lanjutan dan tanggapannya
Mengapa rute tanpa ROA berstatus NotFound dan bukan Invalid?
Invalid memerlukan adanya VRP yang mencakup tetapi origin terotorisasinya tidak cocok. Jika tidak ada VRP yang mencakup, statusnya adalah NotFound. Kebijakan dapat memilih cara menangani ketiadaan bukti, tetapi ketiadaan bukti bukanlah bukti dari asal yang buruk.
Apa yang terjadi jika ROA salah dipublikasikan?
Rute yang sah dapat menjadi Invalid dan ditolak oleh tetangga (neighbors) yang ketat. Cabut atau perbaiki ROA, lalu tunggu pembaruan repositori dan cache; pantau perubahan status dan pertahankan jalur rollback kebijakan sementara.
Bisakah RPKI menghentikan kebocoran rute (route leak)?
Belum tentu. ROV hanya memeriksa apakah origin AS diotorisasi; AS tersebut masih dapat menyebarkan prefiks ke tetangga yang tidak diotorisasi. Filter prefiks, peran tetangga (neighbor roles), dan kebijakan ekspor diperlukan untuk mengurangi kebocoran rute.
Bagaimana Anda memverifikasi bahwa pemfilteran tidak merusak keterjangkauan?
Mulai dalam mode pencatatan log dan bandingkan Valid, Invalid, serta NotFound dengan tabel perutean, sembari mengambil sampel ROA dan panjang maksimum. Aktifkan penolakan secara bertahap, pantau probe keterjangkauan, kesehatan cache, sesi tetangga, dan volume Invalid, lalu batalkan kebijakan (rollback) jika ada sinyal yang memburuk.