FI110464B - IP-tietoturva ja liikkuvat verkkoyhteydet - Google Patents

Description

.,. 110464

IP-TIETOTURVA JA LIIKKUVAT VERKKOYHTEYDET , KEKSINNÖN KOHDE

5 Esillä oleva keksintö liittyy yleisesti matkaviestinverkkoyhteyksiin ja erityisesti IP-tietoturvaa sekä yhteyksiä koskeviin menettelyihin.

KEKSINNÖN TAUSTA

10 Internetin ja sen osan WWW:n (World Wide Web) edut verkossa olevan laajan tietomäärän hyödyntämisessä tunnustetaan laajalti. Internetiin on perinteisesti muodostettu yhteys kiinteistä liityntäpisteistä, esimerkiksi työpaikalta, koulusta tai kotoa. Kiinteiden liityntäpisteiden käsite on ollut Internet-mallin perustana alusta lähtien. Esimerkiksi IP-protokolla reitittää paketit oikeisiin kohteisiin IP-osoitteiden 15 mukaisesti. IP-osoitteet liitetään kiinteään fyysiseen paikkaan paljolti samalla tavalla kuin perinteiset puhelinnumerot liitetään lankapuhelinten fyysiseen sijaintiin. Tämän ansiosta IP-paketit voidaan reitittää aiottuun määränpäähän virheettömästi ja tehokkaasti.

20 Perinteinen yhteyskäsite on muuttunut liikkuvuuden lisääntyessä. Tämä on tullut esiin : viime vuosina esimerkiksi matkapuhelinten käytön yleistyessä. Kannettavien ' ·'.' tietokoneiden käyttö on toinen yhä suositumpi alue, jossa saadaan aikaan selviä etuja, ·...· jos käyttäjät pystyvät tekemään työtä paikasta riippumatta. Luotettavan Internet- yhteyden ansiosta liikkuvat verkkoyhteydet lisäävät myös kaikkien käyttäjien :...· 25 tuottavuutta, koska käyttäjät eivät ole enää sidottuja työpaikoilleen. Nykyisin ollaan yhä useammin siirtymässä langattomiin yhteyksiin, jotka tuovat lisää vapautta tarjoamalla yhteysmahdollisuuksia ajasta ja paikasta riippumatta, esimerkiksi lentokoneissa ja autoissa.

30 Perinteinen Internet-malli, jossa käytetään kiinteitä osoitteita, tekee kuitenkin Internetin saumattoman ja luotettavan käytön matkaviestinlaitteilla hieman ongelmalliseksi. Tämä johtuu siitä, että kun matkaviestinlaite muodostaa yhteyden uuteen verkkoon tai . . liityntäpisteeseen, uuteen verkkoon yhdistetyn IP-osoitteen kautta matkaviestinlaitteelle • ’· muodostuu uusi IP-osoite. Näin ollen alkuperäiseen IP-osoitteeseen kohdistetut paketit -2- 110464 eivät välity uuteen IP-osoitteeseen. Näihin ongelmiin on esitetty ratkaisuksi muun muassa Mobile IP:tä (RFC2002). Mobile IP on IETF (Internet Engineering Task Force) -ohjeistossa ehdotettu standardi, jolla liikkuvien yhteyksien ongelma ratkaistaan niin, että matkaviestinlaitteella on kaksi IP-osoitetta: kotiosoite ja toinen osoite, joka muuttuu 5 aina uuden liityntäpisteen myötä. Mobile IP:n perusajatus on se, että se mahdollistaa saumattoman vierailun eri verkoissa. Matkaviestinlaitteeseen lähetetyt paketit pystyvät kulkemaan määränpäähänsä oikein huolimatta siitä, mihin verkkoon laite on kytkeytynyt.

10 Tyypillisesti lähtösolmusta lähtevät paketit kulkevat kohdesolmuun niin, että ne reititetään saapuvista verkkorajapinnoista lähteviin rajapintoihin reititystaulujen avulla. Reititystaulut sisältävät tietoja seuraavasta hypystä kuhunkin IP-kohdeosoitteeseen. Paketit voivat edetä matkaviestinlaitteeseen staattisen kotiosoitteen avulla, joka antaa sen vaikutelman, että liikkuva solmu pystyy jatkuvasti vastaanottamaan tietoja 15 kotiverkossaan. Tällöin käytetään kotiagenttiverkkosolmua, joka noutaa liikkuvaan solmuun osoitetut paketit ja välittää ne solmun toiseen osoitteeseen, kun solmu on kytkeytyneenä vieraaseen verkkoon. Koska toinen osoite muuttuu aina uuden verkon kiinnityspisteen myötä, kotiagentin on tunnettava kyseiset tiedot, jotta se pystyisi ohjaamaan paketit uudelleen. Tämän vuoksi toinen osoite rekisteröidään kotiagenttinsa ; 20 mukana aina, kun liikkuva solmu siirtyy tai saa uuden IP-osoitteen.

. ·. ·. Pakettien toimittaminen liikkuvaan solmuun edellyttää, että paketti muotoillaan niin, että .···, toinen osoite on IP-kohdeosoite pakettimuunnoksena tunnetussa prosessissa.

Liikkuvalle solmulle määritetty uusi otsikko muodostuu muunnoksessa, jossa 25 alkuperäinen paketti kapseloidaan (tätä kutsutaan myös tunneloinniksi) niin, että kotiverkko ei vaikuta reititykseen, kunnes paketti on turvallisesti perillä liikkuvassa solmussa. Määränpäässä pakettiin sovelletaan käänteistä muunnosta niin, että liikkuvan solmun kotiosoite näyttää olevan paketin kohdeosoitteena, jotta siirtoprotokolla, esimerkiksi TCP (Transmission Control Protocol) pystyy käsittelemään ; 30 pakettia oikein. Vierasta agenttia käytetään tyypillisesti purkamaan sellaisten pakettien • kapselointi, jotka on vastaanotettu kotiagentilta välitettäviksi liikkuvaan solmuun.

