Yandex ປະຕິບັດ RPKI

ສະບາຍດີ, ຂ້ອຍຊື່ Alexander Azimov. ຢູ່ Yandex, ຂ້ອຍພັດທະນາລະບົບການຕິດຕາມຕ່າງໆ, ເຊັ່ນດຽວກັນກັບສະຖາປັດຕະຍະກໍາເຄືອຂ່າຍການຂົນສົ່ງ. ແຕ່ມື້ນີ້ພວກເຮົາຈະສົນທະນາກ່ຽວກັບພິທີການ BGP.

ອາທິດກ່ອນຫນ້ານີ້, Yandex ໄດ້ເປີດໃຊ້ ROV (Route Origin Validation) ຢູ່ໃນການໂຕ້ຕອບກັບຄູ່ຄ້າທັງຫມົດ, ເຊັ່ນດຽວກັນກັບຈຸດແລກປ່ຽນການຈະລາຈອນ. ອ່ານຂ້າງລຸ່ມນີ້ກ່ຽວກັບວ່າເປັນຫຍັງອັນນີ້ຈຶ່ງຖືກເຮັດ ແລະມັນຈະສົ່ງຜົນກະທົບຕໍ່ການຕິດຕໍ່ພົວພັນກັບຜູ້ປະກອບການໂທລະຄົມແນວໃດ.

BGP ແລະສິ່ງທີ່ຜິດພາດກັບມັນ

ທ່ານອາດຈະຮູ້ວ່າ BGP ຖືກອອກແບບມາເປັນໂປໂຕຄອນການກໍານົດເສັ້ນທາງລະຫວ່າງໂດເມນ. ຢ່າງໃດກໍຕາມ, ໃນໄລຍະທາງ, ຈໍານວນຂອງກໍລະນີການນໍາໃຊ້ທີ່ຄຸ້ມຄອງການຂະຫຍາຍຕົວ: ໃນມື້ນີ້, BGP, ຂໍຂອບໃຈກັບການຂະຫຍາຍຈໍານວນຫລາຍ, ໄດ້ຫັນເປັນລົດເມຂໍ້ຄວາມ, ກວມເອົາວຽກງານຈາກຜູ້ປະກອບການ VPN ກັບ SD-WAN ຄົນອັບເດດ: ໃນປັດຈຸບັນ, ແລະຍັງພົບເຫັນຄໍາຮ້ອງສະຫມັກເປັນ. ການຂົນສົ່ງສໍາລັບຕົວຄວບຄຸມທີ່ຄ້າຍຄືກັບ SDN, ປ່ຽນ vector BGP ໄລຍະທາງເປັນບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນກັບ links sat protocol.

ຊາວ. . 1. BGP SAFI

ເປັນຫຍັງ BGP ໄດ້ຮັບ (ແລະສືບຕໍ່ໄດ້ຮັບ) ການນໍາໃຊ້ຫຼາຍ? ມີສອງເຫດຜົນຕົ້ນຕໍ:

• BGP ແມ່ນໂປໂຕຄອນດຽວທີ່ເຮັດວຽກລະຫວ່າງລະບົບປົກຄອງຕົນເອງ (AS);
• BGP ຮອງຮັບຄຸນລັກສະນະໃນຮູບແບບ TLV (type-length-value). ແມ່ນແລ້ວ, ໂປໂຕຄອນບໍ່ໄດ້ຢູ່ຄົນດຽວໃນເລື່ອງນີ້, ແຕ່ເນື່ອງຈາກວ່າບໍ່ມີຫຍັງທີ່ຈະທົດແທນມັນຢູ່ໃນຈຸດເຊື່ອມຕໍ່ລະຫວ່າງຜູ້ປະຕິບັດການໂທລະຄົມ, ມັນສະເຫມີໄປທີ່ຈະມີກໍາໄລຫຼາຍທີ່ຈະຕິດອົງປະກອບທີ່ເປັນປະໂຫຍດອື່ນໆກັບມັນກ່ວາການສະຫນັບສະຫນູນການກໍານົດເສັ້ນທາງເພີ່ມເຕີມ.

