Názory k článku IPv6 umožní používat IoT bez závislosti na službě třetí strany

> V dnešním světě IoT přibývá různých zařízení, která se mají
> propojovat mezi sebou, ale současný internet to neumožňuje.
> (...)
> Internet chytrých věcí by měl využívat princip end-to-end,
> který je základem internetové sítě. Můžete se přímo připojit
> z mobilu k chytré krabičce a ovládat ji přímo. Protože k tomu
> je internet určený. Obvykle to ale vyžaduje nějakou konfiguraci,
> takže je to odsouzeno ke komerčnímu neúspěchu.

Jenže i na IPv6 bude pravděpodobně po cestě nějaký firewall, takže ani s ním to nebude plug-and-play.

Přesně tak. Uživatel bude muset zjistit IP adresu toho zařízení, otevřít přístup ve firewallu, a pak při připojování zadávat ten šílený řetězec IPv6 (vlastní doménu skoro nikdo nemá). Nebo zařízení bude používat centrální server, což bude fungovat out-of-the-box.

A umíte si představit, že výše uvedený postup dělá třeba vaše matka, aby zprovoznila nějakou "chytrou" zásuvku?

Poznam aj lahsie cesty.

Cez UPnP sa da nastavit firewall alebo broadcastovat klientom, kde je to zariadenie v sieti na prve nastavenie. Vo Windows to maju integrovane v GUI a system zariadenie najde ako sietove zariadenie - staci dvojklik a ste na jeho webe.

V dnesnej dobe sa to riesi vacsinou aplikaciou na smartfon, ktora najde to svoje zariadenie a potom si zapamata jeho IP. Tu by to automaticky fungovalo aj z inej siete.

Pri firewalle je samozrejme treba urcit, kto ho spravuje. Ked lubovolne aplikacie, tak netreba potvrdenie. Technicky je lahke vypytat si vo Web UI potvrdenie na to, co chcela aplikacia spristupnit cez UPnP.

UPnP ma kazdy, kdo to mysli s bezpecnosti vazne bud omezeny, nebo uplne vypmuty.

Tak moment, chcete jednoduchost, nebo bezpečnost? Obvykle nemůžete mít oboje.

A umíte si představit, že výše uvedený postup dělá třeba vaše matka, aby zprovoznila nějakou "chytrou" zásuvku?

Ano, u své mamky si to představit dovedu. Je jí sice 66 let a nejvyšší vzdělání má střední školu, ale nemá problém se učit a když něco neví, tak se zeptat.

Jakákoliv technologie se stává nebezpečnou, když člověk neví co dělá a je líný se naučit ji používat a znát alespoň v obrysech její výhody a úskalí.

Pokud někdo není schopen/ochoten naučit se, co je to "adresa", nechť chytré zásuvky nepoužívá. IPv6 pro potřeby uživatele není o nic složitější záležitost, než telefonní čísla nebo poštovní adresy... Dělat "chytré technologie" pro blbé uživatele je největší chyba současné společnosti.

16. 6. 2020, 10:11 editováno autorem komentáře

Vidím to úplně stejně, hlavně pod tu poslední větu bych se podepsal. Teda tím nechci říct, že by každý musel být odborníkem na všechno, to nejde, ale aspoň nějakou míru znalosti o tom, co dělám/s čím pracuju je potřeba mít.

Bohužel mi ale přijde, že pro lidi (rozuměj BFU) je důležité, aby všechno bylo co nejpohodlnější, aby to "myslelo" za ně a aby všechno bylo nejlíp hned. Že tím přichází o soukromí nebo tam mají bezpečnostní díru jako vrata, to nikoho moc nevzrušuje.

Jste v zajetí současných síťových stereotypů. Co kdyby to fungovalo tak, že si zákazník donese domů zařízení, do telefonu nacpe dodanou aplikaci, oboje se při prvním zapnutí napojí na server a vyřeší si nastavení? Od té doby se zařízení spojují napřímo BEZ serveru. TEPRVE AŽ nezafunguje automatické nastavení (server nejede, nebo rovnou výrobce zkape), bude holt uživatel muset zvednout p*del a nastavit to ručně, ale nebude muset zařízení VYHODIT! Co je na tom tak nepochopitelného?