:··. Edellä on kuvattu IP-tunneloinnin perusmuoto. Mobile IP kuitenkin tukee tyypillisesti kolmea tunnelointimekanismia: IP-kapselointi IP:n sisällä (RFC 2003), minimaalinen -3- 110464 kapselointi IP:n sisällä (RFC 2004) ja GRE (Generic Routing Encapsulation, RFC 1701). Usean IP-tunnelointimekanismin toteutusta kutsutaan IP-in-IP-tunneloinniksi. Näitä IP-in-IP-tunnelointimekanismeja voidaan käyttää paitsi Mobile IP:n kanssa myös tilanteissa, joissa on toivottavaa esimerkiksi yhdistää yksityisiä osoitetiloja käyttäviä 5 verkkoja Internetin kautta tai tunneloida monijakeluliikennettä tunnelointia tukemattoman verkon kautta.

Mobile IP:ssä tärkeimpiä huolenaiheita on tietoturva. Internet on luonteeltaan avoin, joten lähetetyt paketit altistuvat turvariskeille. Niitä lisää entisestään liikkuvien solmujen 10 liikkuminen aliverkkojen välillä. Turvariskeihin liittyen kehitettiin IP-turvaprotokolla eli IPsec (esitetty RFC2401:ssä) tuottamaan päästä-päähän-tietoturvaa pakettihyötykuormaa varten IP-terminaalien välisessä siirrossa. Tämä voidaan saavuttaa pääasiassa niin, että terminaaleille tuotetaan pakettien tietosähketasoinen tunnistus ja salaus, tyypillisesti käyttämällä symmetristä salakirjoitustekniikkaa, jossa 15 samoja avaimia on käytettävä molemmissa päissä. Avainten hallintaprotokollalla (esimerkiksi IKE) voidaan luoda symmetriset avaimet käytettäviksi IPsec-pinossa, esimerkiksi samanlaiset, joita käytetään VPN-verkoissa.

IPseciä käyttävä terminaali pitää yllä tietoturvamenettelyä SPD (Security Policy . 20 Database) -tietokannassa, kuten on esitetty esimerkiksi RFC2401 :ssä. SPD tunnistaa, millaista tietoturvaa liikenteeseen sovelletaan; esimerkiksi IPsec-menettely voi edellyttää, että kaikki liikenteessä olevat paketit tunneloidaan ESP (Encapsulating ··· Security Payload) -hyötykuormalla VPN-yhdyskäytävään lukuun ottamatta tiettyjä paketteja, jotka pääsevät läpi ilman IP-käsittelyä. Tässä kuvatun kaltaista . . 25 turvamenettelyesimerkkiä käytetään kaikkiin paketteihin, jotka kulkevat terminaalin solmun läpi. Koska turvamenettely on tyypillisesti staattinen ja konfiguroitu terminaaliin verkko-ohjelmiston asennuksen aikana, eräät yhteysnäkymät tuottavat erityisiä hankaluuksia käytettäessä staattisesti konfiguroitua turvamenettelyä. Asiaa voidaan selventää seuraavalla esimerkillä; jos matkaviestinterminaali vierailee vieraassa ’ 30 verkossa, jossa on IPsec-turvayhdyskäytävä vierailun kohteena olevan verkon ja ‘ ; kotiagentin välillä, ja jos liikkuva solmu käyttää yhteisessä sijainnissa olevaa toista osoitetta (jolloin sen on suoritettava sekä IP-in-IP- että IPsec-tunnelointi), nykyiset :*· IPsec- ja IP-in-IP -toteutukset eivät pysty suorittamaan tarvittavia -4- 110464 matkaviestinterminaalin tunnelointitoimintoja. Tämä johtuu IP-in-IP- ja IPsec-tunneloinnista, kun IP-in-IP-tunneli ei ole uloin muunnos.

Nykyisissä käyttöjärjestelmissä IP-in-IP-tunnelit konfiguroidaan tyypillisesti näennäisinä 5 verkkorajapintoina. Jos liikenteeseen tarvitaan IP-in-IP-tunnelointia, tällöin luodaan reititystaulutietue, joka reitittää liikenteen näennäiseen tunnelointirajapintaan. Koska reititystaulua sovelletaan protokollapinossa IPsec-menettelyn alapuolella, tämän toteutuksen takia IP-in-IP-tunneloinnin on aina oltava ulommainen muunnos paketille. Tämä ei ole kuitenkaan aina toivottava toimenpide. Jos esimerkiksi liikkuva solmu, joka 10 käyttää yhteisessä sijainnissa olevaa toista osoitetta, haluaa AH (Authentication Header- eli tunnistusotsikkotunneli) -tunneloida kaiken liikenteen oletusyhdyskäytävään (yhteysreititin), AH-tunneloinnin tulisi olla ulommainen muunnos ja IP-in-IP-tunneloinnin toiseksi ulommainen muunnos, jotta paketti voidaan elvyttää.

15 Edellä esitetyn valossa keksinnön tavoitteena on tarjota tekniikka, jossa puututaan onnistuneesti aiempien toteutusten puutteisiin, jotka liittyvät IP-tietoturvaan sekä pakettien reititykseen liikkuviin solmuihin ja niistä pois.

YHTEENVETO KEKSINNÖSTÄ , .· 20 : . Lyhyesti'kuvattu ja keksinnön suoritusmuodon sekä siihen liittyvien ominaisuuksien ,·,·. mukainen menetelmä, jossa menetelmäaspektin mukaisesti paketit lähetetään ja vastaanotetaan turvallisessa yhteydessä ensimmäisen ja toisen verkkosolmun välillä. Menetelmän mukaisesti kyseisiä paketteja voidaan siirtää useissa itsenäisissä 25 tietoverkoissa ensimmäisen ja toisen verkkosolmun välisellä polulla, ja ensimmäinen verkkosolmu ja kukin tietoverkko voivat noudattaa eri turvamenettelyjä, jotka määrittävät paketteihin sovellettavia tiettyjä muunnoksia; kyseinen menetelmä on tunnettu siitä, että ensimmäinen verkkosolmu pystyy dynaamisesti muuttamaan turvamenettelyään niin, että paketteihin sovelletaan sopivia muunnoksia turvallisen 30 yhteyden ylläpitämiseksi.

