Masarykova Univerzita Fakulta Informatiky

Technologie pro snadnou konfiguraci sítě klienta a service discovery

Bakalářská práce

Martin Kopecký

Brno 2007 Prohlášení

Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval(a) samostatně. Všechny zdroje prameny a literaturu, které jsem při vypracování používal(a) nebo z nich čerpal(a), v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce Mgr. Vlastimil Holer

-2- Poděkování

Na této straně bych chtěl poděkovat: • rodičům, • Mgr. Vlastimilu Holerovi, vedoucímu mé bakalářské práce, • Lukáši Fryčovi, studentovi, za podnětné připomínky.

-3- Shrnutí Tato práce se zabývá technologiemi a protokoly, které vykonávají automatickou konfiguraci zařízení, připojujícího se do počítačové sítě, a poskytují service discovery. Popisuje principy fungování těchto protokolů, jejich implementace a jejich budoucí využití.

-4- Klíčová slova service discovery, UPnP, SLP, Zeroconf, DHCP, RARP, Neighbor Discovery

-5- Obsah 1 Úvod ...... 8 1.1 Service discovery...... 8 2 Service Location Protocol...... 9 2.1 Popis SLP...... 9 2.2 Struktura a fungování SLP...... 9 2.3 Rozdíly mezi 1. a 2. verzí SLP...... 10 2.4 Bezpečnost...... 11 2.4.1 Útok Denial of Service...... 11 2.4.2 Bezpečnostní politika SLP...... 11 2.5 Použití a implementace...... 12 2.6 Porovnání...... 12 3 Zeroconf...... 13 3.1 Popis...... 13 3.1.1 IPv4 Link Local Addressing...... 13 3.1.2 Multicast DNS...... 14 3.1.3 Service discovery...... 14 3.1.3.1 DNS-SD...... 15 3.2 Implementace...... 15 3.2.1 Bonjour...... 15 3.2.1.1 mDNSResponder...... 16 3.2.1.2 Zabezpečení...... 16 3.2.1.3 Využití...... 16 3.2.2 Howl...... 16 3.2.3 Avahi...... 17 4 Universal Plug and Play...... 18 4.1 Popis...... 18 4.2 UPnP service discovery...... 18 4.2.1 Nalezení zařízení – SSDP...... 18 4.2.2 Popis nalezené entity...... 18 4.2.3 Kontrola zařízení...... 19 4.2.3.1 SOAP...... 19

-6- 4.2.4 Oznamování událostí a prezentace služby...... 19 4.3 NAT...... 20 4.3.1 Internet gateway device...... 20 4.5 Bezpečnost UPnP...... 20 4.5.1 Ověřování nalezeného zařízení...... 20 4.5.2 Zabezpečení kontrolního protokolu...... 21 4.6 Využití a implementace...... 21 5 Další protokoly...... 21 5.1 RARP...... 23 5.2 DHCP...... 23 5.3 NDP – Neighbor discovery protocol...... 24 5.3.1 Komunikace mezi hostitelským počítačem a routerem...... 24 5.3.2 Komunikace mezi hostitelskými počítači...... 25 5.3.3 Funkce pro přesměrování paketu...... 25 5.3.4 Secure neighbor discovery...... 25 6 Závěr...... 27

-7- Kapitola 1 Úvod S rozvojem sítí a jejich rozšířením do běžného života začaly stoupat i požadavky na snadnou a rychlou konfiguraci počítače připojeného do sítě. Cílem bylo odlehčit správě neustále rostoucích sítí a umožnit pohodlnější připojení do sítě. Zároveň s tím může klient ob­ držet i další informace, charakterizující danou síť. Dokud byly sítě poměrně malé, jevilo se jako nejvhodnější řešení použití protokolu RARP1. S rostoucí rozlehlostí a strukturou sítí, se však tento protokol začal jevit jako nedosta­ čující, zejména kvůli jeho omezení nastavit klientovi pouze IP adresu. Tento problém vyřešily protokoly BOOTP2 a DHCP3, které navíc umožňují nastavit počítači i další informace, nezbytné pro komunikaci v síti, jako jsou maska a brána sítě a adresa DNS4 serveru . Kromě těchto pro­ tokolů, vyvinutých primárně pro konfiguraci počítače, existují i technologie, které tuto službu také poskytují, a navíc umožňují vykonávat tzv. service discovery.

1.1 Service discovery Jedná se o schopnost nalézt bez předchozího nastavení v sítích zařízení poskytující určitou službu. Ta pak může být využita k vyžádaným úkonům. Před nalezením však musí být tato služba registrována v síti. K těmto operacím slouží specifické protokoly, tzv. service dis­ covery protokoly. Hlavními cíli při vytvoření service discovery bylo umožnit nalezení dané služby a zaru­ čit, že vyhledávání a registrování bude probíhat bez předchozího nastavení sítě. Dané poža­ davky však velmi snižují bezpečnost a důvěrnost v dané síti. Tyto problémy částečně řeší servi­ ce discovery protokoly. Ty můžeme rozdělit do tří kategorií. V první skupině jsou protokoly pracující v ad-hoc sítích. Ty používají pro komunikaci broadcast (všesměrové vysílání) a multicast (vysílání pouze pro uzly určité skupiny). Mezi ta­ kové protokoly patří např. Bluetooth SDP, DEAPspace nebo Allia. Dále to jsou protokoly určené pro sítě typu WAN (Wide Area Network). Z důvodu pre­ vence před velkým zatížením komunikačních linek je zakázáno používat broadcast a multicast. Nejznámějšími protokoly, vyvinutými pro tento druh sítí jsou např. Superstring nebo GloServ. Posledním typem jsou protokoly operujících v malých lokálních sítích typu LAN (Lo­ cal Area Network), pro něž byl service discovery původně navržen. Zde jsou použity velice fle­ xibilní a spolehlivé protokoly SLP, Zeroconf a UPnP. Kapitoly dvě, tři a čtyři se zabývají výše zmíněnými protokoly umožňující service dis­ covery v lokálních sítích. V kapitole páté jsou popsány historické, současné a budoucí protoko­ ly, které provádějí automatickou konfiguraci zařízení. Závěrečná kapitola obsahuje přehled této práce a možnosti budoucího využití popisovaných technologií. V přiloženém CD se nacházejí funkční zdrojové kódy protokolů service discovery.

1 Reverse Address Resolution Protocol 2 Bootstrap Protocol 3 Dynamic Host Configuration Protocol 4 Domain Name Service

-8- Kapitola 2 Service Location Protocol

2.1 Popis SLP SLP je standardní vyhledávací protokol, který byl vytvořen pro nalezení a využívání za­ řízení v LAN sítích bez předchozího nastavení. Hlavními přednostmi jsou jednoduchá imple­ mentace a nenáročná kontrola. V současné době existují dvě verze tohoto protokolu. Verze č.1 je popsána RFC 2165 dokumentem a specifikaci verze č.2 obsahuje dokument RFC 2608.