ລາວແມ່ນຫຍັງ? ໃນສັ້ນ, ໂປໂຕຄອນບໍ່ມີກົນໄກການກໍ່ສ້າງໃນການກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນທີ່ໄດ້ຮັບ. ນັ້ນແມ່ນ, BGP ເປັນໂປໂຕຄອນຄວາມໄວ້ວາງໃຈຂອງ priori: ຖ້າທ່ານຕ້ອງການບອກໂລກວ່າຕອນນີ້ເຈົ້າເປັນເຈົ້າຂອງເຄືອຂ່າຍຂອງ Rostelecom, MTS ຫຼື Yandex, ກະລຸນາ!

ຕົວກອງທີ່ອີງໃສ່ IRRDB - ດີທີ່ສຸດຂອງທີ່ຮ້າຍແຮງທີ່ສຸດ

ຄໍາຖາມທີ່ເກີດຂື້ນ: ເປັນຫຍັງອິນເຕີເນັດຍັງເຮັດວຽກຢູ່ໃນສະຖານະການດັ່ງກ່າວ? ແມ່ນແລ້ວ, ມັນເຮັດວຽກເກືອບທຸກເວລາ, ແຕ່ໃນເວລາດຽວກັນມັນລະເບີດເປັນແຕ່ລະໄລຍະ, ເຮັດໃຫ້ພາກສ່ວນແຫ່ງຊາດທັງຫມົດບໍ່ສາມາດເຂົ້າຫາໄດ້. ເຖິງແມ່ນວ່າກິດຈະກໍາຂອງແຮກເກີໃນ BGP ຍັງເພີ່ມຂຶ້ນ, ຄວາມຜິດປົກກະຕິສ່ວນໃຫຍ່ແມ່ນຍັງເກີດຈາກແມງໄມ້. ຕົວຢ່າງຂອງປີນີ້ແມ່ນ ຄວາມຜິດພາດຜູ້ປະຕິບັດການຂະຫນາດນ້ອຍ ໃນເບລາຣູດ, ເຊິ່ງເຮັດໃຫ້ສ່ວນຫນຶ່ງທີ່ສໍາຄັນຂອງອິນເຕີເນັດບໍ່ສາມາດເຂົ້າເຖິງຜູ້ໃຊ້ MegaFon ເປັນເວລາເຄິ່ງຊົ່ວໂມງ. ຕົວຢ່າງອີກອັນຫນຶ່ງ - Crazy BGP optimizer ທໍາລາຍຫນຶ່ງໃນເຄືອຂ່າຍ CDN ທີ່ໃຫຍ່ທີ່ສຸດໃນໂລກ.

ເຂົ້າ. 2. ການຂັດຂວາງການຈະລາຈອນ Cloudflare

ແຕ່ຢ່າງໃດກໍ່ຕາມ, ເປັນຫຍັງຄວາມຜິດປົກກະຕິດັ່ງກ່າວເກີດຂຶ້ນທຸກໆຫົກເດືອນ, ແລະບໍ່ແມ່ນທຸກໆມື້? ເນື່ອງຈາກວ່າຜູ້ໃຫ້ບໍລິການໃຊ້ຖານຂໍ້ມູນພາຍນອກຂອງຂໍ້ມູນເສັ້ນທາງເພື່ອກວດສອບສິ່ງທີ່ພວກເຂົາໄດ້ຮັບຈາກເພື່ອນບ້ານ BGP. ມີຖານຂໍ້ມູນດັ່ງກ່າວຈໍານວນຫຼາຍ, ບາງສ່ວນຂອງພວກເຂົາຖືກຄຸ້ມຄອງໂດຍຜູ້ລົງທະບຽນ (RIPE, APNIC, ARIN, AFRINIC), ບາງຄົນແມ່ນຜູ້ຫຼິ້ນເອກະລາດ (ທີ່ມີຊື່ສຽງທີ່ສຸດແມ່ນ RADB), ແລະຍັງມີຊຸດທະບຽນທັງຫມົດເປັນເຈົ້າຂອງໂດຍບໍລິສັດຂະຫນາດໃຫຍ່ (Level3. , NTT, ແລະອື່ນໆ). ມັນແມ່ນຂໍຂອບໃຈກັບຖານຂໍ້ມູນເຫຼົ່ານີ້ທີ່ເສັ້ນທາງລະຫວ່າງໂດເມນຮັກສາຄວາມຫມັ້ນຄົງຂອງການດໍາເນີນງານຂອງມັນ.

