Vlákno názorů k článku Vyčmuchejte si svého hackera! od Jaromír - "Prvních šest bytů ethernetového rámce obsahuje MAC adresu...

Nejsem autor clanku, jen jsem se ho zastal, a poukazal na casty nesvar honit ego tim ze se z relativne jednoduchych zalezitosti delaji slozite, a baziruje se na nuancich v terminologii, tot vse. Pravdou ale je ze mel byt aspon konzistentni, takhle je to zmatene.

já si ego nehoním, jen mě to prostě zmátlo
plácá tám paket přes rámec a je mu to evidentně jedno

dnes se už asi 10 let učí na školách TCP/IP + samozřejmě starý OSI, vím o čem mluvím, taky to do mě naštěstí "cpali" :)

Co je na ISO/OSI starého? Je to logické rozdělení do vrstev vhodné pro poznání rozdílů mezi jednotlivými druhy komunikace. To, že některé reálně existující protokoly mají ty vrstvy splácnuté dohromady, případně je vůbec neimplementují je přece jiná věc. V matematice máme také komplexní čísla, ačkoliv je v reálném světě neimplementujeme (tedy ještě jsem neviděl, aby mi chtěla prodavačka vrátit nějaké to 0,2i :-)

V praxi se prostě občas sahá ke zjednodušením, která nevypadají tak elegantně jako teorie, na druhou stranu ovšem většinou fungují lépe :-)

Někdy jsou ty protokoly opravdu poněkud nelogické. Proč třeba OSPF neběží nad UDP a má své vlastní číslo protokolu?

OSPF je jedne z protokolu IP rodiny - tak jako je jim TCP, UDP, BGP ...

Zrejme od nej jeho autori vyzadovali vlastnosti, ktere maji protokoly IP rodiny, ovsem, nepotrebovaly od nej koncept "portu", ktery prinasi UDP. Tahle informace by tam pak byla naprosto nadbytecna a prinasela by zbytecny overhead. Nebo naopak potrebovali nejakou vlastnost, kterou UDP ve sve definici neobsahuje. Myslim, ze pri navrhu skoro kazdeho noveho protokolu stoji dotycny pred otazkou nad jakym protokolem onen svuj novy postavi. Jestli zvoli TCP, UDP, IP, IPX, NetBEUI - to zalezi od toho, co navrhuje a jake vlastnosti potrebuje ...

BGP je protokol běžící nad TCP.

Tak jak znám OSPF, tak nevyžaduje žádné vlastnosti, které UDP nemá. To, že nepoužívá UDP je prostě nekoncepční zjednodušení. Prostě si to navrhli tak, jak jim zrovna přišlo na mysl a považovali to za nejjednodušší.

Tak jak znám OSPF, tak nevyžaduje žádné vlastnosti, které UDP nemá.

Ale uplne presne snad plati i to, ze OSPF nevyžaduje žádné vlastnosti které UDP má a plne vystaci s temi vlastnostmi, co ma IP. Dalo by se tedy klidne rict, ze uziti UDP je zbytecna komplikace.

S posledni vetou prispevku ovsem plne souhlasim.