2.2 Struktura a fungovaní SLP Struktura SLP se skládá ze tří softwarových entit. Ty tvoří základ SLP, viz. obrázek 2.2a. Komunikace mezi nimi probíhá na protokolech TCP a UDP na portu 427. První entita je User Agent (dále jen UA), což je počítač, který vyhledává služby. Druhou je Service Agent (zkráceně SA), zařízení oznamující existenci jedné nebo více služeb. Poslední volitelným softwarovým objektem je uzel uchovávající informace o registrované služ­ bě, tzv. Directory Agent (neboli DA). Tato úschova dat dokáže snížit množství přenesených dat tak, že SLP může být použito i v sítích s velkým počtem zařízení.

Obrázek 2.2a: příklad struktury SLP s DA Komunikace těchto entit se liší podle toho, zda je přítomen DA. Jeho existenci v síti lze zjistit statickou konfigurací (to ale odporuje původnímu cíli service discovery – nenastavovat síť), DHCP volbami 78 a 79 a SLP zprávou Directory Agent Advertisements poslanou jako mul­ ticast. Pokud není DA objeven, začne UA přímo komunikovat s SA, viz obrázek 2.2b. Protože SLP pracuje na protokolu UDP, který nekontroluje, zda pakety byly doručeny, posílá UA poža­ davek na zjištění služby jako multicast několikrát ve zvyšujících se intervalech, dokud ne­

-9- dostane odpověď v podobě funkce Callback, viz. příklad 2.2c, která vrátí klientovi informace o nalezené službě. Může nastat situace, kdy se SLP zpráva generovaná SA nevejde do UDP datagramu. V tom případě je tento paket označen jako přetečený a je povolena komunikace v protokolu TCP.

Schéma 2.2b: Znázornění komunikace mezi zařízeními bez DA ... SLPBoolean MSCallBack(SLPHandle slphandler, const char* serviceurl, unsigned short lifetime, SLPError error, void* cookie) { if(error==SLP_OK || error==SLP_LAST_CALL) { if(serviceurl==NULL || lifetime==0)exit(0); printf("URL service is %s\n",serviceurl); printf("Lifetime of service is %i\n",lifetime); *(SLPError*)cookie = SLP_OK; } return SLP_TRUE; } ...

Příklad 2.2c: funkce Callback

2.3 Rozdíly mezi 1. a 2. verzí SLP SLPv2 přináší několik důležitých změn. Jednou z nich je existence nové zprávy SA Ad­ vertisement, díky níž je komunikace mezi entitami nezávislá na tom, zda je DA přítomen. Důležitou změnou je povinnost používat při registraci služeb tzv. scopes, což jsou ad­ ministrativní domény, do kterých se seskupují služby s podobnými vlastnostmi. SLP umí vyhle­ dávat nejen podle těchto skupin, ale také podle atributů nebo URL5. Jejich tvar je popsán v tzv. Service templates, specifikovaných v RFC 2609 dokumentu. Použití těchto domén bylo v SLPv1 volitelné. Kromě toho byl přepracován proces ověření identity pro poskytnutí větší bezpečnosti, zejména pro DA Advertisement zprávy. Dalšími vylepšeními je využití LDAPv36 ve vyhledáva­

5 Uniform Resource Locate – unikátní adresa daného objektu 6 Lightweight Directory Access Protocol verze 3

-10- cích filtrech, přidání multicast příznaku, povolení abstraktních typů služeb, použití UTF-87 pro kódování znaků atd.

2.4 Bezpečnost Na bezpečnost v service discovery je kladen velký důraz. Jedná se především o preven­ ci před útočníky, vydávající se za požadované zařízení, a zabezpečené komunikace mezi agenty, aby se zmenšila pravděpodobnost útoků na zařízení poskytující službu a spravující informace o ní. Nejčastější napadení jsou DoS8 útoky a zosobnění.

2.4.1 Útok Denial of Service DoS útok spočívá ve znemožnění normálního fungování zařízení nabízejícím službu. Útočník intenzivně zahlcuje dané zařízení svými falešnými požadavky. To vede k zablokování běžného provozu počítače, který místo poskytnutí služby vyhodnocuje přijímané zprávy. Útok na zařízení s implementovaným SLP začíná odposlechnutím zprávy směřující od SA k DA. Útočník pak nastaví časovou známku na hodnotu větší než jakou měla původní zpráva, aby DA tuto změněnou zprávu akceptoval. Ten zprávu hned nezahodí, ale bude zkoušet ověřit si její pravost. To mu však znemožňuje zpracovávat žádosti od jiných uzlů. Tento bez­ pečnostní problém se částečně řeší omezením počtu žádostí, které mohou být poslány jedním zařízením za určitou dobu.

2.4.2 Bezpečnostní politika SLP Aktuální SLP verze č.2 má bezpečnost, zejména ověřování identity, založenou na kryp­ tografii veřejného klíče. Jedná se o asynchronní kryptografii, ve které se zprávy zakódovávají pomocí veřejného a soukromého klíče. Zpráva zašifrovaná veřejným klíčem může být rozkó­ dována pouze stranou, která vlastní soukromý klíč a naopak. Toto zajišťuje důvěrnost a autenti­ citu mezi komunikujícími entitami. U SLP má soukromý klíč SA nebo DA. UA zná klíč ve­ řejný. Používání této kryptografie sice zvětšuje bezpečnost SLP, ale porušuje jeden ze zá­ kladních cílů service discovery – být schopen objevit a využít službu bez předchozího nastavení sítě. Pro ověření identity je posílán autentizační blok viz. obrázek 2.4, ve kterém je uložen digitální podpis URL, seznamu atributů nebo SA a DA Advertisement zpráv. Tento podpis zajiš­ ťuje, že podepsanou zprávu ověří pouze uživatel vlastnící veřejný klíč. Kvůli zajištění dů­ věrnosti je ze soukromého klíče pomocí DSA9 vypočítán digitální podpis, který je pak zahe­ šován použitím SHA-110. Pro zvýšení úrovně bezpečnosti se používá buď řešení přes aplikační protokol s SSL11 nebo řešení na paketové vrstvě prostřednictvím IPsec12.

7 8-bitový Unicode Transformation Format 8 Denial of Service 9 Digital Signature Algorithm 10 Secure Hash Algorithm 1 11 Secure Sockets Layer 12 IP Security

-11- Obrázek 2.4: struktura autentizačního bloku

2.5 Použití a implementace SLP je využíván především pro nalezení a práci s obyčejnými tiskárnami nebo tiská­ renskými systémy. Kromě toho je však využíván i k jiným účelů. Např. klienti Novell NetWare ho používají k nalezení serverů nebo protokol ACN jeho prostřednictvím vyhledává inteligentní světla. Operační systém Mac OS a Mac OS X ho využívají k nalezení sdílených souborů. Aso­ ciace SNIA provádí service discovery ve SMI-S13 pomocí SLP. Ten je také využit instalátorem OpenSUSE pro nalezení instalačních balíků dostupných na síti. Tento protokol, uskutečňující service discovery je součástí základní distribuce SUSE Linux od verze 9.1 a výše, operačních systémů Mac OS a Mac OS X od verze 10.1, Sun Solaris 8 a NetBSD. Mezi nejznámější implementace SLPv2 patří open source projekt OpenSLP, který byl vyvinut společností Caldera International Inc. Ten je dostupný ve všech klasických jazycích jako jsou C, C++, Java nebo Python. OpenSLP je velmi přenositelný a je určen pro operační systémy Linux, BSD, Solaris, Tru64, UnixWare, OSR5 a Windows. V současné době je tato knihovna dostupná ve verzi 2.0 alpha 1, kterou lze stáhnout např. na internetové adrese http://sourceforge.net/forum/forum.php?forum_id=570427.

