OpenCamp vznikl jako pokračovatel slovenských OSS víkendů a jde o podobný koncept konference jako LinuxDays nebo OpenAlt. Je to jedno z mála podobných setkání na Slovensku, které je úplně otevřené,
řekl na úvod konference Marek Galinský.
Co se dozvíte v článku
Celá akce je postavená na přednáškách přihlášených veřejností, podstatná je možnost setkání. Všechno dělá skupina nadšených přednášejících pro lidi, které tato témata zajímají.
FIIT se snaží dlouhodobě vytvářet prostředí pro setkávání lidí a předávání zkušeností.
Ľubor Jurena: Umělý open-source pankreas
Ľubor je systémový a síťový administrátor, který se přes své onemocnění dostal do komunity snažící se pomáhat si v oblasti diabetu. Onemocnění lidově zvané cukrovka je autoimunitní onemocnění, kdy tělo nemůže správně zpracovávat cukr, který se hromadí v krvi a způsobuje dlouhodobé zdravotní problémy. Léčba je jednoduchá, ale zároveň velmi náročná.
Základem je podávání inzulinu vzhledem k aktuální hladině glukózy v krvi, jídle, aktivitě, stresu a podobně. Každý den je totiž jiný.
Doporučené rozhraní je 3,9 až 10 mmol/l.
Inzulin byl izolovaný v roce 1921 v Torontu, nejprve ze slinivky psů, později z hovězího dobytka a prasat. Už v roce 1922 došlo k prvnímu podání člověku, v roce 1923 získali objevitelé Nobelovu cenu. Jde o jeden z největších úspěchů moderní medicíny.
Inzulin je možné podávat pomocí předplněného pera nebo lékovky. Otázkou ovšem zůstává, kdy podat inzulín. V minulosti jste z kapky krve zjistili pomocí glukometru aktuální hodnotu a podle toho podali inzulín.
Dnes používáme moderní senzory, které dokáží z podkoží průběžně měřit hladinu glukózy a předávat ho pomocí Bluetooth.
Dávkování pak dokáže zajistit takzvaná inzulinová pumpa, což je zařízení, které může neustále dodávat nízké dávky inzulinu do krve. První verze byly ale velmi jednoduché a hloupé. Měli jste senzory a pumpy, které spolu nedokázaly komunikovat.
Čtení dat ze senzorů bylo možné jen ručně pomocí čtečky od vašeho výrobce.
Některé rodiče trápilo, že nedokáží na dálku zjistit hodnoty ze senzorů svého dítěte. Data se dala číst jen na místě a všechno bylo offline.
Proto vznikl projekt Nightscout, který zajišťuje komplexní přenášení dat ze senzoru CGM na server s webovým rozhraním. Stále jde o skvělé řešení, protože je možné měnit senzory různých výrobců a stále ukládat data do jedné databáze.
Nightscout je možné integrovat s různými zobrazovacími zařízeními jako hodinky, telefon, displej v autě a podobně. Má to API, takže si můžete data zobrazit i na zařízeních bez webového prohlížeče.
Takto jsme měli k dispozici data, ale zařízení nebyla nijak propojená a pumpy bylo stále potřeba konfigurovat ručně. V roce 2014 pak vznikl projekt OpenAPS, což je algoritmus pro podávání inzulinu. Původní verze oref0 byla napsaná v JavaScriptu, byla velmi jednoduchá a preferuje bezpečnost před agresivitou. Predikuje například vstřebávání sacharidů a další hodnoty.
V roce 2017 byl představen následovník s názvem oref1, který už uměl automaticky podávat mikrobolusy a každý cyklus rozhodoval o jejich úpravě. Zároveň přišla možnost automatické detekce příjmu potravy podle náhlé změny hodnot. Původní řešení vyžadovalo propojení několika různých zařízení: čtečky hodnot ze senzorů, zařízení pro komunikaci s pumpou, Raspberry Pi pro řízení a power banku pro napájení. Celé jste to museli nosit v batohu a bylo to velmi nepraktické.
V roce 2016 pak Miloš Kozák integroval vše do aplikace pro mobilní telefony a vznikl AndroidAPS, který integruje OpenAPS. Po instalaci musí pacient přejít několikatýdenním testem, kdy každá úroveň odemyká část funkcionality. Některé kroky jsou časově omezené, takže není možné to urychlit.
Nakonec je uživatel edukovaný, má aplikaci správně nastavenou a umí ji používat. AndroidAPS používá Bluetooth a její používání je velmi jednoduché.
AndroidAPS není schválený zdravotnický software, takže jej nenajdete v Google Play. Musíte si stáhnout zdrojové kódy, zkompilovat je, vytvořit APK a poté nahrát do telefonu pomocí sideloadu. Kolem aplikace existuje silná komunita, která vám s celou věci pomůže. Google teď chce zkomplikovat sideloading aplikací kvůli bezpečnosti. Asi to bude stále možné, jde jen o to, jak složité to bude.
Na iOS existuje podobných aplikací více. Například Loop existuje od roku 2016 a má vlastní algoritmus, který sleduje predikovaný vývoj a opravuje předpovědi v reálném čase. Ve Spojených státech vznikl klon pod názvem Tidepool Loop, který je schválenou medicínskou aplikací a může být oficiálně používaný.
Další alternativou je iAPS, který se původně jmenoval FreeAPS X. Hlavní vývojář přišel o svůj účet, ale komunita se postarala o pokračování.
Celý systém je postavený na algoritmech OpenAPS a vývoj je natolik agilní, že nikdo nestačí psát pořádnou dokumentaci. Výhodou je kompletní integrace do ekosystému Apple.
Tento systém má zároveň nejpokročilejší možnosti a nabízí rozšiřující algoritmy a pokročilé matematické funkce. Integrovaná je také možnost rozpoznávání jídel z fotografií pomocí AI.
Konzervativním klonem iAPS je pak Trio, které vychází z toho, že původní iAPS nemusí být bezpečný, protože umožňuje algoritmy nastavovat bez omezení. Proto se pod Nightscout Foundation začalo vyvíjet Trio, které je podobné AndroidAPS a integruje důležité prvky bezpečnosti pro začínající uživatele.
Poté přišly rozšiřující algoritmy, které dovolují lépe reagovat na dynamické potřeby. Upravují vstupy pro oref1.
Lidské tělo totiž funguje tak, že čím je vyšší glykemie, tím tělo hůře reaguje na dávku inzulínu. Tak vznikly algoritmy jako AutoISF a DynISF, které upravují některé vstupní hodnoty pro standardní algoritmy. Cílem je dynamicky řídit potřebu inzulinu, kterou ovlivňuje například nemoc.
Zjišťuje se tak citlivost na inzulin, která se přepočítává v reálném čase na základě aktuální glykémie.
Tyto algoritmy ale stále pracují s tím, že je potřeba relativně přesně vkládat informace o jídle. Proto vznikl algoritmus AutoISF, což je v současnosti nejpokročilejší algoritmus, který vytváří uzavřenou smyčku bez oznamování jídel. Pracuje s akcelerací, odchylky od cíle a času od cíle. Je to algoritmus, který se nepotřebuje dívat na vaši inzulínovou citlivost za posledních 24 hodin, ale sleduje aktuální situaci.
Stále je integrován jen v iAPS a je považován za testovací algoritmus.
Výhodou těchto komunitních systémů je, že mají obrovskou kompatibilitu s mnoha senzory. Android dokáže číst data z jiných aplikací nebo sledovat oznámení, pokud jí to povolíte.
V iOS je podpora a kompatibilita horší, ale s běžně dostupnými senzory je to docela dobré. Podobně dobré je to s pumpami, které jsou propláceny pojišťovnami.
Na přelomu roku 2017 a 2018 začala vznikat i komerční řešení. Jde o naprosto uzavřená řešení, která stojí na konkrétních senzorech a pumpách jednoho výrobce. Ale vše je schváleno jako povolené medicínské zařízení.
Některé systémy se snaží naučit parametry pacienta, ale například během boje s nemocí se dokáží naučit extrémní hodnoty a pak trvá dva týdny, než se vrátí do normálu. Mobilní aplikace k těmto zařízením jsou naprosto tragické, často nefunkční, mají omezenou funkcionalitu a problémy s aktualizacemi.
Všechny tyto systémy se také spoléhají na vstupní údaje od pacienta a není možné je ovládat na dálku.
Zdálo by se, že tyto uzavřené, schválené a certifikované systémy budou bezpečnější. Ukazuje se, že tomu tak není, například firma Medtrum odmítá zveřejnit svoje studie.
Ve Francii bylo schvalování zastaveno, protože tvůrci nedokázali dodržet standardní pravidla pro studie a někteří jejich pacienti skončili v nemocnici. Systém se ale prodává, protože v některém členském státě se to podařilo schválit.
Výhodou je, že máte čtyřiadvacetihodinovou podporu v lokálním jazyce. Chybí ale automatizace a nedochází k úpravám algoritmů podle nejnovějších doporučení.
V open-source světě se dnes řeší především to, jak vše pacientům ulehčit a nutit je otevírat aplikaci co nejméně. Odpovědí je automatizace, která dovoluje nastavit různé profily například podle místa pobytu: v tělocvičně, doma, v autě a podobně. Když pracuji celý den za počítačem, můžu se udržovat na nižších hodnotách, něž když se chystám na nějakou aktivitu.
Je třeba myslet na to, že tyto nástroje mají své legislativní problémy. Nejde o schválené zdravotnické pomůcky, lékař vám je nemůže poskytovat ani nastavovat.
Uživatel přebírá za použití zodpovědnost. Pro lékaře je to ale vlastně výhra, protože takový pacient je poučen a obvykle je správně léčen.
Do budoucna jsou výzvou rozšiřující se silnější šifrování pro komunikaci s pumpami, jazykové překlady aplikací a přicházejí také první pokus se strojovým učením. Objevují se také první komerční systémy postavené na open-source řešeních. Ty není možné certifikovat, protože vývoj je extrémně rychlý a schválení trvá obvykle okolo dvou let.
Problém může v budoucnu způsobit omezení možnosti sideloadingu do zařízení s Androidem nebo iOS. Zatím je to docela jednoduché, uvidíme, jak to bude od listopadu.
Michal Binovský: Základy a praxe optických sítí
V optických sítích se používá poměrně úzké pásmo od 850 nm až po 1600 nm. Jde vlastně o laser, takže je to docela nebezpečné.
Jsou tedy stanovené výkonnostní limity na vysílače, které jsou v řádech mW. Kdybychom pustili více, mohl by nám shořet přijímač v serverovně.
Součástí optické infrastruktury jsou nejrůznější pasivní prvky jako kabely, spojky, splittery nebo chráničky. Optiku je možné do chráničky zafukovat, přičemž se používá speciální lubrikant. Nesmíte používat ten obvyklý, protože ten je založený na vodě a vyschne.
Mezi aktivní prvky pak patří různé přepínače, SFP transceivery, převodníky a zesilovače.
Pro propojování existují různé konektory, rozdělené na UPC a APC. UPC znamená Ultra Physical Connect a poznáme je pomocí modrých konektorů, ve kterých je konec vlákna zaříznutý rovně. APC je Angled Physical Connect a má konektory zelené a vlákno je v nich zaříznuto pod úhlem osm stupňů, což eliminuje zpětné odrazy.
Světlo ve vlákně se pohybuje téměř rychlostí světla a odráží se od různých vrstev ve vlákně, které mají různou hustotu. Jádro má devět mikrometrů a má na sobě obvykle ochranu v podobě barvy. Pro kratší vzdálenosti se používají vlákna typu multimode, které fungují jen na několik jednotek kilometrů. Vlákna typu singlemode pak mohou fungovat na mnoho desítek či stovek kilometrů.
Technik pracující s optikou musí mít svářečku, měřicí přístroj a hlavně lopatu a krumpáč. Je třeba se také nebát, protože někdy je potřeba tahat optiku po sloupech s vysokým napětím.
Pracuje se také v různém počasí a nejrůznějším terénu. Kam nevyjede V3S, tam musejí vybavení vytahat koně.
K propojení vláken je potřeba používat svářečku, dnešní moderní pracují ve třech osách a dokáží samy zarovnat vlákna k sobě. Poté je potřeba mít také měřicí přístroj, který měří zejména útlum a odraz na různých frekvencích. Ty moderní se dokáží připojit přímo k SFP a získat z optické sítě IP adresu.
Důležitá je také pořádkumiluvnost při práci s optikou, protože při nesprávném uložení spojů v kazetě se vše při otevření vysype a oprava trvá čtyřikrát déle. Někdy ze spojky vyteče spousta vody, protože někdo zapomněl při zavírání na těsnění.
Najít v takovém zmatku například červené vlákno k opravě je pak velmi náročné.
Je důležité také nechat všude dost rezervy na kabelu i na vláknech, protože to umožňuje pohodlnější práci. Posunout a vytáhnout odněkud kabel je někdy dost složité.
Svařovat posledních pár desítek centimetrů vlákna je pak také náročné a nebezpečné, protože se může vlákno zlomit a další už k dispozici není.
Marian Rychtecký: Matrix: otevřený standard pro bezpečnou komunikaci
Matrix je open-source standard pro bezpečnou konfiguraci, podobně jako je RFC sada dokumentů pro internetové standardy. Standard pro Matrix se jmenuje MFC, autoři se o něj starají a každý si může přečíst, jak vše funguje a jak to používat. Jde o otevřenou platformu, která je implementovaná v mnoha klientech a několika serverech.
Sdružení NIX.CZ se snaží všechno provozovat ve své režii, má vlastní servery a vlastní infrastrukturu. Nechceme používat cloudová řešení, chceme mít vše u sebe a šifrované.
Hledalo se proto řešení pro rychlou komunikaci, které bude decentralizované a zároveň umožní propojení s dalšími organizacemi.
Cílem bylo získat komunikační kanál pro provozní komunikaci, reakce na incidenty a interní koordinaci. V případě kritické události bychom se chtěli zbavit závislosti na klasických komerčních poskytovatelích.
Požadavkem byl otevřený protokol, možnost federace a šifrování mimo server.
Matrix je otevřený federovaný komunikační protokol, umožňuje decentralizaci při instalaci na vlastní server, umožňuje komunikaci v reálném čase i asynchronní komunikaci. Implementace umějí chatování, ale i VoIP nebo komunikaci pro IoT.
Matrix je velmi podobný staré technologii Jabber, která používala XML, jen dnes Matrix posílá JSON.
Základem infrastruktury je takzvaný Homeserver, což je server ukládající a přeposílající takzvané události (event). Veškeré šifrování se děje na klientech, kteří jsou jediní, kteří rozumějí posílaným zprávám. Server ve výchozím nastavení ukládá jen média jako obrázky, můžeme nastavit i ukládání zpráv.
Na serveru se ale vždy ukládají metadata, takže je možné například zjistit, kdo je ve které skupině.
Federace je dobrovolná a umožňuje předávání zpráv mezi servery. Je možné i říct, s kým chceme federovat a s kým ne.
Je možné to rozhodnout podle adres, jména nebo kryptografického tajemství. Servery si pak pomocí zašifrovaného HTTPS mohou posílat jednotlivé události, ve kterých jsou určitá políčka zašifrovaná. Někteří klienti umožňují zobrazit surové zprávy a někdy je možné i zobrazit dešifrované relevantní položky.
V implementacích serverů je nejdále řešení nazvané Synapse, které je napsané v Pythonu a podle autorů není připraveno na velkou zátěž. Pochopil jsem, že se tím myslí sta tisíce klientů.
Existuje i komerční klon zvaný Dendrite, který je optimalizovaný.
Složitější je to s klientskými aplikacemi, kterých je celá řada. Nejpokročilejší je Element X, který vychází z již nevyvíjeného klienta Element. Není to tak pohodlné, jak jste zvyklí třeba z klientů WhatsApp nebo Telegram.
Software je ale v intenzivním vývoji a velmi rychle se zlepšuje.
Dobře funguje FluffyChat, který v mnoha ohledech funguje lépe než Element X. Nevím, kdo to vyvíjí, ale má blízko k plyšákům. Všechno je tam růžové a veselé.
Uživatelské rozhraní je ale propracovanější a zobrazuje více užitečných informací.
Pro transport zpráv se používá TCP port 443 a standardní HTTPS, na aplikační vrstvě se používá REST a JSON. Tím jsou vyřešeny všechny firewally a proxy.
Komunikace by tedy neměla procházet sítěmi bez problémů.
Jakákoliv komunikace u Matrixu probíhá v místnosti, i když jde o zprávy mezi dvěma uživateli. Jednotlivé zprávy používají Directed Acyclic Graph (DAG), což je kryptograficky ověřitelná a propojitelná řada připomínající „větvený blockchain“. Každá zpráva má svého předka a stav místnosti je deterministický výpočet z událostí. Je možné vždy dokázat, že historie zpráv navazuje.
Je ale problém zprávy smazat, protože by se řetězec přerušil. Aplikace je tedy obvykle jen skryjí.
Každý uživatel může mít více různých zařízení a vystupuje pod svou identitou. Každé zařízení má vlastní pár klíčů a udržuje vlastní kryptografický stav.
Zprávy jsou křížově podepsané, takže ztráta jednoho zařízení neznamená ztrátu identity a je možné zařízení obnovit. Správce může navíc povolit vytvoření master klíče, který je možné si zapsat v podobě sady slov, podobně jako u generovaného klíče pro bitcoin. Na jeho základě je pak možné ze serveru stáhnout hlavní klíč, dešifrovat jej a zařízení tím obnovit.
Pro šifrování se používá kryptografie pomocí protokolu Olm, který pro každou zprávu používá nový klíč. Pro výměnu se používá klíč předaný pomocí algoritmu Diffie-Hellmann, který se ale také jednou za čas sestaví znovu.
Nevýhodou je, že pro práci s historií je potřeba držet mnoho klíčů. Je pak například problém s prohledáváním historie zpráv.
Tohle řešení ale neškáluje pro velké místnosti, protože by bylo potřeba se všemi účastníky navazovat spojení a vyměňovat klíče. Proto vznikl protokol Megolm, který umožňuje pomocí Olm vyjednat jeden společný symetrický klíč pro všechny. Tyhle klíče se nemění tak často a dochází k tomu jen za určitých okolností.
Buď po určitém čase, počtu zpráv, nebo když přijde nový účastník do místnosti. Z toho plyne, že odebraní členové už nemohou číst nové zprávy a nově přidaní členové ve výchozím stavu nevidí historii.
Instalace je překvapivě jednoduchá, stačí nainstalovat balík v Pythonu a připravit konfiguraci v YAML. Celé mi to zabralo jednu hodinu včetně čtení dokumentace.
Uživatelé mohou být vytvořeni manuálně přes CLI, případně je možné používat LDAP, OAuth nebo nabídnout autokonfiguraci, kdy se uživatelé registrují pomocí e-mailu. Je možné také zapnout například federaci.
Při konfiguraci je možné zvolit databázi, včetně SQLite. Tu ale nedoporučuji na produkční provoz, rychle narazíte na zámky databáze a budete čekat desítky sekund na odeslání zprávy.
Mnohem lepší je rovnou zvolit MySQL nebo PostgreSQL. Pro monitoring je možné používat metriky pro Prometheus, přičemž existuje i rozsáhlý dashboard pro Grafanu.
Pro videohovory je možné použít Video RTC, což ale vyžaduje řadu dalších komponent: JWT server pro tokeny, LiveKit pro WebRTC a TURN/STUN server. Dokumentace je ale pěkná, není složité to nastavit.
Klienti si pak naváží RTP stream každý s každým, lze tedy ztišovat jednotlivé protistrany zvlášť a sdílet kromě videa také řadu ploch různých počítačů.
NIX.CZ používá Matrix pro zprávy z monitoringu sítě, komunikaci mezi správci a video hovory. Alarmy z monitoringu je možné posílat například ze Zabbixu, využít je možné nešifrovanou místnost. Pak je to velmi jednoduché, stačí poslat HTTP PUT a přijde to všem a nemusíte nic dalšího dělat.
Existuje knihovna umožňující obsloužit i šifrované místnosti, ale pro některé typy použití to není nutné.
Decentralizace má své nevýhody, na které narazíte během federace. Když se připojíte do velké místnosti, váš server začne kontaktovat všechny servery všech ostatních členů.
Vzniknou tím stovky až tisíce spojení pomocí HTTPS, může vás blokovat firewall a je to velmi náročné na prostředky serveru.
Matrix používají například ke komunikaci členové NATO, Evropská komise ho také zkouší. Jak to dopadne, to nikdo neví, ale když s tím pracují takto velké organizace, něco to znamená.
Řeší se ale šíření metadat ve federované architektuře a legislativa okolo kryptografie a bezpečnosti.
Jozef Mlích: Otevřený svět chytrých hodinek
V alternativních mobilních operačních systémech jako Sailfish OS nebo Ubuntu Touch nejsou k dispozici oficiální aplikace od výrobců chytrých hodinek. Já jsem dostal před několika lety chytré hodinky PineTime a zjistil jsem, že aplikace pro můj telefon neexistuje.
Proto existuje aplikace Amazfish, která dnes už podporuje celou řadu zařízeni i platforem.
Na hodinkách PineTime běží operační systém InfiniTime, je ale možné na nich použít i jiné operační systémy. Na jiných hodinkách je pak možné pustit linuxový systém AsteroidOS, který využívá Qt a je možné jej portovat na hodinky s WearOS. Nevýhodou je, že takové hodinky vydrží jeden až dva dny.
Data se ukládají lokálně, nesynchronizují se a je nutné si je stáhnout přes SSH.
Další možností jsou hodinky Bangle.js, které využívají operační systém Espruino, který obsahuje javascriptový interpret. Je to krásné, velmi jednoduché a dobře se to hackuje.
Toto zařízení má navíc GPS, takže je možné si zaznamenat trasu, ale pak se hodinky vybijí po několika hodinách.
Možné je pořídit také hodinky Lilygo T-Watch, které jsou postavené na ESP32 a nemají příliš dlouhou výdrž na baterii. Operační systém MyTTGO-Watch se snaží být kompatibilní s Espruino.
Zajímavé jsou hodinky Pebble, které nebyly nějakou dobu vyráběny, ale nyní začala jejich opětovná výroba. Ty nejsou podporovány v Amazfish, ale můžete vyzkoušet Rockwork.
Amazfish běží na Saifish OS nebo Ubuntu Touch, ale má to svá úskalí. Například se v Ubuntu Touch definují oprávnění pomocí profilů pro AppArmor. Tady jsme skončili u unconfined, protože existuje spousta oprávnění, na která nejsou profily připravené.
Kromě toho bylo třeba upravit i mapovou aplikaci pro telefon, která jinak nemohla s Amazfish komunikovat.
Pro linuxový desktop existuje varianta aplikace zvaná Kirigami, kterou je možné instalovat pomocí Flatpaku. Na velké obrazovce se ale chová jinak, přeskupují se jinak panely a v desktopu na X.org občas mizejí ikonky.
Amazfish podporuje také sdílení dat na službě Strava, kde ale často unikají citlivá data například z vojenských plavidel. Dá se to udělat lépe? Ano a my už to tak děláme!
Data je v plánu bezpečně ukládat na Endurain nebo FitTrackee a když už sdílet, bude možné to dělat na Fediverse.
Kvalita podpory se liší podle jednotlivých zařízení, existuje matice podpory jednotlivých funkcí na různých hodinkách. Spousta vlastností je ale nebinárních – něco funguje, ale jen částečně.
Oznámení například přijdou, ale už se nesmažou při odkliknutí zprávy na telefonu. Podobně je to s nedokonale podporovanými kalendářovými událostmi, sportovními aktivitami, budíky a podobně.
Marian Rychtecký: RPKI ASPA
V začátcích byla internetová síť malá a komunitní, takže nikdo neměl zájem škodit nikomu dalšímu. Problémy začaly v roce 2008, kdy Pakistan Telecom ukradl omylem IP adresy YouTubu. Byl to omyl, ale vnuklo to některým myšlenku, že to je možné udělat záměrně.
Poté došlo k dalším velkým únikům a začalo se uvažovat o tom, jak podobným problémům předcházet.
Děje se to pořád a všude, na Slovensku třeba bylo za posledních dvanáct měsíců takto zaznamenáno 34 incidentů. Každý ale může postihnout tisíce prefixů, takže může jít o velkou událost.
Data v reálném čase je možné sledovat pomocí služby Cloudflare Radar.
Prvním vyvinutým řešením bylo RPKI, kde regionální registr vydává podepsané zprávy o tom, jaké prefixy mohou být oznamovány ze kterého autonomního systému. Záznam RPKI ROA vygenerujete v LIR Portálu v RIPE, kde jsou záznamy digitálně podepsané a zveřejněné. Pokud nevěříte systémům RIPE, můžete záznamy podepisovat sami a zveřejňovat je pomocí vlastního serveru.
Poté je potřeba, aby hraniční směrovače v sítích tyto informace získávaly, validovaly a používaly při plnění směrovacích tabulek. Dnes je podepsáno přibližně 62 % globálních prefixů, takže je dobré nasazování rozložit do postupných kroků. Ještě před několika lety bylo toto zabezpečení považováno za dostatečné, ale ukázalo se, že je třeba ochránit i celou cestu.
ASPA znamená Autonomous System Provider Authorization a jde o relativně mladý standard pro zabezpečení informací v globální směrovací tabulce. ASPA má za cíl ověřit, jestli cesta internetem je správná a jestli se mezi dva autonomní systémy nevčlenil někdo, kdo by chtěl provoz prohnat svou sítí. ASPA říká, že daný ASN může používat jako svého poskytovatele jen tyto ASN.
Funguje to podobně jako ROA, objekt ASPA se vytváří také v portálu v RIPE. Prohlásíte, které autonomní systémy vám posílají internetový provoz. Tato informace se opět dostane do podepsané zprávy, která je zveřejněna. Validátor si opět stáhne i nové typy záznamů ASPA, rozbalí je, validuje a přes RTR je nahraje do směrovačů. Když pak přijde BGP update, dokáže směrovač ověřit, jestli odpovídá modelu poskytovatel-zákazník.
Při validaci je třeba ověřit, že pro každý ASN je použit jako poskytovatel někdo, kdo se vyskytuje v seznamu poskytovatelů v objektu ASPA. Takové cestě můžeme věřit a můžeme ji přijmout.
Pokud některý ASN nemá uvedené žádné poskytovatele, je stav unknown.
Pokud některý záznam chybí, musíme se podívat i obráceným směrem. My sice neohlašujeme, že daný ASN je poskytovatelem svého souseda, ale může být jeho zákazníkem.
Tomuto stavu se říká cesta bez údolí a je to v pořádku. Snažíme se tedy sestavit orientovaný graf.
Pokud ale zjistíme, že ve zprávě BGP UPDATE existuje ASN, který nemá v ASPA vazbu na souseda ani v jednom směru, považujeme tuto zprávu za neplatnou a nepřijmeme ji. Stejně tak se ale vyhodnocuje, zda cesta udržuje stálý směr nahoru (od zákazníka k poskytovateli) nebo dolů (od poskytovatele k zákazníkovi). Pokud se objeví stav s „údolím“, tedy po cestě jdeme od poskytovatele k zákazníkovi a poté zpět k poskytovateli, považujeme tuto cestu opět za neplatnou.
Každý poskytovatel by si tedy měl připravit seznam svých poskytovatelů a ten zveřejnit v objektu ASPA, podobně jako to teď děláme s ROA. Při validaci v síti je nutný směrovač nebo route server s podporou ASPA. Softwarový směrovač BIRD už má vše implementováno, Cisco a Juniper mají zatím testovací implementaci. Jak se postavíte k výsledku validace, je pak na vás.
S ASPA souvisí rozšíření pro BGP nazvané BGP Roles podle RFC 9234. Při sestavování relace si sousedi řeknou, jaký je jejich vztah.
Může jít o poskytovatele, zákazníka, peera, nebo RS/RS-Client. Toto není ochrana proti úmyslnému únosu, ale proti konfiguračním chybám.
Existuje totiž matice kombinací rolí, které spolu mohou navázat relaci.
Dále je možné do BGP přidat další atribut OTC (Only-To-Customer), který se automaticky přidává k prefixům, které AS šíří svému zákazníkovi. Pokud se takový prefix objeví u peera nebo poskytovatele, je jasné, že je o chybu.
Poznáme tak, že k nám leaknul BGP UPDATE z jiného peeringového uzlu.
Podpora na straně poskytovatelů se postupně rozbíhá, zatím se zveřejňují první záznamy ASPA. Snažíme se to propagovat, zatím se tím zabývají největší nadšenci.
Prozatím totiž vlastně není jak data validovat přímo na směrovačích. Považuji to ale za důležité, protože by se internetová infrastruktura měla chránit.