No nevím, znáte nějaké zařízení, aspoň jedno, které by takhle fungovalo?

Já se zatím setkal jen se 2 možnostmi:
1) zařízení se stabilně připojuje někam do cloudu a odesílá tam cokoliv chce na nějakých vysokých portech nebo naopak na :80 či jiných běžně otevřených portech, předpokládá se, že kdo neumí nastavovat jednotlivá zařízení, neuměl ani nastavit firewall na routeru
2) zařízení používá nějakou řídící krabičku v LAN, samotné dílčí zařízení pak broadcastuje do LAN nebo používá nějakou metodu aktivního párování na HW, čili třeba posílání identifikace po stisknutí tlačítka. Krabička samotná se pak buď ovládá zase z cloudu nebo "je určena pro profesionály", takže používá webové rozhraní na lokální IP.

Varianta 1) je velice oblíbená výrobci, protože jim přináší krom samotných zajímavých dat naprostou kontrolu nad tím, kdy donutí uživatele koupit si nové zařízení. Stačí po uplynutí záruky přestat to zařízení v cloudu podporovat. Varianta 2) je přijatelně levné řešení, které se tváří "profesionálně". Zařízení řízená nějakou aplikací v mobilu jsou vždycky připojená na cloud, protože je tím zajištěný krom telemetrie problém s nastavením a jednotný přístup odkudkoliv.

To ale neznamená, že takto fungující zařízení musíte kupovat.

Variantu 1) jsme dělali taky, ale proto, že jediná jistota byla, že pojede IPv4. Co jsme dělali IoT bazmeky, tak nebyl s mirror serverem problím strhat 10Gbps linku a cena za servery a jejich provoz na pět let byla asi 1/3 ceny výrobku.

S tímhle, pokud by byla možnost jet jenom na IPv6, by se výrobek stal (cenově) hodně konkurence schopný. Jenomže to by museli ISPíci taky začít to IPv6 podporovat...

Momentálně největší problém s IoT a IPv6 je fakt, že se z LTE člověk nepřipojí, kdyby se na ptáka stavěl. Aspoň ne u nás. Kdyby tak aspoň to 5G udělali na IPV6, jinak je to na dalších 15 let beznadějný...

Pri sucasnej kvalite firmware vo vacsine IoT zariadeni, by si len blazon trufol nieco take spristupnit napriamo z vonku.
Pokial toto spravis, tak v podstate ziaden firewall ani nepotrebujes ;-)

Jenže i na IPv6 bude pravděpodobně po cestě nějaký firewall
Proč? Co ten firewall bude dělat?

https://cs.wikipedia.org/wiki/Firewall

Takže je to zbytečné a žádný firewall tam potřeba není. Děkuji za odpověď.

Tak mě napadá, že vy jste poskytoval bezpečnostní konzultace nemocnici v Benešově? ;-)

16. 6. 2020, 12:26 editováno autorem komentáře

Ten firewall bude jako kde? Uvnitř jednosegmentové sítě s čínskou krabičkou (případ garáže) asi ne. U uživatelů, kteří upřednostňují pohodlí před bezpečností, může být firewall vypnutý (jejich věc). A u těch, kteří chtějí bezpečnost, jej holt budou muset nastavit, ale to je jaksi podstata sítí, o tom nemá smysl polemizovat.

@L: Nevím, v čem je problém. IoT většinou stejně jede jenom na MQTT, ZMQ a pár daších standardech, nechat přslušný porty otevřený není problém a když na ně někdo poleze na jiným zařízení, tak to prostě dropne. Pokud to zařízení podporuje, autorizuje se nějakým klíčem (ECDSA apod.). Není to o nic nebezpečnější, než nechat povolenou 22ku. Hotovo.

A pokud jde o spárování, tak třeba Bluetooth má unikátní ID, něco jako MAC adresu. I když dělám vývoj a něco s BT tam bylo a dokonce občas BT i používám, nedal bych ruku do ohně za to, kolik to ID má bitů. Prostě jsem ho nikdy ručně neopisoval a jenom jednou v životě jsem v nějaké zprávě deklaroval pro tohle číslo pole. Myslíš, že pokud se chc, tak se zadávání adresy nevyřeší?