2.6 Porovnání Oproti protokolům UPnP a Zeroconf neposkytuje SLP příliš velký výběr pro své použití a navzdory možnosti začlenění DA do klasické struktury klient-server je prosazován hlavně pro malé sítě. Avšak v porovnání s výše zmíněnými protokoly má specifickou strukturu skláda­ jící se ze tří komunikujících entit.

13 Storage Management Initiative - Specification

-12- Kapitola 3 Zeroconf

3.1 Popis Zeroconf je zkratka pro Zero Configuration Networking, což je sada technik, jejímž cí­ lem je zajištění síťového provozu bez předchozího nastavení nebo administrace. Proto se vy­ užívá zejména v domácím nebo kancelářském prostředí, kde je konfigurace a správa sítě rychlá a snadná . Pro splnění těchto cílů musel Zeroconf zajistit výběr IP adres pro entity připojené do sítě (IPv4 Link-Local Addressing), najít počítač s příslušným jménem (Multicast DNS) a vy­ hledat dostupné služby (DNS-SD).

3.1.1 IPv4 Link-Local Addresing Tato metoda pro přidělování 32-bitových adres, specifikovaná dokumentem RFC 3927, byla poprvé podporována operačními systémy Windows 98 a Mac OS 8.5. Není vhodná pro ad­ resování zařízení, které nejsou přímo propojené na stejném fyzickém nebo logickém spoji. Pro­ to je možné ji použít v bezdrátových LAN sítích, nebo v LAN sítích typu Ethernet a Token- Ring. V síti s IPv4 Link Local by neměla být povolena manuální konfigurace nebo nastavování pomocí DHCP serveru, protože při připojení nového zařízení do takovéto sítě nemůže být zaručeno správné fungování takto nakonfigurovaných zařízení. IPv4 Link-Local zprostředkovává přidělení IP adres v rozsahu 169.254/16, kromě prvních 256 a posledních 255 adres rezervovaných pro budoucí použití. V síti s technologií Zeroconf si zařízení nabízející službu náhodně vybere adresu z již výše zmíněného rozsahu a zjistí, zda tato adresa už nebyla přidělena jinému zařízení. Toto se provádí pomocí ARP do­ tazování, kdy je do sítě poslán broadcast paket, který obsahuje MAC14 adresu odesílatele a cí­ lovou adresu, která je totožná s vybranou IP adresou. Pokud do dvou sekund žádné zařízení ne­ odpoví, že adresa je již využita, dotazující počítač si ji ponechá. V opačném případě si znovu vybere náhodně další a celý proces zopakuje, viz obrázek 3.1.1. Pakety odcházející z adresy zís­ kané metodou IPv4 Link-Local Addressing mají nastavený TTL15 na hodnotu jedna. To zaru­ čuje, že daný vyslaný datagram nebude poslán do jiné sítě.

Obrázek 3.1.1 automatické přidělování IPv4 LL adresy Může však nastat situace, kdy je potřeba poslat paket počítači, nacházejícímu se v jiné podsíti. Pokud má cílové zařízení vlastní směrovatelnou adresu, je paket normálně poslán. Problém nastane, pokud má daný hostitelský počítač Link-Local adresu. Adresa získaná touto

14 Medium Access Control 15 Time To Live

-13- metodou však není směrovatelná, proto se v tomto případě nastaví hodnota TTL na 255 a pošle se do dané podsítě. Toto řešení se používá pro unicast i multicast pakety.

3.1.2 Multicast DNS Multicast DNS, neboli zkráceně mDNS, je jedna z hlavních vlastností Zeroconf. Využí­ vá IP multicast k nalezení jména nebo adresy a k přidělení jména zařízení v lokální síti bez DNS serveru. Při vyhledávání jsou poslány pakety s dotazem na adresu rezervovanou pro mDNS. Její hodnota je 224.0.0.251. Jména počítačů obsahují koncovou doménu „local“. Jedná se o tzv. pseudo-doménu, která vytváří lokální síť s počítači vyhledatelnými mDNS. Díky ní nevznikají konflikty při roz­ hodování, protože odlišuje, zda se jedná o globalní unikátní jmenné adresy, nebo zda jde o ad­ resy v již zmíněné doméně. Jména v „local“ doménách mohou být totožná, ale nesmí se na­ cházet ve stejné lokální síti. Multicast DNS byl poprvé uveden v operačním systému Mac OS X 10.2 v roce 2002. Je využíván např. aplikací iChat. Společnost Microsoft uvažuje, že mDNS může být obsažen v některém z budoucích opravných balíčků, určených pro Windows XP.

3.1.3 Service discovery Zeroconf k zajištění této funkcionality využívá metodu pro nalezení služeb, založenou na DNS, známou jako DNS-SD. Ta zajišťuje dotazy na dané typy služeb v určitých logických doménách a schopnost získat seznam s hledanými službami, schopnost rozlišit jmennou instanci služby, kterou klient použije, a jejich persistentnost. Aby však nalezení služby bylo úspěšné, musí být zařízení s danou službou ve stavu „running“, neboli běžící. Toho se dosahuje zave­ dením tzv. smyčky, viz. příklad 3.1.3. ... int main() { AvahiClient *client = NULL; int error = 0;

simple_poll = avahi_simple_poll_new(); if(!simple_poll) { fprintf(stderr, "Failed during creating of simple poll " "object.\n"); avahi_simple_poll_free(simple_poll); avahi_free(name); } name = avahi_strdup("MyService"); client = avahi_client_new(avahi_simple_poll_get(simple_poll), 0,client_callback, NULL, &error); avahi_simple_poll_loop(simple_poll); avahi_free(name); return 0; }

Příklad 3.1.3: implementace Avahi – vytvoření a spuštění smyčky (loop)

