1. JOHDANTO Tänä päivänä Internet yhdistää suuren osan maapallon ihmisistä. Sen suosio ja käyttäjämäärät ovat lisääntyneet räjähdysmäisesti viimeisten vuosien aikana. Käyttäjämäärän kasvu taas tuo mukanaan uusia ongelmia, joista suurimpana voidaan pitää osoiteavaruuden loppumista. Tällä hetkellä käytössä oleva IPv4-protokolla (Internet Protocol version 4) kykenee tarjoamaan noin 4 miljardia yksittäistä IP-osoitetta. Tuon rajan ylitys tulee tapahtumaan lähitulevaisuudessa. Tästä syystä tämän vuosikymmenen alussa on alettu kehittämään uutta IPprotokollaa, joka on nimeltään IPv6 (Internet Protocol version 6). Uusi protokolla on suunniteltu lähinnä osoiteavaruuden loppumisongelman ratkaisemiseksi, mutta siihen on lisätty myös muita huomattavia parannuksia. Päätelaitteiden suorituskyvyn huima kasvu on asettanut verkolle yhä suurempia suorituskykyvaatimuksia ääntä ja kuvaa käyttävien sovellusten lisääntyessä. Käyttäjien tietoturva on ollut todella olematonta tähän saakka. Uuden IPprotokollan suunnittelussa on pyritty ottamaan huomioon niin reaaliaikaliikenteen vaatimukset kuin käyttäjien tietoturva-asiatkin. Tässä diplomityössä käsitellään uuden protokollan perusominaisuudet ja lisätoiminnot. Tämän työn luvuissa kaksi ja kolme kerrotaan Internetin historiasta aina sen syntymästä tähän päivään saakka. Samoin on kerrottu miten päätös uudesta protokollasta on syntynyt ja mitä eroavaisuuksia siinä on olemassa verrattuna IPv4-protokollaan. Neljännessä luvussa kerrotaan IPv6-protokollasta ja sen lisäkenttien avulla toteutetuista uusista toiminnoista. Luvussa viisi käsitellään tietoturvan lisäämistä salaus- ja tunnistusmekanismien avulla. Kuudes luku esittelee IPv6-protokollan tarjoaman tuen reaaliaikaliikenteelle. Seitsemännessä luvussa käydään läpi muutoksia, joita aiheutuu IPv6-protokollaa käyttäville protokollille. Kahdeksas luku antaa perusteellisen selvityksen uusista 128-bittisitä osoitteista ja niiden käytöstä. Luku yhdeksän kertoo osoitteiden asentamismenetelmistä päätelaitteisiin. Luku kymmenen esittelee keinoja, joiden avulla uuden protokollan käyttämiseen voidaan siirtyä joustavasti ja asteittain. Luvussa yksitoista kerrotaan yksinkertaisesta IPv6-testiverkosta, sen laitteista ja niiden toimivuudesta. -1-
2. INTERNETIN HISTORIAA 2.1 Internetin alkuperä Ensimmäinen tallennettu muistio ihmisten sosiaalisesta kommunikoinnista verkon välityksellä löytyy vuodelta 1962. Tuon muistion oli kirjoittanut J.C.R.Licklider ja se esitteli hänen Galaktisen verkkokonseptinsa. Tuo konsepti vastasi tuolloin melko hyvin nykyistä Internetiä. Vuonna 1962 alkoi tietokoneiden tutkimusohjelma DARPA:ssa (Defense Advanced Research Projects Agency), jonka ensimmäinen johtaja oli Licklider. Tutkimusohjelmassa korostui juuri verkkokonseptin tärkeys.[16] Ensimmäinen dokumentti pakettikytkentäisestä tekniikasta piirikytkentäisen tekniikan rinnalle julkaistiin vuonna 1961 Leonard Kleinrockin toimesta. Useat merkittävät tutkijat tulivat tuolloin vakuuttuneeksi pakettikytkentäisen tekniikan soveltuvuudesta, mitä pidetäänkin yhtenä suurena harppauksena kohti tietoliikenneverkkoja. Pakettikytkentäisyys merkitsi myös enemmän vikasietoisuutta, mikä oli varsin tärkeä ominaisuus sotilaallisille verkkostruktuureille. Vuonna 1966 Lawrence G. Roberts meni mukaan DARPA:an kehittääkseen verkkokonseptia ja pian hän julkaisikin suunnitelmansa, joka tunnettiin nimeltä ARPANET. Samassa julkistustilaisuudessa esiteltiin myös kaksi muuta pakettikytkentäisyyteen perustuvaa verkkoratkaisua. Toisen ehdotuksen teki RAND-ryhmä (Research and Developement) ja siinä työskentelevä Paul Baran ja toisen Donald Davies ja Roger Scantlebury NPL:stä (National Physical Laboratory). Nämä ratkaisut oli siis kehitetty tietämättä toisistaan mitään. Kleinrockin ansiokkaasta kehittämistyöstä pakettikytkentäisen teorian parissa hänen NMC:nsä UCLA:ssa (Network Measurement Center, University of California Los Angeles) valittiin ensimmäisen ARPANET:in solmun paikaksi. Tämä tapahtui vuonna 1969, kun ensimmäiset verkon Honeywell 516-minitietokoneet toimitettiin UCLA:n yliopistoon. Seuraavat tietokoneet sijoitettiin Stanfordin tutkimusinstituuttiin (SRI). Näiden organisaatioiden välillä vaihdettiin siis ensimmäiset ARPANETin päästä-päähän viestit. Vähän myöhemmin kyseiseen verkkoon liittyivät vielä Santa Barbaran ja Utahin yliopistot. -2-
Seuraavien vuosien aikana useita koneita liittyi APRPANETiin, mutta enimmäkseen kuitenkin eri tiedeyhteisöjä. Samalla jatkui myös protokollien kehitystyö. Niinpä vuonna 1970 NWG (Network Working Group) S.Crockerin johdolla sai päästä-päähän protokollan, nimeltä NCP (Network Control Protocol), määrittelyn valmiiksi. Tämän jälkeen verkkoa käyttävien sovellusten toteuttaminen saattoi vasta alkaa.[16][17] Lokakuussa 1972 Bob Kahn järjesti suuren demostraatiotilaisuuden ARPANET:in käytöstä ICCC:lle (International Computer Comunication Conference). Tämä oli ensimmäinen julkinen demo-tilaisuus. Samana vuonna julkaistiin verkon käytön mullistava elektroninen sähköpostiohjelmisto. Sen julkaisijana oli Ray Tomlinson ja sitä kehitti myöhemmin myös Robertson. Sähköposti oli seuraavan vuosikymmenen ajan suosituin verkkoa käyttävä sovellus ja vielä tänäkin päivänä se on hyvin suosittu verkon käyttäjien keskuudessa. Alkuperäinen ARPANET kasvoi Internetiksi. Internet perustui ajatukseen, jonka mukaan verkossa voisi olla kytkeytyneenä useita erilaisia riippumattomia verkkoja. Ajatuksena oli myös, että Internet olisi arkkitehtuuriltaan avoin, josta myös Kahn julkaisi suunnitelmansa vuonna 1972 DARPA:n alaisuudessa ollessaan. Tässä vaiheessa alettiin myös miettiä parannuksia NCP-protokollaan. Puutteellinen osoitteistus, sekä myöskin virhetilanteiden kontrolloinnin puuttuminen vaikuttivat siihen, että Kahn alkoi suunnitella uutta protokollaa, jossa myös arkkitehtuurin avoimuus olisi otettu huomioon. Tätä protokollaa kutsuttiin nimellä TCP/IP (Transmission Control Protocol/Internet Protocol). Oikeastaan ehdotus kulki aluksi nimellä TCP, mutta se jakaantui kahteen eri kerrokseen. Lisäksi määriteltiin myös UDP-protokolla tilanteisiin, joissa ei tarvittu luotettavaa tiedonsiirtoa. Erona vanhaan NCP:hen verrattuna oli, että uusi protokolla toimi enemmän tietoliikenneprotokollan tavoin, kun taas vanha toimi laiteajurin tavoin. TCP/IP-protokolla dokumentoitiin vuonna 1973 ja se julkaistiin konferenssissa, joka pidettiin Sussexin yliopistossa. Sen tekivät Kahn ja Vint Cerf yhdessä. Cerf oli myös ollut NCPprotokollan suunnittelussa voimakkaasti mukana. Seuraavana oli vuorossa TCP/IP-protokollan toteutus, joka tapahtui kolmen organisaation voimalla. Stanford (Cerf), BBN (Ray Tomlinson, Bolt, Beranek and Newman) ja UCLA (Peter Kirstein) vastasivat protokollan toteutuksesta. Tästä alkoi pitkäjänteinen kehitystyö ennenkuin kyseinen protokolla saatiin toimimaan niin päätelaitteissa kuin verkon solmuissakin. TCP/IP-protokollan sovittaminen erilaisiin käyttöjärjestelmiin oli myös oma lukunsa. Tätä jatkui noin kymmenen vuoden ajan, jonka jälkeen tammikuun 1. päivänä 1983 ARPA- NET siirtyi lopullisesti käyttämään TCP/IP-protokollaa NCP-protokollan sijasta. Hieman myöhemmin samana vuonna ARPANET jakaantui kahdeksi eri verkoksi. Toinen verkoista oli nimeltään MILNET, joka oli sotilaalliseen käyttöön tarkoitettu verkko ja toinen oli tiedeyhteisön ARPANET-verkko. Vuonna 1987 NSF (National Sciences Foundation) perusti ARPANET:in rinnalle NFSNET-verkon, jossa tiedonsiirtonopeus oli huomattavasti suurempi. NFSNET perustui myös TCP/IP-protokollan käyttöön. Tästä kolmen vuoden kuluttua eli vuonna 1990 ARPANET-verkon käyttö lopetettiin kokonaan.[16] 2.2 TCP/IP TCP/IP-protokolla on siis oikeastaan protokollaperhe, johon kuuluu useita eri protokollia, mutta tärkeimmät niistä ovat kuitenkin TCP ja IP, joiden mukaan kyseinen protokollaperhe on myös nimetty. Vaikka TCP/IP on noin 20 vuotta vanha, se on edelleen yleisesti käytössä. TCP/IP tarjoaa liityntärajapinnan Internetiin, mikä taas on ollut omiaan lisäämään -3-
kyseisen protokollan suosiota. TCP/IP on avoin protokollaperhe, joka on vapaasti saatavissa, eikä sitä ole myöskään sidottu mihinkään käyttöjärjestelmään. Se tarjoaa maailmanlaajuisen, yksikäsitteisen osoitteistuksen Internetiin liitettäville laitteille. Lisäksi TCP/IPprotokollat eivät ole riippuvaisia käytettävästä siirtomediasta, joten ne voivat toimia lähes minkä tahansa tyyppisessä siirtoverkossa; ATM (Asyncronous Transfer Mode), FDDI (Fiber Distributed Data Interface), Ethernet, Token ring, X.25.[17] TCP/IP-protokollan sijoittuminen OSI-malliin (Open System Interconnect) voidaan nähdä kuvasta 2.1. 7. Sovelluskerros 6. Esitystapakerros Sovellukset 5. Yhteyskerros 4. Kuljetuskerros TCP UDP 3. Verkkokerros 2. Siirtokerros 1. Fyysinen kerros IP Linkkikerros Kuva 2.1: OSI-viitemalli ja TCP/IP-kerrosmalli Kuten edellisestä kuvasta voi huomata, TCP/IP-pino jaetaan neljään kerrokseen verrattuna OSI-viitemalliin. Ylin kerros sisältää sovellukset, jotka käyttävät TCP/IP-protokollaa hyväksi. Linkkikerros taas toimii liityntärajapintana fyysiseen verkkoon. Tässä diplomityössä keskitytään varsinaisesti TCP/IP-pinon IP-kerrokseen, johon on suunnitteilla uusi protokolla. Tosin tässä työssä kerrotaan hieman myös uuden protokollan vaikutuksista lähinnä kuljetuskerroksen protokolliin. IP-kerros vastaa OSI-mallin 3. kerrosta eli verkkokerrosta. Tässä työssä IP-paketilla tarkoitetaan ylemmältä kerrokselta tulevan datan ja IP-kerroksen siihen lisäämien kenttien kokonaisuutta. -4-
3. UUDEN PROTOKOLLAN SYNTYHISTORIA Vuoden 1990 alussa alettiin luoda visioita Internetin tulevaisuudesta. Silloin ennustettiin Internetin yhdistävän lähitulevaisuudessa kaikki maapallon ihmiset. Vuoden 1992 väestönkasvun arvioiden mukaan, maapallolla olisi vuonna 2020 noin 10 miljardia ihmistä. Ja lisäksi kun vielä uskottiin tietokoneita olevan tulevaisuudessa autoissa, kodinkoneissa ja jopa sähkölampuissa, olisi tietokoneita useita, jopa satoja yhtä ihmistä kohden. Tämän vision mukaan tietokoneiden määrä olisi vuonna 2020 tuhat miljardia. Tuolloin myös tiedettiin, että nykyinen IPv4-protokolla, jossa käytetään 32-bittisiä osoitteita, sallii noin 4 miljardia yksittäistä käyttäjää. Tarkempi laskelma osoitti, että 4:n miljardin käyttäjän raja ylittyisi jossain vuoden 2005 ja vuoden 2015 välillä senhetkisen kasvuvauhdin mukaan. Syntyi tarve uuden protokollan luomiseksi, joka tuolloin nimettiin IPng:ksi (Internet Protocol, next generation). Ehdotuksia uudeksi protokollaksi alkoi ilmaantua.[9][10] Vuoteen 1992 mennessä oli korvaavia ehdotuksia esitetty 7 kappaletta. Osa niistä pohjautui IPv4:n käyttöön, osa korvasi sen kokonaan. Vuonna 1992, kun IAB (Internet Architecture Board) kokoontui Kobessa, oli kilpailussa uudeksi protokollaksi jäljellä enää vain kolme ehdotusta. Yksi ehdotuksista, joka pohjautui ISO:n (International Organization for Standarization) määrittelemään CLNP-protokollaan (Connection-Less Network Protocol), tunnettiin nimellä TUBA (TCP and UDP over Bigger Address). Pääosin CLNP erosi IP:stä sen 20-oktettia pitkän NSAP-osoitteen (Network Service Access Point) suhteen. Osoite oli riittävä identifioimaan noin triljoona (miljoona * miljoona) verkkoa. Etuna ehdotuksessa oli, että kyseinen protokolla oli jo valmiiksi määritelty ja implementoitu. Mutta CLNP on vanha ja tehoton protokolla. Se on eräänlainen kopio IP:stä. Tämä ehdotus hylättiin, sillä protokolla yritti olla yhteensopiva alkuperäisen CLNP-protokollan kanssa, joten sen ominaisuudet eivät tukeneet multicast-lähetyksiä, liikkuvuutta sekä resurssien varausta, jotka kuuluivat uuden protokollan ominaisuusvaatimuksiin.[9][10] Vuonna 1992 Robert Ullmanin ehdotus, joka tunnettiin nimellä IP version 7, ilmestyi. Kyseistä ehdotusta kehiteltiin vuosina 1992-1994. Vuonna 1993 sen nimi vaihtui TP/IX:si. -5-
Ehdotuksessa haluttiin muuttaa TCP-protokollaa samanaikaisesti IP:n kanssa. Ajatuksena oli pakettien prosessoinnin nopeuttaminen, kuten myös uuden reititysprotokollan RAP:n käyttö. Ehdotus kuitenkin hylättiin IETF:n (Internet Engineering Task Force) toimesta. Hylätystä ehdotuksesta muodostui uusi ehdotus, nimeltään CATNIP, joka olisi ollut yhteensopiva IP:n ja CLNP:n, kuten myös Novellin IPX:n kanssa. Tämäkin ehdotus hylättiin. Kolmas ehdotus vuonna 1992 oli nimeltään IP in IP. Se ehdotti kahden IP-kerroksen käyttöä. Yksi maailmanlaajuiselle "backbone"-verkolle ja toinen pienemmille alueille. 1993 tästä ehdotuksesta kehittyi uusi ehdotus IPAE (IP Address Encapsulation), jonka periaatetta käytettiin siirtymävaihe-ongelman ratkaisuna SIP:ssä (Simple IP). Steve Deering oli ehdottanut SIP:iä vuonna 1992 IPv4:n seuraajaksi. SIP:ssä ehdotettiin IP-osoitteiden laajentamista 64-bittisiksi. SIP teki pakettien fragmentoinnin valinnaiseksi. Vuonna 1993 SIP ja Paul Francis n ehdotus Pip, liitettiin yhteen, joten syntyi SIPP (Simple IP Plus). Lopulta SIPP valittiin vanhan IP-protokollan jatkajaksi 1994, tosin osoitteet muutettiin 128-bittisiksi. Vuoden kehittelyn jälkeen määriteltiin uusi Internet-protokolla, jonka versionumero oli 6, joten sen nimeksi tuli IPv6. Versionumero 5 oli jo aikaisemmin varattu kokeelliselle "Stream"-protokollalle, joka oli suunniteltu tarjoamaan reaaliaikaista palvelua IP:n rinnalla. Protokollasta ilmestyi standardi vuonna 1995, RFC 1883 (Request For Comments). Kyseinen RFC muuttui tietyiltä osin elokuussa 1997 [6]. Nykyään määrittely on Internet Draftvaiheessa, josta sen odotellaan muuttuvan uudeksi RFC:ksi lähiaikoina.[9][10] Uudessa protokollassa merkittävin muutos on osoiteavaruuden laajeneminen 32-bittisistä IP-osoitteista 128-bittisiin osoitteisiin. Tällöin protokolla pystyy tarjoamaan useita tuhansia yksikäsitteisiä osoitteita jokaista maapallon neliömetriä kohden. Multicast-osoitteen rinnalle on määritelty uusi osoitetyyppi, anycast-osoite, jossa paketti lähetetään lähimmälle ryhmään kuuluvalle solmulle. IPv6-otsikkokenttä on yksinkertaistunut verrattuna vanhaan IPv4-protokollaan. Yksittäisten kenttien lukumäärää on vähennetty joko jättämällä paketeista kenttiä kokonaan pois tai muuttamalla niitä valinnaisiksi. IPv4-protokollapaketissa on 14 kenttää, kun taas IPv6- paketin otsikkokentässä on vain 8 erillistä kenttää. Tällä menettelyllä on tarkoitus vähentää pakettien prosessointiin kuluvaa aikaa verkon solmuissa paketin kulkeman matkan varrella. Myöskin verkkokerroksella tapahtuvasta tarkistussumman laskemisesta on uudessa protokollassa luovuttu. Kuvassa 3.1 on IPv4-otsikkokenttä.[6][9][10] Versio Ots.pit. Palvelu Kokonaispituus Tunnistus Liput Lohkon sijainti Elinikä Protokolla Tarkistussumma Lähdeosoite Kohdeosoite Lisäominaisuudet Täyte Kuva 3.1: IPv4-otsikkokenttä -6-
IPv6-protokolla tarjoaa myös tuen reaaliaikasovelluksille. Siinä on mahdollista määritellä paketille prioriteetti verkon ruuhkatilanteita ajatellen, sekä määrätä paketti kuuluvaksi tiettyyn datavuohon erityisellä Vuonotsikko-kentällä. Tämä takaa sen, että samaan datavuohon kuuluvat paketit saavat samanlaisen kohtelun verkon eri solmuissa. Lisäksi uudessa protokollassa on parannettu käyttäjän tietoturvaa. Se tarjoaa käyttäjän tunnistamisen lisäksi myös datan aitouden ja luottamuksellisuuden varmistamismekanismit.[6] -7-
4. IPv6-PAKETTI IPv6-paketti muodostuu otsikkokentästä sekä mahdollisista valinnaisista lisäkentistä. Periaatteena on että jokaisesta lisäkentästä löytyy Tyyppi-kenttä, joka osoittaa seuraavan lisäkentän tyypin tai protokollapinossa ylemmältä kerrokselta saadun datan tyypin. Poikkeuksena edelliseen mainittakoon tyyppikentän puuttuminen Salaus-lisäkentästä tai ainakin sen salaamattomasta osasta. Kuvassa 4.1 on esitettynä IPv6-paketti, jossa ovat mukana kaikki lisäkentät.[6][10] Kuvassa 4.1 on mainittu myös eri lisäkenttien pituudet, jossa ainoastaan Otsikkokentälle ja Fragmentointi-lisäkentälle on määritelty tarkka pituus. Muiden lisäkenttien pituudet ovat vaihtelevan mittaisia. Lisäkenttien järjestys on myös on myös määritelty, mikäli ne IPv6-paketissa esiintyvät. Järjestys on seuraava: Otsikkokenttä Solmuoptiot-lisäkenttä Kohdeoptiot-lisäkenttä Reititys-lisäkenttä Fragmentointi-lisäkenttä Tunnistus-lisäkenttä Salaus-lisäkenttä Kohdeoptiot-lisäkenttä Huomioitavaa on, että edellisessä listassa on merkitty Kohdeoptiot-lisäkenttä kahteen kertaan. Näin on määritelty, koska IPv6-paketissa Reititys-lisäkentän ollessa mukana lähettäjä voi haluta tiettyjä toimintoja suoritettavan jokaisessa vierailtavassa solmussa. Tässä tapauksessa pakettiin voidaan lisätä Kohdeoptiot-lisäkenttä myöskin Solmuoptiot- ja Reitityslisäkentän väliin. Jälkimmäisen Kohdeoptiot-lisäkentän määräämät toiminnot suoritetaan ainoastaan lopullisessa kohdeosoitteessa. -8-
Pituus oktetteina IPv6-otsikkokenttä Tyyppi 40 oktettia Tyyppi Solmuoptiot-lisäkenttä Vaihtuvan mittainen Tyyppi Reititys-lisäkenttä Vaihtuvan mittainen Tyyppi Tyyppi Fragmentointi-lisäkenttä Tunnistus-lisäkenttä 8 oktettia Vaihtuvan mittainen Salaus-lisäkenttä Vaihtuvan mittainen Tyyppi Kohdeoptiot-lisäkenttä Vaihtuvan mittainen Ylemmältä kerrokselta tuleva data Kuva 4.1: IPv6-paketti Tyyppi-kenttä voi saada seuraavan taulukon mukaisia arvoja [10]. -9-
0 Solmuoptiot-lisäkenttä(IPv6) 1 ICMP Internet Control Message Protocol (IPv4) 2 IGMP Internet Group Management Protocol (IPv4) 2 ICMP Internet Control Message Protocol (IPv6) 3 GGP Gateway-to-Gateway Protocol 4 IP in IP (IPv4-enkapsulointi) 5 ST Stream 6 TCP Transport Control Protocol 17 UDP User Datagram Protocol 29 ISO-TP4 ISO Transport Protocol Class 4 43 Reititys-Lisäkenttä 44 Fragmentointi-lisäkenttä 45 IDRP InterDomain Routing Protocol 51 Tunnistus-lisäkenttä 52 Salaus-lisäkenttä 59 Ei seuraavaa kenttää (IPv6) 60 Kohdeoptiot-lisäkenttä 80 ISO-IP ISO Internet Protocol (CLNP) 88 IGRP Interior Gateway Routing Protocol 89 OSPF Open Shortest Path First 255 Varattu Taulukko 4.1: Tyyppikentän arvot -10-
4.1 Otsikkokenttä Kuvassa 4.2 on IPv6-otsikkokenttä. Tämä kyseinen otsikkokenttä on mukana jokaisessa IPpaketissa, joka annetaan alemmille kerroksille eli pienimmillään IP-paketissa kulkee vain pelkkä otsikkokenttä. Edellämainitussa tilanteessa Tyyppi-kentässä on silloin luku 59. Paketin kokonaispituus on tuolloin 10 x 32 bittiä = 320 bittiä = 40 oktettia.[6][10] Versio Luokka Vuonotsikko Kuorman pituus Tyyppi Elinikä Lähdeosoite Kohdeosoite Kuva 4.2: IPv6-otsikkokenttä Versio (Version) 4-bittinen versionumero, joka on siis numero 6. Luokka (Class) 8-bittinen Luokka-kenttä, joka käsitellään kohdassa 6.1. Vuonotsikko 20-bittinen Vuonotsikko-kenttä. Tämän kentän toiminnal- (Flow Label) lisuus käsitellään tarkemmin kohdassa 6.2. Kuorman pituus (Payload Length) Tyyppi (Next Header) Elinikä 16-bittinen kenttä, joka ilmoittaa kuorman pituuden oktetteina. Pituus lasketaan otsikkokentän jälkeisestä osasta. Jos tässä kentässä on arvo 0, niin kuorman pituus ylittää silloin 65,575 oktettia, jolloin käytetään Jumbopaketti-optiota. Kyseinen optio käsitellään Solmuoptiot-lisäkentän yhteydessä. 8-bittinen tarkennin, joka ilmoittaa paketissa seuraavaksi tulevan lisäkentän tai ylemmältä kerrokselta tulevan datan tyypin. Esim. jos otsikkokentän jälkeen tulee TCP-paketti, niin tässä kentässä on silloin arvo 6. Mahdolliset arvot on on esitetty taulukossa 4.1. 8-bittinen kenttä, joka ilmoittaa paketin eliniän kokonaisluku- -11-
(Hop Limit) Lähettäjän osoite Kohdeosoite na. Jokainen solmu, jossa vieraillaan vähentää tätä arvoa yhdellä. Paketti hylätään, jos arvo saavuttaa 0:n. Tähän kenttään sijoitettavan luvun maksimiarvo on 255. 128-bittinen paketin lähettäjän osoite. 128-bittinen paketin vastaanottajan osoite. Jos IP-paketissa on mukana Reititys-lisäkenttä on silloin tässä kentässä sen solmun osoite, jossa vieraillaan seuraavaksi. 4.2 Lisäkentät 4.2.1 Solmuoptiot-lisäkenttä Solmuoptiot-lisäkenttä (Hop-by-Hop options-header) sijoitetaan IP-pakettiin, jos halutaan kuljettaa mukana informaatiota, jota tutkitaan jokaisessa solmussa (reitittimessä) paketin kulkeman matkan varrella. Jos tämä kyseinen lisäkenttä on mukana, niin IPv6- otsikkokentän Tyyppi-kentässä on arvo 0. Kuva 4.3 esittää Solmuoptiot-lisäkenttää.[6][10] Tyyppi Lisäkentän pituus Optiot Kuva 4.3: Solmuoptiot-lisäkenttä Tyyppi (Next Header) Lisäkentän pituus (Hdr Ext Len) 8-bittinen tarkennin, joka ilmoittaa IPv6-paketissa seuraavaksi tulevan lisäkentän tai ylemmältä kerrokselta tulevan datan tyypin.mahdolliset arvot on esitetty taulukossa 4.1. 8-bittinen luku, joka ilmoittaa solmuoptiot-lisäkentän pituuden 8-oktetin (64-bitin) monikertana, poislukien ensimmäiset 8 oktettia. Optiot Vaihtuvan mittainen kenttä, joka sisältää yhden tai useamman (Options) TLV-koodatun (Type-Length-Value) option. Kuvasta 4.4 selviää TLV-koodauksen periaate. TLV-koodausta käytetään sekä Solmuoptiot- että Kohdeoptiot-lisäkentässä koodaamaan mahdolliset lisätoiminnot. Seuraava kuva selvittää TLV-koodauksen periaatteen.[6][10] -12-
Option tyyppi Datan pituus Option data Kuva 4.4: TLV-koodaus Option tyyppi (Option Type) Datan pituus (Option Data Length) Option data 8-bittinen luku, joka kertoo option tyypin. 8- bittinen luku, joka kertoo option datan pituuden oktetteina. Vaihtuvan mittainen kenttä, johon sijoitetaan optioille tarvittava data. Solmuoptiot-lisäkenttään voidaan siis määritellä useita erilaisia optioita TLV-koodauksella. Tällöin optiot käsitellään vastaanottajan toimesta samassa järjestyksessä, kuin mitä ne on määritelty tässä lisäkentässä. Option tyyppi-kentässä oleva luku, tai tarkemmin luvun kolme ensimmäistä bittiä, kertoo vastaanottajalle sen miten tämän kyseisen option kohdalla tulee toimia, jos tyyppiä ei esimerkiksi tunneta tai sen data on muuttunut matkalla. Kahden ensimmäisen bitin kohdalta on määritelty seuraavat toiminnot: 00 - Hyppää kyseisen option yli ja jatkaa kentän käsittelyä. 01 - Hylkää paketin. 10 - Hylkää paketin huolimatta siitä, oliko paketissa oleva kohdeosoite multicast-osoite vai ei, ja lähettää ICMP-tunnistamaton tyyppi-viestin (Internet Control Message Protocol) [5] paketin lähettäjälle. 11 - Hylkää paketin ja jos paketissa oleva kohdeosoite oli multicast-osoite, lähettää ICMP-tunnistamaton tyyppi-viesti paketin lähettäjälle. Kolmannen bitin osalta määrittely on seuraava: 0 - Option data ei muutu matkalla kohteeseen. 1 - Option data voi muuttua matkalla kohteeseen. Tällä hetkellä on määritelty vain yksi optio tähän lisäkenttään. Jumbopaketti-optiota käytetään tilanteissa, joissa paketin koko ylittää 65,575 oktettia. Otsikkokentässä Kuorman pituus-kentän koko on 16-bittiä, josta määräytyy tuo kyseinen raja. Tämä optio määrittelee mahdollisuuden ilmoittaa kuorman pituuden 32:lla bitillä. Käytettäessä tätä optiota tulee otsikkokentän Kuorman pituus-kenttään arvo 0, joka kertoo vastaanottajalle sen, että Solmuoptiot- lisäkenttä ja siellä oleva Jumbopaketti-optio ovat mukana paketissa. Kuva 4.5 esittää Jumbopaketti-optiota.[6][10] -13-
Jumbopaketin pituus 194 Datan pituus = 4 Kuva 4.5: Jumbopaketti-option rakenne Vaikka Solmuoptiot-lisäkenttä on vaihtuvan mittainen kenttä, täytyy paketin kokonaispituudeksi tulla kuitenkin 8-oktetin monikerta. Tämän vuoksi on määritelty erikseen täyteoptiot: PAD1 ja PADN. PAD1 on optio, joka lisää tähän lisäkenttään tarvittaessa yhden oktetin. PADN-optio lisää TLV-koodatun option, jonka Option tyyppi-kentässä on numero 1, ja sen datana on nollia. Sen pituus määräytyy siten, että koko Solmuoptiot-lisäkentän pituudesta tulee 8-oktetin kerrannainen. 4.2.2 Reititys-lisäkenttä Reititys-lisäkenttää (Routing-header) käytetään tapauksissa, joissa paketin lähettäjä haluaa paketin menevän tiettyjen solmujen kautta kohdeosoitteeseen. Tämä toiminto vastaa IPv4- protokollan Source Route-toimintoa. Reititys-lisäkentän tyyppitunniste, joka sijoitetaan edellisen kentän tyyppi-kenttään, on 43. Kuvassa 4.6 on esitetty Reititys-lisäkentän rakenne.[6][10] Tyyppi Lisäkentän pituus Reititystyyppi Solmuja jäljellä Eri reititystyypeille ominainen data Kuva 4.6: Reititys-lisäkenttä Tyyppi (Next Header) Lisäkentän pituus (Hdr Ext Len) Reititystyyppi (Routing type) Solmuja jäljellä (Segments Left) 8-bittinen tarkennin, joka ilmoittaa paketissa seuraavaksi tulevan lisäkentän tai ylemmältä kerrokselta tulevan datan tyypin. Mahdolliset arvot on esitetty taulukossa 4.1. 8-bittinen luku, joka ilmoittaa Reititys-lisäkentän pituuden 8-oktetin (64-bitin) monikertana, poislukien ensimmäiset 8 oktettia. 8-bittinen kenttä, joka kertoo reititystyypin. Tällä hetkellä on ainoastaan reititystyyppi 0 määritelty. 8-bittinen kenttä, jossa oleva luku kertoo sen, miten monessa solmussa täytyy vielä vierailla ennen lopullista kohdetta. -14-
Reititystyypeille ominainen data Tähän kenttään sijoitetaan eri reititystyypeille ominainen data, jonka pituus on 8-oktetin monikerta. Jos tätä lisäkenttää käsittelevä solmu ei tunnista kyseessä olevaa reititystyyppiä, niin sen toiminta riippuu Solmuja jäljellä-kentän arvosta. Jos kentässä on arvo 0, niin solmun täytyy jatkaa IPv6-paketin käsittelyä seuraavasta lisäkentästä, jonka Tyyppi-kenttä kertoo. Jos taas kentässä on nollasta poikkeava arvo, niin solmun tulee hylätä koko paketti ja lähettää ICMP-viesti paketin lähettäjälle.[6][10] Kuvassa 4.7 on esitelty tyypin 0 Reititys-lisäkenttä. Tyyppi Lisäkentän pituus Reititys tyyppi Solmuja jäljellä Varattu Osoite[1] Osoite[2] Osoite[n] Kuva 4.7: Tyypin 0 Reititys-lisäkenttä Tyyppi (Next Header) Lisäkentän pituus (Hdr Ext Len) 8-bittinen tarkennin, joka ilmoittaa paketissa seuraavaksi tulevan lisäkentän tai ylemmältä kerrokselta tulevan datan tyypin. Mahdolliset arvot on esitetty taulukossa 4.1. 8-bittinen luku, joka ilmoittaa Reititys-lisäkentän pituuden 8-oktetin (64-bitin) monikertana, poislukien ensimmäiset 8 oktettia. Lisäkentän pituus-kentässä oleva luku on yhtäsuuri kuin kaksi kertaa listassa olevien osoitteiden lukumäärä. -15-
Reititys tyyppi 0. (Routing type) Solmuja jäljellä (Segments Left) Varattu Osoitteet[1...n] 8-bittinen kenttä, jossa oleva luku kertoo sen, miten monessa solmussa täytyy vielä vierailla ennen lopullista kohdetta. 32-bittinen määrittelemätön kenttä, joka on varattu tulevaisuuden varalle. Vektori, jossa on 128-bittiset osoitteet, joissa paketin täytyy vierailla matkalla kohteeseensa. Osoitteet on numeroitu 1...n:ään. Maksimissaan osoitteita voi olla 255 kappaletta. Jos tämä lisäkenttä on mukana IPv6-paketissa, niin multicast-osoitteita (osoitteet käsitellään luvussa 9) ei voi esiintyä tässä lisäkentässä olevassa osoitteiden listassa, kuten ei myöskään otsikkokentässä kohdeosoitteena. Tämä lisäkenttä tutkitaan vain silloin, kun paketti saavuttaa otsikkokentän Kohdeosoitekentässä olevan vastaanottajan. Seuraava esimerkki valaisee Reititys-lisäkentän käyttöä. Esimerkki Paketin lähdeosoite on S, kohdeosoite on D. Paketin halutaan kulkevan solmujen eli reitittimien I1, I2 ja I3 kautta, vaikka mukana on vielä ylimääräinen solmu I4. Esimerkkitilanne on kuvan 4.8 mukainen.[6] I4 S D I1 I3 I2 Kuva 4.8: Esimerkkitilanne Seuraavaksi on esitetty otsikkokentän ja Reititys-lisäkentän sisällöt eri vaiheissa. -16-
S->I1 6 0 0 Kuorman pituus 43 Elinikä Tyyppi 6 0 3 Varattu S I2 I1 I3 D I1->I2 6 0 0 Kuorman pituus 43 Elinikä Tyyppi 6 0 2 Varattu S I1 I2 I3 D I2->I3 6 0 0 Kuorman pituus 43 Elinikä Tyyppi 6 0 1 Varattu S I1 I3 I2 D -17-
I3->D 6 0 0 Kuorman pituus 43 Elinikä Tyyppi 6 0 0 Varattu S I1 D I2 I3 Kohteessa käsitellessään Reitititys-lisäkenttää vastaanottaja huomaa, että Solmuja jäljelläkentässä on arvo 0, joten vastaanottaja hyppää tämän lisäkentän yli ja jatkaa paketin käsittelyä seuraavasta lisäkentästä. 4.2.3 Fragmentointi-lisäkenttä Fragmentointi-lisäkenttää (Fragment header) käytetään tilanteissa, joissa lähetettävän paketin koko ylittää käytössä olevan MTU:n (Maximum Transmission Unit). IPv6:ssa fragmentointi tehdään ainoastaan paketin lähetyspäässä, toisin kuin IPv4:ssa. Tämän vuoksi paketin lähettäjän on selvitettävä pienimmän MTU:n arvo koko päästä-päähän yhteydelle. Kuvassa 4.9 on esimerkkitilanne MTU:n selvitysprosessista (path MTU discovering) [10][15]. ICMP Paketti liian iso FDDI MTU=4500 FDDI MTU=4500 Ethernet MTU=1500 FDDI MTU=4500 IP-paketti Kuva 4.9: MTU:n selvitysprosessi Kuvan 4.9 tilanteessa lähettäjän ja vastaanottajan välissä on eri siirtomedioita, joissa on erisuuret MTU:t käytössä. Ideana on, että lähettäjä käyttää sen siirtomedian MTU:ta, jossa on suoraan kiinni, lähetettäessä pakettia. Jos kyseinen paketti on liian suuri jossain vaiheessa, niin paketin lähettäjä saa ICMP-Paketti liian iso-viestin (luku 8 kohta 8.2) [5], jossa on mukana uusi MTU:n arvo, jolla paketteja voi lähettää. Näin ollen kuvan esimerkkitilanteessa käytettävä MTU on 1500 oktettia koko yhteyden ylitse. -18-
Fragmentoitaessa paketin lähettäjä siis pilkkoo alkuperäisen paketin sopivan kokoisiksi osapaketeiksi ja lähettää ne erillisinä IPv6-paketteina vastaanottajalle, jossa taas osapaketit kootaan alkuperäiseksi paketiksi. Fragmentointi-lisäkenttää edeltävän lisäkentän (tai otsikkokentän) Tyyppi-kentässä on tunnistenumero 44. Fragmentointi-lisäkenttä on esitetty kuvassa 4.10.[6][10] Tyyppi Varattu Lohkon sijainti Varattu M Tunnisteluku Kuva 4.10: Fragmentointi-lisäkenttä Tyyppi (Next Header) Varattu (Reserved) Lohkon sijainti (Fragment Offset) Varattu M Tunnisteluku (Idenfication) 8-bittinen tarkennin, joka ilmoittaa paketissa seuraavaksi tulevan lisäkentän tai ylemmältä kerrokselta tulevan datan tyypin. Mahdolliset arvot on esitetty taulukossa 4.1. 8-bittinen määrittelemätön kenttä. Alustetaan 0:ksi ja vastaanotossa hylätään. 13-bittinen kenttä, joka kertoo osapakettien järjestyksen suhteessa alkuperäisen pakettiin. Alkuperäinen paketti voidaan ajatella kuvan 4.11 mukaiseksi. 2-bittinen määrittelemätön kenttä. Alustetaan 0:ksi ja vastaanotossa hylätään. Bitti, joka kertoo tuleeko vielä lisää osapaketteja kuuluen samaan alkuperäiseen pakettiin. 1 = lisää osapaketteja. 0 = viimeinen osapaketti. 32-bittinen tunnisteluku, josta vastaanottaja voi tunnistaa alkuperäiseen pakettiin kuuluvat osapaketit. Lähettäjä antaa jokaiselle alkuperäisen paketin osalle saman tunnistenumeron, jonka avulla vastaanottaja pystyy taas parsimaan kokoon alkuperäisen paketin. Lähettäjän on myös huolehdittava siitä, että ei käytä samoja tunnistenumeroita sinä aikana, kun edellä lähetetyt paketit verkossa kulkevat. Lähettäjä voi käyttää erilaisia laskureita huolehtimaan em. asiasta. Alkuperäinen osa Ensimmäinen osa Toinen osa... Kuva 4.11: Alkuperäinen IPv6-paketti Viimeinen osa Kuvassa 4.11 on esitetty alkuperäinen IPv6-paketti eli paketti, jossa on mukana myöskin kuljetuskerrokselta tullut data ja jonka pituus ylittää siis MTU:n, jaoteltuna osapaketteihin. Alkuperäinen osa sisältää IPv6-otsikkokentän sekä Solmuoptiot-lisäkentän ja Reitityslisäkentän, mikäli kyseiset lisäkentät ovat mukana paketissa. Jokainen osapaketti lähetetään erillisessä IPv6-paketissa kuvan 4.12 periaatteen mukaisesti.[6][10] -19-
Alkuperäinen Fragmentointi osa lisäkenttä Alkuperäinen osa Fragmentointi lisäkenttä Ensimmäinen osa Toinen osa Alkuperäinen osa Fragmentointi lisäkenttä Viimeinen osa Kuva 4.12: Osapaketit Alkuperäisessä osassa olevan otsikkokentän Kuorman pituus-kenttään on muutettu kyseisen osapaketin kuorman pituus. Alkuperäisen osan viimeisen lisäkentän Tyyppi-kenttään laitetaan arvo 44, joka kertoo sen, että seuraavana oleva lisäkenttä on Fragmentointi-lisäkenttä. Jos alkuperäisessä osassa ei ole yhtään lisäkenttää (Solmuoptiot- ja Reititys-lisäkenttä) mukana, tulee otsikkokentän Tyyppi-kenttään silloin tuo edellä mainittu arvo. Fragmentointi-lisäkentän Tyyppi-kentässä on sen lisäkentän tyyppiä osoittava numero, joka tulee alkuperäisessä pilkkomattomassa paketissa seuraavaksi. Osapaketit täytyy muodostaa siten, että niiden koot eivät ylitä MTU:ta. Vastaanotossa kootaan alkuperäinen paketti tulevista osapaketeista, joilla on sama lähettäjä, vastaanottaja sekä sama tunnistenumero. Fragmentointi-lisäkenttä ei ole mukana osista rakennetussa paketissa, joten myös Tyyppi-kentän arvo päivitetään alkuperäisen paketin mukaiseksi. Tämän lisäkentän tarpeellisuudesta on käyty vilkasta keskustelua eri tahoilla. Liikenteen kasvaessa verkossa pyritään ylimääräinen kuormitus minimoimaan, joten on mahdollista, että pakettien pilkkominen jätetäänkin tulevaisuudessa pois kokonaan. 4.2.4 Tunnistus-lisäkenttä Tämä lisäkenttä käsitellään luvussa 5 kohdassa 5.1. 4.2.5 Salaus-lisäkenttä Tämä lisäkenttä käsitellään luvussa 5 kohdassa 5.2. 4.2.6 Kohdeoptiot-lisäkenttä Kohdeoptiot-lisäkenttää (Destination options-header) käytetään haluttaessa kuljettamaan paketissa tietoa, jota tutkitaan ainoastaan paketin lopullisessa kohteessa. Edellisen lisäkentän tai otsikkokentän Tyyppi-kentässä on arvo 60. Tällä lisäkentällä on täysin sama rakenne kuin mitä on Solmuoptiot-lisäkentällä, joka esiteltiin alakohdassa 4.2.1.[6][10] -20-
Tyyppi Lisäkentän pituus Optiot Kuva 4.13: Kohdeoptiot-lisäkenttä Tyyppi (Next Header) Lisäkentän pituus (Hdr Ext Len) Optiot (Options) 8-bittinen tarkennin, joka ilmoittaa paketissa seuraavaksi tulevan lisäkentän tai ylemmältä kerrokselta tulevan datan tyypin. Mahdolliset arvot on esitetty taulukossa 4.1. 8-bittinen luku, joka ilmoittaa Kohdeoptiot-lisäkentän pituuden 8-oktetin (64-bitin) monikertana, poislukien ensimmäiset 8 oktettia. Vaihtuvan mittainen kenttä, joka sisältää yhden tai useamman TLV-koodatun (Type-Length-Value) option. TLV-koodauksen periaate käsiteltiin alakohdassa 4.2.1. Tässä lisäkentässä ei ole tällä hetkellä määritelty muita optioita, kuin täyteoptiot PAD1 ja PADN, jotka käsiteltiin Solmuoptiot-lisäkentän yhteydessä alakohdassa 4.2.1. -21-
5. TIETOTURVA Internetin käytön monipuolistuessa nousee yhä useammin esille käyttäjien tietoturva. Vanhassa IPv4-protokollassa ei tätä osa-aluetta ole otettu mitenkään huomioon. Nykyinen IPprotokolla on varsin avoin liikenteen kaappaamiselle ja sen sisällön analysoinnille sekä myöskin liikenteen vääristämiselle. Myöskään paketin lähettäjien oikeellisuutta ja laillisuutta ei pystytä todentamaan. Tulevaisuudessa verkossa liikkuvien salasanojen, tunnuslukujen, tilitietojen ja yrityssalaisuuksien ym. salaisten asioiden ei haluta joutuvan vieraiden käsiin. Tämä on asettanut huomattavat paineet tietoturvasuunnittelijoille uutta IP-protokollaa suunniteltaessa. Tässä luvussa esitetyt tietoturvaratkaisut suunniteltiin alunperin ajatellen IPv6- protokollaa, mutta IPv4-protokollan laajan käytön sekä siirtymäajan vuoksi, näitä menetelmiä voidaan käyttää myöskin IPv4-protokollan kanssa. 5.1 Käyttäjien tunnistus Tunnistus-lisäkenttä (Authentication-header)[1], mahdollistaa pakettien alkuperäisen lähettäjän oikeellisuuden tunnistamisen. Edellisen lisäkentän Tyyppi-kentässä on tyyppitunniste 51. Kyseisen lisäkentän rakenne on esitetty kuvassa 5.1.[1][10] Tyyppi Pituus Varattu SPI Järjestysnumero Tunnistusdata Kuva 5.1: Tunnistus-lisäkenttä -22-
Tyyppi (Next Header) Pituus (Length) Varattu (Reserved) 8-bittinen tarkennin, joka ilmoittaa paketissa seuraavaksi tulevan lisäkentän tai ylemmältä kerrokselta tulevan datan tyypin. Mahdolliset arvot on esitetty taulukossa 4.1. 8-bittinen kenttä, joka kertoo Tunnistusdata-kentän pituuden 32 bitin yksiköissä. 16-bittinen kenttä, joka on varattu tulevaisuuden varalle. Alustetaan 0:ksi, otetaan huomioon Tunnistusdata-kenttään sijoitettavassa tarkistussumman laskemisessa, vastaanotossa hylätään. SPI 32-bittinen luku, joka ilmoittaa turvallisuusryhmän. 0 (Security Parameter tarkoittaa, että turvallisuusryhmää ei ole olemassa. Index) Järjestysnumero Tunnistusdata (Authentication Data) 32-bittinen järjestysnumero, joka toimii laskurina. Vaihtuvan mittainen kenttä, johon sijoitetaan tarkistussumma, joka lasketaan tietyistä IPv6-otsikkokentän kentistä, joistain lisäkentistä, ylemmältä kerrokselta tulevasta datasta (TCP, UDP,...), sekä salaisesta avaimesta, joka on tiedossa kaikilla samaan turvallisuusryhmään kuuluvilla jäsenillä. Salausavaimien jako käsitellään kohdassa 5.3. Kentän pituus vaihtelee tarkistussumman laskemiseen käytettävän algoritmin mukaan. Eräs vaihtoehto algoritmiksi on MD5. Vastaanotettuaan paketin vastaanottaja laskee vastaavan tarkistussumman paketin sisällön, SPI:n ja salaisen avaimen mukaan, ja vertaa sitten saamaansa lukua Tunnistus data-kentässä olleeseen lukuun. Jos luvut ovat samoja, vastaanottaja varmistuu siitä, että paketin lähettäjä tietää salaisen avaimen ja siten kuuluu samaan turvallisuusryhmään. Tällöin paketin vastaanottaja varmistuu lähettäjän aitoudesta. Kyseinen lisäkenttä sijoitetaan IPv6-pakettiin kuvan 5.2 mukaisesti. Solmuoptiot/Reititys IPv6-otsikkokenttä Tunnistuslisäkenttä Muut lisäkentät Data Kuva 5.2: Tunnistus-lisäkentän sijainti IPv6-paketissa Tunnistus-lisäkenttä ei siis muuta jäljessä tulevaa dataa mitenkään eli data kulkee selväkielisenä verkossa, jolloin joku kolmas osapuoli saattaa analysoida liikennettä vapaasti. 5.2 Liikenteen salaus Koska Tunnistus-lisäkenttä lähettää datan selväkielisenä, on määritelty Salaus-lisäkenttä (Encrypted security payload-header, ESP)[2]. ESP-lisäkenttä tarjoaa pakettien luottamuksellisuuden käyttäen salausalgoritmeja. Tämä lisäkenttä on aina viimeisenä lisäkenttänä, joka halutaan vielä lähetettävän selväkielisenä. Tarkemmin sanottuna ESP-lisäkenttäkin -23-
lähetetään vain osittain selväkielisenä. Kuva 5.3 esittää IPv6-pakettia silloin, kun siinä on ESP- lisäkenttä mukana.[2][10] IPv6-otsikkokenttä Muut lisäkentät ESP-lisäkenttä Salattu data Salaamaton osuus Salattu osuus Kuva 5.3: IPv6-paketti ESP-lisäkentän ollessa mukana Salaus-lisäkentästä lähetetään vain SPI ja järjestysnumero selväkielisenä. Loppuosa, erilaiset parametrit sekä itse data, lähetetään salattuna. Kuvassa 5.4 on esitelty ESP-lisäkentän käyttöä tarkemmin. Turvallisuus indeksi (SPI) Järjestysnumero Aloitusvektori Data Salattu osuus Täyte Täyte Täytteen pituus Kuorman tyyppi Kuva 5.4: ESP-lisäkentän käyttö Aloitusvektori (Initialization Vector) Data Täyte (Padding) Täytteen pituus (Padding length) Vaihtelevanmittainen satunnaisesti tuotettu luku, jonka pituus on 32-bitin monikerta. Salattu kuorma. Täyte, jonka pituus määritetään siten, että kokonaispituus on 64-bitin monikerta. Täytteen sisältö voi olla mitä tahansa. 8-bittinen luku, joka kertoo täyteoktettien lukumäärän. Kuorman tyyppi Kenttä, joka kertoo kuljetuskerrokselta saatavan datan (Payload type) tyypin. Mahdollisia arvoja on esitetty taulukossa 4.1. Data-kentän pituus vaihtelee käytettävästä salausalgoritmista. Eräs vaihtoehto salausalgoritmiksi on DES-CBC (Data Encryption Standard, used in cipher block chaining mode). -24-
Aloitusvektorin tarkoitus on, että salatun osuuden ensimmäinen sana ei olisi ennustettavissa. Aloitusvektorin pituus on tiedossa sekä paketin lähettäjällä että vastaanottajalla. Aloitusvektorin pituus välitetään osapuolille samoin kuten salainen avain. Kuten aikaisemmin on mainittu, tässä lisäkentässä ei ole tavanomaista Tyyppi-kenttää. Tämä siksi, koska sen salatusta osuudesta löytyy Kuorman tyyppi-kenttä, joka kertoo vastaavasti datan tyypin. Salatussa osuudessa kulkee erilainen data salattuna. Salauksessa voidaan käyttää joko Kuljetus-moodia (Transport mode) tai Tunneli-moodia (Tunnel Mode). Kuljetus-moodissa salattuna kulkee vain kuljetuskerrokselta saatava data. Kuva 5.5 esittää Kuljetus-moodissa tapahtuvaa salausta. Tunneli-moodissa salattuun osuuteen kapseloidaan kokonainen IPv6- paketti. Kuva 5.6 havainnollistaa asiaa.[2][10] IPv6-otsikkokenttä Muut lisäkentät ESP-lisäkenttä Kuljetuskerrokselta tuleva data Salaamaton osuus Salattu osuus Kuva 5.5: Kuljetus-moodissa tapahtuva salaus Muut lisäkentät IPv6-otsikkokenttä ESPlisäkenttä IPv6-otsikkokenttä Muut lisäkentät Kuljetuskerrokselta tuleva data Salaamaton osuus Salattu osuus Kuva 5.6: Tunneli-moodissa tapahtuva salaus 5.3 Salausavainten jakaminen Kaiken tämän tietoturvan pohjana on salaiset parametrit, jotka ovat tarpeellisia sekä vastaanotossa että lähetyksessä, niin käyttäjän tunnistuksessa kuin salauksessakin. Kyseiset parametrit eivät kulje samoissa paketeissa normaalin datan mukana, vaan parametrit jaetaan erikseen joko henkilökohtaisesti tai verkon välityksellä. Verkon välityksellä tapahtuvaan salausavainten jakoon on kehitetty useita vaihtoehtoisia menetelmiä.[10] Tällä hetkellä mahdolliset protokollat avaimien jakamiseksi ovat nimeltään Photuris, SKIP ja ISAKMP-OAKLEY. Ne perustuvat suureksi osaksi Whitwield Diffien ja Martin Helmannin nollatiedon avaintenvaihtoalgoritmiin. Ideana algoritmissa on, että osapuolet A ja B sopivat ensin jonkun yhteisen alkuluvun p ja generaattoriluvun g. Sitten A valitsee satunnaisesti jonkun luvun x ja laskee seuraavaksi luvun n, joka tulee seuraavasta kaavasta: n = g x mod p Sen jälkeen kun A on lähettänyt n:n arvon B:lle, B valitsee satunnaisen luvun y ja laskee m:n arvon seuraavasti: m = g y mod p Nyt vuorostaan B lähettää m:n arvon A:lle. Tämän jälkeen A:lla on tiedossa m ja x ja B:llä n ja y. Tässä tilanteessa kolmas osapuoli saattaa ehkä tietää m:n ja n:n, mutta ei tiedä mitään x:n ja y:n arvoista. Näinollen A ja B voivat laskea salaisen avaimen seuraavasta kaavasta: -25-
z = n y mod p = m x mod p = g xy mod p Tätä menetelmää voidaan käyttää sekä käyttäjien tunnistamisessa että salauksessa tarvittavien salaisten parametrien vaihdossa. Tällä hetkellä ISAKMP-OAKLEY -avaintenjakomenetelmä (Internet Security Association and Key Management Protocol) näyttää olevan se vaihtoehto, joka tulee määrittelyihin lähinnä oletusmenetelmäksi. Tämä menettely ei sulje pois muiden menetelmien käyttöä eli myös niitä voidaan käyttää. SKIP-menetelmä (Simple Key-management for Internet Protocol) on ainoa laitevalmistajakohtainen avainten jakomenetelmä ja se on kehitetty Unixlaitteiden valmistajan (Sun Microsystems) toimesta. Seuraavaksi käsitellään ISAKMP-OAKLEY -menetelmä tarkemmin. ISAKMP-protokollassa viestit koostuvat ISAKMP-otsikosta ja sitä seuraavista ISAKMPlisäkentistä. Nämä kyseiset viestit välitetään käyttäen UDP-protokollaa. Yksittäisellä viestillä voidaan neuvotella useita eri avaimia liittyen eri tietoturvayhteyksiin. Ne lisäkentät, jotka kuuluvat samaan tietoturvayhteyteen, koteloidaan erillisellä "kuorella", joka määrittelee tietoturvaryhmän eli kyseisessä kuoressa kulkee kyseisen ryhmän SPI-luku. Seuraava kuva esittää ISAKMP-otsikkoa.[10] Aloittajan tunnusluku Vastaajan tunnusluku Kuorman tyyppi Versio XCHG Liput Pituus Kuva 5.7: ISAKMP-otsikko Otsikossa ensimmäisenä tulee kaksi tunnuslukua, joilla estetään mm. ulkopuolisten verkon tukkimisyritykset (clogging). Aloittajan ja vastaajan tunnukset määrittelevät ISAKMPtietoturvaryhmän. Tyyppi-kenttä kertoo sen kuorman (lisäkentän) tyypin, joka tulee viestissä ensimmäisenä. Versio-kenttä kertoo protokollan versionumeron. XCHG (Exchange type) kertoo mitä tietoja ollaan vaihtamassa; 0 - perustiedot, 2 - identiteetin suojaus ja 3 - tunnistustiedot. Liput-kentässä voidaan määritellä erilaisia toimintoja, joista 16 mahdollisesta ainoastaan kaksi lippua on määritelty; salauslippu ja vertailulippu (collate). Jos salauslippu on 1, kaikki lisäkentät, jotka tulevat ISAKMP-otsikon jälkeen, lähetetään aikaisemmin neuvoteltua algoritmia ja avainta käyttäen salattuina. Jos salauslippu on 0, niin siinä tapauksessa ei käytetä salausta. Jos vertailulippu on 1, samoja parametreja voidaan käyttää eri yhteyksissä. Viimeiseen kenttään tulee koko viestin pituus oktetteina. ISAKMP määrittelee useita eri lisäkenttiä, joita voidaan lisätä otsikon jälkeen. Seuraava taulukko luettelee kaikki kyseiset lisäkentät.[10] -26-
Nro Kuorman tyyppi 0 Ei mitään 1 Kuori (ENV) 2 Turvallisuusryhmä (SA) 3 Avainten jakaminen (KE) 4 Tunnistus (ID) 5 Luokittelu (CERT) 6 Jaottelu (HASH) 7 Signature (SIG) 8 Tilapäinen (NONCE) 9 Ilmoitus (N) 10 Poista (D) 11 Muuta (M) Taulukko 5.1: ISAKMP-lisäkenttien tyypit Koteloinnissa käytetty kuori on esitetty kuvassa 5.8. Kuorman tyyppi Kuormien lukumäärä Protokolla-ID Turvallisuusindeksi (SPI) Kuva 5.8: ISAKMP-kuori Jos esimerkiksi kyseessä on lisäkentät, joissa määritellään erilaisia samaan salaus-prosesiin kuuluvia parametrejä, koteloidaan kaikki lisäkentät saman kuoren sisään. Jokaisesesta lisäkentästä löytyy Kuorman tyyppi-kenttä. Kuoressa taas on vastaavasti protokollan tunnus eli tässä tapauksessa se olisi ESP-lisäkentän tunnus, ja myöskin SPI, josta ilmenee turvallisuusryhmä, johon kuulutaan ja johon parametreja ollaan neuvottelemassa. Itse viestien vaihto tapahtuu OAKLEY-ehdotuksen mukaisesti, josta siis muodostuu nimi ISAKMP-OAKLEY. Useita eri malleja sisältävä ehdotuksen perusmalli viestien vaihdolle on seuraavan kuvan mukainen. Aloittaja Otsikko, SA Otsikko, KE, N(aloittaja) Ots., IDaa, [CERT] SIG Vastaaja Otsikko, SA Otsikko, KE, N(vastaaja) Ots., IDvv, [CERT] SIG Kuva 5.9: OAKLEY-ehdotuksen mukainen perusmalli viestien vaihdolle -27-
Kuvassa 5.9 tapahtuvassa viestien vaihdossa ensimmäiseksi tapahtuu tunnuksien, turvallisuusryhmän sekä salausalgoritmin neuvottelu (SA-lisäkenttä). Sen jälkeen neuvotellaan erilaiset parametrit ja salausavaimet (KE-lisäkenttä). Ja lopuksi vielä vaihdetaan tunnukset aloittajan ja vastaajan välillä, jotka kulkevat salattuina aikaisemmin neuvotellulla algoritmillä ja avaimilla. Salausparametrien vaihtamiseksi saattaa vielä tulevaisuudessa ilmaantua muitakin ehdotuksia näiden edelläesitettyjen protokollien lisäksi. -28-
6. REAALIAIKATUKI Internetin suosion myötä on verkossa alkanut kulkea myöskin yhä enemmän aikakriittistä liikennettä kuten ääntä ja kuvaa. Tästä liikenteestä käytetään nimitystä reaaliaikaliikenne ja niitä sovelluksia, jotka generoivat reaaliaikaliikennettä, kutsutaan reaaliaikasovelluksiksi. Reaaliaikaliikenne vaatii verkolta enemmän tiedonsiirtokapasiteettia ja tietynlaisen takeen liikenteen laadusta. Tästä aiheutuvat ongelmat, kuten viiveet ja verkon kapasiteetin reilu jakaminen erilaisten sovellusten kesken ovat suuren tutkimustyön kohteena ja se näkyy myös uuden IP-protokollan suunnittelussa. IPv6-protokollassa on otettu huomioon mahdollisten reaaliaikasovellusten ajaminen verkossa. IPv6-otsikkokenttään on määritelty erillinen Luokka-kenttä, jonka rakenne selvitetään tämän luvun kohdassa 6.1 sekä erillinen Vuonotsikko-kenttä, josta kerrotaan tarkemmin kohdassa 6.2. Kohta 6.3 käsittelee resurssinvarausta ja erityisesti resurssinvarausprotokollaa, joka on nimeltään RSVP ( Resource ReSerVation Protocol) [4][18]. 6.1 Luokka-kenttä Luokka-kenttä (Class) on 8-bittinen kenttä IPv6-otsikkokentässä. Se mahdollistaa lähetyspäässä pakettien luokittelemisen ja priorisoimisen suhteessa toisiin lähetettäviin paketteihin. Tämän kentän ansiosta myöskin paketteja välittävät reitittimet pystyvät luokittelemaan ja priorisoimaan liikennettä. Tämä on tärkeää varsinkin tilanteissa, joissa verkko on ruuhkainen ja palvelua joudutaan odottamaan erilaisissa jonosysteemeissä. Tällöin on erityisen tärkeää pystyä laittamaan paketit arvojärjestykseen, jolloin viivekriittinen liikenne saisi palvelua mahdollisimman nopeasti ja muut vastaavasti joutuisivat odottamaan palvelua pitempään. Samoin tilanteissa, joissa paketteja joudutaan poistamaan verkosta ruuhkautumisen johdosta, on hyvä kyetä laittamaan paketit taas arvojärjestykseen, jolloin tärkein liikenne kuten esim. kontrolliliikenne poistettaisiin vasta viimeisenä verkosta. Tämän työn kirjoitushetkellä Luokka-kentän tarkempi rakenne viimeisten 4-bitin osalta ei ollut selvillä. Erilaisia ehdotuksia on kuitenkin ollut esillä.[6][10] -29-
Tässä diplomityössä esitelläänkin eräs ehdotus, joka perustuu Steve Deeringin pitämään esitykseen. Esitys välitettiin Internetin välityksellä multicast-lähetyksenä kaikille halukkaille kuuntelijoille syyskuussa 1997. Ehdotus on kuvan 6.1 mukainen. D Prioriteetti Varattu U C Kuva 6.1: Ehdotus Luokka-kentäksi D Prioriteetti (Priority) Varattu U C D-bitti kertoo sen, mikä on viiveen ja läpimenon tärkeysjärjestys 1 = minimaalinen viive tärkeämpi kuin maksimaalinen läpimeno. 0 = maksimaalinen läpimeno tärkeämpää kuin viive. 3-bittinen prioriteetti-kenttä, joka ilmoittaa paketin prioriteetin. Kentänkoosta johtuen prioriteetti voi saada arvoja väliltä 0-7. Mitä suurempi luku kentässä on, sitä suurempi on paketin prioriteetti. Tämän kentän sisältöä voivat reitittimet muuttaa matkan varrella. 2-bittinen kenttä, jota ei ole määritelty. Alustetaan 0:ksi ja vastaanotossa sitä ei oteta huomioon. Bitti, joka kertoo sen, että ymmärtääkö kyseinen paketti ruuhkailmoituksen. Tämä bitti merkitään IP-kerroksen yläpuolella toimivan kuljetuskerroksen protokollan toimesta. Ruuhkailmoitus. Reititin merkitsee tämän bitin paketin hylkäämisen sijaan ruuhkatilanteessa. Tällä hetkellä IETF:n työryhmä valmistelee ratkaisua niin IPv4:n prioriteetti-kentän kuin IPv6:n Luokka-kentän käytöstä. 6.2 Vuon otsikointi 20-bittinen Vuonotsikko-kenttä (Flow Label) IPv6-otsikkokentässä antaa pakettien lähettäjälle mahdollisuuden otsikoida paketteja, joille halutaan erikoiskäsittelyä verkon välittävissä solmuissa. Erikoiskäsittelyä vaativia paketteja ovat esimerkiksi reaaliaikasovellusten generoimat paketit. Pakettien otsikoinnin tarkoitus on, että paketit muodostaisivat datavuon, joka koostuu saman lähettäjän samoilla Vuonotsikko-kentillä varustetuista paketeista, joilla kaikilla on myös sama kohdeosoite. Pakettien vaatimat erikoiskäsittelyt voidaan määritellä joko IPv6-paketin Solmuoptiot-lisäkentässä tai kertoa jollain merkinantoprotokollalla, kuten esimerkiksi RSVP:llä, jonka kanssa Vuonotsikko-kenttää suunniteltiin alunperin käytettävän. [6][10] Lähteestä kohteeseen voi olla useita yhtäaikaisia datavoita ja lisäksi mihinkään datavuohon kuulumatonta liikennettä. Paketit, jotka eivät kuulu mihinkään datavuohon, sisältävät Vuonotsikko-kentän, jonka arvo on 0. Muutoin Vuonotsikko-kenttään valitaan luku satunnaisesti väliltä 1...FFFFFF (heksadesimaaliluku). Datavuon luojan onkin huolehdittava -30-
siitä, että hän ei käytä samoja aikaisemmin käytettyjä vuonotsikoita pakettien (datavuon) eliniän aikana. Tähän tehtävään soveltuvat erilaiset laskurit. Kaikki paketit, jotka kuuluvat datavuohon, lähetetään samalla lähde- ja kohdeosoitteella ja samalla Vuonotsikko-kentällä. Jos jossain paketissa on mukana Solmuoptiot-lisäkenttä, se täytyy olla samanlaisena mukana kaikissa datavuon paketissa. Samoin, jos Reitityslisäkenttä on mukana, niin sen tulee olla samanlainen kaikissa paketeissa. Pääajatus Vuonotsikko-kentän käytössä on, että kaikki samaan datavuohon kuuluvat paketit saisivat samanlaisen kohtelun reitittimissä pakettien kulkeman matkan varrella. Lisäksi tämän kentän käyttö nopeuttaa pakettien käsittelyä, johtuen siitä, että ensimmäisen paketin tullessa reitittimelle, kirjataan ylös minkälaista käsittelyä paketti vaatii. Seuraavien samaan datavuohon kuuluvien pakettien tullessa riittää hakea ainoastaan taulukosta paketin vaatima käsittely koko paketin tutkimisen sijaan. Datavoiden tietoja pidetään taulukoissa tietyn ajan, jonka jälkeen taas tutkittaisiin koko paketti ja kirjattaisiin taulukkoon datavuon paketeille vaatima käsittely uudelleen. Tätä kenttää on myös suunniteltu käytettävän tulevaisuuden Label Switching-tekniikan yhteydessä. 6.3 Resurssien varaaminen Resurssinvarausprotokollat ovat ns. signalointi- eli merkinantoprotokollia. Niiden avulla välitetään tietoa käyttäjien ja sovellusten palveluvaatimuksista välittäville reitittimille. Erityisesti IP-liikennettä varten on suunniteltu merkinantoprotokolla nimeltä RSVP (Resource ReSerVation Protocol). RSVP on määritelty RFC 2205:ssa [4]. RSVP:n avulla laatuparametrit välitetään päätepisteiden välisille solmuille. Tämä tapahtuu erillisillä viesteillä muun IP-liikenteen rinnalla. Itse ISA:n (Integrated Service Architecture) mukaisen palvelun laadun toteuttamiseen ei kyseinen resurssinvarausprotokolla ota kantaa, vaan sen hoitaa jokainen solmu itse. Palvelun laadun ja resurssien varaamiseen liittyviä asioita mietitään IETF:n (Internet Engineering Task Force) Integrated Services-työryhmässä.[4][19] RSVP:n käyttöönotto tapahtuu verkon rakennetta muuttamatta ohjelmistopäivityksillä. Kaikkien verkon solmujen ei tarvitse tukea RSVP-protokollaa, joten sen käyttöönotto voi tapahtua asteittain. RSVP-protokolla on suunniteltu alunperin suurta siirtonopeutta vaativia multimediasovelluksia varten, jotka käyttävät multicast-lähetyksiä (yksi lähettäjä, monta vastaanottajaa). Esimerkkinä tällaisesta voidaan mainita suurinopeuksinen videolähetys, jolle halutaan taattu palvelu verkon eri solmuissa pakettien perillemenon takaamiseksi. Periaatteena on, että etukäteen varataan ja neuvotellaan tarvittava kaista lähetystä varten. Tämän jälkeen liikenne on normaalia IP-liikennettä. RSVP on ns. vastaanottajaorientoitunut protokolla. Pakettien lähettäjä lähettää viestin (Path-viestin) kohdeosoitteeseen kertoen omasta liikenneprofiilista ja siitä miten paljon kapasiteettia tarvittaisiin ja samalla paketissa kulkee myös informaatio haluamastaan palvelusta. Kyselyyn vastataan (Resv-viestillä) ja pyydetty kapasiteetti varataan vastaanottajan niin päättäessä. Datan lähetys voidaan aloittaa samanaikaisesti Pathviestin kanssa tai lähettäjä voi odottaa varausten aktivoitumista ennenkuin alkaa lähettämään dataa verkkoon. Tässä kohtaa tulee esille kohdassa 6.2 esitetyn Vuonotsikkoinnin tarpeellisuus, sillä eri liikenneprofiilit, jotka esitellään resurssinvarausviesteissä, täytyy myöskin suodattaa toisistaan. Oletetaan esimerkiksi, että samasta lähteestä on kaksi yhteyttä samanaikaisesti. -31-