A víš, že používám Syncthing po IPv6 bez toho, že bych konfiguroval cokoliv na firewallu, nebo nastavoval adresy? A funguje to dokonce i mezi mobilama (SLAAC + Private Extension). A synchronizovalo se to i předminulý víkend, když jsem si hrál se sítí a nechal omylem pět dní zakázaný DHCPv4 v LANce a nemělo to IPv4 přes WiFi (LTE doma vypínám). Prostě si přes server vymění adresy a jede se napřímo... A server si můžu spustit i doma v LAN.

Bluetooth má standardní MAC adresu (v tuto chvíli 48 bitů/6 byte), ale jestli mluvíte o UUID služby v rámci Service Discovery Protokolu, to má historicky 16/32 bitů, ale dnes se používá prakticky výlučně 128 bit UUID, na která jsou tato mapována (vložením do prvních 32 bitů hodnoty XXXXYYYY-0000-1000-8000-00805F9B34FB, kde 00000000-0000-1000-8000-00805F9B34FB je Bluetooth Base UUID).

Ta posedlost hodit každé zařízení na internet mě docela děsí. Je to obrovské bezpečnostní riziko ...

Za rozumné minimum bych považoval, že všechny tyhle pračky, teploměry a podobné nesmysly uzavřu do samostatné vlan a před to strčím velmi restriktivní firewall - protože ta zařízení prostě nejsou a nebudou bezpečná. Jenže takhle si to zapojí možná trošku paranoidní IŤák, co má doma i chytřejší switch a trošku ponětí o tom jak ty věci fungují. BFU to strčí všechno do jedné sítě a pak se bude strašně divit, že mu domácí NASku nebo notebook někdo hackne zkrz pračku, která je permanentně připojená do nějakého podivného cloudu.

IPv6 tomu moc nepomůže, protože kolik operátorů domácímu uživateli dá takový rozsah, aby si ho mohl rozdělit na víc /64 do různých vlan ? To samozřejmě neni problém samotné technologie ale toho jak se to implementuje.