,(t Laiteaspektin mukainen matkaviestinlaite pystyy muodostamaan yhteyden verkon :· kanssa ja siinä on tiedonsiirtoa koskeva turvamenettely, jonka mukaan paketteja • 1 > 110464 1

siirretään matkaviestinlaitteeseen ja siitä pois. Kyseinen tiedonsiirron turvamenettely I

käsittää: I

ensimmäisen muunnossarjan, joka liittyy ensisijaiseen turvamenettelyyn, jota I

sovelletaan siirrettyihin paketteihin I

5 toisen muunnossarjan, joka liittyy toissijaiseen turvamenettelyyn, jota sovelletaan I

i sopivalla tavalla siirrettyihin paketteihin. I

KUVIEN LYHYT ESITTELY I

10 Keksintö sekä siihen liittyvät muut tavoitteet ja edut ovat ehkä helpoimmin ymmärrettävissä viittaamalla seuraavaan kuvaukseen, johon liittyvissä kuvissa:

Kuviossa 1 on esimerkki käyttötavasta, joka ei sovi yhteen aiempien toteutusten kanssa.

15

Kuviossa 2 on esitetty aiempien toteutusten mukainen TCP/IP-pino IPseciä käyttävässä terminaalissa.

Kuviossa 3 on esimerkki käyttötavasta seuraavasta IP-paketista.

20 : ’ Kuviossa 4 on esitetty protokollapino, joka toimii keksinnön erään suoritusmuodon mukaisesti.

Kuviossa 5 on esitetty reititystaulutietueiden käyttö keksinnön erään vaihtoehtoisen : 25 suoritusmuodon mukaisesti.

Kuviossa 6 on esitetty kuvion 5 reititystaulusuoritusmuodon laajennus.

Kuviossa 7a on esitetty IPsec-käsittely lähtevälle liikenteelle keksinnön suoritusmuodon . · · 30 mukaisesti.

’ · · · Kuvio 7b on jatke kuviolle 7a suoritusmuodon mukaisesta lähtevästä liikenteestä.

* > -6- 110464

Kuviossa 8 on esitetty IPsec-käsittely saapuvalle liikenteelle keksinnön suoritusmuodon mukaisesti.

YKSITYISKOHTAINEN KUVAUS KEKSINNÖSTÄ 5

Kuviossa 1 on esitetty esimerkkinä käyttötapa, jota ei voida käyttää perinteisessä staattisessa IP-turvamenettelytoteutuksessa. Selvennyksen vuoksi näin voi käydä esimerkiksi silloin, kun käyttäjä yrittää muodostaa yhteyden yhtiönsä Intranet-verkkoon kannettavalla päätelaitteella muualta kuin toimistosta käsin. Yhteyden on ehkä 10 kuljettava useiden erillisten liityntävyöhykkeiden ja -verkkojen kautta, joista jokainen saattaa noudattaa eri turvamenettelyä. Tällöin paketin käänteiset muunnokset eivät ole yhteensopivia. Päätelaite 100 muodostaa esitetyllä tavalla yhteyden Internetiin 120 Access Zone -vyöhykkeen 1 110 kautta. Tämän seurauksena päätelaitteen 100 ja lähimmän reitittimen PAC1 (Public Access Controller 1) välille muodostuu IPsec AH 15 tunneli 104. AH-tunnelin päätarkoituksena on estää tunnistamattomia käyttäjiä käyttämästä päätelaitteen IP-osoitetta pakettien lähettämiseen Internetiin.

Liikkuva toiminnallisuus voidaan mahdollistaa käyttämällä Mobile IP:tä liityntävyöhykkeiden välisiin tai esimerkiksi WLAN-liityntävyöhykkeen ja langattoman : 20 GPRS-tietoverkon välisiin tukiaseman vaihtoihin. Mobile IP käyttää tyypillisesti IP-in-IP- ;·. tunnelia päätelaitteen nykyisen toisen osoitteen ja kotiagentin (HA) välillä. Kun päätelaite 100 haluaa yhteyden vertaissolmun (CN) tarjoamiin yhtiön tietoihin, tämä tapahtuisi normaalisti VPN-yhdyskäytävän kautta. VPN-yhdyskäytävälle voidaan toteuttaa oma turvamenettely, esimerkiksi IPsec ESP (Encapsulating Security Payload) • · 25 -tunneli päätelaitteen kotiosoitteen 100 ja VPN-yhdyskäytävän välille. Kannettavan päätelaitteen 100 vieraillessa toisessa verkossa tapahtuu tukiaseman vaihto, jossa muodostuu AH-tunneli reitittimen PAC2 (Public Access Controller 2) kanssa. Näin saadaan yhteys yhtiön Intranetiin Access Zone -vyöhykkeen 2 140 kautta vertaissolmuun. IP-paketit, jotka kulkevat CN-vertaissolmun ja liikkuvan solmun välillä, ;tt 30 käyvät läpi useita muunnoksia, jotka noudattavat voimassa olevia useita ; . turvamenettelyjä. Tämän tuloksena voi muodostua sekä IP-in-IP- että IPsec-tunneleita.

Tällöin IP-in-IP-tunneli ei ole ulommainen muunnos, mikä aiheuttaa voi hankaluuksia pakettien elvyttämisessä, kun aikaisemmilla toteutuksilla yritetään purkaa Mobile IP:n

» I

.,,, IP-in-IP-tunnelien kapselointi ennen muita IPsec-kapselointien purkamista.

7 110464

Kuviossa 2 on esitetty aiempien toteutusten mukainen TCP/IP-pino IPseciä käyttävässä terminaalissa. IP-in-IP-tunnelointi on toteutettu näennäisenä ’ verkkolaitteena. Reititystaulutietue voi ohjata lähtevän liikenteen IP-in-IP- 5 tunnelilaitteeseen. Saapuvaa liikennettä varten IP-in-IP-tunnelointi poistetaan ennen kuin paketti luovutetaan IPsec-menettelyyn. IPsec-muunnokset tehdään kuviossa esitetyllä tavalla reitityksen yläpuolella niin, että IP-in-IP-tunnelointimuunnos on aina ulommainen muunnos. Toisin sanoen tuloksena syntyvä IP-in-IP-tunnelointiotsikko on aina ulommainen IP-otsikko, mikä aiheuttaa ongelmia, kun paketti yritetään elvyttää 10 tekemällä muunnokset käänteisesti.

Kuviossa 3 on esitetty esimerkkinä, miltä tuloksena oleva IP-paketti näyttää liikkuvassa solmussa, kun siihen on sovellettu asiaan liittyvien verkkojen erilaisia turvamenettelyjä. Ulommainen muunnos on kuviossa 1 esitetty AH-tunneli 104, joka käsittää IP-otsikon 15 300 päätelaitteen nykyisen toisen osoitteen ja PAC:n välillä. AH-tunnelissa 305 on

Mobile IP:n IP-in-IP-tunneli päätelaitteen nykyisen toisen osoitteen ja kotiagentin (HA) välillä käsittäen IP-otsikon 310. AH-tunneli saattaa käsittää erilaisia prosesseja, esimerkiksi tarkistussumma- ja tunnistuskoodit paketin tietoturvan varmistamiseksi. IP-in-IP-tunnelin sisällä on lisäksi VPN-tunneli päätelaitteen kotiosoitteen ja VPN-; 20 yhdyskäytävän välillä käsittäen IP-otsikon 320. VPN-tunnelissa on alkuperäinen IP- . paketti, joka käsittää otsikon 330 ja hyötykuorman 340, joka siirtyy päätelaitteen ;y kotiverkon ja vertaissolmun välillä. VPN-yhdyskäytävän turvamenettely voi määrittää ESP (Encapsulating Security Payload) -hyötykuorman kaikille vertaissolmusta tuleville paketeille, kuten viitenumero 325 osoittaa. Tämän vuoksi AH-tunneloinnin tulisi 25 välttämättä olla ulommainen muunnos ja IP-in-IP-tunneloinnin toiseksi ulommainen muunnos. Otsikkorakenteesta käy selvästi ilmi, että IP-in-IP-tunnelointimuunnos ei ole ulommainen muunnos, ja näin ollen aiempien toteutusten mukainen TCP/IP-pino ei pysty elvyttämään pakettia kunnolla.

30 Keksinnön mukaisesti edellä mainittu ongelma voidaan korjata tekemällä IP-in-IP-tunnelointi niin, että se on osa IPsec-käsittelyä. Tämä voidaan tehdä toteuttamalla dynaaminen IPsec-strategia, joka sallii useiden turvamenettelyjen soveltamisen, jolloin erilaisia käsittelyjä voidaan soveltaa erilaiseen liikenteeseen. Keksinnön eräässä suoritusmuodossa IPsec-toteutus ylläpitää kahta turvamenettelytietokantaa (SPD): -8- 110464 ensisijaista SPD-tietokantaa VPN:ää ja dynaamista toissijaista SPD-tietokantaa Mobile IP:tä varten.

Kuviossa 4 on esitetty protokollapino, joka toimii keksinnön erään suoritusmuodon 5 mukaisesti. Suoritusmuodon proseduurissa IP-in-IP-tunnelointimuunnos pystytään lisäämään IPseomuunnosten väliin, koska IP-in-IP-tunnelointi toteutetaan toissijaisessa IPsec-menettelyssä eikä osana IP-reititystä. Tällöin käänteiset muunnokset voidaan tehdä oikeassa järjestyksessä. Edullisessa suoritusmuodossa ensisijainen menettely konfiguroidaan niin, että kukin ensisijainen SPD-tietue sisältää 10 lipun, joka määrittää, sovelletaanko toissijaista menettelyä paketteihin. Koska toissijainen menettely on ensisijaisen alapuolella protokollapinossa, tällöin lähtevään liikenteeseen sovelletaan ensisijaista menettelyä ennen toissijaista. Saapuvaan liikenteeseen sovelletaan puolestaan toissijaista menettelyä ennen ensisijaista. Toissijainen menettely voidaan konfiguroida dynaamisesti kannettavan tietokoneen 15 liikkuvalla ohjelmistolla, joka saattaa määrittää esimerkiksi, että liikenne on AH-tunneloitava yhteysreitittimeen nykyisellä liityntävyöhykkeellä. Ensi- ja toissijaisten turvamenettelyjen yläpuolella protokollapinossa toimivat korkeamman tason siirtoprotokollat, esimerkiksi TCP tai UDP (User Datagram Protocol) sekä niiden päällä käytettävät sovellukset.

. 20 • * • · *

Kuviossa 5 on esitetty eräs keksinnön vaihtoehtoinen suoritusmuoto. Siinä .·.· reititystaulua on laajennettu tietueilla, jotka pystyvät välittämään lähtevän paketin ,··· takaisin IPsec-käsittelyyn. Tässä tapauksessa IPsec-menettelyn ensimmäisessä ,,,, ajossa sovelletaan kaikkia staattisia (ensisijaisia) IPsec-muunnoksia, esimerkiksi VPN- 25 muunnosta. Lähtevässä liikenteessä liikkuva ohjelmisto voi dynaamisesti konfiguroida reititystaulun. Tässä suoritusmuodossa liikkuva ohjelmisto voi määrittää IP-in-IP-tunneleita reititystauluun. Taulussa voi olla tietueita, jotka vaativat IPsec-menettelyn ajamista uudelleen. Jos pakettiin sovelletaan IP-in-IP-tunnelointia, silloin IPsec-menettelyn eri säännöt voivat soveltua toisen ajon aikana. IPsec-menettelyn toisessa 30 ajossa sovelletaan kaikkia dynaamisia (toissijaisia) muunnoksia. Saapuvassa liikenteessä käänteiset muunnokset tarkistetaan ja mukautetaan paikalliseen IPsec-; , menettelyyn, ja tällöin tarkistuksessa voidaan ottaa huomioon paikallisen IP-in-IP- tunneloinnin konfigurointi ja reititystaulu.

-9- 110464

Kuviossa 6 on esitetty reititystaulun lisälaajennus kuvion 5 mukaiseen vaihtoehtoiseen suoritusmuotoon. Tässä suoritusmuodossa turvamenettely on jaettu kahteen osaan: ensisijaiseen turvamenettelyyn IPseciä varten ja toissijaiseen menettelyyn liikkuvaa ' ohjelmistoa varten. Loogisesti erotellun toissijaisen menettelyn etu on siinä, että ajon 5 aikaiset muutokset eivät vaaranna ensisijaista menettelyä. Toissijaista menettelyä voidaan soveltaa pakettiin, jos reititystaulu ilmoittaa sen tarpeelliseksi. Tämä voidaan tehdä esimerkiksi attribuutilla, vaikkapa lipulla, joka lisätään reititystaulutietueeseen osoittamaan, että tällainen toimenpide on tarpeen.

10 Keksinnön mukaisesti protokollapinon toiminta tuottaa tulokseksi erilaisia proseduureja lähtevien ja saapuvien IP-pakettien käsittelyyn lähtöverkon ja sovelluksen näkökulmasta.

Lähtevä käsittely 15

Kuviossa 7a on esitetty IPsec-käsittely lähtevälle liikenteelle keksinnön suoritusmuodon mukaisesti. Esimerkkipaketti saapuu lähdesovelluksesta siirtoprotokollan, esimerkiksi TCP:n kautta vaiheessa 700 esitetyllä tavalla. Vaiheessa 702 toiminta alkaa vaadittavien muunnosten etsimisellä ensisijaisesta lähtevästä SPD-tietokannasta. Kun , ,· 20 etsintä on suoritettu, tämän jälkeen määritetään, tarvitaanko IPSec-käsittelyä, vaiheessa 704 esitetyllä tavalla. Jos ensisijaisia muunnoksia ei tarvita, paketti tarkistetaan ja määritetään, vaatiiko toissijainen menettely käsittelyn vaiheessa 724. ‘.! Jos osumia ei löydy tai jos menettely vaatii paketin pudottamista, paketti hylätään tässä kohtaa vaiheessa 708. Jos löytyy SPD-osuma, joka vaatii IPsec-käsittelyn, lähtevässä , . 25 SAD (Security Association Database)-tietokannassa suoritetaan haku vaiheessa 710.

SPD (Security Policy Database) -tietokanta sisältää menettelyjä, jotka määrittävät, miten tietyt paketit on käsiteltävä. SAD-tietokannan turvakäytännöt sisältävät parametrit, joita tarvitaan menettelyn sanelemien toimintojen suorittamiseen. 30 Esimerkkiparametrit sisältävät erilaisia kohteita, esimerkiksi salaus- ja > ' * tunnistusavaimia. Turvakäytännöt merkitään kokonaislukutunnisteella, jota kutsutaan t ·

;' ” SPI (Security Parameter Index) -indeksiksi. Tämä numero sisältyy IPsec-otsikoihin (AH

t > » ; · ja ESP), ja sen avulla tehdään haku SAD-tietokannasta lähtevien pakettien I/ käsittelyssä, jolloin (lähtevässä käsittelyssä) sopivaa turvakäytäntöä (SA) etsitään -10- 110464 vastaavan turvamenettelyn perusteella. Tyypillisesti avaimenhallintaprotokolla, esimerkiksi IKE (Internet Key Exchange), joka on IPsecin avaimenhallinnan vakioprotokolla, luo turvakäytännöt dynaamisesti. Turvakäytäntö vaaditaan aina, ennen kuin IPsec-muunnosta voidaan soveltaa. IP-in-IP-muunnoksissa ei tarvita avaimia, SPI-5 indeksejä tai muita parametreja, eli näihin muunnoksiin ei tarvita SAD-tietuetta, jos ne toteutetaan IPsec-menettelyssä.