ຢ່າງໃດກໍຕາມ, ມີ nuances. ຂໍ້ມູນການກຳນົດເສັ້ນທາງຖືກກວດສອບໂດຍອ້າງອີງຈາກວັດຖຸ ROUTE-OBJECTS ແລະ AS-SET. ແລະຖ້າຫາກວ່າທໍາອິດຫມາຍເຖິງການອະນຸຍາດສໍາລັບສ່ວນຫນຶ່ງຂອງ IRRDB, ຫຼັງຈາກນັ້ນສໍາລັບຊັ້ນທີສອງບໍ່ມີການອະນຸຍາດເປັນຫ້ອງຮຽນ. ນັ້ນແມ່ນ, ທຸກຄົນສາມາດເພີ່ມໃຜໃສ່ຊຸດຂອງພວກເຂົາແລະໂດຍວິທີນີ້ຂ້າມຕົວກອງຂອງຜູ້ໃຫ້ບໍລິການຕົ້ນນ້ໍາ. ຍິ່ງໄປກວ່ານັ້ນ, ຄວາມເປັນເອກະລັກຂອງການຕັ້ງຊື່ AS-SET ລະຫວ່າງຖານ IRR ທີ່ແຕກຕ່າງກັນແມ່ນບໍ່ຮັບປະກັນ, ເຊິ່ງສາມາດນໍາໄປສູ່ຜົນກະທົບທີ່ຫນ້າປະຫລາດໃຈກັບການສູນເສຍການເຊື່ອມຕໍ່ຢ່າງກະທັນຫັນສໍາລັບຜູ້ປະຕິບັດງານໂທລະຄົມ, ຜູ້ທີ່, ສໍາລັບສ່ວນຫນຶ່ງຂອງລາວ, ບໍ່ໄດ້ປ່ຽນແປງຫຍັງ.

ສິ່ງທ້າທາຍເພີ່ມເຕີມແມ່ນຮູບແບບການນໍາໃຊ້ຂອງ AS-SET. ມີສອງຈຸດຢູ່ທີ່ນີ້:

• ເມື່ອຜູ້ປະກອບການໄດ້ຮັບລູກຄ້າໃຫມ່, ມັນເພີ່ມມັນໃສ່ AS-SET, ແຕ່ເກືອບບໍ່ເຄີຍເອົາມັນອອກ;
• ຕົວກອງຕົວມັນເອງຖືກຕັ້ງຄ່າພຽງແຕ່ຢູ່ໃນການໂຕ້ຕອບກັບລູກຄ້າ.

ດັ່ງນັ້ນ, ຮູບແບບທີ່ທັນສະໄຫມຂອງການກັ່ນຕອງ BGP ປະກອບດ້ວຍຕົວກອງທີ່ຄ່ອຍໆຫຼຸດລົງໃນການໂຕ້ຕອບກັບລູກຄ້າແລະຄວາມໄວ້ວາງໃຈຂອງ priori ໃນສິ່ງທີ່ມາຈາກຄູ່ຮ່ວມງານ peering ແລະຜູ້ໃຫ້ບໍລິການຂົນສົ່ງ IP.