Jenze zamostatna VLAN se da smysluplne udelat jen tak, ze jsou site oddelene i na L3. A taky nastava potiz, kdyz provider prideli jen IPv6 segment /64 (jak je bezne, kdyz uz nekdo IPv6 adresu dostane. To umoznu je provozovat jen jedinou L3 sit, protoze prestoze 2^64 adres je dost, tak /64 sit je dale nedelitelna (z vice duvodu, i kdyz se to muze podarit rozdelit, je to mimo standart a casem se najde nejake nechtene prekvapeni).

Takovym ISP je treba psat, zadat je o opravu, psat o nich a pripadne od nich odejit.

Čo vďaka miestnym monopolom nie je až také jednoduché. Keď máte na výber medzi UPC a jeho jedinou /64, alebo DSL so 6 MBit/s keď všetko ide dobre, čo si vyberiete?

Na UPC naštěstí (alespoň s modemem Compal) funguje subdelegace prefixů, takže na svůj router dostanete /60 a to už na víc sítí rozdělit jde.

Ale rozumím a souhlasím, místní monopoly ignorující IPv6 jsou problém.

Při té příležitosti bych se chtěl zeptat, zda existuje (u nás či v zahraničí) pronajímatel VPS, který poskytuje IPv6 nejméně /60, takže by se to dalo použít na tunelování do vlastní sítě, a to i do té nejhorší (= bez IPv6, IPv4 neveřejné).

Radek Zajíc na nějakém IPv6 dni zmiňoval, že tohle řeší přes Hetznera, kde se dá o dodatečné /64 požádat nebo si je nějak naklikat snad. Jestli Vám stačí 20 TB za měsíc (většině tohle asi stačit bude) tak to je asi docela dobrá volba. Za ca. 3 € na měsíc to myslím je dost ok. Hlavně tam můžete dobře rozchodit např. Wireguard.
https://www.hetzner.com/cloud?country=cz

Jinak existuje např. tunel od VPSfree v režiji Ondřeje Caletky: https://kb.vpsfree.cz/informace/projekty/ipv6tunel
https://www.linuxdays.cz/2017/video/Ondrej_Caletka-IPv6_tunely_pomoci_OpenVPN.pdf

Jinak asi Hurricane Electric Free IPv6 Tunnel Broker
https://tunnelbroker.net/

16. 6. 2020, 15:05 editováno autorem komentáře

Problém bude mnohem víc to, že BFU neví že něco takového má vůbec řešit. To že lidi jako my tu situaci nějak vyřeší, považuji za samozřejmé. Jestli vytáhneme od operátora alespoň /56 pro IPv6, použijeme pouze lokální IPv4 a NAT, nebo to vyřešíme nějak jinak ... to je pouze technická věc.

Ale případů, kdy nějaké IOT zařízení se stane prostředníkem pro útok na zařízení v interní síti bude prostě čím dál víc. Osvěta je kolem toho nulová a každý výrobce tlačí svoje ultra chytré zařízení ovládané přes aplikaci zkrz cloud. Možná jsem paranoidní ... ale ja takových věcí prostě fanouškem nejsem a zařízení ve své síti chci mít co nejvíce pod kontrolou.

V tom se shodneme. Jako vývojář HW + embedded to vidím takto:

1) Konektivita stojí peníze. Za HW, SW a testování. Pokud nepřinese bonus pro zákazníka, který je ochotný zaplatit, tak je nesmysl se připravit o zisk, nebo být dražší než konkurence.
2) Pokud tam už nějaká komunikace musí být, je lepší volit dráty. Protože rušení, odposlech, vysoký vysílací výkon (nejlešpí přítel akumulátorů a baterií) a cena (když připočítám homologace atd.)
3) Pokud jde o interní komunikaci systému, je lepší volit jednodušší a levnější řešení ( jako Modbus po RS-485 nebo CAN ), než se drbat s TCP/IP, web serverem a zabezpečením.
4) Pokud chci ze systému ven, je lepší udělat gateway (nebo komunikační kartu). Uživatel získá jedno rozhraní (ne 20 webů na 20 krabičkách), já jako dodavatel chybu v komunikaci ven opravuju na jednom místě v jednom produktu (ne zvlášť vypínač, zvlášť zásuvku, zvlášť lustr,...) a gateway si koupí jenom ten, kdo o ni stojí. A mám tam dost výkonu (ty nářky, že teploměr nedá ani AES a MD5 jsou na kopanec špičatou botou).
5) Pokud si povolím přístup z veřejné sítě, zodpovídám za průšvihy a musím řešit záplaty. Ať si zákoš připlatí za podporu. A pokud mám tunelovat NATy a řešit podobný kulišárny, ať si to taky zaplatí.

Pokud síť odělím na druhé síťové vrstvě, tak pochopitelně použiju pro jejich adresaci i jiný adresní rozsah. To je snad samozřejmé.

Je, ale ve světě IPv6 to znamená /64 pro každou VLANu. A když nějakým zázrakem ISP přidělí jenom /64, je vymalováno. Všechno na jedné hromadě (špatně), nebo ULA prefix a NATování (ještě horší, pak IPv6 ztratí smysl).

Momentálně doma jedu na šesti sítích:
0. WAN mezi routerem a modemem
1. LAN (klasicky komply s Linuxem, záplatovaný a relativně bezpečný)
2. "Špinavá" síť pro mobily, telku s HBB, WiFi,...
3. IPTV pro set top boxy + pronajatý stroje, o kterých vím jenom to, že mají víc než dva roky starý FW
4. WiFi pro hosty
5. IoT síť, kde je třeba tiskárna apod., do které se dá dostat jenom z LAN a špinavé sítě
6. Síť pro management, kde můžu konfigutrovat APčka, switche, router,... a je přístupná jenom z LANky
7. Ani to nepočítám jako síť, ale servisní rozhraní z modemu mám trunkem přihozený jako VLANu na switch v pracovně, kdybych něco musel řešit.

Je super, že mám /56 prefix. Jinak by to byl docela problém...