Vaiheessa 712 tehdään tarkistus, jolla määritetään, löytyykö SAD-tietokannasta osumaa. Jos osuma löytyy, IPsec suorittaa turvamenettelyssä määritetyn IPsec-10 muunnoksen käyttämällä turvakäytännön parametreja vaiheessa 718 esitetyllä tavalla. Jos SAD:sta ei löydy osumaa, turvakäytäntö (Security Association eli SA) luodaan avaimenhallintakokonaisuudella, esimerkiksi IKE-protokollalla, vaiheessa 714 esitetyllä tavalla. Jos SA-turvakäytännön luominen epäonnistui tarkistuksen jälkeen vaiheessa 716, paketti hylätään vaiheessa 720 esitetyllä tavalla. Jos SA-turvakäytännön luominen 15 onnistuu, muunnos voidaan aloittaa vaiheessa 718. Koska turvakäytäntöjä ei tarvita IP-in-IP-kapseloinnin purkamismuunnoksiin, SAD-hakua (vaihe 710) ei välttämättä tarvita SPD-tietueisiin, jotka määrittävät IP-in-IP-muunnokset. Kun tällainen menettely löytyy vaiheessa 704, toiminto voi suoraan edetä vaiheeseen 718 ja muunnos voidaan suorittaa. Vaihtoehtoisesti toteutus voi käyttää "täyteturvakäytäntöjä" IP-in-IP-. ,· 20 muunnoksiin, jolloin IPsec- ja IP-in-IP-käsittelyt ovat samanlaiset. Ensisijainen SPD

