Názory k článku
Zabezpečení nejdůležitější části nervové soustavy Internetu je tristní

Zase bych z toho nedelal kovbojku - cimz podotykam nerikam, ze by se TCPAO resit nemelo, ale takto podane je to tak trosku jako stavet novou strechu nad barakem, kteremu se soucasne borti nosne steny, protoze ty skutecne problemy jsou dnes proste jinde a jejich systemove reseni tak trosku drhne.

Ono prakticky pripad kolize MD5, ktery by rozbil TCP (BGP) session nahodilym utocnikem popsany snad ani neni - ten utok je spise v teoreticke rovine "a jinde se prokazaly kolize", ono to da stale pomerne dost prace se trefit do 16B digestu spocitaneho z hlavicek, TCP segment dat plus nejakeho hesla. Zvlast pokud nejsou k dispozici on-wire data, coz u BGP relace s jistotou blizici se k urcitosti ani nebudou. Zrovnatak je pomerne komplikovane vzdalene zautocit na relaci zabezpecenou pomoci GTSM - tento utok se v praxi omezuje pouze na zloducha, co je ve stejnem segmentu (IXP). Realny problem s TCP-MD5 je zmena toho hesla za pochodu, bez resetu TCP session se to prakticky udelat neda.

TCPAO (krom toho, ze vendori s implementaci take nespechali) je z pohledu konfigurace slozitejsi, mimojine prave proto, ze byla snaha umoznit rotaci hesla bez nutnosti resetovat TCP session (kterou ale v praxi bude delat minimum lidi). A pokud bychom chteli v abstraktni rovine napadat kolize u MD5, tak SHA1 trpi obdobnym problemem, takze to je samo o sobe jako prejit z blata do louze :-) SHA1 rozhodne za bezpecne povazovane neni, v tom se autor plete, uz pred mnoha lety se od nej utika krom jineho treba i u IPSECu - u TCPAO se jen s vyuzitim SHA1 pouzivaji stejne argumenty, co ja zminuji ve vztahu k MD5. A pouziti lepsich algoritmu drhne... uz na standardech.

Podstatne vetsi a dlouhodoby chronicky problem je prave to, ze si posle kdokoliv cokoliv - a to cokoliv projde casto siroko daleko. Vynechame-li chyby v samotnych implementacich a neumyslne chyby, tak nejvetsim problemem jsou prave unosy prefixu - ty jsou pricinou vetsiny skutecnych incidentu, to je skutecna achilova pata BGP ekosystemu.

Ono jen na to, aby fungovala RPKI validace musi byt dva - vlastnik prefixu, co svuj announcement podepise a pak kazdy provozovatel smerovace, co to zvaliduje. Uz u te publikace route-origin zaznamu ale narazime na to, ze ne kazdy jej vypublikuje - i kdyz v Cesku na tom s nejakymi 65%/63% (IPv4/IPv6) zas tak zle nejsme, celosvetove se bavime o 41/47% prefixu, co jsou takto pokryte - u zbytku proste smula. Mezery se ale najdou stale i u nasi statni spravy - i kdyz v nejjednodussi variante je to o par kliknutich na RIPE. A siti, co opravdu provadi validaci je jeste min.

Navic ani RPKI nezabrani tomu, kdyz nekdo vezme prefix se spravnym origin AS a "jen" ho posle jinudy (a pokusi se tak na sebe pretahnout traffic, co mu nepatri). Cimz nerikam, ze je RPKI zbytecne - neni, ale chrani spise proti neumyslnym lidskym chybam, kdy se vypropaguje jen nejaky fragment z jineho nez spravneho origin ASN. Ale v prostredi, kde spousta siti deagreguje implicitne propaguje nejmensi mozne prefixy (aka /24 v IPv4, pripadne /48 v IPv6) se tem unosum zije pomerne dobre - ono v 920/180 tisicich globalne routovanych IPv4/IPv6 prefixu se jim schovava snadno.

Kolikrát jsem zažil to, že někdo LACP nastavil jen na jednom portu (nebo pro jistotu do jiný vlany, nebo do vlany, co tam není)! Ach..

Celou architekturu switchů bych předělal.

Ať je prostě nemožný to nastavit blbě :))

Tak zrovna pribehu o tom, ze vam jeden bug vendor opravi a s nim rozbije neco jineho pamatuje historie spoustu. Plus dalsi legrace muze byt samotny software - uz v dobach, kdy se z CatOS prechazelo na IOS dost dlouho trvalo, nez tam byla rozumna feature-parity. Novejsi IOS proste nektere veci z CatOSu vubec neumel. A to same se dnes opakuje u NXOS, kdy veci v pohode fungujici na IOSu ten NXOS umi bud s vyraznym zpozdenim, nebo taky vubec... :-)

Na ten jakysi konzervatismus narazite i u vyrobcu - treba zde zminovane TCPAO popsane v RFC z roku 2010 funkcne poprve implementoval Juniper az po 10 letech... ackoliv sami jsou spoluautory predmetneho RFC. A treba v linuxovem kernelu nemate podporu dodnes (pracuje se na ni; ale ve stabilnich vydani podpora neexistuje), freebsd na tom neni o moc lip. A treba opet s NXOS budete mit take smulu (BGP se tam samozrejme tez provozuje). Mikrotik...? Nechte si rovnez zajit chut. Aneb nehazejte vsechno jen na sitare, ono i vyvojari maji jaksi maslo na hlave ;-)