-14- 3.1.3.1 DNS-SD Tento protokol, oficiálně pojmenovaný DNS Based Service Discovery, byl poprvé implementován už na konci devadesátých let. Do povědomí odborné veřejnosti se však dostal až po té, co byl na jaře roku 2002 představen na prezentaci při otevírání každoroční celosvětové konference vývojářů, pořádané firmou Apple. A už na podzim téhož roku byl uveden jako sou­ část protokolu Zeroconf v operačním systému Mac OS X 10.2 Jaguar. DNS-SD našel využití hlavně v aplikacích iChat, Safari a k nastavení tiskáren. Záhy se stal populární, hlavně mezi vý­ robci tiskáren. V dnešní době ho podporují nejen nové verze Mac OS X, ale i operační systémy Windows, Linux, Solaris, FreeBSD a další. DNS-SD nespecifikuje nový protokol pro vyhledávání služeb, ale popisuje využití stávající DNS služby pro tuto činnost. Pro získání jména služby jsou použity DNS PTR záznamy, které klient obdrží po zaslání požadavku. Z těch se vytvoří seznam jmen dostupných služeb ve tvaru instance.služba.doména. Z něho si pak klient může vybrat vyhovující službu. Informace o službě a zařízení jsou ke klientovi přenášeny v DNS záznamech typu SRV a TXT. SRV záznam, specifikován v dokumentu RFC 2782, je použit hlavně pro přenos infor­ mace, určující jméno zařízení, na kterém služba běží, a umístění služby v síti, jako je číslo portu a IP adresa. Kromě toho však v sobě může mít uloženo jméno služby, její životnost, protokol, na kterém služba pracuje (UDP nebo TCP) atd. TXT záznamy umožňují vložit do DNS zprávy další detaily o existující službě, viz příklad 3.1.3.1. To je výhodné zejména v situaci, kdy klient obdrží více instancí určité služ­ by. V tomto případě se klient díky TXT záznamů nemusí každé instance ještě dotazovat na další informace. Tyto záznamy jsou přenášeny ve formátu jméno=hodnota, kde jméno musí obsahovat alespoň jeden znak. V opačném případě bude takováto zpráva ignorována.

type=paper printer\papersize=A4\resolution=1024x728

Příklad 3.1.3.1 TXT záznamu, určující typ tiskárny, velikost papíru a rozlišení tisku Pro zajištění bezpečnosti je využito rozšíření DNS protokolu, známé jako DNSSEC16. Ten nabízí podporu pro kryptograficky podepsané zprávy. I když DNS-SD používá i multicast DNS zprávy, je na tomto protokolu nezávislý, protože byl původně navrhnut pro posílání uni­ cast paketů. Použití DNS a multicastu v Zeroconf dokazuje, že pokud jsou tyto dvě techniky použity spolu, jejich efektivita vzroste.

3.2 Implementace

3.2.1 Bonjour Bonjour, dříve Rendezvous, je první implementace Zeroconf, dodaná s operačním sys­ témem Mac OS X 10.2 v srpnu 2002 firmou Apple Computer. Ta se však dostala do sporu se společností Tibco Software Inc., která už v roce 1994 vydala vlastní produkt s podobným názvem – Tibco Rendezvous. Po několikaletém jednání bylo dosaženo dohody a 12. dubna 2005 byl Rendezvous přejmenován na Bonjour. Tato implementace nad protokolem TCP a UDP, komunikující přes port 5353, byla ur­ čena primárně pro práci v malých sítích. Ale později byla tato působnost rozšířena i na fungo­

16 Domain Name System Security Extensions

-15- vání ve velkých oblastech, díky funkci zvané Dynamic DNS Update, která byla dodána s verzí Bonjour obsaženou v operačním systému Mac OS X 10.4, umožňující uchovávání záznamů na DNS serverech. Tato funkcionalita je popsána dokumentem RFC 2316. Hlavními přednostmi Bonjour je však přidělování IP adres v síti bez DHCP serveru prostřednictvím funkce IPv4 Link-Local Addressing, překlad jmenných adres bez DNS serveru, díky Multicast DNS, a možnost registrovat, zveřejnit a nalézt službu v lokální síti. Tuto poslední funkcionalitu zajišťuje DNS-SD vykonávanou prostřednictvím mDNSResponder.

3.2.1.1 mDNSResponder MDNSResponder je Bonjour systémová služba, která implementuje Multicast nebo Unicast DNS service discovery, podle toho zda se jedná o lokální nebo globální použití. Opro­ ti SLP má typickou strukturu klient-server. Kde klient představuje entitu vyhledávající službu a server zastupuje nabízející se službu.

3.2.1.2 Zabezpečení Bonjour poskytuje prevenci před Denial of Service útokem. Ta spočívá v nastavení omezení datového toku a v zálohovacím mechanismu. Protože Bonjour byl navrhnut jako tech­ nologie s vysokou prioritou zabezpečení, spoléhá kromě svých funkcí i na bezpečnostní me­ chanismy, jako jsou autentizace klienta a serveru nebo zabezpečení operací před odposlechnu­ tím. Ty jsou poskytovány standardními protokoly, např. IPP17, SMB18 nebo HTTP19, přes které pak po objevení služby probíhá další komunikace.

3.2.1.3 Využití Bonjour byl původně navrhnut pro nalezení a práci se zařízeními jako jsou tiskárny. Kromě toho je také využíván aplikacemi iTunes, iPhoto nebo Safari pro sdílení souborů, nale­ zení rozhraní webových kamer a příslušných webových stránek v LAN síti. Tato implementace Zeroconf je dostupná v jazycích Java a C pro operační systémy BSD, Mac OS X, Linux a od roku 2006 také pro Windows XP a Windows 2000/2003 ve verzi Bonjour for Windows 1.0.3. Ta slouží primárně k nalezení a využití USB tiskáren. V současné době existuje plug-in pro Internet Explorer, po jehož instalaci je možné vyhledávat i webové servery. Zdrojové kódy Bonjour jsou open source a lze je stáhnout na internetové adrese htttp://developer.apple.com/networking/bonjour/download.

3.2.2 Howl Howl, vytvořen v roce 2003, byl jedním z prvních otevřených implementací techno­ logie Zeroconf, umožňující nastavit počítači IP adresu a provádět service discovery. Tuto implementaci bylo možno používat na operačních systémech Unix a Windows. Jeho vývoj byl však společností Porchdog Software v roce 2006 ukončen.

17 Internet Printing Protocol 18 Server Message Block 19 Hyper Text Transfer Protocol

-16- 3.2.3 Avahi Avahi je alternativa k Bonjour, implementaci Zeroconf. Tento produkt, který byl vyvi­ nut programátory Lennartem Poetteringem a Trentem Lloydem, vznikl sloučením mDNS/DNS- SD implementace FlexMDNS a původního programu Avahi v roce 2005 jako odpověď na spory ohledně názvu Bonjour mezi společnostmi Apple Computer a Tibco Software Inc. Stejně jako u Bonjour, se Avahi využívá pro nalezení a použití tiskáren nebo sdílení souborů. Tato nej­ mladší implementace Zeroconf se stala velmi rozšířenou v linuxových a BSD distribucích a je dostupná v C, C++, C# a Python.

-17- Kapitola 4 Universal Plug and Play

4.1 Popis Universal Plug and Play, známý pod zkratkou UPnP, byl zveřejněn v roce 1999 jako technologie pro automatické nastavení jakéhokoliv typu zařízení v síti, jejich vyhledávání a vy­ užívání přes existující standardy, jako jsou IP20, UDP, TCP, XML21 nebo HTTP. UPnP sdílí i některé vlastnosti technologie Zeroconf. Jedná se především o automatické přidělování IP adres, u UPnP známé jako Auto IP. Tato technika se využívá pouze tehdy, když v lokální síti není přítomen DHCP server. Dalším společným rysem je realizace service discovery. Oproti Zeroconf jsou však po­ užity odlišné protokoly a klient vyhledávající službu se označuje jako kontrolní bod.

