Hai, nama saya Alexander Azimov. Di Yandex, saya mengembangkan berbagai sistem pemantauan, serta arsitektur jaringan transportasi. Tapi hari ini kita akan bicara tentang BGP.

Seminggu yang lalu, Yandex memasukkan ROV (Rute Asal Validasi) di persimpangan dengan semua mitra sejawat, serta dengan titik pertukaran lalu lintas. Tentang mengapa ini dilakukan dan bagaimana hal itu akan mempengaruhi interaksi dengan operator telekomunikasi, baca di bawah ini.
BGP dan apa yang salah dengannya
Anda mungkin tahu bahwa BGP dikandung sebagai protokol routing lintas domain. Namun, selama perjalanan, jumlah kasus pengguna berhasil bertambah: hari ini BGP, berkat banyak ekstensi, telah berubah menjadi bus pesan yang mencakup tugas-tugas dari VPN operator ke SD-WAN yang sekarang modis, dan bahkan ditemukan digunakan sebagai transportasi untuk pengontrol seperti SDN, yang berubah vektor jarak BGP menjadi sesuatu yang mirip dengan protokol tautan sate.

Mengapa BGP menerima (dan terus menerima) begitu banyak kegunaan? Ada dua alasan utama:
- BGP adalah satu-satunya protokol yang berfungsi antara sistem otonom (AS);
- BGP mendukung atribut dalam format TLV (tipe-panjang-nilai). Ya, protokolnya tidak sendirian dalam hal ini, tetapi karena tidak ada yang menggantikannya pada sambungan antara operator telekomunikasi, selalu lebih menguntungkan untuk melampirkan satu elemen fungsional lebih banyak daripada mendukung protokol routing tambahan.
Apa yang salah dengannya? Singkatnya, protokol tidak memiliki mekanisme bawaan untuk memverifikasi kebenaran informasi yang diterima. Artinya, BGP adalah protokol kepercayaan apriori: jika Anda ingin memberi tahu dunia bahwa sekarang Anda memiliki jaringan Rostelecom, MTS atau Yandex, tolong!
Filter IRRDB - Yang Terbaik dari yang Terburuk
Muncul pertanyaan - mengapa Internet masih berfungsi dalam situasi seperti itu? Ya, itu berfungsi sebagian besar waktu, tetapi meledak secara berkala, membuat seluruh segmen nasional tidak dapat diakses. Terlepas dari kenyataan bahwa aktivitas peretasan di BGP juga tumbuh, sebagian besar anomali masih terjadi karena kesalahan. Contoh tahun ini adalah
kesalahan seorang operator kecil di Belarus, yang selama setengah jam menjadikan sebagian besar Internet tidak dapat diakses oleh pengguna MegaFon. Contoh lain -
pengoptimal BGP yang marah mematahkan salah satu jaringan CDN terbesar di dunia.