Zkuste obchodní oddělení Internet Info :-)

Však já znám spoustu super chytrých lidí, co to dělají, jen popisuju kulturu, jaká tam často je :)

Důkazem jsou ty statistiky IPv6 a RPKI ve světě.

To, že normální BGP paket z jednoho Cisca shodí druhé Cisco a podobně.. samozřejmě, že znám.

Dělal jsem různé automatizace pro Aristy.
Ani to není bezchybný a moderní design, když se jen plácne Linux s Cisco CLI a Pythonem dohromady.
Bugy mají úplně stejné.

Ono by to chtělo jít asi směrem Cumulus OS.
Nějaká krabice, co třeba bude mít Docker nebo přednastavené VM v sobě na control planu.

Tak, že tam nastavím všechny běžné věci na kliknutí, a rozjede to samo standalone RPKI validátor, spojí se to s ostatníma switchema, bude dělat validaci konfigurace (ať třeba někde svítí BGP bez MD5 jako warning, ať svítí to, že BGP nemá nastavený ACL, ..), nahodí si to vlastní synchronizaci pro všechny settings a bude to mít nějaké templaty pro 90% použití.

Dnes je to strašný mix skriptů a externích služeb, které si většinou člověk musí dodělat sám, pokud jde o velkou síť.

(Faktem je, že tam kde switche umožňovaly třeba stacking, tak se obecně doporučuje proti tomu, protože je to spíš recept, jak si shodit oba dva naráz. Zvlášť s vendor bugem.)

Realita RPKI/filtry: kdyby to bylo “rpki on” a všechno jezdilo jako iPhone, tak to bude všude.

Skutečná realita: musíš udělat službu a někde ji provozovat, musíš generovat config, musí být kompletní a vždycky správně, musíš to integrovat do infra, musíš udělat alerting, musí to nasazování někdo napsat (člověk pak za pár let odejde a tobě zůstane skript v Perlu :D), musí to být komplet fail-safe a sranda na konec: v momentě kdy zákazník blbě podepíše prefix, tak je výpadek.

Reálný short-term benefit je 0, i když bys to nasadit chtěl.

Proto je adoption tak slow.

Pokud je v některých firmách problém předělat IPAM, aby uměl IPv6 subnetting, tak toto je god task.

+ to, jak jsou switche navržené a ty služby, co potřebují by si zasloužilo kompletní refactoring, všechno tam vede k tomu, že se skládá nesourodá komplexita nad komplexitu.

Jestli ono to nebude prave o zkusenostech. Napriklad ma zkusenost asi mesic stara ... Windowsi DNS (2k22) ... zapnuta validace DNSsec (na 2k12 s tim nebyl problem) ... a ... chovalo se to tak, ze cast (rekneme 30%) pozadavku koncila tim, ze timeout. Neprekladalo to dokonce ani nektere vlastni domeny.

Takze si muzu vybrat. Bud budu mit "zabezpeceno" a nefunkcno, nebo ...

Jiny priklad, trochu starsiho data ... aktualizace win srv ... a voiala, zmenilo se uuid = automaticke IPv6 adresy.

Pak proste drive nebo pozdeji kazdy dojde k zaveru, ze nastavit to rucne natvrdo a navzdy je ve skutecnosti zdaleka nejspolehlivejsi zpusob jak to nastavit. Navic v situacich ruznych vypadku nebudete muset resit, ze aby bezelo X musi nejdriv bezet Y, ale to potrebuje Z, ...

Z mých zkušeností: síťaři jsou tak konzervativní, že dotlačit tam cokoliv nad basic config je … opravdu projekt.

Samo o sobě to dokáže být chatrné, každý se bojí, že se něco změní, najde se bug, a přestane to jezdit.

Proto se dávají filtry jen na ty nejjednodušší linky, proto se stále často preferuje všechno mít ideálně staticky místo různých dynamických nadstaveb (ano, jde mít DHCP v datacentru; a sám bych to tak udělal, ale pro 90% síťařů je statika míň scary, musí na to být další HA služba, tím narůstá komplexita, a pak ti to rozbije někdo, kdo v noci blbě přepojí kabel nebo blbou vlanu úplně zbytečně :)

Stejný problém jako s v6. Musel by se totálně re-engineerovat BGP protokol, ať je od základu nutná bezpečná konfigurace.

Protože cokoliv, co je optional, prostě v praxi zůstává optional, aby to bylo pak jednodušší na opravu, když přijdou opravdové problémy.

Druhá věc je archaické CLI těch boxů, nedostatečná znalost configuration managementu u těch lidí oproti tomu, co známe běžně z Linuxu, understaffing…

Aktuálně to úplně nemotivuje k tomu mít tip top best practice config jen pro radost (IPv6 problém) vs snažit se držet uptime v komplexním prostředí.

pěknej prostor - na kolik přišel? :D