4.2 UPnP service discovery

4.2.1 Nalezení zařízení - SSDP Protokol pro objevení služby je založen na protokolu SSDP22. Ten obsahuje me­ chanismy umožňující využít síť pro vyhledání určitého zařízení, zveřejnění jeho nové služby a přenos informací mezi ním kontrolním bodem. SSDP pracuje na portu 1900 a využívá pro uskutečnění výše zmíněných operací XML a UDP unicast pakety, nebo multicast datagramy na adrese 239.255.255.250. Aby nebyla přenosová trasa nebezpečně zatěžována, obsahuje SSDP algoritmus, zajiš­ ťující jeho automatické vypnutí. Ten obsahuje vzorec pro zjištění použité šířky pásma protoko­ lem SSDP. Při jeho výpočtu je brán v úvahu počet všech klientů, provádějící SSDP požadavek, počet všech služeb, odpovídající na tyto požadavky, průměrnou velikost SSDP požadavku nebo odpovědi, časový úsek mezi jednotlivými požadavky a konstanty, určující počet opakování požadavků a počet odpovědí. Výsledek je brán jako nejhorší případ využití šířky pásma pro­ tokolem SSDP, a pokud je tato hodnota překročena, je spuštěno automatické vypnutí SSDP.

4.2.2 Popis nalezené entity Po úspěšném nalezení si kontrolní bod vyžádá podrobné informace o daném zařízení, které jsou zahrnuty v XML dokumentech. Tyto dokumenty mohou obsahovat popis zařízení nebo služby provozované na tomto zařízení. Např. sériové číslo, jméno modelu, typ a iden­ tifikátor služby nebo data potřebná k realizaci dalších fází UPnP service discovery – ke kont­ role daného zařízení, oznámení jeho stavu a jeho prezentace, viz. příklad 4.2.2. ... urn:schemas-upnp-org:service:generalcontrol:1

20 Internet Protocol 21 eXtensible Markup Language 22 Simple Service Discovery Protocol

-18- urn:upnp-org:serviceId:generalcontrol1 /upnp/control/generalcontrol1 /upnp/event/generalcontrol1 NULL ...

Příklad 4.2.2: popis služby v XML dokumentu

4.2.3 Kontrola zařízení Oproti ostatním protokolům umožňuje UPnP kontrolu zařízení pomocí XML dokumen­ tů, které jsou přenášeny nad protokolem HTTP a síťovou vrstvou UDP, a které k tomuto účelu využívají SOAP.23 Ten umožňuje kontrolnímu bodu provádět akce ,jako vypnutí zařízení, změ­ na nastavených hodnot služby, které jsou popsány ve stáhnutém XML dokumentu.

4.2.3.1 SOAP SOAP byl vytvořen v roce 1998 s podporou Microsoftu. Tento protokol využívá nejen protokoly HTTP a UDP pro přenos zpráv, vytvořených v jazyku XML, který byl zvolen pro svou přenositelnost a rozšíření, ale také umožňuje využít protokol HTTPS pro ověření iden­ tity komunikujících stran. Předávání nejčastěji probíhá jako Remote Procedure Call, což je rozhraní, ve kterém program pošle zprávu jinému programu na vzdáleném počítači. Na něm je zpráva zpracována a výsledek poslán zpět do programu iniciující tuto akci. Tento mechanismus umožňuje klientovi ovládat službu na vzdáleném zařízení. Nevýhodou protokolu SOAP je délka XML zpráv, která může zpomalit zpracování zprávy. Kromě toho hodně jeho implementací nastavuje limit pro množství poslaných dat. I přes tyto nevýhody se protokol SOAP jeví jako jedno z vhodných řešeních pro práci s objekty.

4.2.4 Oznamování událostí a prezentace služby Další částí UPnP service discovery je zachycení a reakce na události, které jsou popsá­ ny v dokumentech společně se seznamem proměnných dané služby. Tyto specifikující soubory jsou staženy na začátku interakce mezi kontrolním bodem a zařízením provozujícím službu. Zprávy s událostmi ve tvaru XML, které jsou přenášeny mezi oběma účastníky relace, jsou formátovány architekturou GENA24, což je architektura, popsána v dokumentu na adrese http://www.upnp.org/download/draft-cohen-gena-client-01.txt a využívající protokol HTTP pro přenos oznámení o změně stavu daného zařízení. UPnP také umožňuje ulehčit uživateli služby její ovládání. Pokud v popisu dané služby je obsaženo i URL pro prezentaci, je stránka na této adrese zobrazena ve webovém prohlížeči a uživatel může začít přes grafické rozhraní pohodlně ovládat dané zařízení.

4.3 NAT NAT, neboli Network Address Translation, je IETF standard, který umožňuje více po­

23 Simple Object Access Protocol 24 General Event Notification Architecture

-19- čítačům připojit se na Internet přes jedinou veřejnou IP adresu. Tu vlastní vybraný počítač (brá­ na), který ostatním zařízením přiřazuje soukromé adresy a směruje jejich pakety do okolní sítě. Zároveň si o odchozím datagramu vytváří záznam, podle kterého nalezne počítač určený pro obdržení odpovědi. Tato technika může zvýšit bezpečnost uživatele, protože soukromé adresy jsou viditelné pouze ve své lokální síti a navenek vystupují s jednotnou veřejnou IP adresou. Okolnímu světu tak zůstává skryt i počet počítačů v dané síti. Avšak ochrana není příliš silná, a proto se doporu­ čuje používat s technologií NAT firewall. Nevýhodou je však porušení transparentnosti a propojení end-to-end, vlastnosti Interne­ tu, která umožňuje všem uzlům v počítačové síti posílat pakety od počátečního uživatele ke koncovému bez zařízení, které by tyto pakety dodatečně pozměnilo. To přináší problémy zej­ ména u bezstavových protokolů používající UDP nebo u služeb vyžadujících pro své spuštění TCP spojení z vnější sítě. Kromě toho také jediná veřejná IP adresa, která zastupuje skupinu počítačů, znemožňuje hrát více lidem v takovéto lokální síti on-line hry.

4.3.1 Internet Gateway Device Internet Gateway Device, zkráceně IGD, je UPnP technologie, která poskytuje adre­ sovaní v lokální síti a umožňuje směrování služeb z LAN sítí do Internetu. Také řeší některá omezení technologie NAT díky sadě standardizovaných specifikací IGD Device Control Proto­ col. Poslední verze 1.0 se zaměřuje zejména na nastavitelné spuštění a sdílení přístupu k datům na Internetu přes síťová zařízení z domácí sítě, poskytnutí bohatších služeb pro UPnP zařízení (kontrola stavu spojení), správu hostitelských konfiguračních služeb (DHCP) a umožnění za­ řízením nepodporovaných UPnP zakládat a sdílet přístup na Internet. Kromě toho také umí dovědět se o externích IP adresách, spravovat mapování portů a umožnit aplikacím automaticky si nastavit NAT směrování.

4.5 Bezpečnost UPnP