ການທົດແທນຕົວກອງຄໍານໍາຫນ້າໂດຍອີງໃສ່ AS-SET ແມ່ນຫຍັງ? ສິ່ງທີ່ຫນ້າສົນໃຈທີ່ສຸດແມ່ນວ່າໃນໄລຍະສັ້ນ - ບໍ່ມີຫຍັງ. ແຕ່ກົນໄກເພີ່ມເຕີມແມ່ນປະກົດຂຶ້ນທີ່ເສີມການເຮັດວຽກຂອງຕົວກອງທີ່ອີງໃສ່ IRRDB, ແລະທໍາອິດ, ແນ່ນອນ, ນີ້ແມ່ນ RPKI.

RPKI

ໃນທາງທີ່ງ່າຍດາຍ, ສະຖາປັດຕະຍະກໍາ RPKI ສາມາດຖືກຄິດວ່າເປັນຖານຂໍ້ມູນທີ່ແຈກຢາຍເຊິ່ງບັນທຶກສາມາດກວດສອບໄດ້ cryptographically. ໃນກໍລະນີຂອງ ROA (Route Object Authorization), ຜູ້ເຊັນແມ່ນເຈົ້າຂອງພື້ນທີ່ທີ່ຢູ່, ແລະບັນທຶກຕົວມັນເອງເປັນ triple (prefix, asn, max_length). ໂດຍພື້ນຖານແລ້ວ, ຂໍ້ມູນນີ້ສະແດງເຖິງສິ່ງຕໍ່ໄປນີ້: ເຈົ້າຂອງຊ່ອງທີ່ຢູ່ຂອງ $prefix ໄດ້ອະນຸຍາດໃຫ້ຈໍານວນ AS $asn ໂຄສະນາຄໍານໍາຫນ້າທີ່ມີຄວາມຍາວບໍ່ເກີນ $max_length. ແລະ routers, ການນໍາໃຊ້ cache RPKI, ສາມາດກວດສອບຄູ່ສໍາລັບການປະຕິບັດຕາມ prefix - ລໍາໂພງທໍາອິດທີ່ທາງ.

ຮູບ 3. ສະຖາປັດຕະຍະກໍາ RPKI

ວັດຖຸ ROA ໄດ້ຮັບມາດຕະຖານເປັນເວລາດົນນານ, ແຕ່ຈົນກ່ວາບໍ່ດົນມານີ້, ຕົວຈິງແລ້ວພວກມັນຍັງຄົງຢູ່ໃນເຈ້ຍໃນວາລະສານ IETF ເທົ່ານັ້ນ. ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ເຫດຜົນສໍາລັບການນີ້ສຽງທີ່ຫນ້າຢ້ານກົວ - ການຕະຫຼາດທີ່ບໍ່ດີ. ຫຼັງຈາກການສ້າງມາດຕະຖານໄດ້ສໍາເລັດ, ແຮງຈູງໃຈແມ່ນວ່າ ROA ໄດ້ປ້ອງກັນການລັກລອບ BGP - ເຊິ່ງບໍ່ແມ່ນຄວາມຈິງ. ຜູ້ໂຈມຕີສາມາດຂ້າມຕົວກອງທີ່ອີງໃສ່ ROA ໄດ້ຢ່າງງ່າຍດາຍໂດຍການໃສ່ເລກ AC ທີ່ຖືກຕ້ອງໃນຕອນເລີ່ມຕົ້ນຂອງເສັ້ນທາງ. ແລະທັນທີທີ່ຄວາມເປັນຈິງນີ້ມາຮອດ, ຂັ້ນຕອນຢ່າງມີເຫດຜົນຕໍ່ໄປແມ່ນການປະຖິ້ມການໃຊ້ ROA. ແທ້ຈິງແລ້ວ, ເປັນຫຍັງພວກເຮົາຕ້ອງການເຕັກໂນໂລຢີຖ້າມັນບໍ່ເຮັດວຽກ?