Nikdo to nechce, nikdo to nepotrebuje, end-to-end komunikace predstavuje zejmena pro IoT neskutecne riziko.

Pulka tech kramu ani nema moznost sifrovani, spousta z nich nema autentizaci, nebo se neumi aktualizovat. Implementace tcp/ip je zhusta zalostna.

Raspberry pi fakt NENI typicke produkcni IoT zarizeni, uz kvuli jeho spotrebe, velikosti a narocnosti na napajeni.

Typicky je spis china made singlechip, jaky se treba strka do pracek Candy, nebo ty "chytre" krabicky na radiatorech.

Dokonce i arduino je na hranici pouzitelnosti se svou proudovou spotrebou.

Vstup do domu pres internet je diagnoza hodna odborneho zajmu docenta Chocholouska.

A posledni poznamka, jediny prinos IDN je snazsi oklamani uzivatele utocnikem.

Vendor lock není přeci daní verzí protokolu. Pokud IoT bude svázané se službou výrobce tak bude prostě svázané a 4 vs 6 na tom nic nemění.

To je stejně naivní idea jako, že BTC nelze půjčit, nelze úročit . Proč by to nešlo jen protože si někdo tak ideově přeje?

> Vendor lock není přeci daní verzí protokolu. Pokud IoT bude svázané se službou výrobce tak bude prostě svázané a 4 vs 6 na tom nic nemění.

Presne. Niektorí si len mýlia príčinu a zdôvodnenie. Poväčšinou vendori chcú, aby dané zariadenie bolo zviazané s ich službou, NAT alebo ne-NAT, firewally a ne-firewally.

Rozdíl je v tom, že s IPv6 je to řešitelné, s IPv4 to reálně jinak než přes nějakého zprostředkovatele v internetu nejde.

Stále Vám uniká, že to nikto riešiť nebude. Lock-in na servery vendora je featura (pre daného vendora), NAT je len zdôvodnenie. Pokiaľ by nebolo NAT/IPv4, našlo by sa iné, napr. používateľská prívetivosť, integrácia s ekosystémom, alebo iný žvást.

Riešite svet aký by ste ho chceli mať, nie aký je.

To není vždy pravda. Byl jsem u zrodu jedné cloudové IoT služby a první verze se snažily připojovovat z cloudu přímo na zařízení uživatele v jeho síti. Hodně úsilí se věnovalo nápovědě a nástrojům, které uživateli usnadňovali nastavení portforwardingu, ale stejně drtivá většina uživatelů to nezvládla.

Pak jsme začali dodávat krabičku, která tunelovala spojení ze sítě zákazníka na naše servery a byl to úspěch. Hlavně v USA je cena v řádu desítek dolarů naprosto zanedbatelná proti tomu, když se technik může při zprovozňování služby na několik hodin nečekaně zaseknout u zákazníka a řešit port forwarding.

Kdyby existovalo technické řešení, které jednoduše umožní zákazníkovi nastavit přístup na zařízení v jeho síti z našich serverů, rozhodně bychom ho použili a nebabrali se s vývojem vlastního HW, jeho distribucí, reklamacemi atd.

No ja som videl všeličo, aj hard-coded DNS (napr. aj Chromecast má napevno 8.8.8.8), pretože podľa daného výrobcu mnohí zákazníci mali rozbité DNS.

Pripájanie sa zvnútra siete von bude vždy jednoduchšie, ako naopak. Je jedno, či je tam NAT alebo nie je, či tam je IPv4 alebo IPv6. Vy ako vendor si to na svojej strane ošetríte, a na strane zákazníka to má väčšiu pravdepodobnosť fungovať, pretože by default to firewally v CPE umožňujú.

Jasně, to, že musí platit provoz serverů, z toho je dodavatel vysloveně nadšený. Uživatelská přívětivost ani integrace s ekosystémem nevyžadují, aby veškerý provoz šel přes servery dodavatele.

To sú drobné v porovnaní s prínosmi, ktoré to má. Od telemetrie ktorá sa dá predávať ďalej po umelé ukončenie podpory a donútenie zákazníka kúpiť si novšie modely.