No stare je to, ze uz mu je docela dost, navic dost z nej je citit euro americky akademicky konflikt, ktery tu zname jiz taky dost dlouho. Po teoreticke rovine sice krasny, ale do dnes ani v akademickych podminkach ne zcela implementovany (Vy znate sit, ktera by se presne dle 7-dmi vrstveho ISO/OSI implementovala a chovala a zejmena byla tak striktne delena jak to rika ten model? Kde by se relace oddelovala od aplikacni vrstvy atd.?) Samozrejme mame spoustu hybridu od vseho mozneho, mame take ciste implementace (ROSE (?)) urcitych vrstev... Nerikam, ze ISO/OSI je na nic at zije vse okolo IP, naopak, kdyby to bylo rozsirene, jak krasne a docela jednoduse by se treba implemntoval replikacni FS s vlastnostmi Fail Over a High Availability... jak by bylo snadne vyuzit princip zasilani zprav pro mnoho aplikaci... Bohuzel realita je jina a mluvit o ISO/OSI v souvislosti s IP a vecmi okolo (kam radit ICMP nebo ARP? <g>) mi nidky neprislo jako dobry napad, bohuzel dostalo se to i do ucebnic...:-(

neznám samozřejmě síť, která by fungovala podle ISO/OSI. Co jsem chtěl říct, je to, že tento model dává návod, co do které vrstvy patří. a kde to tedy má implementovat. Potom by se nestávalo, že každý protokol si znovu a znovu implementuje tu stejnou funkčnost (třeba prezentační vrstvu)...

Do učebnic tento model tedy celkem oprávněně patří.

> potom by se nestávalo, že každý protokol si znovu a znovu implementuje tu stejnou funkčnost (třeba prezentační vrstvu)...

Obvykle nikoliv, potřebné knihovny jsou dostatečně standartní (asn.1, xdr, ssl, sasl...). To že jsou občas děravé je jiná věc.

A že máme třeba BER parser/kodér v dynamické knihovně místo přímo v protokolovém stacku nikomu žíly netrhá, na výkon to má nulový vliv, a takhle se to aspoň líp udržuje. "prezentační vrstva" je výmysl který nikomu nechybí.

No prezentacni mozna urcite (obcas), ale co treba takova relacni... proc by se aplikace sama mela starat o autentizaci, proc by mela jit treba az na transportni, pripadne vyse a operovat s pojmy jako certifikat, validace certifikatu atd... - vzdyt to tu aplikaci VUBEC nezajima, ta je uplne pro neco jineho. Uvedu analogii v IP svete - WWW aplikace, ktera funguje jak ma, vubec neresi, zda-li je tento GUI ksicht tunelovany via http nebo https, vubec neresi veci jako certifikaty apod. maximalne si vola servisni funkci isSecure(), ktera vrati true, pokud komunikujeme po zabezpecenem kanalu a dle toho muze upravit chovani... Takze v beznych aplikacich naprosto NIC neresi urcita funkcionalita dislokovana v knihovne, kterou musi aplikace aktivne pouzivat a volat...

> Takze v beznych aplikacich naprosto NIC neresi urcita funkcionalita dislokovana v knihovne

Proc? Ze neni dostatecne transparentni? Ano, treba openssl vas nuti misto read/write prejit na BIO_read/BIO_write. Tak se udela search&replace (pravdepodobne jen jeden), to je toho.

> kterou musi aplikace aktivne pouzivat a volat...

Pokud to API z knihovny presunete do protokoloveho stacku, bude to stale treba "aktivne" pouzivat. Pravdepodobne to bude o neco jednodussi, ale nijak drasticky.

Prominte, ale ISO/OSI je prave o protokolove separaci ve vrstvach... - nevim o tom, ze by v ISO/OSI bylo pripustne aby prezentacni vrstva kumunikovala se sitovou (validace a hlidani session proti IP adresam a MIM utokum) nebo relacni a linkovou (zamykani komunikace na portech - switche (link) proti autentizaci (relacni - certifikaty)) atd.

Naopak, pokud system policy rekne, ze pravidla jsou takova makova, tak bud aplikace pozaduje prostredky, ktere jsou dosazitelne v danem kontextu nebo nejsou a pak neni mozno tu aplikaci provozovat. A na abstraktni rovine si to klidne predstavte tak, ze se nejedna o protokoly, ruzny HW, ale o to, ze uzivatel A ziska takovy environment, ze neco muze a uzivatel B ziska jiny, kdy neco nemuze. Aplikace pouze o prostredek pozada a bud ho ziska nebo ne, jak kdo cim apod. to cele definuje je zcela mimo ramec teto aplikace (takze zpet poukazuji treba na to, ze aplikaci je kulovy po autentizaci, certifikatech atd.) a je to vec jinych vrstev. Zda-li je to obsah OS, sitoveho protokolu (kterym aplikace nekomunikuje, ale muze slouzit jako transportni pro jeji komunikacni protokol), knihovny vrstvy/tev pod aplikaci je zcela ukradene...