ເປັນຫຍັງມັນເຖິງເວລາທີ່ຈະປ່ຽນໃຈຂອງເຈົ້າ? ເນື່ອງຈາກວ່ານີ້ບໍ່ແມ່ນຄວາມຈິງທັງຫມົດ. ROA ບໍ່ໄດ້ປ້ອງກັນກິດຈະກໍາຂອງແຮກເກີໃນ BGP, ແຕ່ ປ້ອງກັນການລັກລອບການຈະລາຈອນໂດຍບັງເອີນ, ສໍາລັບການຍົກຕົວຢ່າງຈາກການຮົ່ວໄຫຼ static ໃນ BGP, ເຊິ່ງກາຍເປັນທົ່ວໄປຫຼາຍ. ນອກຈາກນີ້, ບໍ່ເຫມືອນກັບຕົວກອງທີ່ອີງໃສ່ IRR, ROV ສາມາດຖືກນໍາໃຊ້ບໍ່ພຽງແຕ່ຢູ່ໃນການໂຕ້ຕອບກັບລູກຄ້າ, ແຕ່ຍັງຢູ່ໃນການໂຕ້ຕອບກັບເພື່ອນມິດແລະຜູ້ໃຫ້ບໍລິການທາງນ້ໍາ. ນັ້ນແມ່ນ, ຄຽງຄູ່ກັບການແນະນໍາຂອງ RPKI, ຄວາມໄວ້ວາງໃຈຂອງ priori ແມ່ນຄ່ອຍໆຫາຍໄປຈາກ BGP.

ໃນປັດຈຸບັນ, ການກວດສອບເສັ້ນທາງໂດຍອີງໃສ່ ROA ແມ່ນຄ່ອຍໆຖືກປະຕິບັດໂດຍຜູ້ຫຼິ້ນທີ່ສໍາຄັນ: ເອີຣົບທີ່ໃຫຍ່ທີ່ສຸດ IX ກໍາລັງຍົກເລີກເສັ້ນທາງທີ່ບໍ່ຖືກຕ້ອງໃນບັນດາຜູ້ປະຕິບັດການ Tier-1, ມັນເປັນມູນຄ່າທີ່ຈະເນັ້ນໃສ່ AT&T, ເຊິ່ງໄດ້ເປີດໃຊ້ຕົວກອງໃນການໂຕ້ຕອບກັບຄູ່ຮ່ວມມືຂອງຕົນ. ຜູ້ໃຫ້ບໍລິການເນື້ອຫາທີ່ໃຫຍ່ທີ່ສຸດແມ່ນຍັງເຂົ້າຫາໂຄງການ. ແລະຜູ້ປະກອບການຂົນສົ່ງຂະຫນາດກາງຫຼາຍສິບແຫ່ງໄດ້ປະຕິບັດມັນຢ່າງງຽບໆ, ໂດຍບໍ່ມີການບອກໃຜກ່ຽວກັບມັນ. ເປັນຫຍັງຜູ້ປະກອບການທັງຫມົດເຫຼົ່ານີ້ປະຕິບັດ RPKI? ຄໍາຕອບແມ່ນງ່າຍດາຍ: ເພື່ອປົກປ້ອງການຈະລາຈອນຂາອອກຂອງທ່ານຈາກຄວາມຜິດພາດຂອງຄົນອື່ນ. ນັ້ນແມ່ນເຫດຜົນທີ່ Yandex ເປັນຫນຶ່ງໃນທໍາອິດໃນສະຫະພັນລັດເຊຍທີ່ຈະລວມເອົາ ROV ຢູ່ໃນຂອບຂອງເຄືອຂ່າຍຂອງຕົນ.

ຈະມີຫຍັງເກີດຂື້ນຕໍ່ໄປ?

