Novou zkratkou, kterou bylo často slyšet v kuloárech vancouverského meetingu IETF, je IRS. Cílem této iniciativy je, jak už název napovídá, standardizované rozhraní pro přístup do „střev“ IP směrovačů. Toto rozhraní má zprostředkovat externím softwarovým aplikacím poměrně detailní náhled do stavu směrovacího subsystému, ale také umožnit přímé zásahy do směrování a modifikace směrovacích tabulek (RIB) a dalších datových struktur, například LFIB (pro MPLS) a multicast RIB.
Více informací o IRS lze prozatím získat ze dvou Internet draftů:
- draft-atlas-its-problem-statement-00 identifikuje obecné problémy, které má IRS v budoucnu řešit, a též zdůvodňuje, proč jsou stávající řešení nedostatečná;
- draft-ward-irs-framework-00 obsahuje rámcový popis architektury IRS a jeho funkcí.
Oba dokumenty lze těžko obvinit z přílišné skromnosti, pokud jde o šíři očekávaných aplikací. Autoři předpokládají nasazení IRS jak pro monitoring a diagnostiku směrování, tak i pro implementaci nejrůznějších administrativních politik v oblastech jako QoS, bezpečnost, diferencované nakládání se zákazníky apod., prostě všude tam, kde standardní konfigurace a směrovací protokoly (údajně) nestačí.
Prezentace IRS při jednání pracovní skupiny Routing Area vyvolala velmi bohatou diskusi. Reakce byly většinou pozitivní a podpůrné, kritické komentáře upozorňovaly hlavně na nebezpečí přílišné šíře záběru – jak se pěkně anglicky říká: „boiling the ocean“.
IRS se má od existujících metod interakce se směrovacím systémem (CLI, SNMP, IPFIX, NETCONF) lišit možností rychlého přístupu k detailním informacím o stavu systému a možností operativních softwarově řízených zásahů. První z uvedených dokumentů však při analýze vhodnosti protokolu NETCONF coby mechanismu pro realizaci IRS vycházel v řadě ohledů ze zastaralých anebo přímo nesprávných informací – NETCONF byl pak na jejich základě zavržen. Tyto nedostatky byly v diskusi také zmíněny a aktivisté IRS přislíbili, že se k výchozí analýze ještě vrátí a použití NETCONFu a jeho datových modelů znovu zváží.
Moje osobní dojmy jsou zatím smíšené. Samotná idea IRS jako mechanismu pro přístup ke směrovacím datům je v pořádku, trochu mne ale dráždí jeho avizované použití. Vychází totiž z předpokladu, že směrování v Internetu lze optimalizovat aktivním řízením routerů z nějakého „inteligentního“ centra. Dosavadní zkušenosti mne přesvědčují, že se v takových případech výkon sítě často spíše zhorší.
Otázky IRS jsou intenzivně diskutovány v konferenci irs-discuss. Pokud půjde vše podle předpokladů, bude se na příštím meetingu IETF 85 v Atlantě konat zasedání typu BoF (Birds of a Feather) a z něj by následně mohla vzejít nová pracovní skupina IRS při IETF.
Ladislav Lhotka
Z IETF 84: SNMP data pod křídla NETCONFu?
Můj druhý postřeh z meetingu IETF 84 se také týká protokolů a nástrojů pro síťový management. Zatímco minulý příspěvek byl věnován konfiguračním datům, dnes bych se rád zmínil o jedné diskusi týkající se stavových dat, která jsou pro efektivní správu síťových zařízení také velmi důležitá. Čím se liší od těch konfiguračních? Rozdíl můžeme ukázat na jednoduchém příkladu IP adresy. Ta může být pro dané rozhraní buď statická, a pak je zapsána někde v konfiguračních datech, anebo se získává pomocí DHCP a její aktuální hodnotu může správce zjistit ze stavových dat. Za stavová data se obvykle považují i různé statistické čítače, kupříkladu počty bajtů přijatých a odeslaných přes dané rozhraní.
Pro práci s oběma typy dat jsou k dispozici dva konkurenční protokoly: SNMP a jeho mladší bratranec NETCONF. Pokud jde o konfigurační data, hovoří vše celkem jasně pro NETCONF, SNMP se v této oblasti neosvědčil a dnes se prakticky nepoužívá. U stavových dat je ale situace do velké míry opačná a SNMP tu zatím jednoznačně vládne. Síťovým operátorům už se ovšem dosti zajídá spravovat sítě pomocí dvou různých protokolů – a začínají se hlasitě ozývat.
Diskuse na toto téma propukla na IETF 84 poněkud nečekaně během jednání pracovní skupiny OPSAWG, když byl na programu Internet draft draft-schoenw-opsawg-vm-mib-01, který definuje část databáze SNMP MIB se stavovými daty pro virtuální počítače s hypervizorem. Rozbuškou však nebyl tento celkem nevinný dokument, ale osoba přednášejícího: byl jím Jürgen Schönwälder, který je jednou z vůdčích figur stojících za návrhem protokolu NETCONF. Dotaz z pléna zněl zhruba takto: „Jestli to s NETCONFem myslíte vážně, proč nás pořád zásobujete novými daty pro SNMP a neimplementujete raději stejná data v NETCONFu?“ Většina diskutujících se pak skutečně přiklonila k názoru, že by bylo velmi prospěšné toto schizma postupně odstranit a mít všechna stavová data k dispozici prostřednictvím NETCONFu.
To se snadno řekne, ale hůře udělá. Převod všech definic objektů z databáze MIB (zapsaných v jazyku SMIv2) na datový model pro NETCONF (v jazyku YANG) je sice možný, vzhledem k vysokému počtu MIB objektů je to ale práce pro vraha, a tak se do ní nikomu nechce. Druhou alternativou, která se již také testovala, je proto automatický převod. Pro tento účel dokonce existuje specifikace v RFC 6643, jehož autorem je shodou okolností rovněž Jürgen Schönwälder.
Jenže, jak víme i z jiných případů, výsledky strojového překladu nebývají zrovna ideální. V daném případě se naráží jednak na některé nekompatibility mezi jazyky SMIv2 a YANG (příkladem je rozdílný způsob indexace objektů v databázi), ale také na problém převodu důležitých informací zapsaných v MIB modulech volným textem – doplňujících popisů a implementačních instrukcí.
Momentálně tedy převládá názor, že automatický převod lze použít ad hoc v případě akutní potřeby přístupu k MIB datům pomocí protokolu NETCONF. Z dlouhodobého hlediska bude ale asi nezbytné podstoupit martyrium spojené s ruční konverzí. Vypadá to tedy, že internetová komunita má v této oblasti o práci postaráno na řadu příštích let.
Ladislav Lhotka
Z IETF 84: standardizace konfiguračních dat
Během posledního meetingu IETF, který měl pořadové číslo 84 a konal se v kanadském Vancouveru, se výsledky mých „kmenových” pracovních skupin NETCONF a NETMOD objevily v zajímavé diskusi na širších fórech, konkrétně v mailing listu ietf@ietf.org, při jednání pracovní skupiny OPSAREA (Operations and Management Area), jakož i v kuloárních debatách.
Diskusi zahájil svým příspěvkem polský kolega Robert Raszuk. Pozastavil se nad tím, že ve specifikacích nových protokolů chybí schéma konfiguračních dat, a navrhl, aby všechna RFC povinně obsahovala oddíl s takovým schématem, protože bez něho si každá implementace vytváří svůj vlastní způsob konfigurace, který nemusí být s ostatními zrovna kompatibilní. Problém je to reálný, kdo by tomu nevěřil, ať si zkusí mezi sebou převést netriviální konfigurace směrovačů různých výrobců (včetně našeho BIRDa).
Navrhované řešení, tedy zavést toto jako povinnost, se ovšem setkalo s jednoznačným odporem. Robertovi se též dostalo doporučení, aby se seznámil s výsledky pracovní skupiny NETMOD, kde se již datové modely pro některé základní protokoly a subsystémy vyvíjejí.
V této souvislosti se ale ukázalo, že datové modely NETMOD tak docela nenaplňují vizi unifikace konfiguračních schémat. Jsou totiž poměrně pružné a umožňují definovat schémata v různých podobách, od odlišností v pojmenování objektů (klasickým příkladem jsou třeba jména síťových rozhraní) až po menší či větší rozdíly v logice a uspořádání konfiguračních dat. Důvody jsou nasnadě: Nelze očekávat, že přední výrobci směrovačů a jiných zařízení po zveřejnění datových modelů srazí paty a překopou svá konfigurační rozhraní, která si po léta hýčkají a školí na nich své zákazníky. Jistá míra pružnosti proto dává naději, že by se konkrétní implementace datových modelů mohly naopak přizpůsobit existujícím konfiguračním rozhraním. Lze pak ovšem očekávat, že nebude možné jednoduše vzít konfiguraci jednoho boxu a instalovat ji beze změn na obdobném zařízení jiného výrobce.
Toto je docela složité dilema, uvidíme, jak se věci vyvinou. Rozhodně by ale bylo dobré, kdyby se specifikace konfiguračního schématu staly součástí standardů aspoň pro nové protokoly – byť třeba nepovinně.
Ladislav Lhotka
Kéž by duch IETF do českého e-governmentu ráčit vešel
Pokud čtete tento článek, je to i díky lidem, kteří se na konci osmdesátých let sdružili v organizaci s názvem IETF. IETF nebo-li Internet Engineering Task Force je hlavní organizací pro vývoj standardů pro internet. Nejedná se o žádnou státem vedenou organizaci. V této organizaci nejsou žádní členové. Přihlásit se do ní může doslova každý. Kdokoliv na světě (pokud tedy není za nějakým ošklivým firewallem). Prostě klikne, že chce být na „mailing listu“ dané pracovní skupiny, nebo se přihlásí na jednání IETF (virtuálně nebo fyzicky). To je vše. Každý rok se tímto způsobem aktivně zapojí do pracovních skupin více než sedm tisíc lidí. Dobrovolně. Bez nároků na odměnu. S jediným cílem – aby internet lépe fungoval.
IETF 93 v číslech
Minulý týden hostila Praha (a naše sdružení spolu se společností Brocade) summit IETF 93. O tom, jak funguje tato komunita, jste si mohli přečíst v článku Ládi Lhotky z našich laboratoří na Root.cz. Stejný server přinesl i článek o (virtuální) účasti Edwarda Snowdena.
Ohlédnutí za IETF 83
Jelikož jsem v předchozích dvou blogpostech o OpenID a WHOISu nalákal čtenáře na IETF 83, sluší se přinést nějaký report o tom, jak tato konference splnila očekávání. Dá se říct, že více než dostatečně.
Jak už je na IETF zvykem, je neděle věnovaná tutoriálům. Mezi ně byl trochu narychlo zařazen i tříhodinový tutoriál na OpenID Connect. To ještě více umocnilo fakt, že tato konference byla problémům digitálních identit věnovaná víc než jsem sám čekal. V zajímavé souhrnné prezentaci bylo zmíněno i probíhající vzájemné testování existujících implementací. Zájemcům o OpenID Connect bych určitě doporučil blogy jeho autorů, zejména články OpenID Connect in a nutshell a Designing a Single Sign-on system using OAuth 2.0. A pokud někdo stále nerozumí rozdílům mezi OpenID a OAuth, existuje i Dummy’s guide. Na závěr byl prezentován i projekt AccountChooser jako nástroj pro poskytovatele služeb, kteří chtějí implementovat jednotné přihlášení napříč technologiemi. Jak udělat správně uživatelské prostředí na straně poskytovatele služeb je zjevně oříšek a nikdo není spokojen s tím co se nazývá NASCAR UI – desítky barevných tlačítek s různými poskytovateli, mezi kterými si uživatel musí nalézt toho svého.
Z pondělních pracovních skupin zaujala NETMOD, jejíž cíl je vydefinovat univerzální datové modely pro vzdálenou konfiguraci různých prvků pomocí protokolu NETCONF. Na datovém modelu pro konfiguraci routingu totiž pracuje Láďa Lhotka z našich laboratoří. Odpolední technické „plenary“ začalo připomenutím druhého dne IPv6, na který se připravujeme i my. Potom už byly hlavními tématy TLS, problémy certifikačních autorit a zabezpečení webu obecně, které se lehce vyhrotilo při kritice tvůrců prohlížečů spočívající v tvrzení, že napadené nebo pochybné certifikační autority neodstraňují z prohlížečů flexibilně.
Avizovaná panelová diskuze o OpenID a OAuth pořádaná organizací ISOC v úterý před polednem byla pro auditorium, ve kterém seděli zástupci různých (číselných i doménových) registrů, spíše seznamovací. Její obsah nejspíš jen vyvolal v posluchačích otázky, které jsme si my položili již dříve a odpověděli na ně v podobě služby MojeID. V navazující pracovní skupině KITTEN, o které jsem se zmiňoval dříve v souvislosti s použití OpenID pro zabezpečení dalších internetových protokolů, se pouze probral stav existujících dokumentů bez nějakého zásadního posunu. To na WEIRDS se očekávala bouřlivá diskuze o podobě nového WHOIS protokolu. Překvapivě se ozvali pouze jednotlivci, kteří mají obavy o zbytečně vynaložené úsilí. Navržený „charter“ pro připravovanou pracovní skupinu tedy bude poslán ke schválení příslušným orgánům IETF. V podvečer ještě zasedla pracovní skupina DNSEXT. Na ní Ondra Surý z našich laboratoří prezentoval navrhovanou úpravu protokolu IXFR. Tato pracovní skupina se pravděpodobně setkala naposledy; její odsouhlasené rozpuštění již čeká pouze na administrativní proceduru.
Středeční program nabídl mimo jiné pracovní skupinu TLS. Ta probírala rozšíření mechanismů pro získání certifikátů při navazování TLS spojení, např. z DNS, jak bylo schváleno v rámci pracovní skupiny DANE. Tato pracovní skupina již všechny svoje dokumenty dokončila a jsou v procesu schvalování, takže pro ni nebyl důvod se tentokrát scházet.
A opět ty identity. Na čtvrteční ráno byl naplánován BOF týkající se protokolu SCIM (Simple Cloud Identity Management). Velcí poskytovatelé cloudových služeb by si rádi standardním způsobem synchronizovali data o uživatelích. Navrhli tedy protokol, který má standardizovány operace pro založení, zobrazení, změnu a zrušení (CRUD) vzdáleného kontaktu spolu s univerzální datovou strukturou v XML a JSONu. Jestli vám to připomíná EPP, které používáme v našem doménovém registru, tak mně také. To jen ukazuje, že staré nápady jsou neustále recyklovány a možná není daleko doba, kdy místo EPP protokolu budeme také používat nějaký REST protokol nad HTTP. Následovala druhá panelová diskuze týkající se OpenID, OAuth a tentokrát i BrowserID. Je více než zřejmé, že BrowserID nemůže OpenID aktuálně plnohodnotně nahradit. Pracovní skupina OAUTH poté řešila hlavně tzv.“rechartering“, tzn. změnu svých cílů. Pro OpenID Connect bude důležité, jestli si pracovní skupina vezme za své některé osiřelé specifikace, na kterých je závislý jako např. Simple Web Discovery. Proti tomu se zvedl částečný odpor, neboť se opět jedná o alternativní přístup k něčemu, na co již existují v IETF jiné standardy host-meta a webfinger.
Závěrečnou tečku za konferencí udělala v pátek pracovní skupina DNSOP. Hlavním tématem bylo TTL a jeho snižování nebo zvyšování. Inženýři z Verisign navrhují jeho výrazné zvýšení jako ochranný mechanismu proti případné nedostupnosti autoritativních serverů. Jejich japonští kolegové naopak doporučují výrazné snížení jako ochranný mechanismus z důvodu rychlého zotavení z případné chyby např. v souvislosti s technologií DNSSEC. K tomu se samozřejmě ještě přidává zákaznický pohled, neboť uživatelé samozřejmě chtějí vidět svoje požadované změny okamžitě. Jednoznačná odpověď asi neexistuje.
Jaromír Talíř
Knot DNS – DNSSEC (2)
V předchozím dílu jsme si představili základy fungování a provozu DNSSEC na serveru Knot DNS. Dnes navážeme popisem některých dalších funkcí tohoto serveru, které s DNSSEC souvisí.
Knot DNS – zónové transfery
V úvodním dílu jsme si zprovoznili automatickou synchronizaci zóny na sekundárním serveru. Dnes si ukážeme jaké jsou další možnosti nastavení zónových transferů a co je jejich obsahem.
Šifrované DNS v Knot Resolveru: DoT a DoH
V tomto příspěvku popíšeme rozdíly mezi dvěma rozšířenými protokoly pro šifrování DNS: DNS-over-TLS (DoT) a DNS-over-HTTPS (DoH). Porovnáme technické aspekty těchto protokolů a jejich vliv na soukromí uživatelů. Představíme také novou vestavěnou podporu DoH v Knot Resolveru a vysvětlíme některá naše rozhodnutí při její implementaci.
Novinky v Knot DNS 3.0
Open-source implementace autoritativního DNS serveru Knot DNS vyšla ve verzi 3.0. Navzdory kulatému číslu se na dosavadní funkcionalitě software nic nemění: novinek je sice o něco více než v běžné desetinkové verzi 2.9, ale jde převážně o featury, které když uživatel nezapne, bude vše fungovat jako u předchozích verzí. Migrace je tudíž jednoduchá.