i määrittää tyypillisesti vain varsinaisia IPsec-muunnoksia, ei IP-in-IP-muunnoksia. ,·,· Vaiheessa 722 tehdään tarkistus lisämuunnosten tarpeen selvittämiseksi. Jos lisämuunnoksia tarvitaan, SAD-haku toistetaan vaiheessa 710. Kun kaikkia ensisijaisia muunnoksia on sovellettu, tämän jälkeen tarkistetaan, vaatiiko ensisijainen menettely , , 25 toissijaisen menettelyn käsittelyä vaiheessa 724 esitetyllä tavalla.

Kuvio 7b on jatkoa kuvioon 7a, ja siinä toissijaisen käsittelyn osalta tarkistettu paketti välitetään vaiheessa 746 liikkuvaan solmuun, mikäli toissijaista käsittelyä ei tarvita. Jos toissijainen käsittely tarvitaan, toissijaisessa SPD-tietokannassa tehdään haku ] 30 vaiheessa 726. Jos osumia ei löydy tai toissijainen menettely vaatii pudottamaan ‘ ·· paketin, paketti hylätään vaiheessa 730. Jos osuma löytyy, suoritetaan haku lähtevästä SAD-tietokannasta vaiheessa 732. Joskus saattaa käydä niin, että toissijainen SPD-*:* tietue vastaa hakua mutta ei vaadi käsittelyä. Tätä tapausta ei ole kuitenkaan esitetty it|/ yksikäsitteisesti. Tässä tapauksessa paketti välitetään vaiheeseen 746. Kuten - 11 - 110464 ensisijaisessa SPD-käsittelyssä, IP-in-IP-muunnoksiin ei tarvita turvakäytäntöä, ja näin ollen nämä muunnokset voidaan tehdä ilman SAD-tietokantahakua. IPsec-muunnoksissa tehdään aina tarkistus, jonka avulla määritetään, löytyikö lähtevästä SAD-tietokannasta osumaa vaiheessa 734. Muunnos suoritetaan vaiheessa 742. Jos 5 lähtevästä SAD:sta ei löydy osumaa, turvakäytäntö (Security Association eli SA) luodaan avaimenhallintakokonaisuudella vaiheessa 736 esitetyllä tavalla. Jos SA-turvakäytännön luominen epäonnistui tarkistuksen jälkeen (vaiheessa 738), paketti hylätään vaiheessa 740. Jos SA-turvakäytännön luominen onnistuu, IPsec-muunnos pääsee alkuun vaiheessa 742. Vaiheessa 744 tarkistetaan, tarvitaanko lisää 10 toissijaisen menettelyn tekemiä muunnoksia. Jos muunnoksia tarvitaan, toiminto palaa vaiheeseen 732. Jos muunnoksia ei tarvita lisää, paketti siirretään verkkoon vaiheessa 746 esitetyllä tavalla.