4.5.1 Ověřování nalezeného zařízení UPnP zajišťuje bezpečnost ve dvou oblastech. První z nich je fáze objevení zařízení s danou službou, viz. obrázek 4.5.1, protože samotné vyhledávání přes protokol SSDP je ne­ zabezpečené. Využívá se při tom asymetrická kryptografie a SC25, což je komponenta, která slouží k ověřování zařízení, a která spolu s kontrolním bodem vlastní soukromý klíč. Cílem ověřování je zjistit, zda je SC sdruženo s daným zařízením a naopak. Klient ob­ jeví zabezpečené zařízení a vyžádá si od něj SecurityID, což je haš veřejného klíče. Mezitím SC obdrží od zařízení jeho veřejný klíč, ze kterého vypočítá SecurityID daného zařízení. To pošle klientovi za účelem porovnání s již dříve získaným SecurityID. Pokud si identifikátory odpoví­ dají, vybere si klient dané zařízení ze seznamu všech dostupných zařízení a pojmenuje ho. Ten­ to postup analogicky platí i pro případ, kdy uživatel hledá další kontrolní bod. Pokud by klient chtěl převzít vlastnictví už ověřeného zařízení, zažádá dané zařízení o heslo a poskytne ho SC, které si z něho vypočítá hodnotu. Tu spolu s dalšími získanými hodnotami od zařízení využije k získání argumentů potřebných k realizaci volání funkce pro získání požadovaného vlastnictví.

25 Security Console

-20- Obrázek 4.5.1: nalezení, ověření a převzetí vlastnictví zabezpečeného zařízení

4.5.2 Zabezpečení kontrolního protokolu UPnP se také stará o zajištění bezpečnosti SOAP kontrolních zpráv pro vykonání určité akce a jejich odpovědí. Pro toto používá vlastní bezpečnostní model. V něm se nejprve ověřuje, zda má příchozí zpráva ve své SOAP hlavičce položku Secu­ rityInfo. Pokud ano, je potvrzena jako podepsaná. V opačném případě je vlastník označen jako neznámý a zpráva je poslána rovnou k ověření autorizace. U podepsané zprávy se dále ověřuje podpis, u kterého se ověřuje její integrita a pravost, a jeho stáří. Při tomto procesu se využívá SecurityID. To jednoznačně určuje odesílatele. Pokud vše proběhne v pořádku, je odesílatel označen za vlastníka této zprávy. Jinak proces schválení selže a vygeneruje se chybové hlášení. V dalším kroku se testuje autorizace podepsaných i nepodepsaných zpráv. K tomu se nejdříve získají ACL26, seznam vlastníka a certifikáty, které jsou buď lokálně uskladněné, nebo obsažené v položce KeyInfo kontrolované zprávy. Pokud nebude autorizace úspěšná, opět se vy­ generuje chybové hlášení. Jestliže je oprávnění ověřeno, může se vykonat požadovaná operace. Při žádosti o vykonání speciální akce DAE27 jsou zašifrované parametry zprávy rozluštěny a re­ kurzivně poslány zpět odesílateli za účelem vytvoření procesu pro provedení dané činnosti.

4.6 Využití a implementace UPnP lze využít v mnoha oblastech. Například architektura UPnP AV (Audio Video) , na kterou spolu s ostatními UPnP standardy dohlíží organizace DLNA28, se skládá z mnoha komponent, které umožňují sdílet a stahovat různá data, hlavně data multimediální. K tomu se můžou využít známé programy, jako jsou VideoLan Network Client nebo WinAmp. Kromě toho je také možné vzdáleně ovládat nástroje pro přehrávání videa a hudby, pořádat

26 Access Control List 27 DecryptAndExecute 28 Digital Living Network Allience

-21- videokonference a využívat služby standardních zařízení, např. tiskáren. Protože je UPnP nezávislý na použitých zařízeních, může být naimplementován pomocí jakéhokoliv jazyka a na jakémkoliv operačním systému. UPnP vyskytuje hlavně na systémech Microsoft Windows, Mac OS X, BSD, Unix a Linux. UPnP SDK je linuxová implementace společnosti Intel, která byla poprvé vydána v roce 2000. Nabízí vývojové prostředí a open source zdrojové kódy pro tvorbu kontrolních bodů a zařízení. V současné době je SDK ve verzi 1.3.1 a lze ji nalézt na internetové adrese http://sourceforge.net/projects/upnp. V nedávné době se v počítačovém světě objevila konkurence UPnP, řešící některé jeho problémy – DPWS.29 Ten byl vydán na trh jako součást operačního systému Microsoft Windows Vista.

29 Devices Profile for Web Services

-22- Kapitola 5 Dalších protokoly

5.1 RARP Automatického nastavení síťového připojení se dalo dosáhnout i pomocí protokolu Reverse Address Resolution Protocol, zveřejněného v roce 1984 v dokumentu RFC 903. Ten obsahuje metody, které se starají o překlad MAC adresy na IP adresu. Nastavení probíhalo velice jednoduchým způsobem. Počítač poslal prostřednictvím RARP dotaz, obsahující MAC adresu, neboli adresu NIC30 síťové karty. Tato zpráva byla poslá­ na jako broadcast. V dané síti ji přijal RARP server, který podle svých tabulek rozhodl, zda dané MAC adrese odpovídá určitá IP adresa. Pokud ano, pošle ji žádajícímu počítači v RARP odpovědi. Díky této jednoduchosti se však RARP potýká se dvěma omezeními. Prvním z nich je skutečnost, že dotaz je posílám na fyzickou adresu, a proto se nedostane za hranice fyzické sítě. Z tohoto důvodu musí být pro každou fyzickou síť přítomen vždy jeden RARP server. Druhé omezení je spojeno s konfigurací zařízení, protože je nastavována pouze IP ad­ resa. Ta však není dostačující pro provoz dané stanice v síti. Počítač totiž potřebuje k plnému on-line provozu i další informace, jako je adresa výchozí brány, dns serveru atd. Z těchto důvodů se už RARP prakticky k automatickému nastavení nepoužívá a jeho roli převzaly novější protokoly, například DHCP.

5.2 DHCP Tento protokol je v dnešní době používán ve většině spravovaných sítích. Oproti svému předchůdci, protokolu RARP, nepřiděluje dynamicky danému počítači jen IP adresu, ale také masku sítě, bránu sítě a IP adresy DNS serverů. Protokol DHCP byl poprvé zveřejněn ve specifikaci RFC 1541 v roce 1993. Je založen na protokolu BOOTP31, který automaticky počítačům přiřazoval statickou IP adresu. Toto se však hodilo pouze pro relativně neměnné sítě. Postupem času s příchodem Laptopů a jiných přenosných zařízení se frekvence jejich připojení do různých sítí začala zvětšovat, a proto se jako výhodnější řešení pro správu sítě jevil přechod na protokol DHCP. Ten kromě dynamické­ ho přidělování IP adres také podporuje její manuální alokaci zprostředkovanou administrátorem dané sítě a automatické přidělování. To se liší od dynamického tím, že adresa je zařízení přidě­ lena nastálo. Výhodou DHCP protokolu je centrální, a tedy i jednodušší správa sítě a možnost přečíslovat danou síť s minimálním zásahem do běžného provozu. Přidělení informací, nezbytných pro fungování zařízení v síti, se děje podobným způso­ bem, jako u protokolu BOOTP. Daný počítač, vystupující jako klient, pošle přes UDP port 68 DHCP žádost o přidělení IP adresy. DHCP server, poslouchající na UDP portu 67, tuto zprávu zachytí a pošle DHCP paket s nabídkou IP adres. Klient si jednu z nich vybere a požádá o ni DHCP server. Ten mu pošle DHCPPACK zprávu, která kromě dočasně přidělené IP adresy ob­ sahuje i další nezbytné, výše uvedené informace. Když se začne platnost adresy chýlit ke konci, musí počítač požádat DHCP server o novou konfiguraci. V 90% případů dostane zařízení stejné

