Multicast je obecně zasílání dat z jednoho zdroje více příjemcům, ideálně tak, aby byla co nejefektivněji využita síťová infrastruktura. Data by ideálně měla sítí téct každou linkou maximálně jednou a „větvit“ se pouze tam, kde je to nezbytně nutné - nejlépe až na přístupové (access) vrstvě. Multicast se používá především pro online přenos multimediálních dat, kdy nechceme zbytečně zatížit síťovou infrastrukturu.
Obecnému popisu multicast vysílání v IPv6 jsme se již před lety zabývali v sedmém dílu jiného seriálu. V rámci tohoto seriálu se podíváme, jak nám zavádění protokolu IPv6 do větších sítí zamávalo s úmysly využít pro všechny případy multicast provoz. Pro začátek si ale udělejme krátkou exkurzi do historie a zopakujme základní informace, které budeme potřebovat pro pochopení zbytku článku.
Trocha historie
Protokol IPv6 byl navrhován jako nekompatibilní s IPv4. Proto byla snaha ho navrhnout od začátku správně a eliminovat určité nedostatky, kterými se tehdy potýkal protokol IPv4. Jedním z problémů, který v 90. letech trápil síťové administrátory, bylo příliš mnoho broadcast provozu. Sítě byly tehdy propojené pomocí hubů či jednoduchých přepínačů a v takových sítích je příliš mnoho broadcast zpráv problém. Pro tento jev se vžilo označení broadcast storm a dokázal správcům způsobit celou řadu problémů.
Výpočetní čas pro zpracování zprávy na zařízení byl v té době ještě drahý (CPU nebyla tak výkonná), a problémem je, že broadcast zprávu musí zařízení zpracovat vždy a až podle obsahu se rozhodnout, jestli ji budou ignorovat, nebo ne.
Jedním z důvodů vzniku velkého množství broadcast zpráv může být zapojení velkého množství zařízení. Každé zařízení totiž občas potřebuje zaslat zprávu všem ostatním v dané síti a více zařízení vede logicky k většímu počtu broadcast zpráv.
Dalším důvodem je samotná architektura protokolu Ethernet. Ethernet totiž sám o sobě nemá žádný prostředek pro eliminaci smyček, jako například IP v podobě TTL, tedy, jakmile je síť omylem zakruhována, broadcast provoz je přeposílán stále dokola. Síť je v takovém případně nestabilní, musí se dohledat zařízení, na kterém zakruhování vzniklo a kruh rozpojit. Tento problém eliminuje protokol STP (Spanning Tree Protocol), nicméně jednoduché přepínače ho v té době nepodporovaly a nedokázaly tedy smyčku v síti automaticky přerušit.
Snahou tedy od začátku bylo u protokolu IPv6 broadcast eliminovat. Ač IPv6 nemůže vyřešit problém zakruhování topologie, může odstranit nutnost zasílání broadcast zpráv na síťové vrstvě. Jelikož je ale občas potřeba zaslat nějaké informace více zařízením, nelze používat pouze unicast. Multicast se tedy nabízel jako správná volba, jelikož je to obecně nejefektivnější doručení dat více zařízením skrz síťovou infrastrukturu. Navíc za prvotním návrhem IPv6 stojí Steve Deering, autor celého konceptu multicast vysílání.
Při návrhu protokolu IPv6 byl tedy multicast použit téměř pro všechny obslužné protokoly a činnosti. Jedná se zejména o bezstavovou konfiguraci, kontrolu duplicity adresy, zjištění mapování mezi IPv6 a MAC adresami aj.
Multicast - základní princip
Pojďme se nyní podívat na základní pravidla fungování multicast vysílání. Pokud je třeba data efektivně doručit skrz síť, zdroj dat je zašle do příslušné multicast skupiny - tedy jako cílovou IPv6 adresu nastaví IPv6 adresu dané multicast skupiny. Klienti, pokud o daná data mají zájem, se do dané multicast skupiny přihlásí a začnou data odebírat. Vidíme tady trochu odlišné chování od unicast komunikace. Klienti si o multicast data musí nejprve říci, než jim jsou zaslaná. Toto projevení zájmu provedou pomocí protokolu MLD (Multicast Listener Discovery).
Protokol MLD využívá tři základní zprávy - Query, Report, Done, které jsou součástí ICMPv6. Zpráva Query slouží k detekci zájemců o multicast provoz. Zpráva Report slouží k vyjádření zájmu o multicast a zprávou Done zařízení informuje, že o daný multicast provoz již zájem nemá.
Princip fungování protokolu MLD je pak následující. Směrovač (Querier) se pravidelně prostřednictvím zprávy Query ptá, jestli jsou v síti nějací zájemci o multicast provoz. Koncová zařízení mu odpovídají zprávou Report, ve které sdělují, o jaké skupiny mají zájem. Multicast provoz jim je pak následně přeposílán. Aby byl směrovač informován, že zprávám protokolu MLD má věnovat pozornost, obsahují všechny MLD zprávy rozšířenou hlavičku Hop-by-Hop s nastavenou volbou Router Alert.
U multicast vysílání také rozlišujeme, zda-li se jedná o multicast přeposílaný mezi směrovači, kde směrování multicast provozu zajišťuje převážně protokol PIM (Protocol Independent Multicast) nebo multicast v lokální síti. My se v tomto dílu budeme věnovat pouze multicast provozu v lokálních sítích.
V lokální síti platí pro multicast provoz trochu jiná pravidla než mezi směrovači, protože se pro jeho doručení nepoužívá žádný směrovací protokol. Zařízení v lokální síti (přepínače, uživatelské počítače) musí tedy nějakým způsobem sama zjistit, že daný provoz je opravdu multicast provozem. Na síťové vrstvě je to vcelku jednoduché - IPv6 multicast má vyhrazený prefix ff00::/8. V lokální síti ale rámce adresujeme pomocí linkových (MAC) adres. K odlišení multicast provozu od unicast komunikace nám zde poslouží speciální MAC adresa, jejíž prvních 16 bitů má hodnotu 33:33. Zbývajících 32 bitů dané MAC adresy se doplní spodními 32 bity multicast IPv6 adresy. Například IPv6 muticast skupina FF02::1:FF68:12CB se tak namapuje na Ethernet multicast 33:33:FF:68:12:CB. Díky tomuto mapování všechna zařízení pracující na linkové vrstvě (přepínače, síťové karty klientů) poznají, že se jedná o multicast provoz a zachází s ním odpovídajícím způsobem. Pokud se klient přihlásí do IPv6 multicast skupiny, síťová karta si poznamená odpovídající multicast MAC adresu a příchozí data z této skupiny bude předávat operačnímu systému. Zbytek multicast provozu může odfiltrovat, aby se operační systém nezabýval jiným multicast provozem, než o který má opravdu zájem.
O jaké skupiny má zájem třeba vaše zařízení, si můžete v Linuxu zobrazit příkazem ip maddr. Daným příkazem vypíšete, k jakým multicast skupinám je vaše zařízení přihlášeno. Například:
$ ip maddr
2: eth0
link 33:33:ff:ea:d4:8a
inet6 ff02::1:ffea:d48a
Z tohoto zkráceného výpisu, vidíme, že zařízení je přihlášeno, na rozhraní eth0, do multicast skupiny ff02::1:ffea:d48a. Z výpisu můžeme také vyčíst odpovídající linkovou multicast adresu (33:33:ff:ea:d4:8a) k dané IPv6 multicast skupině (ff02::1:ffea:d48a).
Pokud byste hledali podobný příkaz pro Windows, tak lze použít netsh interface ipv6 show joins.
Efektivní doručení multicast provozu
Jakým způsobem můžeme v lokální síti zajistit distribuci multicast provozu? Ten nejjednodušší způsob je s multicast provozem zacházet jako s broadcast provozem. Jelikož nevíme, kdo o něj má zájem, pošleme ho prostě po celé síti. Koncová zařízení se pak sama rozhodnou, zdali data zahodí nebo předají operačnímu systému. Tento způsob ilustruje následující obrázek, na kterém vidíme, že se multicast provoz šíří i na zařízení, která o něj zájem nemají.
Tento způsob nicméně není příliš efektivní. Ne všechny síťové karty dokáží odfiltrovat multicast provoz, který je nezajímá. Pokud do sítě vysíláme např. větší množství multimediálních dat ve vysokém rozlišení, bitrate často dosahuje desítek až stovek Mb/s. Takovým množstvím dat již můžeme koncová zařízení nepříjemně zatížit. Aby se tomuto problému zabránilo, používá se technika označovaná jako MLD Snooping. Zjednodušeně řečeno, když zařízení informuje síť o svém zájmu o určitou multicast skupinu zprávou Report, přepínač si u sebe tuto informaci poznamená. Díky tomu přepínač ví, na kterém portu je jaký zájemce o jaký multicast. Trochu tím porušujeme vrstvový model, jelikož přepínač (L2 zařízení) se dívá do vrstev vyšších, protože potřebuje zpracovat zprávy protokolu MLD, nicméně je to vyváženo efektivitou zasílaného provozu. Pokud tedy v síti aktivujeme MLD Snooping, zajistíme tak efektivní přeposílání multicast provozu a tok multicast dat pak může vypadat jako na následujícím obrázku.
Tabulka na zařízeních Cisco může vypadat následovně:
Switch#show ipv6 mld snooping address
Vlan Group Type Version Port List
-----------------------------------------------------------------------
1 FF1E::1 mld v2 Fa0/11, Fa0/23
1 FF02::FB mld v2 Fa0/23
Z daného výpisu je patrné, že např. provoz směřující do multicast skupiny FF1E::1 bude zasílán pouze na porty Fa0/11 a FA0/23. Ostatní zařízení v síti nebudou provozem obtěžována. V praxi tyto optimalizace multicast provozu provádí pouze operátoři, kteří využívají svou infrastrukturu pro přenos větších objemů multimediálních dat - typicky televizní vysílání. Většina sítí tyto optimalizace u IPv6 a často ani u IPv4 neprovádí a provoz je tak rozesílán na všechna zařízení jako u prvního příkladu.
Broadcast = multicast?
Přestože byla u IPv6 snaha kompletně eliminovat broadcast, někdy prostě potřebujeme zaslat informace všem klientům v jedné síti - například zprávu Ohlášení směrovače. Jak to udělat v IPv6, když broadcast nemáme? Pravdou je, že IPv6 nemá broadcast jenom na první pohled. Broadcast totiž představuje speciální případ multicast provozu, kdy se všechny uzly v síti přihlásí k příjmu stejné multicast skupiny. Daná multicast skupina all-nodes má adresu FF02::1 a podle RFC 4861 se do ní musí povinně přihlásit všechny uzly. V tomto případě ale nedává smysl, aby zařízení signalizovala pomocí MLD, že o danou skupinu mají zájem. Proto RFC 3810 definuje, že se pro danou skupinu žádné zprávy protokolu MLD neposílají. Přepínače s podporou MLD Snooping si tedy nemusí pro danou skupinu udržovat stavovou informaci a data rozešlou na všechny porty. Reálně je tedy tato skupina implementována naprosto totožně jako broadcast u IPv4. Fakticky tedy u IPv6 broadcast máme a záleží pouze na vás, jestli zprávy poslané s cílovou adresou FF02::1 nazvete broadcast nebo multicast provozem.
IPv6 překlad IPv6 - MAC
Víme už jak multicast obecně pracuje a jak lze provést jeho efektivní doručení v síti. Pojďme se nyní ještě podívat na část protokolu IPv6, která se podstatně změnila oproti IPv4 - překlad mezi IP a MAC adresou. IPv4 využívá k tomuto účelu protokol ARP definovaný v RFC 826. Dotazy protokolu ARP využívají broadcast a jsou jednoduše rozposílány na všechna zařízení v lokální síti. Odpovědi využívají unicast a jsou tedy zasílány zpět přímo žadateli.
IPv6 protokol používá pro překlad mezi IPv6 a MAC adresou protokol ND (Neighbor Discovery protocol) definovaný v RFC 4861, kterým jsme se již zabývali v předchozích dílech seriálu. Z protokolu ND se využívá zpráv Ohlášení souseda (Neighbor Advertisement) a Výzva sousedovi (Neighbor Solicitation). Tyto zprávy jsou zasílané do speciální IPv6 multicast skupiny solicited-node.
Jakým způsobem to pak celé funguje? Každé zařízení si nejprve pro každou svou IPv6 adresu vytvoří vlastní multicast skupinu solicited-node. Multicast adresa dané skupiny vzniká tak, že k multicast prefixu FF02:0:0:0:0:1:FF00::/104 se přidá spodních 24 bitů IPv6 adresy, kterou si chce zařízení nakonfigurovat. Ilustrujme si celý postup na příkladu na následujícím obrázku.
Zařízení si chce nakonfigurovat IPv6 adresu 2001:67c:1220:80e:3f89:4943:87c5:7cc. Spodních 24 bitů této adresy, tedy v hexa zápisu 0xC507CC se přidají k multicast prefixu určený pro solicited-node skupinu a vznikne tak multicast adresa ff02::1:ffc5:7cc. Tato IPv6 multicast skupina se přemapuje podle již nám známých pravidel na multicast MAC adresu 33:33:ff:c5:07:cc.
Pokud chce nějaké zařízení zjistit, jaká MAC adresa odpovídá IPv6 adrese 2001:67c:1220:80e:3f89:4943:87c5:7cc, pošle dotaz Neighbor Solicitation právě do multicast skupiny ff02::1:ffc5:7cc. Jelikož zařízení odebírá zprávy zasílané do této skupiny, může mu zprávou Neighbor Advertisement odpovědět, jaká je jeho MAC adresa. Zařízení si danou informaci poznamenají do cache sousedů a mohou spolu začít komunikovat. Použitím solicited-node multicast skupiny je zajištěno, že dotazem nebudou obtěžována všechna zařízení v síti, ale pouze dané konkrétní zařízení. Může se stát, že se spodních 24 bitů bude u několika IPv6 adres shodovat. V tom případě se budou shodovat i jejich multicast skupiny. To ale vcelku ničemu nevadí, jelikož síť zajistí doručení oběma zařízením. Obě předají dotaz svému operačnímu systému, ale pouze to zařízení, které danou IPv6 adresu opravdu má, odpoví. Oproti protokolu IPv4 tady můžeme nalézt vylepšení v tom, že dotaz na překlad adresy nejde všem zařízením, ale pouze těm konkrétním, které IPv6 adresu opravdu mají.
Je důležité ale připomenout následující požadavky. Pokud si zařízení konfiguruje IPv6 adresu, vytvoří si k ní odpovídající solicited-node multicast skupinu, jak jsme si popsali výše. Zařízení se pak ale také musí do této skupiny přihlásit pomocí protokolu MLD. To je právě z důvodu, aby byly informovány přepínače v lokální síti, že na daném portu je zařízení, které je členem dané multicast skupiny. Pokud chceme aby správně fungoval překlad IPv6 - MAC adres, musíme tedy zajistit i správné fungování multicast provozu.
Zneužití MLD
Protokol MLD je zajímavý také pro útočníky, protože se jedná o protokol v lokální síti, který v principu nemůže být moc filtrován a neobsahuje žádné bezpečnostní mechanismy. Protokol je také zajímavý tím, že je u operačních systémů implicitně aktivován. Pro útočníka se tak otevírá další kanál, kterým může se zařízením komunikovat. Protokol MLD se tedy dá použít k několika neplechám:
Mapování sítě
Pokud si útočník dělal zálusk na nějakou IPv4 síť, proskenoval ji adresu po adrese, aby zjistil aktivní zařízení. Protokol IPv6 ale používá pro adresaci zařízení v lokální síti typicky 64 bitů. To je potenciálně natolik velké množství adres, že je jejich skenování adresu po adrese nemyslitelné. Existuje nicméně pár triků, které může útočník použít. Pokud je připojený v lokální síti, lze vyzkoušet ping na adresu všech zařízení (ff02::1). Tento způsob nicméně naráží na problém, že některá zařízení (typicky Windows) na něj neodpoví. Pro oskenování sítě lze ale vcelku triviálně použít protokol MLD. Pokud útočník do sítě pošle zprávu MLD Query, zařízení v lokální síti se budou moci přetrhnout, aby ho informovala do jakých multicast skupin jsou přihlášené. Útočník tak zjistí nejenom jejich link-local adresy, ale také lze z odpovědi zjistit nebo alespoň vytušit operační systém - např. Windows se přihlašuje do multicast skupiny FF02::1:3 (Link Local Multicast Name Resolution). Pokud znáte link-local adresy, můžete se začít pokoušet zjišťovat, jaké služby zařízení provozuje, protože implicitní nastavení serveru je, že naslouchá na všech IPv6 adresách - tedy i na link-local. Tento problém se týká hlavně datových center, kde často nemají poskytovatelé oddělenou síť pro jednotlivé virtuální stroje, jak popisuje například tento článek.Odepření příjmu multicast provozu
Pokud je v síti šířen např. televizní stream pomocí skupinového vysílání, může se útočník pokusit odepřít příjem těchto dat ostatním zařízením. Realizace tohoto útoku je vcelku jednoduchá a velice podobná jako u protokolu IGMP pro IPv4. Útočník se pokusí přesvědčit ostatní zařízení, že je Querier (tj. směrovač odpovědný za přeposílání multicast provozu). Podle RFC se Querier stává ten, kdo má nejmenší IP adresu. Díky tomu, že IPv6 adresa se většinou u směrovačů generuje na základě linkové adresy podle algoritmu EUI-64, je vcelku triviální si nakonfigurovat adresu nižší a stát se tak Querier pro daný segment. Pokud by vás tato problematika zajímala podrobněji, můžete se na detaily podívat například v prezentaci MLD Considered Harmful prezentované na konferenci DeepSec.Přetížení síťových zařízení
Největší bolení hlavy síťovým operátorům ale způsobuje zneužití protokolu MLD pro vytížení jejich infrastruktury. Při tomto typu útoku se snaží útočník zneužít právě optimalizací, které přepínače musí provádět, aby byly efektivně schopny doručovat multicast. Již jsme si popsali, že de facto jediným způsobem, jak zajistit opravdové efektivní doručení multicast provozu v lokální síti, je nutnost aktivovat MLD Snooping na přepínačích. Aktivováním si zařízení jsou schopny zjistit informace v jakých skupinách a na kterých portech jsou klienti přihlášeni. Pro zařízení to znamená, že všechny MLD zprávy Report a Done musí přeposílat do svého CPU, aby je byl schopen zpracovat.Jak takový útok může vypadat? Lze použít Scapy pro vytvoření MLD Query zprávy, kterou je pak možno zaslat do sítě. Například:
$ python >>> from scapy.all import * >>> a = IPv6(dst='ff02::1',hlim=1) >>> b = IPv6ExtHdrHopByHop(nh=58,options=RouterAlert()) >>> c = ICMPv6MLQuery(mrd=0) >>> mldquery = a/b/c >>> send(mldquery, inter=’x’)Jako cílovou adresu nastavíme “broadcast”, tedy všechny klienty v síti. Dle RFC mají mít multicast zpráv nastavený Hop Limit (TTL) na 1. Vložíme rozšířenou hlavičku Hop-by-Hop s volbou Router Alert, kterým informuje směrovač, že by danému paketu měl věnovat pozornost. Pak stačí doplnit zprávu ICMPv6 MLD Query a zaslat do sítě. Na tuto zprávu odpoví všechna zařízení v síti připojená a nahlásí tazateli své multicast skupiny do kterých jsou přihlášená. Stačí pak tuto zprávu poslat v cyklu a zařízení se mohou dost zapotit. Pro představu, cca 3000 těchto paketů za vteřinu zcela vytíží Cisco Catalyst 3650 a udělá z něj vcelku nepoužitelné zařízení. V reálné síti bude dopad takovéto zprávy ještě větší. Zařízení se totiž přihlašují do několika skupin a zpráva pro přihlášení do multicast skupiny se dle RFC má zaslat dvakrát. Amplifikace takového útoku je pak značná.
Řešením daného problému může být filtrace zpráv MLD Query na přístupovém portu, pokud vám to vaše zařízení podporuje. ACL může pak vypadat například takto:
Switch(config)# ipv6 access-list DENY-MLD Switch(config-ipv6-acl)# deny icmp any any mld-queryDané ACL zabrání nicméně pouze výše zmíněnému útoku. Útočník se ale může přihlašovat do náhodně generovaných multicast skupin a potom je filtrace podstatně obtížnější. Pokud použije prefix pro solicited-node multicast skupiny, tak správce navíc nemůže rozhodnout, která adresa je validní a která ne. Velký počet multicast skupin však nemusí být jen známkou útoku, ale zcela normálním stavem. Pojďme se podívat, kolik takových skupin můžeme v reálné síti očekávat při běžném provozu.
Kolik skupin?
Počet multicast skupin v IPv6 síti primárně závisí na způsobu adresace koncových zařízení. IPv6 protokol vyžaduje, aby každé zařízení mělo link-local adresu pro komunikaci s ostatními zařízeními na lince. Koncept link-local adres je u IPv6 vcelku novinkou. Protokol IPv4 tyto adresy sice měl také (169.254.0.0/16) nicméně ty se používají pouze když selžou jiné způsoby konfigurace IPv4 adresy. Oproti tomu, link-local adresy jsou u IPv6 opravdu třeba, jelikož se používají jako adresa výchozí brány, směrovače je používají pro výměnu směrovacích informací aj. Jelikož je link-local IPv6 adresa jako každá jiná, zařízení si tedy pro ni musí vytvořit odpovídající multicast adresu.
Pouze s link-local adresou bychom ale daleko nedošli, jelikož dosah link-local adresy je omezen pouze k nejbližšímu směrovači. Nelze se tedy pomocí těchto adres dostat na zdroje v Internetu. K tomu potřebujeme, aby zařízení mělo přidělenou ještě globální IPv6 adresu, tedy další multicast adresu. Pokud používáme v síti ULA adresy (Unique Local IPv6 Unicast Addresses) pro přístup k lokálním službám, máme další multicast adresu. Počet adres nám může narůst také při použití více prefixů, nebo když kombinujeme automatickou konfiguraci s DHCPv6. Vždy tedy musíme počítat s tím, že v síti budeme mít minimálně dvojnásobek multicast skupin jako je připojených zařízeních v daném segmentu sítě, často více.
Historicky tomu tak ale nebylo a zařízení měla typicky pouze jednu multicast adresu. Proč? Původní návrh protokolu IPv6 totiž počítal s tím, že zařízení si IPv6 adresu vytvoří na základě prefixu sítě a své MAC adresy. Všechny adresy, které by si koncové zařízení přidělilo (globální, link-local, ULA) by tedy měly stejný koncový identifikátor. Díky tomu by byla stejná i multicast adresa. Koncept vytvoření identifikátoru z MAC adresy se ale znelíbil, jelikož nezaručuje dostatek privátnosti a vznikly tak náhodně generované IPv6 adresy (RFC 4941 a RFC 7217). Každá IPv6 adresa má tedy v dnešní době spodních 32 bitů rozdílných, tedy pro každou adresu se vytvoří unikátní multicast skupina.
Jaká je realita v koncových sítích? Kolik adres a tedy multicast skupin můžeme očekávat? Podívali jsme se podrobněji na přibližně 5500 unikátních uživatelů v naší síti. Následující graf nám pak zobrazuje kolik má jeden uživatel typicky unikátních IPv6 adres za jeden den. Měření jsme provedli v letošním roce a pro porovnání je zobrazen i rok minulý.
Vidíme, že nejvíce uživatelů má 2 IPv6 adresy - to odpovídá kombinaci adres globální + link-local. Nicméně více jak 70% uživatelů má adres více. Proč? Každý restart operačního systému nebo reasociace ve WiFi síti u mobilního telefonu vede typicky k vygenerování nové IPv6 adresy. Průměr je pak přibližně 3.6 adres na uživatele za den v roce 2013 a víc jak 4 adresy na uživatele za den v roce 2014. Podstatně také narůstá maximální počet IPv6 adres. Zatímco před rokem jsme se většinou nepřehoupli přes 20 adres na uživatele, dnes není problém nalézt uživatele, který má za den více jak 60 unikátních IPv6 adres.
Z pohledu síťových zařízeních je tedy kladen stále větší důraz na velikost paměti (cache sousedů - Neighbor cache), která je určena k uchování těchto záznamů. Této problematice se budeme věnovat podrobněji v příštím díle seriálu. Nás z pohledu dnešního článku spíše zajímá, kolik můžeme čekat multicast skupin a zde nám z dat vyplývá, že je to přibližně 4x více než je uživatelů v lokální síti. Pokud tedy máte 1000 uživatelů v jedné L2 síti, můžete počítat s přibližně 4000 unikátními multicast adresami.
Škálovatelnost MLD
Jak se protokol IPv6 začíná více prosazovat, vychází najevo také několik provozních komplikací. O zábavu se síťovým operátorům v nedávné době postarala společnost Intel a její síťové karty viz. Intel fórum, Cisco mailing list nebo blog. Problémem bylo, že síťové karty, po přepnutí do sleep mode, posílaly do sítě větší množství IPv6 MLD zpráv a došlo tak k přetížení přepínačů. Zde byl na vině pouze špatně naprogramovaný driver pro síťovou kartu a společnost vydala v zápětí opravenou verzi. Dalo by se tedy říci, že to byla pouze chyba v implementaci, nicméně to není zas tak jednoduché.
Pokud by se IPv6 multicast používal pouze pro přeposílání například televizního provozu, nebyl by to problém, protože situace by byla stejná jako u IPv4. Protokol IPv4 sice multicast v lokálních sítích využívá také a jsou protokoly, které dokážou zaslat velké množství IPv4 multicast zpráv (např. mDNS nebo Link-local Multicast Name Resolution), nicméně pokud je pro zařízení problém, lze je jednoduše zablokovat. Multicast je ale u IPv6 použit téměř všude, zejména pro zjištění mapování mezi IPv6 a MAC adresou, jak jsme si popsali výše. Zde ale leží zakopaný pes, jelikož použití pro tyto účely přináší ve větších sítích komplikace. Mohou tak nastat situace, kde zařízení nejsou schopna zpracovat tak velké množství multicast skupin. V dnešní době totiž typická topologie v enterprise nebo kampus sítích vypadá tak, že klienti jsou svedeni na distribuční vrstvu, kde probíhá samotné směrování. Zařízení, které se o dané směrování starají nicméně nejsou a v principu ani nemohou být tak výkonná, aby dokázala zvládnout potenciálně všechny IPv6 solicited-node multicast skupiny. Filtrovat dané skupiny nelze, protože IPv6 adresy jsou náhodně generované, tedy nelze daný prostor (16 777 216 adres) nikterak omezit. Příklad z praxe pak lze nalézt třeba u výpadku MIT sítě způsobené právě velkým množstvím IPv6 multicast ND provozu - viz. The network nightmare that ate my week.
Topologie v datových center, kde je velké množství virtuálních strojů svedené do několika málo fyzických tzv. Top of the Rack (ToR) přepínačů je ještě více problematická. Na jednom fyzickém prvku pak může být připojeno několik tisíc virtuálních strojů a daný ToR přepínač pak může být multicast provozem dost vytížen.
Řešení problému
Síťový administrátor má několik možností, jak se poprat s daným problém, nicméně ideální řešení není. Možné řešení jsou následující:
- Pokud chceme zachovat výhody multicast provozu, musíme mít zapnutý MLD snooping. Jelikož přepínač nedokáže zpracovat tolik multicast skupin, může ignorovat stav multicast skupiny pro Solicited-node adresy a bude je přeposílat klasicky jako broadcast. Pokud má síťová karta koncového zařízení dostatečně velkou hardware kapacitu pro odfiltrování nezajímavých dat, pořád je tu výhoda, že operační systém nebude obtěžován provozem, který mu není určen. Toto zjednodušení používají již v dnešní době někteří výrobci. HP nevytváří MLD tabulku pro jakékoliv link-local skupiny - tedy skupiny s prefixem FF02::/16 Cisco například stav pro Solicited-node skupiny nevytváří, nicméně je stejně musí vyhodnotit, tedy i s tímto vylepšením ho lze jednoduše vytížit. Problém nicméně zůstal u virtuální infrastruktury, kdy Hyprevisor stále musí zpracovávat velké množství skupin a filtry síťových karet jsou v tomto zatím nedostatečné.
- Nepoužívat MLD snooping je další variantou, jak problém vyřešit. Zcela tím eliminujeme výhody efektivního doručení paketů, nicméně infrastruktura bude o trochu stabilnější. Toto řešení ale není vhodné použít, pokud je multicast využíván pro šíření většího objemu dat.
- Upravit specifikaci protokolu, aby nevyužívala multicast pro překlad IPv6 adresy na MAC adresu. Toto řešení nicméně není na pořadu dne. I pokud by se v budoucnu použilo, potrvá několik let, než by se tato optimalizace dostala do koncových systémů. Reálně tedy v dnešní době nic neřeší.
- Omezit množství multicast/broadcast dat, které je zasláno do CPU přepínače, pokud to zařízení podporuje. Nevýhodou zde je, že může dojít k zahození relevantního provozu.
- Rozdělit architekturu sítě na menší celky použitím více směrovačů/L3 přepínačů. Toto může pomoci proti problémům s velkým množstvím klientů, nicméně to nevyřeší problém cíleného útoku.
Multicast a WiFi
Zcela samostatnou kapitolou je problematika multicast vysílání IPv6 v bezdrátových sítích. Připomeňme si základní charakteristiky bezdrátových sítí.
Zásadním rozdílem oproti drátové nebo optické infrastruktuře je, že bezdrátové sítě fungují v režimu half-duplex, tedy pouze jedno zařízení může vysílat, ostatní v danou chvíli mohou pouze naslouchat. Zařízení jsou také typicky v různých vzdálenostech od AP (Access Point) a používají tak rozdílné rychlosti a způsob kódování. Zjednodušeně řečeno, čím je zařízení dál od AP, tím používá robustnější kódování a tedy i nižší přenosovou rychlost.
Pokud AP zasílá uživatelům multicast rámce, snaží se je zaslat co nejspolehlivěji tak, aby došla na všechna, i vzdálená, zařízení - tedy zasílá je co nejmenší rychlostí. Přenosová rychlost je pak typicky 1Mbps nebo 6Mbps. Zaslání jednoho multicast rámce tak časově blokuje médium po dlouhou dobu a může zabrat tolik času, jako odeslání několika unicast rámců. Jelikož ve WiFi sítích nejsou multicast a broadcast rámce potvrzovány, může také dojít k tomu, že zařízení data nepřijme a je pak záležitost vyššího protokolu, aby zajistil jejich případné přeposlání.
Dalším charakteristickým znakem bezdtrátových sítí je, že jsou používány primárně mobilními zařízeními, případně různými senzory, napájenými baterií, kterou se snaží co nejvíce šetřit. Standard 802.11 pak umožňuje, aby zařízení sdělilo AP, že se uspí. Pokud AP registruje pro uspané zařízení nějaká unicast/multicast data, uchová si je a přepošle je danému zařízení, až se znovu probudí. Tento mechanismus může značně prodloužit životnost daného zařízení na baterii. Spotřeba zařízení se pak může pohybovat okolo 10 mA při uspání a něco mezi 100 až 150 mA při přijetí multicast rámce, jak zdokumentoval Yoann Desmouceaux v draftu Power consumption due to IPv6 multicast on WiFi devices u zařízení Samsung i9195.
Protokol IPv6, který opírá většinu své signalizace o multicast, pak dokáže v bezdrátové síti způsobit pár nepříjemností. Této signalizační komunikace navíc není zcela málo. Zařízení si totiž generuje více IPv6 adres, kde pro každou musí ověřit její unikátnost a přihlásit se do odpovídajících multicast skupin. Jedná se typicky o desítky multicast paketů s každým připojením zařízení do WiFi sítě. Problém také je, že zprávy Ohlášení směrovače jsou zasílané všem zařízením v síti. Jelikož typický scénář při připojení zařízení je, že si pomocí zprávy Výzva směrovači vyžádá konfigurační parametry, daných zpráv může být ve velké síti velké množství. Protokol NDP, který zaštiťuje všechny tyto konfigurační IPv6 zprávy navíc není příliš připraven na to, že se některé pakety ztratí. Ztrátovost ale ve WiFi sítích není zas tak výjimečná věc a takové ověření unikátnosti IPv6 adresy pak může poněkud “drhnout”.
Již zmíněný draft, také analyzuje dopad IPv6 multicast vysílání na zařízení ve WiFi sítích a dochází k závěrům, že už u 30 zařízení v síti se spotřeba baterie vlivem IPv6 multicast dat zdvojnásobuje. U větších sítích (600 uživatelů) může být až 15x větší.
Jak z této šlamastyky ven? V současné době není příliš mnoho kontrolérů, které by podporovaly nějaké formy optimalizace IPv6 multicast komunikace. Cisco umožňuje aktivovat techniku RA throttling, která omezuje množství zpráv Ohlášení směrovače. Těch totiž může být ve velkých WiFi sítí opravdu hodně, protože si každé WiFi zařízení žádá o zaslání konfiguračních parametrů při každém připojení. Princip Ra throttling je pak vcelku jednoduchý - AP propustí pouze zprávu co definovaný interval. Další optimalizace - NDP proxy na AP, zasílání Ohlášení směrovače pomocí unicast zpráv atp., popisuje draft Reducing Multicast in IPv6 Neighbor Discovery. Tématem se také zabývá například Eric Vyncke ve své prezentaci na IPv6 Council Belgium, případně Christopher Werny ve své prezentaci.
Tyto optimalizace jsou zatím většinou ve stádiu diskuzí a nenajdete moc zařízení, které by je podporovalo. Některé optimalizace také vyžadují změnu standardu, což je sám o sobě velice dlouhý proces. V případě, kdy se sahá na integrální součásti IPv6 jako navrhují nynější optimalizace, tak diskuze bude o to delší. Reálné implementace tak jsou zatím v nedohlednu.
Závěr
IPv6 multicast měl zefektivnit komunikaci klientů a zabránit vytížení koncových zařízení, jak byli navrhovatelé protokolu svědky v 90. letech. Proto se multicast komunikace u IPv6 použila pro celou řadu obslužných činností. Poněkud se ale zapomnělo na fakt, že efektivní doručení multicast dat musí podporovat samotná infrastruktura. Optimalizace přeposílání multicast dat stojí ale přepínače a směrovače určitý výkon, což ve větších sítích nebo datacentrech může vést k problémům s jejich přetížením. Vzniká zde totiž velký počet IPv6 multicast skupin, jelikož IPv6 zařízení si typicky adres konfiguruje několik. Síťový administrátor si tedy musí dát pozor zejména na to, aby znemožnil útočníkovi využít protokol MLD pro vedení DoS útoků a také aby vytvořil dostatečně robustní infrastrukturu, která bude schopna pojmout velké množství IPv6 multicast adres. V současné době připadá na koncové zářízení minimálně dvě, průměrně čtyři multicast adresy. Částečně by daný počet mohla snížit implementace RFC 7217, která doporučuje vytvářet náhodné identifikátory s vazbou na síťový prefix. Zařízení by si tedy ve stejné síti mělo vždy vygenerovat stejnou náhodnou adresu. Počet multicast skupin by se pak zmenšil, nicméně implementací zatím nedisponuje žádný operační systém. Implementaci lze nicméně vyzkoušet v podobě userspace aplikace dhcpcd. I v tomto případě je ale třeba počítat s několika IPv6 adresami na jedno zařízení, protože dané RFC neřeší problematiku dočasných IPv6 adres. Zcela novou sérii problémů přinesl multicast do WiFi komunikace. Z bezpečnostního hlediska se však nejedná o nové bezpečnostní hrozby. Přemíra multicast komunikace v IPv6 se tak projevuje pouze v neefektivní komunikaci a rychlejším “vysáváním" baterek.