Keksinnön suoritusmuodossa IPsec-toteutukselle annetaan lupa suorittaa IP-in-IP-15 tunnelointi, kun taas aiemmissa toteutuksissa IPsec ei suorita IP-in-IP-tunnelointia. Ensisijaisen SPD:n tietueisiin on lisätty lippu, joka osoittaa, tarvitaanko toissijaista IPsec-käsittelyä paketeille, jotka vastaavat ensisijaisen SPD:n tietuetta. Kun lippu lisätään, IPsec-toteutus etenee toissijaisella käsittelyllä sen jälkeen, kun kaikki ensisijaisen SPD:n vaatimat IPsec-muunnokset on tehty. Jos lippua ei lisätä, . .* 20 toissijaista IPsec-käsittelyä ei tehdä. Tällöin IPsec-käsittely on samanlainen kuin • t » aiempien toteutusten mukainen käsittelytoiminta. Jos toissijainen IPsec-käsittely ,·,· tarvitaan, tällöin IPsec-toteutus suorittaa IPsec-muunnokset toissijaisen SPD:n , · * vaatimalla tavalla.

25 Saapuva käsittely

Kuviossa 8 on esitetty IPsec-käsittely saapuvalle liikenteelle keksinnön mukaisesti. Vaiheessa 800 on esitetty verkosta vastaanotettu paketti. Vaiheessa 805 ulommaisesta otsikosta tarkistetaan, onko se IP-in-IP- tai IPsec-otsikko. Jos ulommainen otsikko ei 30 ole IP-in-IP- tai IPsec-otsikko, käsittely jatkuu vaiheessa 830. Jos ulommainen otsikko ' · on IP-in-IP- tai IPsec-otsikko, SAD:sta haetaan turvakäytäntöä vaiheessa 807. SAD- :<t haku vaaditaan aina, kun muunnos on IPsec-muunnos (AH tai ESP). IP-in-IP- muunnoksissa turvakäytäntöjä ei välttämättä tarvita, joskin toteutus saattaa käyttää ,, ’"täyteturvakäytäntöä", jotta käsittely olisi samanlainen IPsec- ja IP-in-IP-muunnoksissa.

• I i 110464 - 12-

Vaiheessa 810 tehdään tarkistus, jotta saataisiin selville, löytyykö osumia. Jos osumia ei löydy, paketti hylätään vaiheessa 815 osoitetulla tavalla. Jos osuma löytyy, IPsec suorittaa muunnoksen vaiheessa 820, ja samalla käytetyt turvakäytännöt (tai IP-in-IP-muunnokset, jotka tehdään ilman turvakäytäntöjä) ja niiden soveltamisjärjestys 5 pannaan merkille. Vaiheessa 805 tarkistetaan, onko IPsec- ja/tai IP-in-lP-otsikoita jäljellä. Jos on, vaiheen 807 saapuva SAD-haku toistetaan. Jos otsikoita ei ole jäljellä, ensisijainen saapuva SPD tarkistetaan vaiheessa 830, jotta voitaisiin määrittää, onko tarvittavia muunnoksia sovellettu. Tämä vaihe on esitetty vaiheessa 835. Jos vastaavaa menettelyä ei löydy, paketti hylätään vaiheessa 840 osoitetulla tavalla. Jos 10 vastaavuus löytyy, vaiheessa 845 tehdään tarkistus, jotta voitaisiin määrittää, vastaako nykyinen ensisijainen SPD-tietue sovellettua käsittelyä kokonaan tai osittain. Jos nykyinen ensisijainen SPD-tietue vastaa sovellettua käsittelyä kokonaan ja jos se ei vaadi toissijaista menettelyä, paketti lähetetään tarkistukseen, jossa määritetään kohdeterminaali, vaiheessa 860.

