Vlákno názorů k článku Děravá IPv6, snadné nasazení DNSSEC a Turris (LinuxAlt 2013) od Pavel Šimerda - Pan Matěj Grégr odvedl (zřejmě s dalšími) ve...
-
Pan Matěj Grégr odvedl (zřejmě s dalšími) ve výzkumu zranitelností implementací IPv6 ACL skvělou práci. Podle mě je obrovská škoda, že její výsledky podává takto nesmyslně bulvárně. V přednášce libovolně zaměňoval problémy (i kdyby mnoha) konkrétních implementací za problémy protokolu, nerozlišoval jednotlivé specifikace IPv6, statickou a dynamickou konfiguraci. Přednáška měla hromadu závažných nedostatků, které sice přispěly k všeobecní senzaci, nicméně tím značně utrpěla důvěryhodnost.
A fakt mě to mrzí. Co si pamatuju, tak Tomáš Podermański podobné informace před časem na EurOpen.CZ podal rovněž v zábavné formě, ale bez nutnosti takovéhoto mlžení.
To nic nemění na tom, že si samotné práce a po přefiltrování balastu i prezentovaných výsledků vážím.
-
Jednalo se především o tvrzení, které se týkala zjevných implementačních chyb, která ale namísto toho byla aplikována na sadu protokolů. Dokonce k nim ani nenásledovalo dovysvětlení, jak mluvčí usoudil, že problém je v daném případě už ve standardu (a kterém!).
Hurónská tvrzení typu „vyzkušeli jsme pár nejznámějších implementací a na základě toho jsme usoudili, že prolomíme úplně cokoliv“ taky podle mě patří spíš do hospodského špičkování než do přednášky na veřejné konferenci.
Výsledkem podle mě bylo, že ti, co se v problematice nevyznají, si odnesli zcela mylné informace. Ti, co se nějakým způsobem vyznají zase museli pečlivě filtrovat každou větu, zda přináší nějakou informaci nebo je to jen plácnutí do větru typu.
Disclaimer: Byl jsem cca na posledních dvaceti minutách, předtím jsem byl v jiné přednáškové místnosti. Je možné, že byl začátek přednášky na lepší úrovni a tou dobou už se jen vařilo z vody.
-
Můj dojem je, že se tým na FIT VUT rozhodl, že IPv6 nemá rád, a proto místo řešení hledají problémy.
Já myslím, že je pochopitelné, že implementační úroveň je zatím na horší úrovni (či je naprosto nesmyslně licencovaná jinak než IPv4), ale to přece neznamená, že je "Děravá IPv6". Osobně mne tenhle bulvární styl diskreditace IPv6 také velmi mrzí, a jsem rád, že to řekl nahlas ještě někdo další.
-
Karel (neregistrovaný)
Pokud jde o bezpečnost, tak potřebujete lidi dva - jednoho, co chyby hledá, a jiného, co je opravuje. Takže je fajn, že někdo záměrně hledá chyby a problémy. Nepochybně se někdo jiný snaží je opravovat. Chápu, že někomu by spíš vyhovovala "security by obscurity" a že "chyba, o které se neví, není chybou", ale já osobně preferuji přístup "jestli je tam chyba, tak o ní chci vědět co nejdříve". O možném DDoS útoku se chci dozvědět na internetu a ne z logu mého routeru.
A bulvární styl odpovídá cílové skupině - mírně pokročilí uživatelé, kteří jsou schopni pochopit detaily, ale zároveň to nejsou ostřílení harcovníci, co "už to mají všechno dávno ošetřeno".
-
Jenda (neregistrovaný)
Nešťastné ale je, když chyby prezentuje ve FUD stylu, jako je to v článku (přednášku jsem neviděl). Například když někdo někdo obecné síťové chyby vydává za chyby IPv6.
> V IPv6 je rozdíl zejména v tom, že podporuje bezestavovou konfiguraci a síťové rozhraní může mít více IPv6 adres. "Konfigurace jednoho klienta je v IPv6 složitější, protože kombinuje stavovou a bezestavovou konfiguraci a přidává další vlastnosti."
V IPv4 totiž rozhraní nemůže mít více IP adres a rozhodně neexistuje víc způsobů konfigurace. Ehm.
> Konkrétně je možné útočit například pomocí DAD útoku. Jde o formu DDoS útoku, kdy útočník na všechny dotazy na adresy odpovídá, že jsou už využívány.
V DHCPv4 totiž NACKy spoofovat nejde, že?
> Dalším zmíněným útokem je Router Advertisement flood, kdy se do sítě posílá velké množství RA paketů.
ARP flood jsme taky nikdy nikde neviděli.
> Kromě DDoS je možné zaútočit sofistikovaněji pomocí MitM. Většina systémů má dnes ve výchozím stavu podporu IPv6 zapnutou, takže jsou tímto útokem ohroženy. "Klientovi pomocí RA řekneme, ať si informace zjistí od DHCPv6, který ovládáme. Tam můžeme například nadiktovat vlastní DNS servery a tím přesměrovat provoz."
ARP poison ani DHCPv4 poison taky neexistuje.
-
Karel (neregistrovaný)
Pomohlo by vám podívat se na historii obou protokolů. Řada známých problémů IPv4 nebyla známa v době, kdy IPv6 vznikalo. Boom "internetových útoků" přišel na konci devadesátých let. A to už bylo IPv6 hotové. Nenechte se mást tím, že se IPv6 teprve teď prosazuje, ve skutečnosti už příští rok bude mít volební právo.
-
Sten (neregistrovaný)
IPv6 tyhle problémy samozřejmě řeší, má IPSec a SEND, problém je spíš s nasazováním a využíváním toho řešení, které je ještě o několik řádů odlišnější od současných sítí s IPv4 a potřebovalo by to dalších nejméně pět až deset let vývoje, než to bude plug&play a dostatečně podporované jako třeba SLAAC (např. distribuci veřejných klíčů pro SEND přes WiFi handshake). Nakonec třeba takovou primitivní a naprosto zásadní věc jako RDNSS nepodporují šest let po příslušném RFC ani Windows ani Android. A protože IPv6 je už opravdu nutné začít nasazovat, tak se tohle při nasazování celkem opomíjí a kritici IPv6 to hned používají pro FUD — což je skutečně FUD, protože IPv4 má ty samé problémy, ale na rozdíl od IPv6 ani nemá řešení.
-
„A bulvární styl odpovídá cílové skupině - mírně pokročilí uživatelé, kteří jsou schopni pochopit detaily, ale zároveň to nejsou ostřílení harcovníci, co "už to mají všechno dávno ošetřeno".“
Já nejsem příznivcem bulvárního stylu, protože vede k dezinformaci a tudíž může ve výsledku vést k naprosto špatným představám a rozhodnutím. Mám rád zajímavé a živé přednášky, ale ne za cenu, že si z nich lidé odnesou špatné informace.
„O možném DDoS útoku se chci dozvědět na internetu a ne z logu mého routeru.“
To já samozřejmě taky, leccos se dalo vyčíst ze slavných článků Tomáše Podermańského. Právě tím, že je to důležité téma a že je za výzkumem v této oblasti hromada práce je mi líto, když se ta práce při prezentaci dezinterpretuje a znehodnocuje.
-
Filip JirsákStříbrný podporovatelOtázka je, kdo se takhle podanými chybami bude zabývat. A kdo se bude vůbec zabývat dalšími chybami hlášenými tím samým člověkem. Když se ze souhrnu dozvím, že "IPv6 na rozdíl od IPv4" a následuje příklad několika bezpečnostních problémů, které se úplně stejně týkají i IPv4, je to pro mne signál, že autora té přednášky nelze brát tak úplně vážně.
"Security by obscurity" nepropagují kritici té přednášky, ale naopak přednášející. Vytvořením zmatku v tom, co je důležité a co ne, co je nová chyba a co dávno platí i pro IPv4, totiž není odhalování chyb, ale jejich ukrývání.
-
Vladimír Veselý (neregistrovaný)
Jsem z FIT VUT a neřekl bych, že tu vedeme kruciádu proti IPv6. Poukazujeme na věci, které ve v6 nefungují, zatímco ve v4 už byli alespoň nějak řešené. Z mého pohledu dělat klon v4 ve v6 s tím, že bude mít větší adresní prostor, mohlo, jak se ukazuje, být lepší řešení, než si tam navymýšlet nové nekoncepční vlastnosti, jejichž vysvětlení či implementace pokulhávají (SLAAC, chování ND cache, problémy při parsování extension headers).
Nehodlám totiž tvrdit lidem, že po 17 letech existence v6 (a téměř 3 roky po vyčerpání volných IPv4 bloků) je "horší implementační úroveň pochopitelná" a že penetrace Internetu touto technologií v řádech tolika procent, kolik je na rukou prstů, je eklatantní úspěch, za který by se mělo IETF poplácávat po zádech.
Pokud bych se měl odvážit zkratkovitého uvažování, tak v6 toho umí stejně jako v4, jen s tím, že stojí víc, hůř se administruje a přináší k těm starým problémům i vlastní nové.
Přiznám se, že já jsem na LinuxAltu nebyl, a jsem tak rád, že mám možnost si přečíst výběr postřehů a odborný světonázor člověka, co byl na posledních dvaceti minutách osudové přednášky.
-
Sten (neregistrovaný)
Co je nekoncepčního na SLAAC? A co je naopak koncepčního na stavovém DHCP pro domácí sítě?
IPv6 sice existuje 17 let, ale velkou část té doby se převážně vyvíjelo a nasaditelné je jen cca 6 až 8 let: v Linuxu se IPv6 objevilo už v roce 1996 (1998 ve Windows), ale až v roce 2005 bylo uznáno za stabilní pro produkční nasazení (2007 ve Windows). IPv6 prostě není honem honem náhrada za docházející IPv4, stejně jako IPv4 nebyla honem honem náhrada za NCP a jeho vývoj také zabral deset let. Hlavní problém nasazení IPv6 je, že u přechodu na IPv4 stačilo říct „všichni od 1. ledna přestanete používat NCP a přejdete na IP“, protože internet (tehdy ještě ARPANET) byl velmi omezenou sítí s velmi pevnou centrální autoritou. Dnes se musí řešit i přechodové mechanismy, což je výrazně složitější, dražší a pomalejší.
Problémy při parsování extension headers jsou problémy implementace, ne v protokolu. Na rozdíl od IPv4 jsou extension headers (v IPv4 jen omezeně použitelné a nazývané options) velmi snadno iterovatelné, takže zahodit packet, když obsahuje RA header, je o dost snažší. Ano, mnoho implementací to dělá blbě, ale to je většinou proto, že k IPv6 přistupuje jako k novější IPv4.
Což je ten skutečný problém: IPv6 je velmi odlišné, protože to, co se u IPv4 dohackovávalo nebo obcházelo později (autokonfigurace, mobilní IPv4 adresy, QoS, podivné fragmentace, přečíslování sítí, multicast, link-local služby ap.; většina navíc ve stylu „za chvíli stejně přijde nový IP protokol, tak to můžeme splácat takhle“), má už v základu a kvůli tomu se samozřejmě chová dost jinak. Dokud budete k IPv6 přistupovat jako k IPv4 s větším adresním prostorem (a administrovat ji tak), nikdy nepochopíte, proč má ty nové vlastnosti a jak vůbec funguje, a zůstanete u „v6 toho umí stejně jako v4, jen s tím, že stojí víc, hůř se administruje a přináší k těm starým problémům i vlastní nové“.
-
Ivan (neregistrovaný)
Pv6 sice existuje 17 let, ale velkou část té doby se převážně vyvíjelo a nasaditelné je jen cca 6 až 8 let: v Linuxu se IPv6 objevilo už v roce 1996 (1998 ve Windows), ale až v roce 2005 bylo uznáno za stabilní pro produkční nasazení (2007 ve Windows).
Prvni pouzitelny IOS, ktery podporuje IPv6 a zaroven MPLS se objevil az letos.
Ono je neco jineho implementovat cast IPv6 v Ccku v kernelu a neco jineho mit "plnou" podporu v ASICu.C++ taky neni spatny jazyk. To ze trvalo vice nez deset let nez prisly kompilatory, ktere nemely zabugovanou implementaci je taky chyba implementatoru. Neni to problem v navrhu jazyka?
-
Sten (neregistrovaný)
Samozřejmě, implementovat IPv6 v ASICu je výrazně složitější než v Céčku, stačí se podívat, jak dlouho to trvalo, než bylo v ASICu implementované směrování pro IPv4 :-)
Trvalo to asi deset let soustavného vývoje na straně překladačů i na straně Stroustrupa a ISO WG. Tedy asi tak stejně dlouho, jako se vyvíjelo IPv6 od prvního RFC po stabilní implementace (vývoj těch implementací netrval tak dlouho proto, že by bylo IPv6 příliš složité, ale protože IPv6 se během té doby zkoušelo, měnilo a upravovalo). A taky se podívejte na C++ dnes. Nebo byste raději, kdybychom zůstali u Pascalu, Basicu a K&R C?
Jinak jak jsem už poznamenal, i IPv4 to trvalo deset let, než DARPA uznala, že je dostatečně stabilní pro nasazení. A pak jej protlačila silou.
-
j (neregistrovaný)
Proc vymejset nove veci jako trebas rizene vztrikovani, turbo, ... kdyz prece staci jen zvetsit motor ....
A o kvalite tohoto postu svedci uz jen "hůř se administruje" ... jiste, 3xNAT se administruje rozhodne lip ... hlavne je to prehledny ... proto mam v IPv4 firewallu cca 300 pravidel, a v IPv6 cca 60 ... dela to naprosto TOTEZ.
Mimochodem, Ipv4 se pouziva jaksi ... hmm pres 30 let ... kdyz pujdu az ke zrodu, tak 40.
-
KapitanRUM (neregistrovaný)
IPv6 šlo udělat o poznání lépe, dokonce zásadně lépe.
Všimni si, že řada kritiků a já jsem jeden z nich, nerozporuje potřebu nového protokolu, ale konkrétní realizaci IPv6. Samozřejmě je nám jasné, že byl nový protokol potřeba, ale proč z TurboDieselu (IPv4 je Turbo s Dieselem) přecházet na Plyno-prdový-motor IPv6? Přejít na něco jiného? Dobrá, je to potřeba, ale proč IPv6 v této podobě? Ale ano, chápu, že tobě IPv6 přidá dokonalejší než Mona Lisa, nám ne, proto se ptáme, jestli si náhodou nespadl na hlavičku.
To je celé. -
Sten (neregistrovaný)
Ano, většina ostrých kritiků IPv6 by radši současný bordel s IPv4 zachovala a jenom přidala delší adresy. To, že spousta věcí se musí řešit hacky a workaroundy ve stylu „ono to snad bude fungovat“ (uznávám, že většinou to funguje, ale občas taky ne a pak jste dost v loji, takže radši bych to tam neměl), jim jaksi nedochází, oni si svoje sítě jednou složitě nakonfigurovali a nechce se jim to měnit. Být tito kritici v DARPA, zůstali bychom u NCP.
-
Filip JirsákStříbrný podporovatel
To je myslím docela trefné. Jenže pak jsou tu ještě další lidi, kteří šli ještě o krok dál, a přemýšleli o tom, zda by se to dalo implementovat lépe. Zjistili, že vlastně ne a že IPv6 je plus mínus nejlepší možné řešení. Někteří z těch lidí, kteří si tohle uvědomili, v této diskusi shodou okolností stojí na straně IPv6.
-
TP (neregistrovaný)
Zde bych si dovolil nesouhlasit. Pokud se podivate na standartizacni proces, tak jsou zde momenty, kde s onim "plus minus" nelze souhlasit. Nekolik pripadu:
- Az do roku roku 2003 (standartizace DHCPv6 - rfc3315) nebyla v IPv6 moznost predat klientum adresy rekurzivnich name serveru. (Pomineme-li microsoft hack se site local adresama).
- I pres obrovskou poptavku ze strany praktiku protokol DHCPv6 az do roku 2013 (rfc6939) nemel moznost identifikovat klienty podle MAC adresy (coz dost vadi v dualstackovem prostredi).
- Obdobny pripad je s default route v DHCPv6 (to neni dodnes).
- Misto toho je DHCPv6 pevne svazano se SLAAC prostrednictvim rade lidi neintuitivnich flagu (Managed, Other, Autonomous), byt rada spravcu o to moc nestoji.
Je to jen nekolik pripadu, ktere myslim sly resit mnohem lepe. Pokud tyto veci vysvetluji nekomu sestkou dosud nepolibenemu, tak vesmes nevericne krouti hlavou, ze takto to prece nekdo nemohl vymyslet. Bohuzel vymyslel.
Je mi lito, ale za stav ve kterem je IPv6 dnes si muze komunita sama. Misto toho aby se snazila reagovat nejakou sebereflexi, tak IPv6 posouva do roviny nedotknutelne posvatne kravy, kde se je jakakoliv kritika netoleruje a prislusne osoby jsou oznacovany za kacire, pitomce nebo ty, co to necahpou (=blbce).
Vysledek je velice jednoduchy. Rada erudovanych lidi postupne komunitu opousti, protoze si dokazou najit jinou zabavu a zustavaji pouze nekriticti zastanci, coz v konecnem dusledku problem jen prohlubuje.
V praxi se cim dal tim vic setkavam s tim, ze lide kteri byli zapaleni do IPv6 a byli ochotni teto problematice venovat nemaly cas a invenci jsou na zaklade vlastnich zkusenosti a stavem veci znacne flustrovani. Nic horsiho se 6 nemohlo stat - zklamana duvera se da vratit jen obtizne. Osobne se domnivam, ze IPv6 svou sanci promarnila a my vsichni se muzeme pripravit na zivot za NATy. A moment - uz vlastne za nima davno jsme, tak nic.
Na druhou stranu, pokud nahodou 6 skonci na smetisti dejin, tak to nebude ani prvni ani posledni protokol. To smetiste je velke a jeden protokol navic se tam ztrati jako nic - tedy zadne drama se nedeje. Lidstvo bude nejspis fungovat dal :-)
-
„- I pres obrovskou poptavku ze strany praktiku protokol DHCPv6 az do roku 2013 (rfc6939) nemel moznost identifikovat klienty podle MAC adresy (coz dost vadi v dualstackovem prostredi).“
Skvělé, to je pro mě nová informace! Myslel jsem si, že k té MAC adrese už nedojde a bude se tlačit na používání DUID i na DHCPv4.
„- Obdobny pripad je s default route v DHCPv6 (to neni dodnes).“
To by umožnilo překlopit celou konfiguraci na DHCPv6. A to není až tak dobrý nápad, pokud to neudělají všichni. To by ale znamenalo označit celé router discovery za deprecated a dočasně doporučit současné použití obou protokolů na klientské straně a nějaký mechanismus na výběr mezi nimi (tam se musí bohužel řešit časování). Podle mě by to byl dobrý krok, pokud by se to udělalo dobře.
„Je mi lito, ale za stav ve kterem je IPv6 dnes si muze komunita sama. Misto toho aby se snazila reagovat nejakou sebereflexi, tak IPv6 posouva do roviny nedotknutelne posvatne kravy, kde se je jakakoliv kritika netoleruje a prislusne osoby jsou oznacovany za kacire, pitomce nebo ty, co to necahpou (=blbce).“
Komunita si za to může skutečně sama, ale jedním z důvodů je i to, že se určitá netriviální část kritiků místo zapojení se do procesu a vytvoření relevantních návrhů dokumentů pouští na křížové výpravy a tím namísto užitku vytváří jenom napětí.
Plkat v diskuzích umí každý, napsat konzistentní a smysluplný návrh už je těžší, že.
„Vysledek je velice jednoduchy. Rada erudovanych lidi postupne komunitu opousti, protoze si dokazou najit jinou zabavu a zustavaji pouze nekriticti zastanci, coz v konecnem dusledku problem jen prohlubuje.“
Jak dokazuje tenhle článek a přednáška na konferenci, tak naopak v komunitě přibývá hlasitých kritiků.
„V praxi se cim dal tim vic setkavam s tim, ze lide kteri byli zapaleni do IPv6 a byli ochotni teto problematice venovat nemaly cas a invenci jsou na zaklade vlastnich zkusenosti a stavem veci znacne flustrovani.“
To není nic nového. Za „IPv6“ není problém do té věty z fleku dosadit tisíce jiných věcí.
„Osobne se domnivam, ze IPv6 svou sanci promarnila a my vsichni se muzeme pripravit na zivot za NATy. A moment - uz vlastne za nima davno jsme, tak nic.“
Vzhledem k druhé větě, opět žádná nová informace. Tohle už víme víc než deset let. Problém je, že svou šanci do jisté míry promarnila internetová komunita a tím zprostředkovaně i uživatelé internetu. Je nesmysl se na to dívat tak, že to promarnily nějaké dokumenty, když člověk uvědomí význam některých vět z diskuze, kde je IPv6 podmětem, je to opravdu komedie.
„Na druhou stranu, pokud nahodou 6 skonci na smetisti dejin, tak to nebude ani prvni ani posledni protokol. To smetiste je velke a jeden protokol navic se tam ztrati jako nic - tedy zadne drama se nedeje. Lidstvo bude nejspis fungovat dal :-)“
Což ovšem činí zbytečnými všechy předchozí odstavce příspěvku, že.
-
Ivan (neregistrovaný)
Zrovna s tim router discovery muze mit spouta lidi "mentalni" problem. Ve spouste firem plati dogmaticky prirucky o bezpecnosti. Nikdo nesmi mit pristup na vsechny prvky a sitari se moc nebavi se spravci serveru - a naopak. A rozhodne si navzajem nelezou na boxy.
Doted si admini spravovali "svoje" stanice na "svym" DHCP serveru. A to ted nemuzou. Nova technologie vyzaduje i nove procesy a i v tom muze byt problem.
-
„Zrovna s tim router discovery muze mit spouta lidi "mentalni" problem.“
Já osobně mám s router discovery naprosto praktické problémy. Je to podle mě špatný nápad. Ten nápad je špatně zpracovaný do RFC. A ta RFC jsou špatně implementovaná všude, kde se podíváte.
„Doted si admini spravovali "svoje" stanice na "svym" DHCP serveru. A to ted nemuzou. Nova technologie vyzaduje i nove procesy a i v tom muze byt problem.“
DHCP server je standardní součást síťové infrastruktury. Osobně jsem moc neviděl, že by síťaři přenechávali DHCP správcům serverů. V tom konkrétně nevidím mezi IPv4 a IPv6 rozdíl.
-
Ivan (neregistrovaný)
"DHCP server je standardní součást síťové infrastruktury. Osobně jsem moc neviděl, že by síťaři přenechávali DHCP správcům serverů. V tom konkrétně nevidím mezi IPv4 a IPv6 rozdíl."
To jsem si taky myslel. Pak mi ale bylo vysvetleno, ze jediny spravny DHCP (DNS) server je ten, ktery je soucasti Active Directory. Takhle to bohuzel funguje v korporatnim prostredi - o lokalni sit se staraji Windows admini.
-
TP (neregistrovaný)
rfc4862:
Even if a link has no routers, the DHCPv6 service to obtain addresses
may still be available, and hosts may want to use the service. From
the perspective of autoconfiguration, a link has no routers if no
Router Advertisements are received after having sent a small number
of Router Solicitations as described in [RFC4861].M ci O flag v oznameni smerovaci pouze cely proces urychli.
Rozdil mezi falesnym DHCP serverem a falesnym smerovacem je ten, ze vsechna zarizeni v prislusne podsiti na zaklade falesneho smerovace zmeni/upravi svou konfiguraci behem milisekund. U falesneho DHCP musi byt utok veden sofistikovaneji. Renew se navid u DHCP resi primo (unicastem) se serverem, ktery adresu pridelil, tedy do komunikace je zase o neco slozitejsi zasahnout. Rozdil je tedy v narocnosti provedeni utoku.
-
Ivan (neregistrovaný)
Tenhle priklad jsem uvadel jako procesni problem (ne jako bezpecnostni). Proste tymy, ktery spolu doted ani nemluvily najednou musi spolupracovat. A navic k tomu neni ani klikatko do AD - takze je to vlastne cely naprd.
Debaty okolo IPv6 se vice-mene toci okolo objemu transformacnich nakladu a privetivosti pro implementatory.
PS: falesny DHCP server da zablokovat jedinym "cudlikem".
-
Sten (neregistrovaný)
Nemusí, tedy ne nijak víc, než doteď:
V IPv4: síťaři nastavili router, řekli adminům jeho IP adresu a ty to zanesli do DHCP.
V IPv6: síťaři nastavili router, řekni adminům přidělenou IP adresu pro DHCP server a ti ji použili.
Snadno zablokovat jde ale falešný RA taky. Anebo pomocí SEND jde rovnou zablokovat možnost, aby ho někdo bral vážně.
-
Sten (neregistrovaný)
O nativních implementacích nevím, ale znám tohle. V Linuxu to používá ip6tables, takže podvržené pakety NetworkManager neuvidí.
-
Otázka nezní, zda je tam bezpečnostní rozdíl. Ten je zřejmý, když se vezme v potaz, že DHCP se neúčastní klient, který už má nakonfigurováno s dostatečně dlouhou platností, zatímco router discovery se účastní neustále.
Spíše je potřeba se zabývat tím, jaký má ten rozdíl praktický význam a jaká jsou k dispozici řešení. Když si odmyslím balast, tak z té přednášky vyplývalo, že řešení od několika vybraných výrobců routerů a smartswitchů (včetně Cisco a HP) pokrývají běžné konfigurační problémy, nikoli cílené *lokální* útoky.
Výsledkem je nicneříkající informace, že bezpečnostní vlastnosti zkoumaných implementací *můžou být* nedostatečné. Na druhou stranu zcela chybí informace o tom, jak je to s IPv4, zda tak jako se úspěšně útočí pomocí IPv6 option headers, lze útočit třeba pomocí IPv4 options či nikoliv.
-
j (neregistrovaný)
Dovolim si na zaklade vlastnich zkusenosti tvrdit, ze v 99% pripadu plati, ze jak IPv4 tak IPv6 lze vpohode napadnout, protoze admini stejne nepouzivaji ani existujici a dostupne prostredky. Dost casto je to ovsem dano tim, ze se ve fimach chce, aby mohl kdokoli a kdykoli pripojit cokoli a kamkoli. Bezpecnost je proste druhorada.
BTW: Falesny RAcko v siti se (prevazne) pozna narozdil od DHCPka velmi rychle. Ve vetsine pripadu totiz nejde o zadny sofistikovany utok na sit, ale o neci blbe nakonfigurovane zarizeni (v obou pripadech).
-
Filip JirsákStříbrný podporovatel
Ty příklady ukazují věci, které se k IPv4 dolepovaly postupně, v IPv6 jsou některé z nich od začátku a teď si stěžujete, že tam od začátku nejsou všechny. To ale není srovnání v neprospěch IPv6, že?
Máte nějaký příklad toho, kdy se jakákoli kritika IPv6 netoleruje? Ono to možná zaniká v tom množství hloupé a stokrát vyvrácené kritiky, kdy opravdu nikdo nemá chuť to dotyčným „kritikům“ vysvětlovat stále dokola – ale na rozumnou kritiku se myslím reaguje rozumně, o čemž svědčí například nové standardy, které se stále vydávají (sám jste některé jmenoval).
Moc se nedalo čekat, že to s IPv6 bude vypadat jinak. Na IPv4 se postupně nabalovaly hacky, které umožňují nějak to horko těžko používat. A pokud s IPv4 teď něco nejde, prostě se to považuje za nemožné. Takže IPv6 je v situaci, kdy teď akutně není potřeba, protože všechno co teď máme, umíme s IPv4, a nějaké zjednodušení nebo nové možnosti přijdou až tehdy, až se IPv6 pořádně rozšíří a v druhém kole až se IPv4 bude moci přestat používat. Logicky se málokomu chce dnes investovat do něčeho, z čeho bude mít přínos až v budoucnosti – zvlášť v konzervativním světě IT.
-
„Ano, většina ostrých kritiků IPv6 by radši současný bordel s IPv4 zachovala a jenom přidala delší adresy.“
Problém je v tom, že člověk, který se sítěmi dělá a pracuje i s IPv4 i s IPv6 tak se z principu musí stát jak kritikem IPv4, tak kritikem IPv6. Jestli je zároveň propagátorem jednoho z nich už na tom nic moc nemění.
Navíc není až tak důležité, co si myslí většina kritků IPv6, protože většina kritiků jsou jen diskuzní plácalové. Zajímavé je, co si myslíme my, kteří s tím opravdu něco děláme a je jasně vidět, že máme mezi sebou od tradičních propagátorů, až po lidi, kteří veřejně dezinformují v neprospěch IPv6 (ať už to znamená cokoli) ze mně zcela neznámých důvodů.
-
MG (neregistrovaný)
Reagovat jsem moc nechtěl, protože diskuze se vede spíše v ideologickém duchu, nicméně mi to nedá, protože veřejná dezinformace je pro mě už docela silné tvrzení. Na základě čeho? Co z dané přednášky technicky rozporujete? Zatím mi to přišlo, že jste napadal formu přednášky, proti čemuž brojit nehodlám - je to věc názoru, někomu se líbí, někomu se nelíbí, nelze se zavděčit všem.
Co se týče ostatních připomínek tak ty lze velice obtížně řešit v diskuzi na Internetu, kde se ztrácí technické detaily. Navíc spousta věcí ani vyřešit nelze, protože na to prostě existují 2 rozdílné názory, nicméně pár připomínek.
1) Argumentujete neporovnáním mezi protokoly, avšak na přednášce byly protokoly porovnány mezi sebou - útoky na IPv4 a techniky obrany vůči těmto útokům byly zmíněné na začátku přednášky - ostatně je to popsáno i v článku. Je zajímavé, že u IPv4 útoky jako CAM flood, ARP poisoning, IPv4 spoofing považujeme za vlastnost protokolu - tedy problematický návrh IPv4, u IPv6 se vůči tomuto tvrzení bráníme a poukazujeme na špatnou implementaci. Přitom v základních návrzích od IAB byly požadováno, aby tyto chyby protokolu IPv4 byly v IPv6 odstraněny. Proto tedy netuším, proč se bráníme tomu, nazývat to chybou protokolu IPv6 a nazýváme to chybou implementace.
Resp. IPv4 spoofing považujete za chybu protokolu IPv4 (ARP) že to umožňuje, nebo chybu implementace na přepínači? Obecně to považujeme za chybu protokolu a snažíme se tomuto zabránit třeba DHCP snoopingem. V IPv6 toto ale díky návrhu protokolu udělat jednoduše prostě nelze - zde tomu brání například (a nejenom) skládání extension headers, které znemožňují rozumné filtrování. Věci co jsou špatně je například benevolentní řetězení hlaviček. Proč je povoleno řetězit stejný typ hlaviček, i když hlavičky jsou většinou TLV, takže případně se dá nafouknout a dodefinovat options přímo v dané hlavičce? Ne že by rozšířené hlavičky byly apriori špatné, nicméně proč jsou povolené u link local adres? K čemu u link local je nutná podpora routing header, když ji vlastně ani použít nemůžu - díky vlastnostní link local adres? U IPv4 tento problém není, tam jsem schopen vcelku jednoduše skočit vždy na další protokol, tedy First Hop security je funkční. O nápravu návrhu se snažilo několik lidí, vždy je po sáhodlouhé diskuzi návrh zamítnut. Pokud to vezmu na příkladu - vy jste reportoval race condition u RFC 6106 před rokem, výsledek není žádný - žádná errata, žádné vydání RFCbis. Jen pár zpráv v mailing listu. Tuto race condition považujete - podle mailu, za špatný návrh protokolu, nicméně tato vlastnost lze ošetřit v rámci implementace. Není to ale stejný případ jako u výše zmiňovaných útoků? Protokol umožňuje útok, ale útoku lze zabránit implementací (IPv4 spoofing + DHCP snooping). U IPv6 je to to samé + protokol navíc znemožňuje rozumnou implementaci na čipu. Jakto že je to najednou vnímáno jako špatná implementace? Vkládání RA zpráv do směrovací tabulky u koncových uzlů je dodržování RFC. Implementace se pomocí rate limiting brání vůči RA flood, nicméně takto nejsou schopni zajistit vložení správného RA. Proč je toto najednou bráno jako chyba implementace, když rate limiting nemají (Windows) a ne chyba návrhu? Přitom vývojáři z Microsoftu zcela jasně řekli, že oni pouze dodržují RFC - proto zde nebyla a není extra snaha to opravit.Add hurónské tvrzení: Pokud vím, tvrdil jsem, že jsem daný firewall netestoval, tedy nevím. Dále, díky tomu, že je to L7 zařízení by to odfiltrovat asi šlo ale záleží co z filtrace používají v HW, jelikož obecně je problém parsovat dynamické věci na čipu. Tvrzení, že by to určitě obejít šlo na základě naší (mojí) zkušenosti s implementacemi byla forma nadsázky. Navíc třeba pomocí Teredo věřím, že by to obejít šlo, protože jsem zatím neviděl firewall, který by dokázal dělat DPI nad UDP a hledat Teredo - a to jsem se na to ptal na nemálo vědeckých a technických konferencích. Pokud máte příklad zařízení, které si můžu dnes koupit a které to umožňuje tak dejte vědět.
Jak už jsem psal výše, tyto věci jsou věcí názorů a je přirozené, že někteří na to mají názor takový a jiní jiný. Nicméně říkat, že někdo záměrně dezinformuje a že je to balast už je spíše argumentace ad hominem, jelikož zatím jsem neviděl v diskuzi od vás žádné technické připomínky k obsahu prezentace, vždy pouze ideologické nebo vůči formě. Mimochodem pro další názory se klidně můžete stavit na fakultu, nemáte to z práce tak daleko.
-
„Reagovat jsem moc nechtěl, protože diskuze se vede spíše v ideologickém duchu“
To je asi do jisté nevyhnutelné, vzhledem k tomu, že diskuze vychází z přednášky podané v ideologickém duchu (tedy alespoň pokud se bavíme o posledních dvaceti minutách, kterých jsem se zúčastnil).
„nicméně mi to nedá, protože veřejná dezinformace je pro mě už docela silné tvrzení. Na základě čeho? Co z dané přednášky technicky rozporujete? Zatím mi to přišlo, že jste napadal formu přednášky, proti čemuž brojit nehodlám - je to věc názoru, někomu se líbí, někomu se nelíbí, nelze se zavděčit všem.“
Jsem přesvědčen, že druhá věta mého prvního příspěvku v diskuzi je dostatečným ospravedlněním slova „dezinformace“.
Já samozřejmě chápu, že člověk do přednášky vkládá osobní názory a osobní hodnocení situace a samozřejmě to i sám dělám. Ale zaprvé se snažím fakta a osobní pohled do jisté míry oddělit, a zadruhé se snažím fakta prezentovat v kontextu, pravdivě, a pokud jsou nějakým způsobem překvapivá, tak i s dostatečným zdůvodněním.
Jeden příklad za všechny. Když řeknu, že IPv6 je nebezpečné, protože má rozšiřující hlavičky, měl bych při té příležitosti říct, proč je obdobná funkcionalita v IPv4 bezpečná. A určitě bych neměl tvrdit, že je IPv6 obecně nebezpečné, protože jeden nebo více výrobců používají jako výchozí ACL politiku ACCEPT, jestliže má paket neobvyklou strukturu.
Za vyloženě idiotský* argument bych si dovolil ozačit tvrzení, že je IPv6 nebezpečné, protože se dá tunelovat po IPv4. Světe div se, IPv4 jde taky tunelovat!
A takhle bych mohl pokračovat, a to jsem ani nebyl na zdaleka celé přednášce. Nicméně, pokud by se celá přednáška zrevidovala tak, aby se výkřikům tohoto typu vyhnula, a
pokud by pojednávala *především* o výsledcích výzkumu bezpečnosti (a třeba i praktické použitelnosti) konkrétních RFC a o výsledcích penetračních testů konkrétních produktů nad protokoly IPv4 i IPv6, tak bych si i rád zaplatil vstup na konferenci, kde se taková přednáška objeví. Samozřejmě se nebráním tomu, aby přednášející okořenil fakta svým pohledem, pokud to bude přínosné.Každý si může přednášet jak chce, ale pokud upřednostní ideologii a senzaci před fakty, nesmí se pak divit reakcím.
* Použít idiotský argument samozřejmě neznamená býti idiotem.
-
Sten (neregistrovaný)
Proto jsem psal o ostrých kriticích, protože ti většinou reagují slovy „SLAAC je špatné“ (bez znalosti, že ho nemusí používat, pokud jim vadí, a často vůbec bez nějakého povědomí, jak vlastně funguje), „ND/RA spoofing je zásadní problém“ (bez nějakém povědomí o SEND, často navíc vydávané za nový problém přinesený s IPv6) nebo „IPv6 je zbytečně složité“ (bez nějakého zdůvodnění, co konkrétně jim připadá zbytečně složité a proč podobnou vlastnost implementovanou často pomocí různých hacků v IPv4, pokud ji vůbec umožňuje, za složitou nepokládají) a podobně.
Samozřejmě je také spousta konstruktivních kritiků, kteří IPv6 používají dlouhodobě a reagují na reálné problémy, které se objevily třeba při provozu 6bone, a těch si vážím — také proto se ten protokol dost razantně vyvíjel ještě nějakých deset let po prvním RFC a dneska obsahuje spoustu věcí, které při původním vývoji nikoho ani nenapadly.
-
TP (neregistrovaný)
To uz je teda ale hodne drsne. Predpokladam, ze myslite ze by se tato adresa nastavila jako default:
Ok, teoreticky - ff02::2 je multicastova adresa. Plati tedy:
1. V Ethernet siti, kde neni zaply MLD snooping se budou vsechny odchozi pakety sirit jako broadcast - tedy vsem. To mi neprijde jako prilis efektivni forma prenosu.
2. V siti kde MLD snooping zaply je by se paket siril ke vsem smerovacum, vznikala by tedy duplikace (podle poctu smerovacu).
3. Nejsem si uplnejisty zda ve smerovaci tabulce muzete nastavit next hop pro default routu na multicastovou adresu.Vy to mate tak nekde nakonfigurovane ci spon vyzkousne?
-
Sten (neregistrovaný)
ff02::2 je multicast, proto pomocí Neightbor Discovery (nebo třeba pingu, když to nastavujete ručně) na tuto adresu dostanete unicast link-local adresu routeru (resp. všech routerů v síti) a zjištěnou adresu použijete stejně, jako když přijde Router Advertisment. Vyzkoušené to nemám, protože používám SLAAC, ani nevím, jestli tohle někdo implementoval, ale teď jsem si vyzkoušel, že routery odpovídají a uvádějí svoji link-local adresu.
-
MG (neregistrovaný)
Řešení, kterým to útočníkovi ještě více usnadníte, protože mu pak nic nezabrání se přihlásit do dané multicast skupiny a odposlouchávat celý uživatelský provoz na LAN. Tuto skupinu navíc nejste schopen filtrovat (zakázat) pro uživatele, protože byste zároveň zamezil zasílání RS a porušil byste tak standard. Navíc jak tuto informaci sdělíte klientovi? Pakety nemohou mít jako source multicast adresu. Jak tedy chcete sdělit klientovi (bez toho abyste ho staticky nakonfiguroval) aby používal ff02::2 jako default? Vaše argumenty jsou naprosto mimo současné standardy. Což není špatný způsob myšlení, protože standardy jsou od toho aby se vyvíjely, nicméně navrhovaný způsob přinese mnohem více problémů, než jich vyřeší - zahlcení klientů, pokud není MLD snooping, jak už zmínil Tomáš je asi nejpalčivější z nich.
-
Sten (neregistrovaný)
Šlo o odpověď na to, jak najít router, který neposílá RA. Tak jsem psal, že routery lze vyhledat pomocí ff02::2, a to tak, že posláním ND nebo pingu na tuto adresu se dozvíte link-local adresu routeru, kterou již můžete použít jako default route (multicast samozřejmě není dobré používat jako routu). Tenhle způsob hledání routerů není běžný, ale je plně v souladu s existujícími RFC a bude fungovat (pokud tedy router naslouchá na dané multicast adrese, jak mu přikazuje RFC). Všechno tedy končí na tom, jestli tohle klient umí. Kdyby to někoho zajímalo, tak tady jsem splácl dost jednoduchou implementaci pro
/etc/network/interfaces:up ip route add default via "$(ping6 -nc 1 "ff02::2%$IFACE" | awk '$3 == "from" { sub(/:$/, "", $4); print $4 }')" dev "$IFACE"Samozřejmě filtrování multicastu je složitější než filtrování RA.
-
TP (neregistrovaný)
To ze neco odpovida na ff02::2 automaticky neimplikuje, ze takovy router zna cestu smerem ven. Muze to byt napriklad router umisteny na stejne podsiti (napriklad router dalsiho zakaznika), ktery je chycen z nadrazeneho staticky (byt ve vetsine pripadu bude znat default a preposlal by ten paket smerem ven).
Nicmene v te Vasi uvaze jste neudelal nic jineho, nez ze jste nahradil vyzvu smerovaci (RS) a oznameni smerovace (RA) jinym typem ICMPv6 zpravy, ale princip zustava stejny. Navic to nema oporu ve standardech, takze ciste hypoteticky ano, ale v soucasne praxi nikoliv.
Spatruji zde jednu vyhodu. Funguje to pak cele systemem vyzva - odpoved, coz by z principu velkou cast problemu, ktere mame dnes s RA eliminovalo.
-
Santiago (neregistrovaný)
> Funguje to pak cele systemem vyzva - odpoved, coz by z principu velkou cast problemu, ktere mame dnes s RA eliminoval.
RA funguji take na principu vyzva (RS, router solicitation) a odpoved (RA, router advertisement), i kdyz ty RA se posilaji i periodicky (kvuli obnove platnosti). Rozumna klientska implementace po pripojeni posle RS, aby nemusela cekat na periodickou RA.
-
TP (neregistrovaný)
Zalezi na uhlu pohledu. RS slouzi pouze k urychleni procesu zaslani RA. Bez ohledu na to, klient poslucha a zpracovava RA vzdy.
System dotaz - odpoved v predchozim odstavci je myslen tak, ze se klient nezabyva zpracovanim RA paklize mu nepredchazela zadost (RS).
Tim padem utocnik behem jedne milisekundy neni schopen zmenit najednou konfiguraci vsech zarizeni pripojenych v podsiti. Musi se trefit do okamziku od odeslani RS + nejaky cas urceny pro prijem RA. Ne ze by to tyto utoky primo eliminovalo, alespon je komplikuje. Nicmene takhle to neni v IPv6 mysleno, takze tyhle uvahy jsou zbytecne.
-
„Zalezi na uhlu pohledu. RS slouzi pouze k urychleni procesu zaslani RA. Bez ohledu na to, klient poslucha a zpracovava RA vzdy.
System dotaz - odpoved v predchozim odstavci je myslen tak, ze se klient nezabyva zpracovanim RA paklize mu nepredchazela zadost (RS).“
Chápu to správně tak, že byste viděl zlepšení bezpečnosti v případě, že by klienti přestali zpracovávat RA mimo stav, kdy si ho vyžádali?
-
Sten (neregistrovaný)
Ano, v mé implementaci jsou stále různé gotchas, ale ty by se daly lepší implementací vychytat. Reagoval jsem pouze na to, že bez RA nejde najít default gateway.
Pokud máte na mysli princip fungování, pak to oporu v RFC má (používám link-local adresy dokumentovaným způsobem), ale pokud chcete dokumentovaný postup hledání routerů, tak máte pravdu, že nic jiného než RA není.
RA můžete také provozovat principem výzva — odpověď, neboť je vysíláno také jako reakce na RS. Pak můžete nastavit v RA platnost třeba týden (nebo kolik používáte v DHCPv6) a periodické RA nepoužívat, i když tady si nejsem jistý, jestli to splňuje RFC nebo ne.
-
j (neregistrovaný)
A jaky je rozdil v tom, jestli neco vysila do site nejakou informaci, a klient ji nejak pouzije, vs klient vyzaduje nejakou informaci a neco mu nejak odpovi? Me to prijde prast jako uhod. Nemluve o tom, ze to, ze v siti bude vice routeru je soucasti standardu, a pokud je to spravne implementovano, tak by si s tim klient mel poradit.
-
MG (neregistrovaný)
Podle toho, jak vnímáte pojem SLAAC. Součástí SLAAC (RFC 4862) jsou RA/RS zprávy, tedy SLAAC musím použít vždy - minimálně zprávy RA. M flagem pouze řeknu, že adresu si můžu nakonfigurovat z DHCPv6, nicméně vždy musím do sítě posílat RA zprávy a tedy provozovat 2 protokoly.
Navíc dle RFC 6434 - IPv6 Node Requirements je SLAAC povinný, zatímco DHCPv6 volitelný (must vs should) - tudíž i Android, který DHCPv6 vůbec neimplementuje vlastně dodržuje standard. To RFC je zajímavé už jenom proto, že třeba IPSec je odstraněn z povinných implementací IPv6, tedy v současné době IPSec je na tom v IPv6 úplně stejně jako v IPv4.
-
Sten (neregistrovaný)
RA je součástí Neighbor Discovery (RFC 4861), RFC 4862 pouze uvádí, jak ho zpracovávat pro SLAAC.
Routery nejsou součástí DHCPv6, protože routery můžete najít vždy na ff02::2. Ale dobře, pokud chcete mít pevně daný router, musíte tam nastavit RA. Máte ale pořád tu samou sadu protokolů jako u IPv4, RA je Neighbor Discovery, což je akorát náhrada ARPu.
Překvapení: v IPv4 je DHCP také nepovinné ;-) Takže je to tak, jak jsem to psal, problém je hlavně v implementaci, ne v protokolu.
-
„Jsem z FIT VUT a neřekl bych, že tu vedeme kruciádu proti IPv6.“
To si ani nemyslím a věřím, že i Ondra to psal s trochou té nadsázky. Ale...
„Poukazujeme na věci, které ve v6 nefungují, zatímco ve v4 už byli alespoň nějak řešené. Z mého pohledu dělat klon v4 ve v6 s tím, že bude mít větší adresní prostor, mohlo, jak se ukazuje, být lepší řešení“
Já vidím v IPv6 právě klon IPv4 s větším adresním prostorem.
„než si tam navymýšlet nové nekoncepční vlastnosti, jejichž vysvětlení či implementace pokulhávají (SLAAC, chování ND cache, problémy při parsování extension headers).“
Taky SLAAC dvakrát nemusím a nevidím ho ve všech důsledcích vůbec jako dobrý nápad. A mám pro to spoustu důvodu, které nejspíše na FITu ani neznáte, protože se zaměřujete se zaměřujete na jinou oblast a ve světě to řeší relativně malá skupina lidí.
„Přiznám se, že já jsem na LinuxAltu nebyl, a jsem tak rád, že mám možnost si přečíst výběr postřehů a odborný světonázor člověka, co byl na posledních dvaceti minutách osudové přednášky.“
Na jednu stranu jsem tušil, že se někdo chytí toho, že jsem nepřišel na celou přednášku kvůli časové kolizi si jinou akcí. Na druhou stranu jsem si říkal, že mé sdělení člověku, který se k takovému argumentu uchýlí, tak jako tak nic nedá.
-
ike (neregistrovaný)Ja myslim, ze org. autor chtel proste rict, ze u IPv6 se mu (a mozna i jinym) zda, ze nenaplnuje ocekavani. Ja osobne se take klonik k nazoru, ze by bylo lepsi roztahnout adresni prostor a ocesat nepouzivane/hackovane/zneuzivane blbiny a mozna vyresit nejaky extra palcivy problem IPv4 (ktery?).
Z meho uhlu pohledu se IPv6 jevi jen jako konkretni projev meta problemu soucanostni, kterym je rostouci slozitost a z ni vyplyvajici krehkost veci/systemu/sveta. IPv6 (a mnoho jinych veci) proste porusuje princip KISS a myslim si, ze na to dojede. Koneckoncu mame i par precedentu ze stejne oblasti - sit. protokoly ISO/OSI take "podlehly" hloupemu TCP/IPv4.
Skoro to vypada, ze jednoduche, hloupe, jen 95% reseni je tak nejak "lepsi" nez super slozite, super chytre, 99% reseni.
-
j (neregistrovaný)
Ipv4 ma spoustu problemu, ktere bezni useri ani admini vubec nemusi vnimat a "pouhym" rozsirenim adresniho prostoru by se jeste zhorsily. Kuprikladu fragmentace adresniho prostoru ... To se prechodem na IPv6 casem poresi "samo".
Nebo defakto nefungujici a neexistujici multicast, multihoming ... to vse se da i na IPv4 ... ale defakto se to nepouziva, protoze to ma spoustu ale, a kdyz, tak, mozna, ... proto Ipv6 vypada jak vypada, protoze se vsechny tyhle hacky snazi vyresit nejakym atandardnim postupem.
-
Ivan (neregistrovaný)
Ten multicast je zajimavy priklad. Pamatuju si, ze kdyz na Strahovkych kolejich zacali experimentovat s multicastem, tak to pravidelne sestrelovalo paterni router CVUT. Teoreticky ten router umel zpracovavat multicast pres ASIC, ale neco v tom provozu zpusobovalo, ze vsechno slo pres CPU. V tomhle pripade se to kratkodobe resilo tak se se cely Strahov odpojil od site. Dlohodobe se to vyresilo tak ze se sehnaly penize na Nortel se vymenil za Cisco. (On ten Nortel mel i spoustu jinych problemu)
Muze se neco takoveho opakovat na IPv6? Urcite ano - vzdit je to jesne narocnejsi na implementaci nez predchozi verze.
Odlisnost IPv6 muze zpusobit, ze vsichni budou muset znovu resit uz jednou veresene problemy. Mozna, ze je to "chyba" v navrhu, mozna jsou to jen nutne transformacni naklady. -
Tomáš Podermanski (neregistrovaný)
> Můj dojem je, že se tým na FIT VUT rozhodl, že IPv6 nemá rád, a proto místo řešení hledají problémy.
Nemyslím si, že se kdokoliv na VUT rozhodl, že nemá rád IPv6. Naopak v rámci VUT bylo (a nadále je) věnováno značné úsilí a nemálo prostředků na implementaci IPv6. Dnes IPv6 provoz tvoří cca 15-20% (cca 0.5-1Gbps) celkového provozu univerzity, viz. veřejně přístupné statistiky http://6lab.cz/live-statistics/ipv6-brno-univeristy-of-technology/.
Pokud tedy někde vzniknul dojem, že VUT organizuje křížové výpravy proti IPv6 tak je zcela jistě mylný :-)
-
Nezlobte se na mne, ale uvěřím Vám to, až od Vás někdy budu číst článek nebo poslouchat přednášku, která bude končit slovy: "A toho jsme udělali pro to, aby to nebyl dál problém, a teď už je to opravené." nebo "Považujeme to za problém, proto jsme to otevřeli v v6ops WG."
Například by někdo (se supportem a dostatečným počtem boxů) mohl začít tlačit na vendory, aby základní licence obsahovaly podporu IP protokolu/ů v souladu s RFC 6540.
Co se týče mylného dojmu ... podívejte se na titulek tohoto článku a na diskuzi pod ním. Pokud nevedete křížovou výpravu, tak v komunikaci toho, co vlastně děláte, něco děláte špatně. Každopádně i tak se připojuji k pavlixovi v tom, že deskripce problémů v implementaci IPv6 je záslužná, ale pořád se nemůžu zbavit dojmu, že byste byli radši, kdyby IPv6 nebylo.
-
Tomáš Podermanski (neregistrovaný)
Popravdě netuším s kolika články a přednáškami jste se na téma IPv6 od lidi z VUT měl možnost potkat, nicméně řada lidí z VUT se problematikou IPv6 aktivně zabývá dlouhou dobu a komunitě poskytuje přesně ten typ výsledků, po kterých voláte.
Namátkou zmíním aktivní účast na beta testingu pro HP v roce 2010. V HP tehdy implementovali IPv6 do svých síťových produktů (viz. http://www.lupa.cz/clanky/je-libo-ipv6-na-prepinacich-hp-procurve/). Po zkušenostech s nasazováním v roce 2011 na Lupě vycházela série článků s názvem v rámci seriálu "Pohněme s IPv6" (http://www.lupa.cz/serialy/pohneme-s-ipv6/), či naše provozní zkušenosti, které jsme se ve spolupráci s kolegy s CESNETu a dalších univerzit, snažili předávat i na mezinárodní úrovni jak v podobě praktických doporučení pro kampusové sítě (http://www.terena.org/activities/campus-bp/bpd.html), či několika konferencích. V implementační rovině vznikl například systém, který řeší problematickou identifikaci uživatelů v IPv6 (http://www.fit.vutbr.cz/~poderman/pubs.php?id=9840&shortname=1), či několik dalších drobnějších nástrojů. Více se toho dá najit na webu http://6lab.cz/, který ostatně vznikl také na podporu IPv6, či fakultních stránkach získaného grantu, který se problematikou IPv6 zabývá (http://www.fit.vutbr.cz/~poderman/grants.php?id=517). To, že se univerzita neangažuje například v IETF je čistě dáno omezenými lidskými a finančními zdroji.
Osobně příliš nerozumím proč nějaká prezentace, článek, či diskuse o konkrétních problémech, která je podložena jak faktickými informacemi, tak bezesporu vlastními názory a zkušenostmi zaangažovaných vnímáte jako křížovou výpravu proti IPv6. Nakonec i kdyby se konala, tak několik neškodných bláznů z Brna jistě nedokáže ovlivnit postoje mnoha odborníku, kteří zajisté mají na věc vlastní názor.
Rozumím tomu, že se někomu nemusí líbit forma, jakou autor příslušnou věc pojal a kritika má bezesporu své místo. Nicméně vždy zůstane na samotném autorovi, jak s ní naloží.
-
Když už jsme se potkali v diskuzi, mám docela dost výhrad vůči konkrétním problémům a nesmyslům v IPv6 standardech, jen to všechno nestíhám zprocesovat sám, už jen proto, že s IETF nemám prakticky žádné zkušenosti. Docela by mě potěšilo, kdyby se v česku našel někdo, kdo by se mnou šel do vytváření a údržby errat a RFC v této oblasti.
Už jsem se vícekrát ptal v CZ.NIC a tam na to zřejmě nikdo čas nemá, ale možná by se někdo našel právě na VUT. Pokud víte o nějakém člověku, který by se zajímal o zlepšování samotných IPv6 standardů spíše ve funkční oblasti s jen malým přesahem do bezpečnosti, především pak automatické konfigurace, dost by mě to potěšilo.
-
„Pokud tedy někde vzniknul dojem, že VUT organizuje křížové výpravy proti IPv6 tak je zcela jistě mylný :-)“
Otázkou je, zda je to skutečně dobrý námět k pobavení. Já osobně si určitých lidí v CZ.NIC včetně Ondřeje Surého vážím, takže pokud on dochází k takovémuto závěru, tak bych se rád zeptal, zda je to skutečně *jen* jeho chyba.
-
Benedikt (neregistrovaný)
Simerdo, vy bezduvodne verbalne zneuzivate cloveka, ktery slusne prednesl prednasku:
"nesmyslne bulvarne" - "mlzeni" - "balast" - to je verbalni zneuzivani.
Jste bezduvodne agresivni, bezduvodne napadate cloveka.
Jste zavrzenihodny clovek. Vase zavrzenihodne chovani je potreba potrestat. Timto vas verejne ponizuji a zesmesnuji.
-
KapitanRUM (neregistrovaný)
O tom zavržení hodném člověku lze pochybovat, výstižnější slovo je myslím fanatik, fanatik může být třeba Islámský fanatik, ale i IPv6-kový fanatik.
Pokud fanatikovi ukážete něco, co mu není po chuti, přijde bouře v zásadě iracionálního hněvu a agrese. Myslím, že je prostě nemocný. -
Jestliže reaguješ na kapitána, tak mi úplně není jasné, proč se namáháš. Z předchozích diskuzí jsem pochopil, že ten člověk je chytrý, ale na roota se většinou nechodí dělit o své znalosti, ale pobavit. Jestliže chce provokovat pro zábavu a nikoliv argumentovat, tak ho příspěvkem tohoto typu asi těžko přesvědčíš. Nicméně jeho poznámka o kriticích IPv6 zde v diskuzi byla docela trefná.
Všimni si někdy, jak argumentuje little.owl na Abclinuxu ohledně těch pár věcí, kde se rozhodl být ďáblovým advokátem (Gnome 3, systemd a některé další).
-
KapitanRUM (neregistrovaný)
Chci se omluvit za tu silně přehnanou poznámku o nemoci, ta nebyla na místě a byla VELMI nevhodně řečená. Omlouvám se. Měl jsem napsat, že jste do IPv6 "šíblej". Jsem o Vás přesvědčený, že jste blázen do IPv6-kový, za tím si stojím, stejně jako za tím zbytečným hněvem, který ve Vás kritika IPv6 zdá se vyvolává. Na místě je i poznámka o tom, že já na tom nejsem o mnoho lépe, IPv6 je na mě jako červený hadr na býka. A je téměř jisté, že i ve mě IPv6 vyvolává zbytečný hněv. Tedy že jen těžko můžeme najít společnou řeč. Na druhou stranu, musím ocenit Vaše znalosti a odbornost. Inteligence, chytrost a znalosti jsou to, čeho si velmi Vážím, kdybych chtěl, aby pro mě někdo implementoval IPv6, byl byste to právě vy. Dle mého soudu je IPv6 nejhorší zlo, krok špatným směrem a provoz dualstacku je zásadní bezpečnostní i administrativní problém.
Tomuto postoji jistě rozumíte. Chápu, že Váš názor na věc je odlišný. Chci, abyste věděl, že moje případné výpady, byť mají za cíl se trefit, nejsou mířeny proti Vám, jako bytosti, člověku a osobě, ale jen té části osobnosti, která propaguje IPv6. Do té, se pak trefím velmi rád, pokud mi k tomu dáte příležitost. A něco lehčího na závěr, vždy máte možnost odvrhnout falešnou modlu IPv6 a vrátit se pod přívětivá křídla církve IPv4 a přemýšlet o její reformaci! -
Jenda (neregistrovaný)
> Dle mého soudu je IPv6 nejhorší zlo, krok špatným směrem a provoz dualstacku je zásadní bezpečnostní i administrativní problém.
FYI, na neznalého kolemjdoucího podle mě může působit fakt špatně, že jsi toto tvrzení ještě nepodložil žádnými argumenty. Mohl by si pak na to nebo na tebe udělat nečekaný názor.
-
„Měl jsem napsat, že jste do IPv6 "šíblej".“
To je sice formálně pravda, ale „šíblej“ jsem do sítí a síťových technologií. IPv6 to na první pohled schytává víc než IPv4 jen proto, že je tu IPv4 tak dlouho, že už to nikomu nepřijde jako zajímavé téma.
„který ve Vás kritika IPv6 zdá se vyvolává.“
Považuju se za jednoho z *největších* kritiků IPv6 v této diskuzi (ne-li v česku), alespoň pokud jde o relevantní kritiku založenou na znalostech. Pokud by mě kritika IPv6 nasírala, tak bych pak byl značně samonasírací ;).
„Tedy že jen těžko můžeme najít společnou řeč.“
Právě naopak. Mám za to, že mimo špičkování v diskuzi bychom našli hodně společné řeči a to i k IETF standardům síťové vrstvy.
„Na druhou stranu, musím ocenit Vaše znalosti a odbornost. Inteligence, chytrost a znalosti jsou to, čeho si velmi Vážím, kdybych chtěl, aby pro mě někdo implementoval IPv6, byl byste to právě vy.“
Asi se budu červenat. Bez legrace, udělalo mi to radost.
„Dle mého soudu je IPv6 nejhorší zlo,“
Dle mého soudu souhrnný název IPv6 přísluší sadě standardů, které je potřeba posuzovat jednotlivě. Mně na IPv6 vyhovuje především rozšíření adresního prostoru a pár drobných změn.
„krok špatným směrem“
Ten vidím v bezstavové automatické konfiguraci a vůbec bych se nezlobil, kdyby se to celé scratchovalo. Nahradit kontrakt (DHCP le[root.cz má nahovno spamfilter]ase) volným přijímáním konfiguračních parametrů z okolí mohl být dobrý nápad pro jednoduché sítě typu domácí automatizace, jestli vůbec, ale rozhodně ne pro konfiguraci počítačů.
„a provoz dualstacku je zásadní bezpečnostní“
Ano.
„administrativní problém.“
Ano.
A zásadní vývojářský a QA problém. Před pár měsíci jsem změnil práci (v rámci jedné firmy) a dostávám jedno hlášení chyby týkající se dualstacku za druhým. Dokonce mě to donutilo zamyslet se nad nějakým smysluplným řešením a výsledek je zde...
https://sourceware.org/git/?p=netresolve.git;a=tree;hb=HEAD
„Chci, abyste věděl, že moje případné výpady, byť mají za cíl se trefit, nejsou mířeny proti Vám“
Já pevně doufám, že je z mého předchozího příspěvku zřejmé totéž vůči vám (na velká písmena u zájmen jsem si nikdy nezvykl).
„A něco lehčího na závěr, vždy máte možnost odvrhnout falešnou modlu IPv6 a vrátit se pod přívětivá křídla církve IPv4 a přemýšlet o její reformaci!“
Když my kacíři jsme hrozně urputní ;). Ale pravda je, že by bylo fajn zrevidovat celý proces a vyhodit ze špatných věcí v IPv6, co se dá, a na zbytek vytvořit nějaká standardizovaná řešení. Budu se muset podívat, jestli se to náhodou už neděje, třeba identifikace MAC adresou v DHCPv6 byla ještě nedávno no-go.
-
Santiago (neregistrovaný)
> Ten vidím v bezstavové automatické konfiguraci a vůbec bych se nezlobil, kdyby se to celé scratchovalo. Nahradit kontrakt (DHCP ease) volným přijímáním konfiguračních parametrů z okolí mohl být dobrý nápad pro jednoduché sítě typu domácí automatizace, jestli vůbec, ale rozhodně ne pro konfiguraci počítačů.
Me to prijde jako vcelku dobry napad, ale pro urcity segment. Pokud mam nejakou nemanagovanou sit (ad-hoc sit nebo treba domaci sit), tak distribuovana autokonfigurace a distribuovany neighbor discovery je IMHO optimalni. Pokud mam ale managovanou sit (napr. podnikovou ci koncovou sit ISP), tak ma smysl mit oboje centralizovane (tedy i neighbor discovery). V tomhle ohledu jak IPv4 tak IPv6 selhava a je videt, ze ten samy problem se resi hned na nekolika vrstvach a po kazde znova.
-
„Me to prijde jako vcelku dobry napad, ale pro urcity segment.“
To jsem popravdě psal už i v té části, kterou cituješ.
„Pokud mam ale managovanou sit (napr. podnikovou ci koncovou sit ISP), tak ma smysl mit oboje centralizovane (tedy i neighbor discovery). V tomhle ohledu jak IPv4 tak IPv6 selhava a je videt, ze ten samy problem se resi hned na nekolika vrstvach a po kazde znova.“
To je pravda, ačkoli zrovna toto IPv6 řeší lépe v tom smyslu, že umožňuje distribuovat adresy, aniž by byly automaticky on-link.
-
j (neregistrovaný)
Pokud chces administrovat sit a resit co se ti kde pripoji/nepripoji, tak na to jsou nastroje o layer niz. Trebas IEEE 802.1X. Technicky neni zasadni problem nechat libovolny zarizeni projit autorizaci a teprve potom mu umoznit komunikovat do zbytku site. Samo to vyzaduje prislusny prislusne nakonfigurovany HW = managovatelne switche, a zadne krabky ruzne v rohu/pod stolem/...
Tim zaroven vyresis onen "problem" s falesnym dhcp/ra. Pri predpokladu, ze svuj HW mas plne pod kontrolou, ze si useri nemuzou instalovat/prenastavovat kde co, se pak proste nemuze stat, ze by takovy zarizeni proslo pres port switche.
Realita je ovsem samo jinde, a proto se i tu resi co se resi ...
-
MG (neregistrovaný)
Kdo se připojí/nepřipojí řešit přes 802.1X lze (pominu-li fakt prakticky dost často špatných implementací), nicméně tento proces je zcela nezávislý na přidělení adresy klientovi, či pokud autentizovaný klient odesílá podvržené informace do sítě. Tzn. vůbec případ podvržených RA, DHCP či čehokoliv neřeší. Proto je to třeba vždy kombinovat s FHS, kde potom třeba díky DHCP snoopingu vnutím klientovi jednu adresu, kterou mám pod kontrolou já a zamezím tak podvržení, flood, MiM apod. Jediné co mi 802.1X umožní je potenciální rychlejší dohledání útočníka. Nicméně to je pozdě.
-
j (neregistrovaný)
Jakto ze neresi ... resi to naprosto vpohode. Jakejkoli ucastnik v siti je autorizovanej. Zaroven plati, ze ucastnici site jsou pod kontrolou admina === uzivatel si nenainstaluje ani nespusti nic, co by admin neschvalil => naprosto logicky nemuze nastat pripad, ze by se nekomu v siti povedlo spustit RA nebo DHCP.
Me by fakt zajimalo, jak si jako user s omezenejma pravama spustis na tom stroji dhcpko nebo neco co bude posilat RAcko, protoze ty se jednoduse ani nedostanes k prislusnym portum/adresam. Nejdriv bys musel hacknout firemni system, ale to se bavime uz o ponekud jinym levelu, nez ze "nekdo prisel a podvrhnul RA".
Samo, pokud chces provozovat nejakym zpusobem verejne pristupnou sit ... je to ponekud neco jinyho, ale v takovym pripade je to proste "as is". O svoji bezpecnost necht se pak kazdej postara jak umi.
-
Santiago (neregistrovaný)
> Jakto ze neresi ... resi to naprosto vpohode. Jakejkoli ucastnik v siti je autorizovanej. Zaroven plati, ze ucastnici site jsou pod kontrolou admina
Jenze to plati jen pro nektere typy managovanych siti (napr. podnikove), v jinych nema sitovy admin kontrolu nad pripojenyma stanicema.
-
KapitanRUM (neregistrovaný)
A zase potvrzuješ, že je můj názor na tebe správný.
Sám jsem v tom smyslu o sobě a o post výše - psal, ostatně jsi to četl.
Ty si přečteš, co jsem napsal a pak to jen přepíšeš, tím vznikne tvůj jedinečný názor. Na jednu stranu by mě to mohlo těšit,ale na druhou stranu se jedná jen o otravné papouškování. Jestli od mne čekáš nějaká slova uznání, jako že když se chci omluvit panu Šimerdovi, že jsem snad v nějaké rozněžněné náladě, tak že bych se mohl třeba omluvit i tobě, tak se nedočkáš, PAN Pavel Šimerda je sice někdo, s jehož názory ohledně IPv6 naprosto nesouhlasím, ovšem je také člověk, který má (nejen) můj respekt.