30 Network Interface Controller 31 Bootstrap Protocol

-23- nastavení. Protokol řeší i situace, kdy dvě nebo více síti jsou spojeny routerem, ale pouze v jedné z nich se nachází DHCP server. Pokud takovýto stav nastane, je na směrovačích zapnuta sou­ část protokolu DHCP, tzv. relay agent. Ten zajistí, že všechny DHCP dotazy, přicházející ze sítě bez DHCP serveru přesměruje do sítě, která ho obsahuje. Agent k těmto zprávám připo­ juje masku sítě, ze které byly poslány. Díky tomu nedochází ke kolizím IP adres. Kromě této funkce nabízí DHCP protokol i další funkce. V Unix systémech je možné nakonfigurováním DHCP serveru vyhledat služby, dostupné v lokální síti, jako jsou např. ča­ sové, jmenné nebo tiskové servery. S protokolem DHCP se počítá i v budoucích sítích. Jeho nová verze, pracující na pro­ tokolu IPv6, která je momentálně ve stádiu vývoje pod názvem DHCPv6, by měla být využita pro konfiguraci stavové adresy, což je technika, kdy server klientovi poskytuje informace pro nastavení. A pro různé metody adresování zařízení, hlavně pro místně spojovou oblast mul­ ticastových adres. I když stejně jako jeho předchůdce bude mít tento protokol komponentu re­ lay agent, neočekává se, že bude ve všech oblastech zpětně kompatibilní s DHCPv4.

5.3 NDP – Neighbor Discovery Protocol Kvůli rostoucímu počtu počítačů připojených do sítě a nedostatku IP adres se na počát­ ku 90.let rozhodlo o vývoji nového 128-bitového Internetového protokolu, dnes známého jako IPv6. Jeho součástí je i Neighbor discovery protokol, který nahrazuje funkce protokolů z IPv4. A to funkce protokolu ARP, ICMP32 Router Discovery a ICMP Redirect. Dovednosti tohoto protokolu, jehož aktuální specifikace RFC 2461 byla vydána v roce 1998, můžou být rozděleny do třech funkčních skupin.

5.3.1 Komunikace mezi hostitelským počítačem a routerem První z nich je skupina obsahující 4 funkce, potřebné pro nalezení směrovače a výměnu informací mezi ním a klientem. Nejdůležitější z nich je metoda Router discovery pro objevení routeru v lokální síti, který pravidelně vysílá multicast Router Advertisement zprávy, ve kterých se vyskytují jeho nabízené parametry a služby. Další možností klienta je schopnost zjistit prefix sítě, ve které se nachází, neboli Prefix discovery. To také zajišťuje pro daný počítač schopnost rozeznat, zda cílové zařízení je vzdá­ lené nebo lokální. A tedy, zda s ním může komunikovat přímo nebo pomocí směrovačů. Kromě prefixu dané sítě se o ní může hostitelský počítač dovědět, jaký je výchozí Hop limit, neboli maximální počet přesměrování paketu, nebo jaká je velikost jednotky MTU33, kte­ rá popisuje velikost limitu pro danou fyzickou síť. Oproti protokolu IPv4, kde tato jednotka měla velikost 576 bytů, je její velikost přibližně dvojnásobná a čítá 1280 bytů. Poslední službou, která je popsána v dokumentu RFC 2462, je automatické nastavení adresy na určitý časový úsek nebo dobu neurčitou. Tento proces, zastupující funkci DHCP, je u IPv6 známý jako konfigurace nestavové adresy, protože si klient všechny potřebné informace nastavuje sám s ohledem na předem získané lokální informace a informace, poskytnuté místním routerem.

32 Internet Control Message Protocol 33 Maximum Transmission Unit

-24- 5.3.2 Komunikace mezi hostitelskými počítači První funkcí, která má za úkol nahradit protokol ARP, je Address resolution. To umožňuje hostitelskému počítači zjistit MAC adresu jiného počítače, pokud zná jeho IP adresu. Počítač požadující adresu síťového zařízení pošle Neighbor Solicitation zprávu na multi­ castovou adresu určenou cílovou IP adresou. Pokud se v lokální síti nachází zařízení s daným určením umístění, pošle toto zařízení Neighbor Advertisement odpověď s požadovanou MAC adresou. Neighbor discovery protokol umožňuje určit další vývoj směrování paketů. Tento pro­ ces předvídání další cesty spočívá ve zjištění nejlepšího shodného prefixu sítě ke zjištění, zda je IP adresa součástí lokální sítě. Pokud ano, je paket odeslán na tuto adresu. V opačném případě je ze seznamu DFR (Default Router List) vybrán nejvhodnější směrovač, kterému bude da­ tagram poslán. Při plánovaném odeslání paketu je nutno zjistit, zda je vybraný uzel dostupný. To větši­ nou zajišťuje vyšší síťová vrstva, například protokol TCP. Pokud ale informace z vyšší vrstvy nejsou k dispozici, použije se funkce Neighbor discovery protokolu pro detekci nedosažitelnosti uzlu. Ta funguje na principu, kdy počítač pošle danému uzlu Neighbor Solicitation požadavek. Pokud uzel neodpoví Neighbor Advertisement paketem, provede počítač tuto proceduru ještě několikrát. Pokud ani poté nedostane žádnou odpověď, vymaže tento uzel z tabulky NC (Neighbor Cache), ve které se uchovávají všechna dostupná zařízení. Tento proces pro zjištění nedostupnosti se však používá pouze v případě, že se posílají unicast pakety. Pokud je do sítě zapojeno nové zařízení, musí se při autokonfiguraci bezstavové adresy zajistit, že zařízení nepoužije už přidělenou IP adresu. Toho se dosáhne funkcí pro detekci du­ plicitních adres, která zajišťuje poslání Neighbor Solicitation paketu na svou vlastní adresu. Když tato zpráva dorazí k uzlu, který už vlastní danou adresu, pošle tento počítač multicast Neighbor Advertisement zprávu určující, že daná adresa je již používána.

