Vlákno názorů k článku Den IPv6 proběhl a ke kolapsu nedošlo od anonym - IPv6 jako takové není až tak špatný protokol....
-
IPv6 jako takové není až tak špatný protokol. Ale kvůli věcem ohledně autokonfigurace ho prostě v koncových sítích nemůžu nasadit. Potřebuju filtrovat počítače s konkrétními adresami a ne aby se mi počítače konfigurovaly samovolně. V tom vidím jediný zásadní problém s nasazováním IPv6 v koncových sítích. Kdyby nic jako autokonfigurace neexistovalo, nebo to šlo lehce vypnout, mám pocit, že IPv6 by bylo daleko jednodušší na nasazení, než je teď.
S tím souvisí i to, že měl být zachován DHCP server ve stávající podobě, jako ho známe teď. A ne nějaké nesmysly s DUID. MAC adresa je přeci taky unikátní a dostanu stejnou adresu pro Windows, tak pro Linux. Navíc, při reinstallu systému se nemění.
Kdyby IPv6 fungoval tak, že budeme mít jak DHCP, tak RA, přičemž by bylo na správci, pro co se rozhodne, bylo by to fajn. DHCP by fungoval na základě MAC, uměl by nějakým parametrem vypnout autokonfiguraci a vše by běželo "podobně" jako na IPv4.. Kdežto přes RA by se sdělil jen prefix podsítě a autokonfigurace by mohla svištět vesele dál. Toho by se např. dalo využít u Wifi sítí v budově. S tím samozřejmě, že při použití obou systémů by mělo mít prioritu DHCP a nebo by byla volitelná přes DHCP či RA
-
f. (neregistrovaný)
Zatial existuje iba RA guard - blokovanie "bogus" ipv6 smerovacov. Pracuje sa na implementacii "ip source guard" pre IPv6 podobne ako to funguje na IPv4 (pustaju sa iba dvojice ip-mac, ktore autorizoval dhcp server). Linux ma uz niekolko rokov v iptables modul eui64, ktory pusti iba IPv6 adresy v EUI64 formate (ip adresa odvodena z MAC) - nevyhoda je, ze na windows sa musi explicitne vypnut nahodne generovanie IPv6 adresy (privacy extension), aby sa pouzivala ako primarna ta EUI64, co v sietach, kde je velka migracia roznych klientov je dost problematicke.
-
Bezpečnost je v tomto případě stejná, jako je ve světě IPv4. Zkusím to vysvětlit na následujícím modelu....
Ačkoliv jsem maturoval před pár týdny, spravuju síť na jedné menší obchodní akademii (cca 200 žáků). Naši síť tvoří 7 Cisco SW, 2 linux routery a asi 120 počítačů plus tiskáren. V současné době je stav takový, že mám síť rozdělenu do 6 VLAN a v každé z nich mám jinou adresaci. Toť asi k současném stavu, kdy chodí vše jak má.
Nyní si vemte, že bych chtěl zavádět IPv6. No fajn, takže to znamená získat nejlépe native konektivitu od providera (není problém) a začít rozdělovat podsítě. Taky v pořádku. Ale jak jsem psal výše. Nejhorší na IPv6 je právě a jen jeho spravování. Nyní mám všechno děláno přes DHCP s tím, že mám vytvořeny rezervace na základě MAC. To je na systému nezávislé a chodí to naprosto spolehlivě a JEDNODUŠE. Teď si vemte, že bych tam měl nasadit IPv6. V tu chvíli se ze sítě, která je srovnaná a přehledná stane síť naprosto rozházená a nesrovnaná. Proč ? Odpovím si sám. Autokonfigurace.
Současný stav je takový, že fajn, použiju RA, ale v tu chvíli si PC vygeneruje pseudonáhodnou síťovou část adresy. No fajn, ale jak poznám, které PC je lektorské, abych si ho povolil na proxy ? To to mam hledat podle MAC adresy a přepočítávat si ji do IPv6 ? no to snad ne. V IPv4 kouknu a vidim, že adresa 192.168.x.100 je lektorské PC.... A nebo mohu použít DHCPv6, které ovšem nesdělí default-gateway a stejně pracuje na základě nějakého DUID, které se ovšem s reinstalací systému mění a není pro všechny systémy stejné.
Z toho jasně plyne, že jediný opravdu reálný problém nasazení IPv6 v koncových sítích je jen a jen jeho složitost na autokonfiguraci a tím pádem i bordel v síti. Obcházet 120 zařízení a všude nastavit statickou IP, to opravdu nee. Pokud by byli lidé, kteří IPv6 vymýšlí při smyslech, stačilo by to implementovat tak, jak jsem psal výše a většina složitostí by byla eliminována.
Navíc, píšete tu o bezpečnosti. To je ale prašť jako uhoď v IPv4. Klient si může změnit MAC adresu, může změnit IP a může změnit i DUID. To je fakt. Ale na toto stačí podle mě 3 písmenka - ACL. Pokud uživateli na klientské stanici nedáte práva k těmto změnám, tak nic z toho nehrozí. Tím myslím i zabezpečení biosu, bootování, DVD mechaniky apod. V tu chvíli si nikdo neškrtne ani s LIVE CD. Můžete namítnout, že v tu chvíli si přinese někdo svůj PC a tohle vše obejde. To ano. Ale proto existuje věc jako 802.1X a RADIUS.
Nejsem sice žádný bezpečnostní fanatik, ale u nás ve škole to mám takto.
1) na žákovských PC vypnuty USB, DVD mechaniky, zaheslovaný BIOS, zašroubovanou case
2) studenti i učitelé mají omezená práva, tudíž změna MAC, IP či DUID je vyloučena.
3) celá drátová síť je zabezpečena pomocí 802.1X, kdy se ověřuje proti Active Directory identita počítače. Jakmile není v AD, tak si prostě neškrtne. Linux na desktopech nepoužívám a ve velkém prostředí ani používat nehodlám, takže tohle neřešim.Můžete mi dát za pravdu, můžete se mnou nesouhlasit. Takhle to prostě vidím já. Dokud nebude možnost volit mezi RA+SLAAC a DHCPv6, jak jsem psal výše, tak se IPv6 budu bránit zuby nechty. Podle mě má RA+SLAAC odůvodnění jen v podnikových wifi sítích a v nezabezpečených sítích. Ale v sítích, kde potřebujem pořádek mi lépe vychází použití DHCPv6 tak, jak to navrhuju.
Můžu se zeptat, jak pořádek v koncových sítích řešíte vy ?
-
Santiago (neregistrovaný)
Nejak nevidim, v cem je problem. Pokud mate tabulku MAC - IPv4, tak z ni muzete snadno vygenerovat lektorske IPv6 adresy (ktere se prideli pres SLAAC/RA) a ty povolit na proxy. Nebo jeste lepe oddelit lektorske PC do samostatne vlan a pridelit jim jiny prefix.
Souhlasim, ze DUID namisto MAC adresy u DHCPv6 je pitome reseni.
-
Tak jediné k čemu je DUID dobré, je, že vím, komu tu danou adresu dávám. Takže pokud mám tu potřebu registrovat DUID a reagovat na změny v případě přeinstalování OS, tak všem neregistrovaným DUID přidělím adresy z nějakého poolu a pak je při přístupu na web transparentně přesměruju na webserver, kde si zaregistrují/přeregistrují svoje DUID. Stejně jako bych to udělal v případě, že si někdo vyměnil síťovku v počítači a chce stejnou IPv4 adresu. (a to se ještě nebavíme o různých windowsových přihlašovacích skriptech, kde se to dá určitě udělat automaticky při přihlášení do domény)
-
TP (neregistrovaný)
Myslenka dobra az na jeden problem, ze tohle ten uzivatel bude muset absolvovat hned 2x. Jednou pro IPv4 a pak pro IPv6.
Asi se to da poresit nejakym sikovnym javascriptem ktery si na tom registracnim webu jednou tapne na IPv6 a jednou na IPv4 adresu.
Mimochodem, tohle vytvari zajimave kombinace, protoze napriklad google uzivateli funguje (po IPv4), ale na imap server se z neznameho duvodu nedostane, protoze ten uz je napriklad dostupny po ipv6 - urcite se to bude dobre diagnostikovat :-).
A pritom stacila takova drobnost - zanechat v pozadavcich DHCPv6 klientu i MAC adresu a razem by bylo vse jednoduche.
-
TP (neregistrovaný)
Ta souvislost je velice prosta. Pokud by byla krome DUIDu (ten mi nijak nevadi) v pozadavcich zachovana i linkova adresa zadajiciho rozhrani tak si jednoduse vygeneruju dhcpdv6.conf po vzoru dhcpd.conf tedy:
host pcXXX {
hardware ethernet 08:00:09:aa:f4:cf;
fixed-address 2001:aaa:bbb::<napr. nejak zakleta IPv4>;
}a hodne veci se mi s tim zjednodusi. Takto musim vymyslet zcela novy mechanizmus jak se dostat k tomu DUIDu, coz nemusi byt ve vesech prostredich uplne snadne.
Prave to, ze je mnohdy mechanizmy v siti hodne prekopat, docela dost lidi od zavadeni IPv6 odrazuje :-(.
-
Aha, taková trivialita mne teda nenapadla. V tom případě se to holt udělá na dva kroky. V prvním kroku z DHCP serveru přidělím adresu z poolu, tím vznikne vazba DUID-IPv6 adresa, následně z neighbour-cache vytáhnu vazbu IPv6 adresa - MAC. Zbytek řešení je stejně triviální a můžeme nechat za domácí úkol :-)
-
tomfi (neregistrovaný)
Nevím kde přesně je problém.
Ve firemním prostředí dělá registraci administrátor.V domácím prostředí zákazník dostane celý prefix na router. Jak si přiděluje adresy svým zařízením doma, to je jeho věc.
V těch řídkých případech, kdy bude zákazník požadovat připojení PC přímo "do zdířky" ISP (tedy bez možnosti využít jednou zaplacený internet pro připojení mobilu, telefonu, televize, herní konzole apod.) si to holt bude muset řešit nějakou "registrací".
Pokud jsem se trefil s tím ISP tak jenom dotaz...
To zase chcete zákazníkům "prodávat" adresy a limitovat počet zařízení a jako "extra službu" budete prodávat připojení celé domácnosti?... to už můžete rovnou dodat, že IETF vám limituje příjmy, protože chcete klientům přidělovat IPv6 privátní natované adresy. (Aby dostal opravdu tu "nejkvalitnější" službu) -
TP (neregistrovaný)
Pravda, v samotnem DUID je zakleta MAC adresa a vetsina systemu je takto i vyvari, ale nemusi (viz. http://www.ietf.org/rfc/rfc3315.txt). Nicmene ma tom (jak uz to tak v IPv6 chodi) jsou 2 hacky:
- s DUID by se melo vzdy pracovat jako s celym retezcem viz. prislusne RFC:
Clients and servers MUST treat DUIDs as opaque values and MUST only
compare DUIDs for equality. Clients and servers MUST NOT in any
other way interpret DUIDs.To by jeste nevadilo. Zadne RFC neni svate tak ta moznost teoreticky prichazi v uvahu. Ale
- DUID nemusi byt vytvoren na zaklade MAC adresy karty kterou komunikujete. Takze pokud jste na Ethernetu muze DUID obsahovat MAC adresu WiFi a obracne. Takze celkove receno i kdybyste se pokusil vycenichat MAC adresu z DUIDu tak vam ten udaj je stejne k nicemu, protoze koncovy system pouzije ke komunikaci jinou linkovou adresu nez je v DUIDu.
-
To stejné dělají překvapivě i současné počítače na IPv4. Do jednoho z těch vnitřních polí (myslím, že GIADDR) klidně narvou adresu bezdrátové síťovky, ačkoliv používají drátovou síť (a switch se vzteká a dál nepustí). Takže nic nového pod sluncem v IPv6.
DUID se pro DUID-LL vytváří správně z built-in síťovky. Nakonec chcete registrovat počítač, ne síťovku.
Pořád mně nedochází, jakým zásadním způsobem se liší GIADDR v DHCPv4 a DUID v IPv6. Jediné, co mne napadá, že OS se přeinstalovává častěji než síťovka.
-
Pavel Šimerda (pavlix) (neregistrovaný)
„DUID se pro DUID-LL vytváří správně z built-in síťovky. Nakonec chcete registrovat počítač, ne síťovku.“
Na kterých systémech to tak je? Protože tohle by stačilo jako řešení (skoro) celého problému.
„Pořád mně nedochází, jakým zásadním způsobem se liší GIADDR v DHCPv4 a DUID v IPv6. Jediné, co mne napadá, že OS se přeinstalovává častěji než síťovka.“
Říká ti něco bootování ze sítě?
-
> Na kterých systémech to tak je? Protože tohle by stačilo jako řešení (skoro) celého problému.
RFC 3315, 9.4.
> Říká ti něco bootování ze sítě?
Jo, a co má být? Pokud chce počítač nabootovat ze sítě přes IPv6, tak si DUID vytvoří nezávisle na OS, bude aso DUID-LL, tedy jiný než má OS, ale to neznamená, že ho v DHCPv6 nemůžu mít nabindovaný na stejnou IPv6 adresu. Pak je ovšem otázka, jak se s tím vypořádá OS. IMHO až to bude aktuální, tak se výrobci hardware a OS dohodnou, jak to DUID budou tedy dělat. Osobně bych to viděl na malý patch, který OS řekne "pokud už mám nabootováno ze sítě, tak DUID neměň".
-
Lukáš Doležal (neregistrovaný)
Proxy: ověřování přes AD (nebo jinak) podle uživatelského účtu. Transparentně přes IP je bezpečnostní riziko.
Autokonfigurace: Na switchích nastavit ACL na podle tabulky port/IP/MAC - když máte takový pořádek, jistě takovou tabulku již někde máte, jen s IPv4 (při troše snahy to lze automatizovat). Ale jinak stejně nechápu proč to řešíte, protože pokud máte 802.1x tak máte jistotu, že se do sítě připojuje stroj, který spravujete a tam nastavíte DHCP a vypnete stateless ;) ACL připadá v úvahu u ISP..
DUID: počítače spravujete, máte možnost DUID nastavit/zjistit - takže v tom problém nevidím (určitě také nebude větší problém to automatizovat). Naopak nespojenost s MAC vidím jako výhodu (vyměním počítač, tak akorát nastavím stejné DUID jako starý, vyřazený)
Souhlasím s Vámi, že IPv6 přináší nové a jiné vlastnosti než IPv4. Ale podle mě je potíž v tom, že lidé jsou na něco zvyklí a nechtějí to měnit. Když se nad některými věcmi zamyslíte, zjistíte, že jsou třeba lepší. Mluvit o tom, že lidé tvořící IPv6 nejsou/nebyli při smyslech, bych řekl, Vám nepřísluší ;)
-
TP (neregistrovaný)
Dovolim si par komentaru:
ad 1 - Autokonfigurace: tabulka port/IP/MAC je sice hezke tvrzeni ma nekolik problematickych ale. Prvne musim mit koncove prepinace s podporou IPv6 ACL. Tech je jaksi na trhu za rozumne penize pomalu. I kdybych tohle dokazal, tak ve svete IPv6 vznikaji napriklad LL adresy nahodile (Windows 7). 802.1x mi problem prilis neresei, protoze zajistuje autentizaci pouze na linkove vrstve - viz. thread http://www.root.cz/clanky/den-ipv6-probehl-a-svet-se-nezboril/nazory/387080/. Pokud vychazite z predpokladu, ze do site pripojuju pouze stoje ktere spravuju pak tyhle veci ani resit nemusim - mam nad vsim kontrolu. Nicmene zde se prave snazime resit mechanizmus pripojovani PC/zakazniku napriklad v panelakove siti, kde jaksi nad temi koncovymi zarizenimi z principu neni zadna kontrola, resp. neda se prilis zasahovat do jejich konfigurace.
ad 2 - DUID : nastavovani/meneni DUID je vec hodne problematicka. Schvalne zkuste si pohledat jak to udelat treba na Windows 7. Tohle rozhodne neni provozne pouzitelne.
ad 3 - nove vlastnosti : je to velice diskutabilni. Kdyz se na nektere veci podivate, tak na prvni pohled vypadaji nesmirne lakave (rozsirene hlavicky, likvidace broadcastu, diskutovana autokonfigurace, bezpecnost, ...), nicmene pokud jdete do hloubky, tak zjistite ze maji nektera velice problematicka ale. Jenze prave na tech detailech po certech zalezi. Samotnou skutecnost, ze jsou lide na neco zvykli a to ze se neco dela nejak v IPv4 vic nez 10 let (napr. autokonfigurace) nelze zkratka ignorovat. Naopak to svedci lecos jiste vyzralosti tohoto postupu. Bohuzel tyto zkusenosti jsou v ipv6 casto ignorovany s ideologickou vidinou neceho lepsiho. A vysledek je jednoduchy. Spravci/firmy radeji blokuji/nezavadeji IPv6 jako celek, protoze se tech novych veci proste boji (a chapu je). Vysledkem je, ze dnes mame v koncovych sitich cca 0,3% penetraci IPv6 i presto, ze tak odhadem 30 - 40% systemu v nejake podobe podporuje IPv6 (Win Vista/7, MAC OS, Linux/BSD).
V pripade autokonfigurace - co je napriklad tak strasne spatneho na DHCP(v4) ? Proc se tento koncept musel zcela zaslapat v podobe SLACu a pak prostrednictvim DHCPv6, ktere vypada jak vypda? Pricemz pridani DUIDu jako dalsi volby by rozhodne nebyl problem (klidne i do DHCPv4). Kazdy by si pak vybral, kterou polozku vyuzije pro identifikaci klientu - jinymi slovy vlk by se nazral a koza zustala cela.
-
orim (neregistrovaný)
Souhlas.
Prostě jde především o to, že vývoj protokolu v budoucnu doiteruje buď k úplné funkčí autokonfiguraci včetně potřebných bezpečnostních mechanizmů, nebo se začne používate dhcpv6. Záleží především na tom jaké mechanismy bude podporovat OS Windows.
Velkým problémem IPv6 jsou také rozšířené hlavičky, které dnes nejdou rozumně parsovat v hardware (kvůli plovoucí délce a možnosti jejich nekonečného opakování).
-
TP (neregistrovaný)
Souhlas. Autokonfigurace v IPv6 je naprosty des a osobne to vidim jako celkem velkou prekazku zavadeni IPv6.
K tomuto tematu se posledni dobou pomerne casto vynoruji diskuse (s cca mesicni periodou) tech kteri pozaduji aby DHCPv6 zaclo fungovat jak se ocekava, a tech kteri si za zadnym koncem nechteji nechat vyvratit, ze bezstavova autokonfigurace (SLAAC) je uzasna vec.
Posledni takova dikuse se odehrala behem poslednich tri dnu v listu operatoru severni ameriky - viz. http://seclists.org/nanog/2011/Jun/657, kde padaji i pomerne hodne kriticka slova smerem k IETF.
Bohuzel i pres VELKE vyhrady ke SLACu ze strany operatoru a pomerne jasnych prikladu toho, ze je to velike nestesti si stale nekteri nechteji tuto "hracku" nechat vzit.
Ale to je holt realita IPv6. Vymysleji se veci typu SLAAC, 6to4, teredo, rozsirene hlavicky, SEND ktere praxe tak jak tak zavrhne, nicmene vzdy trva cca 10 az 15 let se takovycho "vylepseni" zbavime.
-
TP (neregistrovaný)
To samozrejme neni pravda. Vnucuje. V okaziku kdy se do site pripojuji nejroztodivnejsi zarizeni, tak autokonfiguraci vypnout nemuzu. Jak se pak koncova zarizeni dozvi udaje o konfigurace site? Nastavim to vse rucne? Nebo pouziju DHCPv6 a rucne nastavim jen default GW? Bohuzel autokonfigurace je vec na ktere se musi shodnout fakt vsichni aby byla rozumne pouzitelna - tak jak to postupem casu doiterovalo v IPv4 k DHCP.
Dalsi problem je, ze SLAAC tak jak je navrzeny tak se prakticky neda zabezpecit a ma to pomerne fatalni presahy i na IPv4. Bohuzel tohle jsou argumenty, ktere se neustale bagatelizuji. Mnozi IPv6 protagoniste namisto aby pripustili, ze na tech problemech fakt neco bude, tak neustale opakuji, ze problemy vlastne nejsou problemem, zabezpeceni je stejne jak v IPv4 a za vse muzou jen nechopni spravci, zli vyrobci a nevim kdo jeste...
Je jasne, ze tyto problemy se casem vyresi akorat nemuzu pochopit, proc je snaha si v IPv6 nektere veci zamerne komplikovat, kdyz existuji jiz casem overena a pomerne primocara reseni.
-
TP (neregistrovaný)
Bohuzel je. DHCPv6 je postaven tak, ze prakticky nemuze fungovat bez SLAAC, resp. sireni RA (flag M). Nemam totiz cestu jak sdelit klientovi default GW. Snaha propasovat default GW byla v roce 2009 navrzena, nicmene IETF ji shodilo ze stolu (viz. http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00)
Tak utekly 3 roky, nez se problem podarilo do agendy IETF propasovat dalsi navrh dhcpv6-route-option (viz. http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-01), ktery uz nastesti nebyl shozen ze stolu v samem zarodu a pokracuje do dalsiho zpracovani. Draft je sice k dnesnimu dni vyexpirovany, nicmene je naplanovan v agende na 81. meeting IETF. Musime tedy doufat.
Problem je, ze i kdyz bude prijat, tak bude trvat radu let nez se dostane do implementaci OS. Problem je take se soucasnou podporou DHCPv6, ktera prakticky rozumne funguje jen v MS produktech, jakz takz v UNIX-like produktech. V OS X mate napriklad smulu. Takze pokud chci dnes zavest IPv6 fungujici ve vetsine OS nemam jinou moznost nez SLAAC.
Mezi dalsi lahudky patri, ze jsem schopen 1 vhodnym RA paketem (slovy jednim) zcela zrusit konektivitu vsem klientum v lokalni siti podporujici SLAAC - coz nampriklad naprosto s klidem udelaji Win Vista se zaplym Internet Connection Sharing.
Takze z celeho toho vyplyva, ze volba vhodneho prostredku autokonfigurace tak aby nad siti byla jakz takz kontrola a aspon primerena uroven zabezpeceni je prakticky neresitelna uloha. Pokud chce spravce rozumne zabyzpecit sit tak mu nezbyva nez zakazat IPv6 protokol jako celek idelane na accesovem portu a je po problemech. Bohuzel - hodne spatne vysvedceni pro IPv6... :-(
Co me na tom stve je to cele zpusobene tim, ze je odmitano zapracovat reseni, ktere je jiz praxi proverene a leta pouzivane bez vetsich vyhrad.
-
TP (neregistrovaný)
Heh... mi to fakt zkratka neda... :-)
Ty implemetacni detaily jsou dost problem. Ono tem vselek jmenem RA guard neni zas tak vsespasitelny. Staci ten paket nafragmentovat anebo podstrcit vhodnou hlavicku, ktere ten fitrujici switch nerozumi, nicmene koncovy system ano.
Viz. http://www.networksecurityarchive.org/html/FullDisclosure/2011-05/msg00446.html .
Takze s celyma RA Gaurdama se muzou jit vsichni klouzat a delat packet reassembling asi nebude uloha vhodna pro accesovy switch. Reseni je proste. Prohlasime ze urcite ICMPv6 zpravy nesmi byt fragmentovane a nesmi obsahovat rozsirene hlavicky. Viz. http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt
Akorat zas bude trvat dlouho nez ty implementace OS budou tyto pakety interpretovat spravne. Takze vyrobce switche vas odkaze na toto RFC (az bude RFC) a vyrobce OS vam sdeli, ze toto RFC nepodporuje. No a spravce si to muze resit jak chce.
Btw. u vyrobce si stezovat muzete. Pak si ale nestezujte, ze switch, ktery podporuje tyhle prvky bude o neco drazsi. Takze si cilove koupite msito gigabitovych portu jen stovkove. Odmenou za to je ze budete mit napr. RA guarda, ktery vas stejne neochrani proti cilenemu utoku. No... nevim teda...
-
TP (neregistrovaný)
No - jenze ono fakt podle me horsi je. Pokud si na notasu zapnete DHCP server tak tim budou postizeni jen nove pripojeni klienti, protoze ti existujici si jiz budou prodluzovat adresu primo u DHCP serveru. Jeste neni 100% jistota, ze vas DHCP server odpovi rychleji nez ten spravny. Navic ty ochranne prvky jsou dneska uz docela znamy/bezne pouzivane.
Pokud takove RA pustite v IPv6 siti, tak jsou vsichni klienti vyrizeni prakticky okamzite. Faktem je, ze kdyz se neco takoveho stane tak se tenhle stav da lepe opravit nez podvrzeny DHCP server s nastavenym dlouhym casem :-)
Ochrana zatim... hmm no, spise je to spatne
RA guard - obejitelny viz. problemy s fragmentaci a rozsirenymi hlavickami
SEND - neni nativne podporovan zadnou platformou
ACL - jista sance je, musi to podporovat prvek a fragmentaci musi resit reasemblng :-(Takze realita je takova, ze na takovy typ cileneho utoku dneska muzete tak akorat bezradne koukat. Resp. dokazete to resit s naprosto silenymi naklady. A to zatim jen blokujeme RA. Ani jsme se nepriblizili k vecem jako je validace komunikujicich IP/MAC adres.
-
Santiago (neregistrovaný)
No, pokud si v (IPv4) siti nastavim stejnou IP jako brana, taky okamzite zacne mit problem znacna cast klientu (a dalsi se brzy pridaji).
Zakladni problem vidim v tom, ze na sitove vrstve (a to jak v IPv4 tak v IPv6) neni rozumne resena bezpecnost zakladni infrastruktury (ARP, pridelovani adres ..), cele je to navrzene spis pro site nezavislych pocitacu nez pro centralne spravovane site. Pak se to obchazi silenymi hacky jako RA/DHCP guard ve switchich.
-
mb (neregistrovaný)
DHCP stejně neřeší to, že si může uživatel nastavit IP adresu sám, stejně tak i MAC adresa se dá změnit a nakonec ani DHCP protokol není zabezpečený. Pokud to někdo s bezpečností myslí vážně tak se stejně musí autorizovat uživatel a né počítač např. na linkové vrstvě pomocí 802.1X nebo nějaký proxy server a při autorizaci se může rovnout spojit MAC/IP adresa s konkrétním uživatelem a to funguje stejně s IPv4 i IPv6.
-
TP (neregistrovaný)
Bohuzel to je caste a mylne dogma, ktere kolem 802.1x koluje. 802.1x mi resi autentizaci pouze na linkove vrstve. Dozvim se tedy, ze za PC s MAC adresou XY-XY-XY-XY-XY-XY sedi uzivatel ABC, pripadne autentizoval se na portu D switche E.
To samozrejme samo o sobe nic nerika o tom jakou IPv4/IPv6 adresu uzivatel pouzil - obecne vzato muze pouzit jakoukoliv. V IPv4 je mnohdy donucen k tomu (konfiguraci port security na switchi), aby mu fungovala IPv4 adresa pridelena jen DHCP serverem. Tim padem je mozne na DHCP serveru spojit autentizacni informace radius serveru a DHCP databazi a mam co jsem chtel.
V IPv6 na tohle muzeme zapomenout. Pro identifikaci klienta v DHCPv6 se pouziva DUID, ktery nema vztah k MAC adrese pouzitou ke komunikaci. Takze nemohu provest ono propojeni mezi udaji na radiusu a DHCPv6 databazi, protoze nemam zadny udaj, kterym bych veci dokazal propojit.
Reseni je sbirani obsahu Neighbor Cache na smerovaci. Nicmene to ovsem vyzaduje pomerne vyrazne poupravovat systemy, ktere se pouzivaji pro IPv4. Nastroju, ktere by to dokazaly delat neni mnoho (zatim co znam tak system NAV http://metanav.uninett.no/, system netdisco ve vyvojove verzi http://www.netdisco.org/ ci ubastlit si neco vlastniho). V kazdem pripade to nnei vec na jedno dopoledne.
Takze zaver: 802.1x neni vsespasitelne. Je to technologie ktera dela co se od ni ocekava, ale z principu fungovani pochopitelne nic nerika o identite uzivatele na vyssich protokolovych vstvach.
-
Pavel Šimerda (pavlix) (neregistrovaný)
1) Autokonfigurace jde lehce vypnout na routeru. Jediný problém je, pokud se někdo jiný vydává za router. Tento problém je přímou obdobou problému, kdy se na IPv4 někdo vydává za DHCP server. Lze řešit například filtrováním na switchi, stejně jako na IPv4.
Nový vývoj IPv6 přináší ještě experimentální na switchi nezávislé řešení v podobě SEND. Buď se to ujme nebo ne.
2) DUID je velmi dobrý nápad, pokud by to jeho implementace dotáhly do konce a ukládalo se například v nastavení BIOSu nebo v jiném trvalém úložišti, jako je to s MAC adresami.
Lidi, kteří potřebují MAC adresy k přidělování adres a zároveň jim z nějakého důvodu nevyhovuje bezstavová automatická konfigurace, se měli zajímat o IPv6 daleko dřív a včas připomínkovat. Teď už bohužel vznikly implementace bez toho.
Ale nasazení IPv6 je zatím malé, takže doporučuju tlačit na IETF, ať ještě informaci o MAC adrese do protokolu doplní, nebo tlačit na implementátory, aby DUID odvozovali z něčeho, co je pevně svázané s počítačem nebo našli způsob, jak DUID trvale ukládat.
3) Přesně tak to je, správce rozhoduje, jestli počítače budou používat autokonfiguraci (je to flag v router advertisement), DHCP na základě MAC jde teoreticky v lokální síti implementovat, ale musí se vyčíst MAC adresa z ethernetového rámce. Ale nebude to fungovat s relay servery.
RA určuje, která konfigurace se provede.
-
TP (neregistrovaný)
Ty fltrace, SEND - vyz. vyse. Neni to zas tak uplne snadne.
Jinak naprosty souhlas. Pokud ale sledujete deni v IETF, tak jakekoliv zmeny jsou hodne problematicke a mnohe byt dobre napady jsou mnohdy zatracovany. Ono na ne driv nebo pozdeji dojde (namatkou DHCPv6, NAT66, likvidate automatickych tunelu, Default GW v DHCPv6, Unifikace rozsirenych hlavicek, ...), ale jsou s tim spojeny zbytecne prodlevy - v lepsim pripade nekolik let.
Ale rozhodne souhlasim, ze vytvareni tlaku na zaklade praktickych zkusenosti je jedina cesta jak veci dat do nejakeho pouzitelneho stavu. To ovsem vyzaduje hodne namahy, casu a trpelivosti ze strany tech co se snazi na techto hladinach neco prosadit. To je kritika smerem k IETF, ktera zazniva i z rad vyrobcu, rady velkych operatoru atd. Viz. treba Juniper, ktery odmita opravovat problemy s RA s tim, ze si to ma opravit nejdrive IETF ve svych standardech.