ຕອນນີ້ພວກເຮົາໄດ້ເປີດໃຊ້ການກວດສອບຂໍ້ມູນເສັ້ນທາງຢູ່ໃນສ່ວນຕິດຕໍ່ກັບຈຸດແລກປ່ຽນການຈະລາຈອນ ແລະຂໍ້ມູນສ່ວນຕົວ. ໃນອະນາຄົດອັນໃກ້ນີ້, ການຢັ້ງຢືນຍັງຈະຖືກເປີດໃຊ້ກັບຜູ້ໃຫ້ບໍລິການການຈະລາຈອນທາງເທິງ.

ຄວາມແຕກຕ່າງນີ້ເຮັດໃຫ້ເຈົ້າມີຫຍັງແດ່? ຖ້າທ່ານຕ້ອງການເພີ່ມຄວາມປອດໄພຂອງເສັ້ນທາງການຈະລາຈອນລະຫວ່າງເຄືອຂ່າຍຂອງທ່ານແລະ Yandex, ພວກເຮົາແນະນໍາ:

• ເຊັນຊື່ພື້ນທີ່ທີ່ຢູ່ຂອງທ່ານ ຢູ່ໃນປະຕູ RIPE - ມັນງ່າຍດາຍ, ໃຊ້ເວລາ 5-10 ນາທີໂດຍສະເລ່ຍ. ນີ້ຈະປົກປ້ອງການເຊື່ອມຕໍ່ຂອງພວກເຮົາໃນກໍລະນີທີ່ມີຄົນລັກເອົາພື້ນທີ່ທີ່ຢູ່ຂອງເຈົ້າໂດຍບໍ່ຕັ້ງໃຈ (ແລະແນ່ນອນຈະເກີດຂຶ້ນໄວຫຼືຫຼັງຈາກນັ້ນ);
• ຕິດຕັ້ງຫນຶ່ງຂອງແຫຼ່ງເປີດ RPKI cache (ripe-validator, ຜູ້ປະຈຳການ) ແລະເປີດໃຊ້ການກວດສອບເສັ້ນທາງຢູ່ຊາຍແດນເຄືອຂ່າຍ - ນີ້ຈະໃຊ້ເວລາຫຼາຍ, ແຕ່ອີກເທື່ອຫນຶ່ງ, ມັນຈະບໍ່ເຮັດໃຫ້ເກີດຄວາມຫຍຸ້ງຍາກດ້ານວິຊາການ.

Yandex ຍັງສະຫນັບສະຫນູນການພັດທະນາລະບົບການກັ່ນຕອງໂດຍອີງໃສ່ວັດຖຸ RPKI ໃຫມ່ - ASPA (ການອະນຸຍາດຜູ້ໃຫ້ບໍລິການລະບົບອັດຕະໂນມັດ). ການກັ່ນຕອງໂດຍອີງໃສ່ວັດຖຸ ASPA ແລະ ROA ບໍ່ພຽງແຕ່ສາມາດທົດແທນ "ຮົ່ວ" AS-SETs, ແຕ່ຍັງປິດບັນຫາຂອງການໂຈມຕີ MiTM ໂດຍໃຊ້ BGP.

ຂ້າພະເຈົ້າຈະສົນທະນາຢ່າງລະອຽດກ່ຽວກັບ ASPA ໃນເດືອນຫນຶ່ງໃນກອງປະຊຸມ Hop ຕໍ່ໄປ. ເພື່ອນຮ່ວມງານຈາກ Netflix, Facebook, Dropbox, Juniper, Mellanox ແລະ Yandex ຍັງຈະເວົ້າຢູ່ທີ່ນັ້ນ. ຖ້າທ່ານສົນໃຈໃນເຄືອຂ່າຍ stack ແລະການພັດທະນາຂອງມັນໃນອະນາຄົດ, ມາ ເປີດລົງທະບຽນແລ້ວ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com