15

Jos nykyinen ensisijainen saapuva SPD-tietue vastaa sovellettua käsittelyä kokonaan tai osittain sekä vaatii toissijaisen menettelyn käyttöä, toissijaiseen saapuvaan SPD-tietokantaan tehdään haku, jotta voitaisiin määrittää, onko olemassa toissijaista saapuva SPD-tietuetta, joka vastaa sovellettua käsittelyä muilta osin, vaiheessa 850 20 esitetyllä tavalla. Jos ensisijaisen menettelyn tietue vastaa jo nykyisellään sovellettua käsittelyä kokonaan, tällöin on pakko olla myös toissijainen menettely, joka ei vaadi muunnoksia. Vaiheessa 855 tehdään tarkistus, jotta voitaisiin määrittää, vastaako sovellettu käsittely muilta osin toissijaista SPD-tietuetta. Jos vastaavaa toissijaista • j menettelyä ei löydy, ensisijainen saapuva SPD tarkistetaan jälleen vaiheessa 830.

25 Ensisijaisen saapuvan SPD:n tarkistaminen jatkuu seuraavasta tarkistamattomasta menettelystä.

Keksinnön suoritusmuodon mukaisesti toimiva saapuva käsittely suorittaa käänteiset , , : IPsec- ja IP-in-IP-muunnokset, jotka se havaitsee pakettien otsikoissa, SAD:n 30 parametrien mukaisesti. Vaihtoehtoisesti toteutus voi suorittaa IP-in-IP-muunnoksia ilman vastaavaa SAD-tietuetta. Keksinnön mukaisesti IP-in-lP-tunnelointi on sallittu muunnos, toisin kuin aiemmissa toteutuksissa. Kun kaikki IP-in-IP- ja IPsec-otsikot on käsitelty, IPsec-toteutukset tarkistavat, että paketti vastaa SPD:tä. Tämän jälkeen -13- 110464 ensisijainen menettely tarkistetaan, ja tietueista tarkistetaan, vastaavatko ne sovellettua käsittelyä.

Jos ensisijaisen SPD.n tietue vastaa sovellettua käsittelyä ja tietue ei vaadi toissijaista 5 menettelyä, tällöin IPsec-toteutus luovuttaa paketin ylempiin protokollakerroksiin tai välittää sen.

Toisaalta jos ensisijaisen SPD:n tietue vastaa sovellettua käsittelyä kokonaan ja tietue vaatii toissijaisen menettelyn, tällöin IPsec-toteutus tarkistaa, onko olemassa 10 toissijaista menettelyä, joka ei vaadi käsittelyä. Jos ensisijaisen SPD:n tietue vastaa sovellettua käsittelyä osittain ja tietue vaatii toissijaisen menettelyn, IPsec-toteutus tarkistaa, onko olemassa toissijaista menettelyä, joka vastaa sovellettua menettelyä muilta osin, toisin sanoen sitä osuutta, jota ensisijainen SPD-tietue ei kata. Jos toissijaisesta SPDistä löytyy osuma, IPsec-toteutus luovuttaa tämän jälkeen paketin 15 ylempiin protokollakerroksiin tai välittää sen. Jos vastaavaa toissijaista menettelyä ei löydy, IPsec-toteutus jatkaa ensisijaisen SPD:n kääntämistä.

On syytä huomata, että suoritusmuodossa kuvatut ensi- ja toissijaiset turvamenettelytietokannat (SPD) ovat käsittellisiä tietorakenteita. Alan asiantuntijat : 20 tietävät, että varsinaisen toteutuksen ei välttämättä tarvitse sisältää kahta erillistä : ’ ·.. tietokantaa vaan ne voivat käyttää yhtä tietokantaa, jonka tietueet sisältävät esimerkiksi ;y; SPD-indeksikentän, joka osoittaa, kuuluuko tietue ensi- vai toissijaiseen SPD:hen.

Tällainen toteutus voidaan yleistää tukemaan useampaa kuin kahta SPD:tä edellyttäen esimerkiksi, että indeksin arvot ovat muut kuin 1 ja 2. Lisäksi IPsec-toteutus voisi ·. 25 rekursiivisesti soveltaa SPD-tietueita nousevalla indeksillä.

Vaikka esillä olevaa keksintöä on kuvattu joiltakin osin viitaten sen tiettyyn suoritusmuotoon, alan asiantuntijat ymmärtävät siihen liittyvät variaatiot ja muunnelmat.

. . Siksi seuraavien patenttivaatimusten tulkintaa ei tule rajoittaa, vaan niihin tulee lukea !,.' 30 mukaan variaatiot ja muunnelmat, jotka on johdettu esillä olevasta keksinnön aiheesta.

Claims (18)

1. Menetelmä, jossa paketit lähetetään ja vastaanotetaan turvallisessa yhteydessä ensimmäisen ja toisen verkkosolmun välillä. Menetelmän mukaisesti kyseisiä 5 paketteja voidaan siirtää useissa itsenäisissä tietoverkoissa ensimmäisen ja toisen verkkosolmun välisellä polulla, ja ensimmäinen verkkosolmu ja kukin tietoverkko voivat noudattaa eri turvamenettelyjä, jotka määrittävät paketteihin sovellettavia tiettyjä muunnoksia; kyseinen menetelmä on tunnettu siitä, että ensimmäinen verkkosolmu pystyy dynaamisesti muuttamaan turvamenettelyään 10 niin, että paketteihin sovelletaan sopivaa muunnosta turvallisen yhteyden ylläpitämiseksi.

2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että ensimmäinen verkkosolmu on liikkuva verkkosolmu ja toinen verkkosolmu on lähtösolmu; 15 menetelmässä liikkuva verkkosolmu sisältää SPD (Security Policy Database) - tietokannan, jonka käsittämiä erilaisia turvamenettelyjä voidaan dynamisesti soveltaa yhteyden kautta kulkeviin paketteihin.