Fig. 2. Cloudflare traffic interception
Tapi tetap saja, mengapa anomali seperti itu terjadi setiap enam bulan, dan tidak setiap hari? Karena operator telekomunikasi menggunakan database informasi perutean eksternal untuk memverifikasi apa yang diperoleh tetangga mereka dari BGP. Ada banyak database seperti itu, beberapa di antaranya dikelola oleh pendaftar (RIPE, APNIC, ARIN, AFRINIC), beberapa adalah pemain independen (yang paling terkenal - RADB), dan ada juga serangkaian pendaftar yang dimiliki oleh perusahaan besar (Level3, NTT, dll.). Berkat database ini, perutean lintas-domain mempertahankan stabilitas relatif dari pekerjaannya.
Namun, ada nuansa. Informasi rute diverifikasi berdasarkan objek ROUTE-OBJECTS dan AS-SET. Dan jika sebelumnya menyiratkan otorisasi pada bagian IRRDB, maka otorisasi tidak ada sebagai kelas untuk kelas kedua. Artinya, siapa pun dapat menambahkan siapa saja ke perangkat mereka dan dengan demikian memintas filter dari pemasok yang lebih tinggi. Selain itu, keunikan penamaan AS-SET antara pangkalan IRR yang berbeda tidak dijamin, yang dapat menyebabkan efek luar biasa dengan hilangnya konektivitas secara tiba-tiba di operator telekomunikasi, yang sebagian tidak mengubah apa pun.
Masalah tambahan adalah model penggunaan AS-SET. Ada dua poin:
- Ketika seorang operator memiliki klien baru, ia menambahkannya ke AS-SET-nya, tetapi hampir tidak pernah menghapusnya;
- Filter sendiri dikonfigurasikan hanya di persimpangan dengan klien.
Akibatnya, format modern dari filter BGP secara bertahap menurunkan filter pada antarmuka dengan pelanggan dan kepercayaan apriori pada apa yang datang dari mitra peer-to-peer dan penyedia transit IP.
Apa yang menggantikan filter awalan berdasarkan AS-SET? Hal yang paling menarik adalah bahwa dalam jangka pendek - tidak ada. Tetapi ada mekanisme tambahan yang melengkapi operasi filter berdasarkan IRRDB, dan pertama-tama, tentu saja, RPKI.
RPKI
Sederhana, Anda dapat membayangkan arsitektur RPKI sebagai basis data terdistribusi yang catatannya dapat diverifikasi secara kriptografis. Dalam kasus ROA (Otorisasi Objek Rute), pemilik ruang alamat adalah penandatangan, dan catatan itu sendiri adalah rangkap tiga (awalan, asn, max_length). Bahkan, entri ini mendalilkan sebagai berikut - pemilik ruang alamat $ awalan mengizinkan AS dengan nomor $ asn untuk mengumumkan awalan dengan panjang tidak lebih dari $ max_length. Dan router, menggunakan cache RPKI, dapat memeriksa kepatuhan dengan sepasang
speaker awalan-pertama saat bepergian .
Gambar 3. Arsitektur RPKI
Objek-ROA telah distandarisasi untuk waktu yang lama, tetapi sampai saat ini, pada kenyataannya, tetap hanya di atas kertas jurnal-IETF. Menurut pendapat saya, alasan untuk ini kedengarannya menakutkan - pemasaran yang buruk. Setelah standardisasi selesai, itu dianggap sebagai insentif yang melindungi ROA terhadap pembajakan BGP - dan itu tidak benar. Penyerang dapat dengan mudah mem-bypass filter ROA dengan memasukkan nomor speaker yang benar di awal jalur. Dan segera setelah kesadaran ini datang, langkah logis berikutnya adalah penolakan terhadap penggunaan ROA. Dan sungguh, mengapa kita membutuhkan teknologi jika itu tidak berhasil?
Mengapa sekarang saatnya untuk berubah pikiran? Karena ini bukan keseluruhan kebenaran. ROA tidak melindungi dari aktivitas peretasan di BGP, tetapi
melindungi terhadap pembajakan lalu lintas yang tidak disengaja , misalnya, dari kebocoran statis di BGP, yang menjadi lebih umum. Selain itu, tidak seperti filter berdasarkan IRR, ROV dapat digunakan tidak hanya pada antarmuka dengan pelanggan, tetapi juga pada antarmuka dengan rekan dan pemasok yang lebih tinggi. Artinya, dengan diperkenalkannya RPKI, BGP secara bertahap meninggalkan kepercayaan apriori.
Sekarang pengecekan rute berbasis ROA secara bertahap diperkenalkan oleh pemain kunci: IXs Eropa terbesar sudah membuang rute yang salah, di antara operator Tier-1 perlu menyoroti AT&T, yang menghidupkan filter di persimpangan dengan mitra yang mengintip. Juga, penyedia konten terbesar cocok untuk shell. Dan lusinan operator transit menengah telah diam-diam mengimplementasikannya, tanpa memberi tahu siapa pun. Mengapa semua operator ini menerapkan RPKI? Jawabannya sederhana: untuk melindungi lalu lintas keluar Anda dari kesalahan orang lain. Itulah sebabnya Yandex adalah salah satu yang pertama di Federasi Rusia untuk memasukkan ROV di perbatasan jaringannya.
Apa yang akan terjadi selanjutnya?
Sekarang kami telah memasukkan memeriksa informasi routing di persimpangan dengan titik pertukaran lalu lintas dan peer-to-peer pribadi. Dalam waktu dekat, verifikasi juga akan disertakan dengan penyedia lalu lintas upstream.

Apa yang berubah bagi Anda? Jika Anda ingin meningkatkan keamanan perutean lalu lintas antara jaringan Anda dan Yandex, sebaiknya:
- Menandatangani ruang alamat Anda di portal RIPE mudah, rata-rata dibutuhkan 5-10 menit. Ini akan melindungi konektivitas kami dengan Anda jika seseorang secara tidak sengaja membajak ruang alamat Anda (dan ini akan terjadi cepat atau lambat);
- Menempatkan salah satu cache RPKI open source (ripe -validator , routinator ) dan mengaktifkan pengecekan rute pada batas jaringan akan membutuhkan waktu lebih lama, tetapi itu tidak akan menyebabkan kesulitan teknis lagi.
Yandex juga mendukung pengembangan sistem penyaringan berdasarkan objek RPKI baru -
ASPA (Autonomous System Provider Authorization). Filter berdasarkan objek ASPA dan ROA tidak hanya dapat menggantikan AS-SET "bocor", tetapi juga menutup serangan MiTM menggunakan BGP.
Saya akan berbicara secara rinci tentang ASPA dalam sebulan di konferensi Next Hop. Juga akan ada rekan dari Netflix, Facebook, Dropbox, Juniper, Mellanox dan Yandex. Jika Anda tertarik dengan tumpukan jaringan dan pengembangannya di masa mendatang - datang,
pendaftaran terbuka .