5.3.3 Funkce přesměrování paketu Tato skupina zahrnuje pouze jedinou funkci, která nahrazuje službu pro odesílání zpráv ICMP Redirect message v protokolu IPv4. Umožňuje vybrat pro paket výhodnější cestu k cíli. Pokud posílá host datagramy do jiné sítě, může router, přes kterého přenos probíhá, zjistit lepší cestu k danému cíli. V tom případě pošle hostitelskému počítači unicast ICMPv6 Redirect zprávu o nalezení výhodnější cesty. Host zprávu odposlechne a zbytek zpráv začne směrovat na tuto novou trasu. Pro zmenšení zatížení linky je také možné, aby v dané ICMPv6 Redirect zprávě byla MAC adresa routeru, přes který bude nová komunikace probíhat.

5.3.4 Secure Neighbor Discovery Neighbor Discovery protokol čelí hlavně dvěma typům útoků – DoS a zneužití funkce pro přesměrování paketů, kdy se útočník vydává za směrovací zařízení za účelem zahlcení za­ řízení, a tedy provedení DoS útoku, nebo pro zachycení paketu. Proto byl stávající protokol rozšířen specifikací RFC 3971 na protokol Secure Neighbor Discovery. V něm jsou použity dvě kryptografické metody, CGA34 a ABK35.

34 Cryptographically Generated Addresses 35 Address Based Key

-25- Metoda CGA je založena na principu vytvoření heše z posledních 64 bitů IPv6 adresy. Ten je pak poslán příjemci zprávy, který heš přepočítá a porovná ho s identifikátorem rozhraní, patřící odesílateli. Pro zvýšení bezpečnosti je také možné vztáhnout heš na danou síť. A to buď zahrnutím MAC adresy, nebo prefixu dané sítě do hešovací funkce. Tato metoda autorizace se používá hlavně pro podepsání zpráv posílaných při přesměrování paketu, upozornění na dupli­ citní adresu a při zjištění MAC adresy hostitelského počítače. Oproti ABK zde není potřeba po­ užití důvěrné třetí strany. Druhou možností je použít techniku ABK. Ta umožňuje libovolnému veřejně známému identifikátoru, například e-mailové adrese nebo IP adrese uzlu, stát se veřejným klíčem v komu­ nikaci mezi dvěma počítači. Odesílatel pošle veřejný klíč důvěrné třetí straně, známé jako IPKG36. Ta pomocí specifického algoritmu vytvoří soukromý klíč a pošle ho zpět zabezpe­ čeným kanálem. Tento proces umožní při interakci použít asymetrickou kryptografii. ABK se používá zejména pro ověření identity zpráv při vyhledávání směrovačů.

36 Identity based Private Key Generator

-26- Kapitola 6 Závěr Tato práce poskytuje přehled o nejznámějších standardních technologiích provádějící automatickou konfiguraci sítě klienta a service discovery. Zaměřuje se na starší, současné i bu­ doucí protokoly a techniky, vykonávající výše zmíněnou funkcionalitu. Přibližuje jejich struktu­ ru, bezpečnostní politiku a využití v lokálních sítích. V budoucnu se předpokládá nárůst významu technologií provádějící service discovery. A to díky očekávanému nástupu Mobile Commerce, známou také jako M-Commerce nebo U- Commerce. Což je schopnost provádět obchodní operace přes mobilní zařízení, jako jsou mo­ bilní telefony, PDA počítače atd., zatímco je uživatel v pohybu. V této oblasti technologie service discovery najdou využití zejména kvůli potřebě připojit se kdykoliv a kdekoliv do sítě a zpřístupnit požadovaná data. Další motivací pro budoucí použití je plánovaný nástup sítí s protokolem IPv6, zejména použití plánované metody automatické konfigurace bezstavové adresy. Tato funkce je jedno­ dušší pro použití i správu než nastavení přes DHCP server.

-27- Literatura [1] Service Location Protocol. c2007 URL:

[2] PERKINS, CHARLES: Slp white paper topic. c1997 URL:

[3] GUTTMAN, E., PERKINS, CH., VEIZADES, J., DAY, M.: RFC 2608 – Service Location Protocol, Version 2. c1999 URL:

[4] GUTTMAN, E., PERKINS, CH., KEMPF, J.: RFC 2609 – Service Templates and Service: Schemes. c1999 URL:

[5] CALDERA SYSTEMS, INC., NOVELL, INC.: OpenSLP. c2005 URL:

[6] APPLE COMPUTER, INC.: Bonjour printing specification. c2005 URL:

[7] APPLE COMPUTER, INC.: Bonjour. c2007 URL:

[8] APPLE COMPUTER, INC.: Bonjour Overview. c2006 URL:

[9] CHESHIRE, S., KROCHMAL, M.: Multicast DNS. c2006 URL:

[10] CHESHIRE, S., KROCHMAL, M.: DNS-Based Service Discovery. c2006 URL:

-28- [11] CHESHIRE, S., ABOBA, B., GUTTMAN, E.: RFC 3927 - Dynamic Configuration of IPv4 Link-Local Addresses. c2005 URL: [12] APPLE COMPUTER, INC.: Bonjour. c2005 URL:

[13] APPLE COMPUTER, INC.:Mac OS X: About Multicast DNS. c2005 URL:

[14] CHESHIRE, S., KROCHMAL, M., SEKAR, K.: NAT Port Mapping Protocol (NAT- PMP). c2006 URL:

[15] THE AVAHI TEAM: Avahi. c2005-2007 URL:

[16] Avahi (Software). c2007 URL:

[17] PORCHDOG SOFTWARE, INC.: Howl is dead. Long live Howl. c2003-2006 URL:

[18] GUTTMAN, ERIK: Autoconfiguration for IP networking. c2001 URL:

[19] WELCH, JOHN C.: Zeroconf. c1984-2007 URL:

[20] Kolic, R., Iyer, P.: The Advantages of the UPnP* Internet Gateway Device. c2002 URL:

-29- [21] ELLISON, CARL: UPnP Security Ceremonies Design Document. c2003 URL:

[22] Universal Plug and Play. c2007 URL:

[23] SOAP. c2007 URL:

[24] GOLAND, YARON. Y., CAI, T., LEACH, P., GU,Y.: Simple Service Discovery Protocol/1.0. c1999 URL:

[25] INTEL CORPORATION: Intel Authoring Tools for UPnP Technologies. c2003 URL:

[26] FINLAYSON, MANN, MOGUL, THEIMER: RFC 903 - A Reverse Address Resolution Protocol. c1984 URL:

[27] DROMS, R.: RFC 2131 - Dynamic Host Configuration Protocol. c1997 URL:

[28] HUNT, CRAIG: The dhcpd.conf Configuration File. c1999 URL:

[29] NARTEN, T., NORDMARK, E., SIMPSON, W.: RFC 2461 - Neighbor Discovery for IP Version 6 (IPv6). c1998 URL:

[30] KOZIEROK, CHARLES M.: IPv6 ND Overview, History, Motivation and Standards. c2001-2005

-30- URL:

[31] KOZIEROK, CHARLES M.: IPv6 ND General Operational Overview: ND Functions, Functional Groups and Message Types. c2001-2005 URL:

[32] KOZIEROK, CHARLES M.: IPv6 Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly. c2001-2005 URL:

[33] ED, J. ARKKO, KEMPF, J., ZILL, B., NIKANDER, P.: RFC 3971 - SEcure Neighbor Discovery (SEND). c2005 URL:

-31-