3. Minkä tahansa edeltävän patenttivaatimuksen mukainen menetelmä, tunnettu 20 siitä, että ensimmäisen verkkosolmun turvamenettely käsittää ensi- ja toissijaisen SPD:n; tällöin ensisijainen SPD sisältää tietueita ensisijaisen turvamenettelyn mukaisiin muunnoksiin ja toissijainen SPD sisältää tietueita - toissijaisen turvamenettelyn mukaisiin muunnoksiin.

4. Minkä tahansa edeltävän patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että ensisijaisen SPD:n tietueisiin lisätään attribuutti, joka osoittaa, että toissijaista turvamenettelyä on käytettävä, voidaan käyttää tai ei saa käyttää paketteihin.

5. Minkä tahansa edeltävän patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että ensisijainen SPD sisältää tietueita "sisäisiä" muunnoksia (sisäisiä ... otsikoita) varten ja toissijainen SPD sisältää tietueita "ulkoisia" muunnoksia ’·' varten, ja lähteviin paketteihin suoritetaan sisäisiä muunnoksia ennen ulkoisia ja saapuvaan liikenteeseen päinvastoin. „ 110464

6. Minkä tahansa edeltävän patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että toissijainen menetelmä määrittää lisämuunnoksia, kun lähtevään liikenteeseen on sovellettu kaikkia ensisijaisen menettelyn muunnoksia. 5

7. Menetelmä, jossa saapuva liikenne käsitellään käänteisessä järjestyksessä vaatimukseen 6 verrattuna.

8. Minkä tahansa edeltävän patenttivaatimuksen mukainen menetelmä, tunnettu 10 siitä, että ensi- ja toissijaiset menettelyt voidaan konfiguroida itsenäisesti ja yhtä aikaa, jolloin menettelyjen muokkaaminen voidaan rajoittaa vain toiseen tai molempiin.

9. Minkä tahansa edeltävän patenttivaatimuksen mukainen menetelmä, tunnettu 15 siitä, että ensisijainen turvamenettely pysyy muuttumattomana ja toissijainen turvamenettely konfiguroidaan niin, että sitä sovelletaan valikoiden tiettyihin paketteihin.

10. Minkä tahansa edeltävän patenttivaatimuksen mukainen menetelmä, tunnettu 20 siitä, että muunnostoiminnot sisältävät paketin muunnoksia, esimerkiksi protokollaotsikoiden tai vaihtoehtojen lisäämistä ja poistamista, pakettien ;’· kapselointia ja kapseloinnin purkamista uusien pakettien sisällä, pakettien tai niiden osien salausta ja salauksen purkamista tai pakettien tai niiden osien pakkaamista ja pakkauksen purkamista. • 25

11. Patenttivaatimuksen 10 mukainen menetelmä, tunnettu siitä, että muunnostoiminnot sisältävät siirtotilamuunnoksia, joissa käytetään AH (Authentication Header) -tunnistusotsikkoa ja ESP (Encapsulating Security ·_ . Payload) -hyötykuormaa, sekä IP-in-IP-tunneleiden, AH-tunneleiden ja ESP- l.. ’ 30 tunneleiden kapselointia ja kapseloinnin purkamista.

12. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, että liikkuva ·’ · verkkosolmu muodostaa verkkoyhteyden käyttämällä esimerkiksi Mobile IP:tä ,··· paikallisesti määritellyn Access Zone -vyöhykkeen kanssa muodostettavan -16- 110464 yhteyden kautta; tällöin Access Zone -vyöhyke tukee verkkovierailua vaihtamalla yhteyden toiseen Access Zone -vyöhykkeeseen.

13. Minkä tahansa edeltävän patenttivaatimuksen mukainen menetelmä, tunnettu 5 siitä, että itsenäisiin verkkoihin sisältyy Internet, paikalliset Intranetit, kotiverkot, paikalliset Access Zone -vyöhykkeet ja tietoliikenneverkot, esimerkiksi langattomat ja ei-langattomat verkot.

14. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että verkkojen (tai 10 solmujen) turvamenettelyt koskevat paketteihin tehtäviä erityisiä muunnoksia, kun paketit siirretään verkojen (tai solmujen) läpi; menetelmässä paketteihin sovellettavat sopivat muunnokset perustuvat kyseisiin muunnoksiin, joita on sovellettu niin, että kyseiset muunnokset käännetään käytännössä niin, että paketin hyötykuormatiedot voidaan elvyttää. 15

15. Matkaviestinlaite, joka pystyy muodostamaan yhteyden verkon kanssa ja jossa on tiedonsiirtoa koskeva turvamenettely, jonka mukaan paketteja siirretään matkaviestinlaitteeseen sekä siitä pois. Tiedonsiirron turvamenettely käsittää: ensimmäisen muunnossahan, joka liittyy ensisijaiseen turvamenettelyyn, : ; *: 20 jotka sovelletaan siirrettyihin paketteihin ·*·. toisen muunnossahan, joka liittyy toissijaiseen turvamenettelyyn, jota ;; ‘ · sovelletaan sopivalla tavalla ja valikoiden tiettyihin paketteihin.

.... 16. Patenttivaatimuksen 15 mukainen matkaviestinlaite, jossa ensisijainen .· · 25 turvamenettely on sellainen, joka määrittää tiettyjen pakettien käsittelyn, ja toissijainen turvamenetely on sellainen, joka määrittää tiettyjen muiden pakettien käsittelyn.

. . 17. Patenttivaatimuksen 15 mukainen matkaviestinlaite, jossa ensisijaisen 30 turvamenettelyn muunnostietueet sisältävät attribuutin, esimerkiksi, mutta siihen ” . rajoittumatta, lippuosan, joka osoittaa, että toissijaista turvamenettelyä on :. käytettävä, voidaan käyttää tai ei saa käyttää paketteihin. - 17- 110464

18. Patenttivaatimuksen 15 mukainen matkaviestinlaite, jossa matkaviestinlaitteen yhteys Internetiin siirtää paketit siirtokerroksen, esimerkiksi TCP.n tai UDP:n päällä. 110464 -18-