Gesaan dan konteks yang berkaitan
Penemu duga menerangkan satu awalan (prefix) yang diumumkan oleh AS yang salah dan bertanyakan cara anda menentukan sama ada pengumuman tersebut dibenarkan oleh pemegang alamat. Terangkan RPKI, Route Origin Authorizations (ROA), dan BGP Prefix Origin Validation (ROV), sambil menyatakan bahawa ROV mengesahkan AS asal (origin AS) dan bukannya keseluruhan AS_PATH. Ini bersesuaian dengan peranan rangkaian, CDN, platform awan, dan infrastruktur.
Perkara yang diuji oleh penemu duga
Jawapan yang mantap bermula dengan "AS mana yang dibenarkan untuk memulakan awalan mana," dan bukannya memanggil RPKI sebagai BGP yang disulitkan. Calon harus menerangkan bagaimana VRP dibandingkan dengan awalan laluan BGP dan origin AS untuk menghasilkan Valid, Invalid, atau NotFound; bagaimana dasar (policy) menggunakan status tersebut; mengapa cache boleh berbeza; dan mengapa menapis Invalid masih boleh menyebabkan kerosakan sampingan (collateral damage). Kenyataan "RPKI menghalang setiap perampasan laluan" menunjukkan bahawa calon terlepas pandang batasannya.
Soalan untuk dijelaskan terlebih dahulu
- Adakah kita melindungi asal awalan atau mengesahkan AS_PATH yang lengkap? ROV hanya menjawab perkara yang pertama.
- Adakah kita membincangkan penerbitan ROA, pengesahan penghala (router), atau penapisan dasar masuk (inbound policy filtering)? Setiap satunya merupakan titik kawalan yang berbeza.
- Adakah kita mempunyai cache ROA berlebihan (redundant) dan dasar gangguan cache yang jelas? Gangguan cache tidak seharusnya secara tiba-tiba menjadikan setiap laluan Invalid.
- Adakah keutamaan diberikan kepada keselamatan, kebolehcapaian (reachability), atau kelajuan pengunduran (rollback)? Penapisan yang ketat memerlukan tetingkap perubahan dan kebolehcerapan (observability).
Jawapan 30 saat
"Saya akan meminta pemegang awalan menerbitkan ROA yang membenarkan origin AS dan panjang awalan maksimum (maximum prefix length). Pengesah (validator) memproses objek yang ditandatangani menjadi VRP, dan pemidato BGP (BGP speaker) membandingkan awalan laluan dan origin AS di sebelah kanan ASPATH: meliputi dan sepadan ialah Valid, meliputi tetapi tidak sepadan ialah Invalid, dan tiada VRP yang meliputi ialah NotFound. Dasar boleh menolak Invalid dan mengendalikan NotFound secara berasingan, tetapi ini melindungi asal, bukan setiap lompatan (hop) ASPATH. Sebelum pelaksanaan, saya akan menyemak liputan ROA, kesegaran cache, pengunduran, dan kebolehcapaian kerana cache teragih boleh menjadi tidak konsisten untuk sementara waktu."
Jawapan mendalam langkah demi langkah
- Takrifkan kebenaran. ROA ialah objek bertandatangan yang mengikat awalan IP, panjang awalan maksimum, dan origin AS yang dibenarkan. Ia menyatakan siapa yang boleh memulakan awalan mana; ia tidak menandatangani setiap atribut BGP.
- Bina data pengesahan. RPKI bergantung pada sijil sumber (resource certificates), objek bertandatangan, dan repositori teragih. Pengesah mengambil dan mengesahkannya secara berkala untuk membina VRP tempatan; pemidato BGP menggunakan cache tempatan dan bukannya melakukan pengesahan sijil penuh bagi setiap laluan.
- Kira tiga status. Sesuatu laluan adalah Valid apabila VRP meliputi awalannya dan sepadan dengan origin AS-nya; Invalid apabila wujud VRP yang meliputi tetapi tiada yang sepadan; dan NotFound apabila tiada VRP yang meliputi awalan tersebut. Laluan yang lebih khusus (more-specific) masih perlu memenuhi panjang maksimum ROA.
- Sambungkan dasar. Dasar masuk boleh memadankan status: biasanya menolak Invalid, merekodkan log atau merendahkan kepercayaan untuk NotFound, dan menerima Valid. Pastikan dasar boleh diundur balik (reversible) supaya ROA yang silap atau masalah cache tidak menimbulkan gangguan besar.
- Nyatakan batasan cache. RFC 6811 menerangkan RPKI global sebagai pandangan teragih yang konsisten secara longgar (loosely consistent); cache boleh berbeza buat sementara waktu kerana ia disegarkan pada masa yang berlainan. Pantau cap masa VRP, sesi cache, dan pengagihan status daripada terus melabelkan amaran laluan sebagai serangan serta-merta.
- Terangkan batasan perlindungan. ROV boleh mengurangkan asal yang salah dan beberapa perampasan laluan; NIST menyifatkannya sebagai platform berasaskan piawaian untuk mengurangkan salah konfigurasi dan serangan berniat jahat yang berkaitan. Ia tidak membuktikan bahawa AS perantaraan bertindak dengan betul dan tidak boleh dengan sendirinya menghentikan setiap kebocoran laluan (route leak).
- Rancang pelaksanaan yang selamat. Mulakan dalam mod pemerhatian, periksa Invalid dan NotFound, serta dayakan penolakan untuk set jiran yang kecil. Sebelum setiap perubahan, sahkan panjang maksimum ROA, pengumuman berlebihan, dan arahan pengunduran. Selepas itu, pantau kebolehcapaian, volum Invalid, kesihatan cache, dan kelewatan amaran.
Contoh jawapan berkualiti tinggi
"Saya akan membahagikan masalah ini kepada kebenaran, pengesahan, dan dasar. Pemegang awalan menerbitkan ROA yang menamakan origin AS yang dibenarkan dan panjang awalan maksimum. Pengesah RPKI menyemak objek bertandatangan dan menghasilkan VRP; pemidato BGP membandingkan setiap awalan yang diterima dengan origin AS daripada ASPATH. Meliputi dan sepadan ialah Valid, meliputi tetapi tidak sepadan ialah Invalid, dan tiada objek yang meliputi ialah NotFound. Penghala boleh menolak Invalid dan menganggap NotFound sebagai pilihan dasar yang berasingan, tetapi langkah itu tidak mengesahkan keseluruhan ASPATH atau menyelesaikan setiap kebocoran laluan. Saya akan melaksanakannya dalam mod pemerhatian, mengesahkan liputan ROA dan panjang maksimum, memantau kesegaran cache serta kebolehcapaian, kemudian mendayakan penapisan secara beransur-ansur dengan pelan pengunduran."
Kesilapan biasa
- Gejala → "RPKI mengesahkan keseluruhan AS_PATH." Sebab ia gagal → Status RFC 6811 hanya membandingkan liputan awalan dan origin AS. Penyelesaian → Panggil ROV sebagai pengesahan asal dan namakan kawalan berasingan bagi integriti laluan.
- Gejala → "Laluan tanpa ROA adalah berniat jahat." Sebab ia gagal → NotFound bermaksud tiada data yang meliputi, bukan bermaksud pengumuman itu palsu. Penyelesaian → Anggap NotFound dan Invalid sebagai input dasar yang berbeza.
- Gejala → "Gangguan cache menjadikan setiap laluan Invalid." Sebab ia gagal → Cache teragih mungkin tidak tersedia atau lapuk; penapisan secara mendadak boleh membesarkan insiden. Penyelesaian → Terangkan semakan kesihatan cache, pengendalian data lapuk yang selamat, dan pengunduran.
- Gejala → "Menetapkan sebarang panjang maksimum ROA." Sebab ia gagal → Terlalu pendek membatalkan pengumuman more-specific yang sah; terlalu panjang meluaskan kebenaran secara berlebihan. Penyelesaian → Dapatkan maxLength daripada set pengumuman sebenar.
Soalan susulan dan jawapan
Mengapa laluan tanpa ROA berstatus NotFound dan bukannya Invalid?
Invalid memerlukan VRP yang meliputi yang mana asal yang dibenarkan tidak sepadan. Tanpa sebarang VRP yang meliputi, statusnya ialah NotFound. Dasar boleh memilih cara mengendalikan ketiadaan bukti, tetapi ketiadaan bukti bukanlah bukti bagi asal yang tidak sah.
Apakah yang berlaku apabila ROA diterbitkan secara salah?
Laluan yang sah boleh menjadi Invalid dan ditolak oleh jiran yang ketat. Batalkan atau betulkan ROA, kemudian tunggu penyegaran repositori dan cache; pantau perubahan status dan kekalkan laluan pengunduran dasar sementara.
Bolehkah RPKI menghentikan kebocoran laluan (route leak)?
Tidak semestinya. ROV memeriksa sama ada origin AS dibenarkan; AS tersebut masih boleh menyebarkan awalan kepada jiran yang tidak dibenarkan. Penapis awalan, peranan jiran (neighbor roles), dan dasar eksport diperlukan untuk mengurangkan kebocoran laluan.
Bagaimanakah anda mengesahkan bahawa penapisan tidak menjejaskan kebolehcapaian?
Mulakan dalam mod pengelogan dan bandingkan Valid, Invalid, serta NotFound dengan jadual penghalaan, sambil menyampel ROA dan panjang maksimum. Dayakan penolakan secara kelompok, perhatikan prob kebolehcapaian, kesihatan cache, sesi jiran, dan volum Invalid, serta undurkan dasar sekiranya sebarang isyarat merosot.