Letošní komunitní setkání CSNOG zahájil Ignas Bagdonas úvodním seminářem na téma BGPsec v kontextu bezpečnosti směrování. Na něm vysvětlil, co je to BGPsec, jak pomůže zabezpečit směrování v internetu a co brání jeho nasazení do praxe.
Co řeší BGPsec?
BGPspc není úplně nová věc, vlastně už na papíře existuje přes deset let a první myšlenky na zabezpečení směrování se objevily už před dvaceti lety. Pořád máme ale velmi málo praktických zkušeností z nasazení.
Stále jde tedy spíše o experiment, který je velmi živý a neustále se v něm dějí zásadní změny.
Když před třiceti lety vznikal protokol BGP, bylo síťové prostředí velmi přátelské a nebylo potřeba se příliš zabývat bezpečností. Bezpečnost v této oblasti je bohužel problémem dodnes.
Většina bezpečnostní politiky stojí na reputaci jednotlivých sítí a jejich provozovatelů. Představte si, že jsem operátor jménem Charlie Root a začnu oznamovat krásný prefix do internetu. Všichni by ho měli přijmout, protože mám přece skvělou reputaci. Takhle bohužel dnes funguje velká část bezpečnosti.
Velkým problémem je, že oznamovanou informaci není možné ověřit na úrovni registru nebo někde jinde. BGPsec je snahou přinést do routovacích protokolů ověřitelnost, podobně jako to dělá IPsec.
Nejde o nový protokol, ale o doplněk pro BGP. Dokáže vyřešit zejména různé administrátorské chyby, jako když chcete začít oznamovat chybný prefix.
Existuje také celá řada úmyslných útoků, které se snaží například unést známý prefix a provést útok typu man-in-the-middle. Jako příjemce této informace můžete zdroji věřit, ale nemáte jak ověřit, že jsou informace v pořádku. Validace zdroje může pomoci ve většině neúmyslných úniků, ale nezabrání většině únosů. Navíc neřeší konkrétní cestu sítí.
Přidáváme podpisy
BGPsec zavádí kryptograficky bezpečný mechanismus, který vám umožní při přijetí nové informace zjistit, zda je update v pořádku a výsledná síťová cesta je taková, jaká by měla být. Informace jsou uspořádané hierarchicky, musejí se potvrzovat a vy máte jistotu, že nikdo nebyl schopen je po cestě modifikovat nebo něco třeba přidat.
BGPsec stojí na asymetrické kryptografii, kdy má každý směrovač pár klíčů: soukromý si nechá v bezpečném úložišti a veřejný šíří pomocí RPKI. Jakmile pak odesílá aktualizace, šíří také elektronický podpis, který dokáže příjemce ověřit. Tranzitní uzly pak podepisují aktuální AS path, ale také forward AS hop.
Má to svou cenu: router má více práce. S výkonem ovšem nebývá problém, protože chytré implementace mohou využít řadu optimalizací včetně kešování.
Systém elektronických podpisů je stejný, jaký se používá například v HTTPS. Používají se tu algoritmy využívající eliptické křivky a funguje to velmi dobře.
Řeší se tu také stejně problémy: distribuce klíčů, viditelnost různých klíčů v různých pohledech, hierarchie klíčů a podobně. Podstatné je, že BGPsec zajišťuje podepisování, ne šifrování informací.
BGPsec používá nový atribut BGP path BGPsec_PATH, který se ovšem vylučuje s AS_PATH. Není možné zveřejnit jeden update zároveň podepsaný a nepodepsaný.
Je ale možné takto pokrýt jen část informací, některé je pak možné posílat podepsané a jiné ne. Podepsány jsou pouze AS paths, nic jiného.
Při oznamování nové informace pomocí BGPsec je potřeba nejprve použít privátní klíč ve směrovači a podepsat položky: AS path, prefix a targeted ASN. Každý prefix je přitom podepsán samostatně a nový podpis je pak přidán za ty předchozí.
Podpis pak obsahuje také identifikaci veřejného klíče směrovače. Každý podpis je úplně jiný, i když jsou data stejná. Data totiž obsahují náhodně generovanou část, aby nebylo možné z podpisů získat zpět soukromý klíč.
Ověřování podpisů
BGPsec samotný nepoužívá nic jako certifikáty, neřeší tedy vystavování certifikátů, jejich validaci nebo revokaci. Nenese dokonce ani klíč samotný, obsahuje jen jeho identifikaci.
Klíč jako takový je potřeba získat jiným kanálem, pomocí certifikátů z RPKI. Směrovač tedy musí mít přístup k tomuto externímu zdroji veřejných klíčů.
Při ověřování informací je možné k BGPsec přistoupit tak, že podpisy sice přijímáme, ale nemusíme je nutně ověřovat sami. Může to za nás dělat náš upstream, se kterým máme důvěryhodný vztah.
Ověřování podpisů je netriviální operace, která je náročnější než samotné vytváření podpisů. S tím nic nenaděláte, tak je postavena podkladová kryptografie.
Realita je taková, že čím menší jste, tím máte méně výkonný hardware a máte s ověřováním více práce. Proto ji můžete nechat na někom větším, komu věříte, čímž ušetříte výkon vlastního CPU.
Při přijetí informace pomocí BGPsec jsou ověřeny všechny položky obsahující AS path hops a prefixy. Každý AS hop je ověřen samostatně. Cesta je validní, pokud je v pořádku podpis každého hopu.
Veřejné klíče potřebné pro ověření jsou získány z RPKI pomocí protokolu RTR. Výstup celé operace je pak binární: buď je validní nebo nevalidní.
Odkud začít
Podstatné je, že BGPsec má být nasazován na hraničních směrovačích autonomních systémů. Uvnitř vaší infrastruktury se nic nepodepisuje ani neověřuje. Můžete tam provádět třeba inspekci, ale není to potřeba.
BGPsec ovšem může odhalovat informace z vnitřní sítě, protože je vždy vidět celá cesta od zdroje generujícího podpisy, který může být schovaný uvnitř sítě. V čistém BGP to tak typicky není, tam vidíte cestu jen na hranice AS.
Zda je to skutečný problém, záleží na konkrétním návrhu sítě.
Peeringové uzly (Internet exchange, IXP) jsou dobrým místem, kde začít s nasazováním BGPsec. Drží směrování a provoz na lokální úrovní. Vlastně jsou to takové ostrovy, což je ideální pro postupné nasazování BGPsec.
Dá se tu dobře experimentovat, protože počet prefixů tu není obvykle příliš vysoký, takže se nedostanete do problémů s výkonem.
Pro použití BGPsec je potřeba mít podporu ve svém směrovači. Většina implementací je dnes čistě softwarových a jsou open source. Komerční dodavatelé jsou bohužel pozadu, musíte to po nich chtít a hlasovat peněženkou.
Pro praktické nasazení v širokém měřítku ovšem potřebujeme mít k dispozici oba typy implementací.
Jak bude vypadat budoucnost? Buďme realističtí, globální nasazení end to end je zatím nepravděpodobné.
Mnohem pravděpodobnější jsou lokální nasazení, během několika následujících let bychom se ale mohli dočkat prvních větších nasazení. Ke konci této dekády by měl být BGPsec už produkčně velmi dobře nasaditelný.
Nedořešené problémy
Současný návrh protokolu BGPsec není dokonalý, není například optimálně navržen pro běh na současném hardware. Je možné experimentálně prokázat, že zatímco konvergence sítě průměrného peeringového uzlu může proběhnout za minutu, s nasazením BGPsec se doba protáhne na půl hodinu. Samotné podepisování je bez problémů a je velmi rychlé, potíže nám dělá hašování dat, které sice není výpočetně příliš náročné, ale je drahé z pohledu přístupů do paměti.
Při praktickém nasazení je tak možné rychle narazit na výkonnostní limity. To vše jen proto, že je potřeba zbytečně provádět spoustu opakovaného hašování nad stejnými daty.
Mírnou úpravou protokolu je pak možné dosáhnout desetinásobného zrychlení, protože si můžeme celou zbytečnou práci odpustit. Nikdy to nebude zadarmo, kryptografie má vždy svou cenu, kterou musíte zaplatit.
Je tu ale velký prostor k optimalizaci a dalším architektonickým změnám.
Současným největším problémem je, že nemáme žádné skutečné zkušenosti s nasazením BGPsec a budeme potřebovat zavést úpravy. Bohužel není možné zavést změny, aniž byste rozbili předchozí implementace.
Máme ale mnoho nových zkušeností a bude zřejmě potřeba vytvořit nějaký BGPsec2.
