NO317294B1 - Sømløs Ip-mobilitet på tvers av sikkerhetsgrenser - Google Patents

Description

Foreliggende oppfinnelse angår området IP-mobilitet på tvers av sikkerhetsgrenser mellom domener. Spesielt angår foreliggende oppfinnelse en ny arkitektur dannet av kjente nettverksinfrastrukturkomponenter sammen med klientdatamaskinprogram på en brukerinnretning som gir nye muligheter.

Den store familien av IP-protokoller danner grunnlaget for utviklingen av Internet. I dag er Internet basert på versjon 4 av protokollfamilien (Ipv4). I fremtiden forventes det at den gradvis vil bli erstattet av versjon 6 av protokollfamilien (IPv6).

IP-mobilitet er en utvidelse som har vunnet interesse i de senere år. Forskjellige IP-mobilitetsprotokollforslag foreligger både for IPv4 og IPv6. Å gjøre Internet mobilt har innlysende fordeler sammenlignet med de nedarvede mobilnett som i hovedsak kun er skreddersydd for talekommunikasjon. Sømløs IP-mobilitet angår det tilfellet når brukerapplikasjonen er transparent for nettverksendringer. Dette står i kontrast mot ordinær IP når applikasjonssesjonen bryter opp hvis brukeren endrer sitt tilknytningspunkt til nettet. Dagens fremherskende IP-mobilitetsteknologi er Mobil IP, som angitt i dokumentet IETF RFC3220, med tittelen "IP-mobility support for IPv4", som faktisk eksisterer for både versjon 4 og versjon 6 av IP-protokollfamilien.

Nøkkelelementene i et mobil-IP-system er en mobil-IP-klientprogramvare på brukerterminalen og en mobil-IP-hjemmeagent (HA) i nettverksinfrastrukturen. Terminalen med klientprogramvaren bli vanligvis referert til som en mobilnode (MN). Hjemmeagenten styrer mobilnodens topologiske korrekte adresse (kalt hjemmeadressen) og vedlikeholder en bindingsliste med mobilnodens aktuelle lokalisering (kalt c/o-adresse). Mobilnoden signalerer til hjemmeagenten sin aktuelle c/o-adresse. Dette skjer enten direkte, eller et valg via en mellomliggende fremmedagent (FA) hvis en slik eksisterer i lokalmiljøet. Hjemmeagenten setter opp en foroverrettet tunnel for å omdirigere trafikk fra den topologisk korrekte hjemmeadressen til den aktuelle c/o-adressen. Tunnelen oppstår fra pakkeinnkapsling som blir utført av hjemmeagenten. I denne sammenheng blir en vert som ikke er mobil omtalt som en korrespondentnode (CN).

Sømløs IP-mobilitet finner sin viktigste anvendelse sammen med fjernaksess-IP-sikkerhetsløsninger, slik som IPSec VPN, som omtalt i kjente IPSec-standarder. En fjernaksess-VPN-løsning består av en VPN-klient i brukerterminalen og VPN-gateway (VPNGW) i infrastrukturen. Sammen benytter VPN-klienten og den nevnte gateway begge tunnelering og kryptering for å opprettholde kommunikasjon fra et sikkert domene til en terminal som er fjemforbundet fra en usikker plassering i et annet domene. VPN-løsningen er vanligvis det eneste vis på hvilket komponenter innenfor det sikre domene kan nås.

Teknikkens stand i dag bruker brekkstangprinsippet på versjon 4 av protokollfamilien som blir anvendt på Internet og å kombinere mobil-IP med IPSec VPN som således muliggjør første generasjonsarkitekturen for sømløs og sikker IP-mobilitet. Den mest fremtredende anvendelsen er forTetningsdirftsmiljøet i hvilket et Intranett representerer det sikre domenet og Internet representerer det usikre domenet. Denne kombinasjonens potensialet er stort fordi den gir mindre ekstraarbeid for "nomade"-arbeidere og forbedret produktivitet når disse er på reise. Den mest utfordrende delen av den kombinerte arkitekturen er å opprettholde sømløs drift også på tvers av sikkerhetsbarrieren mellom bedriftsenhetene og verden utenfor. Enhver applikasjon som blir startet av en bruker mens denne er forbundet med sitt Intranett bør overleve også når brukeren forflytter seg utenfor dette. Samtidig må VPN-løsningen bli nyttiggjort mens brukeren befinner seg på utsiden. Innenfor det sikre domenet bør VPN-løsningen være avslått.

I patentsøknadsdokumentet US202/0194385 beskrives en VPN-grensesmttrnodul som undersøker den mobile noden for tilgjengelige fysiske grensesnitt som linker seg til den den har oppslagstavler for adresser og kan således finne ut om den befinner seg i et indre hjemmeområde, slik at den overtar funksjonen til HA (hjemmeagenten). Tunnelering vil da ikke bli benyttet.

I et "Internettdraft" fra organisasjonen IETF, med tittelen "Mobile IPV4 Traversal Across VPN or NAT and VPN Gateways, publisert på Internettadressen http:// www. ietf. org/ intemet- dratfs/ draft- a^ fremlegges et utkast til drøfting i IETF-organisasjonen, som tilhører "mobil-IP-arbeidsgruppen. Side 9 i denne publikasjonen viser den kjente teknikken med VPN-gateway og MIP-proxy i en DMZ, og ytre og indre brannmur. På side 10 beskrives konfigurering av MN og Mip proxy og gateway's eksterne VPN-adresse. MN skal kunne sammenligne tabeller av adresseblokker for å finne ut når den er utenfor det indre nettet.

Dette dokument beskriver en ny arkitektur sammen med korresponderende klientprogramvare som kan anvendes for å løse problemet med åpen og sømløs IP-mobilitet på tvers av sikkerhetsbarrierer. Den foreslåtte fremgangsmåte er generell og har bedre karakteristika enn nåværende kjente alternativer.

I dette dokumentet brukes begrepet arkitektur for å angi en kombinert struktur som innbefatter både en mobil-IP-del og VPN-del. Mobil-IP-delen blir selv omtalt som et system. VPN-delen omtales derimot som en løsning. Denne forklaring er gitt for at man skal forstå at disse begrepene kunne ha vært benyttet på omvendt måte.

En VPN-løsning og et mobil-IP-system krever begge klientprogram på mobilnoden. Begrepet klientprogram anvendes generelt hvis den bestemte betydning fremgår klart fra sammenhengen. Ellers tilføyes tilleggsordene "mobilitet" og "sikkerhet" for å skille klientprogramdelene.

For å gi en bedre forståelse av oppfinnelsens bakgrunn vil nå kjente arkitekturer og deres assosierte egenskaper bli forklart i sammenheng med vedfølgende tegninger som skildrer kjent teknikk, hvor:

Figur 1 er et skjematisk representasjonseksempel av et kjent mobil-IP-system.

Figur 2 er en skjematisk representasjon av et annet eksempel av et kjent mobil-IP-system. Figur 3 er en skjematisk fremstilling av et ytterligere eksempel av et kjent mobil-IP-system. Figur 4 er en skjematisk fremstilling av nok et eksempel av et kjent mobil-IP-system. Figur 5 er en skjematisk lagmodellfremstilling av et eksempel på et kjent klient- og nettverksadapterarrangement i en mobil-IP-dataterminal. Figur 6 er en skjematisk lagmodellfremstilling av et ytterligere eksempel på et kjent klient- og nettverksadapterarrangement i en mobil-IP-dataterminal.

Som antydet ved figurene 1 og 2 foreligger i utgangspunktet to motstående måter på hvilke det kan utplasseres et mobil-IP-system sammen med en VPN-løsning for å realisere en kombinert arkitektur. Begge arkitekturene er velkjente for standardiseringsmyndighetene, så vel som generelt i industrien. Utgangspunktet er i begge tilfeller et sikkert domene 105 som er adskilt fra et usikkert domene 107 ved hjelp av en sikkerhetsgateway 104. Denne gateway definerer grenselinjen mellom domenene, og den indre side korresponderer med den sikre siden. For enkelthets skyld kan leseren tenke seg et bedriftsnett (sikkert indre domene) som er forbundet med Internet (usikkert ytre domene). Det sikre domenet innbefatter et eller flere IP-nett under den samme administrative styring. Det sikre domenet omtales også som de assosierte brukernes hjemmedomene. Det usikre domenet innbefatter IP-nett som er styrt av forskjellige administrative enheter. Sikkerhetsgatewayen (eventuelt brannmur) er ansvarlig for pakkefiltrering så vel som fjernaksess utenfra til det sikre domenet. For domenene i de vedfølgende tegninger angir således en jevn grå tone et sikkert domene med sine bestanddeler.

I figur 1 er mobil-IP-hjemmeagenten 102 lokalisert utenfor det sikre domenet som for eksempel i den demilitariserte sonen 106 i et bedriftsmiljø. Mobil-IP-systemet arbeider i dette tilfellet utenfor det sikre domenet og dets rolle er å mobilisere VPN-løsningen. Systemet tilbyr en fast adresse for VPN-tunnelendepunktet slik at VPN-tunnelen opprettholdes på tross av nettverksendringer skapt av mobilnoden 103. De krypterte VPN-pakkene transporteres som nyttelast i mobil-IP-systemet og VPN-løsningen omtales da som overlagret. Dette illustreres i figur 1, ved at VPN-tunnelen 123 omsluttes av mobil-IP-tunnelen 124. Den "innfødte" trafikken 125 som er rettet mot den korresponderende noden 101 på utsiden blir tydelig i det sikre domenet etter dekapsulering fra VPN-tunnelen. Mobil-IP-komponenten 102 og 103 er i dette tilfellet trukket med et skravert gråhvitt mønster for å angi at disse komponentene er assosiert med det sikre domenet (vist i grått) men ellers arbeider i et usikkert miljø (angitt ved hvitt).

I figur 2 er hjemmeagenten 102 lokalisert innenfor det sikrede domenet 105. Mobil-IP-systemet arbeider i dette tilfellet på innsiden, og kan kun nås fra utsiden over VPN-løsningen. Hjemmeagenten er derfor tegnet inn i figuren med en jevn grå farge. VPN-tunnelen 123 omslutter nå mobil-IP-tunnelen 124, som svarer til den motsatte sekvens av det som er vist i figur 1.

Arkitekturen som er vist i figur 2 har imidlertid den ulempen at det fjerntliggende VPN-tunnelendepunktet hos mobilnoden 103 vil endre seg for hver nettverksendring. Følgelig må VPN-tunnelen 123 bli gjenetablert ved hver overlevering. Dette vil i sin tur kreve gjenetablering også av mobil-IP-tunnelen. På den annen side er det også enkelte ulemper med den arkitekturen som er vist i figur 1. For det første, fordi hjemmeagenten 102 er utplassert på utsiden, har mobilens hjemmeadresse ikke tilhørighet i det sikre domenet 105. Som følge av dette må brukeren anvende sin VPN-løsning fra alle sine lokaliseringer, også når brukeren befinner seg innenfor brukerens ellers sikre hjemmedomene. Av samme årsak vil det sikre domenets trafikk til enhver annen korresponderende node 101 som befinner seg på innsiden gå i sløyfe via hjemmeagenten 102 på utsiden når mobilnoden befinner seg på innsiden. Begge disse virkninger er uønskede etter som de påfører en ekstra ytelsesbelastning. Endelig foreligger også en mulig sikkerhetsrisiko etter som hjemmeagenten 102 må sette opp dynamiske videreformidlingstunneler gjennom brannmuren 104 til vilkårlige mobilnoder som befinner seg på innsiden av det sikre domenet. Normalt tillates kun en tunnel gjennom en brannmur hvis begge endepunkter er statiske, og hvis trafikken gjennom tunnelen er gjenstand for kryptering i begge retninger.

For å overvinne de her nevnte ulemper er det mulig å danne hybridarkitekturer som kombinerer karakteristika fra de arkitekturer som er vist i figurene 1 og 2. I figurene 3 og 4 illustreres to forskjellige tilnærminger til problemet. Den arkitekturen som er vist i figur 3 tilsvarer kjernetilnærmingen hos enkelte leverandørbestemte tilbud som er tilgjengelige for industrimarkedet. På det nåværende tidspunkt er den arkitekturen som er vist i figur 1 foreslått for standardisering for å legge til dette for implementeringer fra flere leverandører. Imidlertid er realiseringer av den arkitekturen som er vist i figur 4 for tiden ikke tilgjengelig fra noen leverandør, men forventes å bli tilgjengelig i den nærmeste fremtid.

I figur 3 er hjemmeagenten 102 og VPN-gatewayen 104 implementert i en enkelt enhet. Hjemmeagenten er i dette tilfellet tegnet til dels i jevnt grått og til dels i et skravert mønster for å angi at den tilhører det sikre domenet, men også samtidig er tilgjengelig fra utsiden uten bruk av VPN-løsninger. Arbeidsmodellen er hovedsakelig den samme som den som er vist i figur 2, men arkitekturen i figur 3 har ikke de samme ulemper. På den annen side gir enkeltenhetsløsningen 102 begrenset fleksibilitet og skalerbarhet etter som hjemmeagentkomponentene og VPN-komponentene alltid er samlokaliserte. Den realitet at begge komponentene må være tilveiebrakt av den samme leverandøren representerer også en ulempe. Mange bedrifter har allerede foretatt investeringen i enten mobil-IP eller VPN-komponenter, og en integrert enkeltenhetsløsning er for disse bedrifter et hinder for å få avkastning fra sine tidligere investeringer.

Den arkitektur som er vist i figur 4 er grunnlagt på de samme prinsipper som gjelder for figur 3, men er implementert som en flerenhetsløsning. Enkeltenhetsløsningen er her erstattet av tre komponenter: Den indre hjemmeagenten 102, VPN-gatewayen 104 og en proxyagent 108. Proxyagenten er lokalisert i en demilitarisert sone 106 utenfor det sikre domenet, og svarer i utgangspunktet til en hjemmeagent og en mobilnode som er implementert i den samme enheten. Proxyagentens rolle er å være en mellomliggende formidler for signalering og pakkeformidling mellom den virkelige mobilnoden 103 og den indre hjemmeagenten 102. Proxyagentens hensikt er å håndtere signalering og pakkeformidling på en sikker måte ved å arbeide i harmoni med VPN-gatewayen og den indre hjemmeagenten. Proxyagenten må være lokalisert i en DMZ etter som den må beskyttes av den omgivende brannmurens vernekriterier. Proxyagenten 108 er til dels tegnet med jevn grå farge og til dels i et skravert mønster for å angi at den indre hjemmeagenten 102 anser den som pålitelig og at proxyagenten samtidig er tilgjengelig utenfra uten å anvende VPN-løsning.

Selv om arkitekturen som er vist i figur 4 er en forbedring over den som er vist i figur 3, og gir økt fleksibilitet og dessuten gir plass for et flerleverandørsmiljø, har arkitekturen vist i figur 4 også noen uønskede egenskaper.

For det første krever proxyagenten 108 at det tas hensyn til bestemte protokollkrav og spesielle hensyn hva angår nettverkskonstruksjon. Dette skyldes i stor grad den realitet at både VPN-gatewayen 104 og proxyagenten 108 medvirker i ruting av den samme samling av mobilnodeadresser, med tilhørende risiko for konflikter og konstruksjonssvakheter. Disse enhetene må også lokaliseres på det samme delnett (subnett), som derfor reduserer utplasseringsfleksibiliteten. Den grunnleggende tanke er å sikre at både signalering og datapakker mellom modellnoden 103 og den faktiske hjemmeagenten 102 alltid vil gå over proxyagenten 108. Sist, men ikke minst, er proxyagenten en sårbar komponent etter som sikkerheten den arkitektur som er vist i figur 4 er fullstendig avhengig av en korrekt installasjon. På den ene siden må proxyagenten, VPN-gatewayen og hjemmeagenten alle virke i harmoni. På den annen side må proxyagenten være beskyttet ved hjelp av brannmuren. I dette sammensatte miljøet representerer enhver feilkonfigurering en sikkerhetsrisiko. For det annet er proxyagenten en ny komponent som må utvikles av industriaktørene før den arkitektur som er vist i figur 4 er klar for utplassering. Dessuten kreves ytterligere kvalifikasjoner både fra VPN-gatewayen, hjemmeagenten og mobilnoden som enten går utover basisprotokollstandarden eller utover det som for tiden tilbys fra industrien som teknikkens stand. Det vil dessuten ta betydelig tid å imøtekomme disse endringene. Alt i alt krever arkitekturen som er vist i figur 4 en betydelig innsats fra hele industrien før den er klar for utplassering.

Til slutt er proxyagentens 108 ytelse i henhold til Amdahrs lov koblet til VPN-gatewayen 104. Økning av systemets totalytelse krever en nøyaktig balansert oppgradering av systembestanddelenes ytelse. Den indre hjemmeagenten 102 og proxyagenten 108 er også koblet etter som proxyen konstrueres for å være den primære håndteringsagenten. En mobilnode på innsiden vil først forsøke en registrering hos proxyagenten, og kun senere registrere seg hos den indre hjemmeagenten 102 hvis proxyagenten gir beskjed om dette til mobilnoden. Dette gjør proxyagenten til en kritisk komponent som reduserer totalsystemets samlede pålitelighet. Hvis proxyagenten blir utilgjengelig, kollapser hele systemet.

I det følgende beskrives teknikkens stand hva angår klientprogramvare.

Klientprogramvare i henhold til teknikkens stand, innbefattende både mobil-IP-delen og VPN-delen, har innvirkning på hvordan en kombinert arkitektur kan realiseres. Ved å ta utgangspunkt i en mobil-IP-klientleverandør, slik som Birdstep, viser figur 5 og figur 6 de rådende implementeringsprinsippene. Disse prinsippene gjelder for dagens teknikkens stand terminaler, slik som bærbare datamaskiner og PDA'er, som arbeider på grunnlag av et toppmoderne operativsystem slik som Windows fra leverandøren Microsoft. Disse terminalene og operativsystem skiller mellom brukerrom 119 og kjemerom 120. Brukerapplikasjonen 121 kjøres i brukerrommet. Dette er forskjellig fra nøkkelnettverkskomponentene slik som en TCP/IP-stakk 118, drivere for LANAVLAN-adaptere 1110 eller drivere for PPP oppringt forbindelse 111, som kommer som en iboende del av operativsystemet i kjernerommet. Her skal man endelig merke seg at de prinsipper som er legemliggjort ved fremstillingene i figurene S og 6, antar den overlagrede VPN-modellen fra figurene 2,3 og 4. Følgelig er VPN-driverens nivå, 117 horisontal, over mobil-IP-dirvernivået, 115 horisontal, i kjernerommet. Utvidelsene av disse programvarekomponentene til brukerrommet, 115 vertikal, 117 vertikal, representerer de tilsvarende "daemon"-delene.

En forskjell mellom det som er vist i figurene 5 og 6, er det vist på hvilken VPN-programvaren er implementert. Som foreslått i figur 5, tilføyer enkelte leverandører en virtuell VPN-adapter 112 til klientprogramvaren for lokalt å være vert for den adressen som fra det sikrede domenet er assosiert med VPN-forbindelsen. En virtuell VPN-adapter er ellers lik enhver annen adapter for de overliggende drivernivåene. Fordi det ikke foreligger noen fysisk forbindelse på en virtuell VPN-adapter, må VPN-programvaren 117 derfor ta seg av ruting av trafikk til en av de fysiske adapterne 110, 111. Som foreslått i figur 6 vil andre VPN-klientimplementeringer ikke ha en virtuell VPN-adapter. Disse løsningene vil heller opprettholde I VPN-gatewayen assosiasjonen mellom en bestemt VPN-forbindelse og en adresse fra det sikre domenet. Gatewayen vil i dette tilfellet også faktisk utføre en operasjon med nettverksadresseoversettelse

(NAT).

I ethvert tilfelle anvender mobil-IP-klientvaren 115 sin egen virtuelle mobilitetsadapter 112 for å opprettholde den utforanderlige mobil-IP-adressen. Brukerromdelen av mobil-IP-programmet, 115 vertikaldelt, er en "daemon" som bestemmer den fysiske adapter som representerer den gjeldende optimale forbindelsen. Rollen til mobil-IP-driverdelen, 115 horisontaldelt, er å veksle pakketrafikk ifølge bestemmelsen mellom den virtuelle mobilitetsadapteren og den for tiden aktive fysiske adapteren. De stiplede vertikallinjene i figurene 5 og 6 angir hvordan de forskjellige adapterinstansene er synlige på alle nivåer helt opp til brukerapplikasjonen. De heltrukne vertikallinjedelene som forbinder de forskjellige nivåene i kjernerommet representerer pakkeutvekslingen. Følgelig viser disse linjene den virkelige pakkestrømmen. Trafikk til eller fra brukerapplikasjonen er assosiert med VPN-adapteren, hvis en slik eksisterer. Ellers er trafikken assosiert med mobilitetsadapteren. I det første tilfellet vil VPN-"daemon" utføre den nødvendige pakkeutvekslingen mellom VPN-adapteren og mobilitetsadapteren.

Klientdataprogrammet for arkitekturen som er vist i figur 2, som er det motsatte av den overlagrede VPN-arkitekturen vist i figur 1, realiseres ifølge det som er trukket opp ved det som er vist i ifgurene 5 og 6. For det første må driverne 115 og 117 ombytte sine stakkposisjoner. For det andre er pakkeveksling ikke lenger et diskusjonstema etter som mobil-IP-klienten da alltid vil sende sin trafikk over den som defineres som standardruten hos VPN-løsningen.

Man skal her merke seg at hybridarkitekturen som er vist i figur 4 faktisk antar at mobil-IP-adressen og den indre VPN-adressen som er assosiert med mobilnoden 103 er den samme adressen. Av denne årsak vil hybridarkitekturen kun fungere hvis VPN-klienten ikke har sin egen virtuelle adapter. En VPN-klient som gir bruk av en virtuell VPN-adapter vil føre til en adressekonflikt med den virtuelle mobilitetsadapteren som anvendes av mobil-IP-klienten.

Det foreligger to klasser av dagens moderne VPN-løsninger, hva angår grensesnittet som oppfattes av brukeren. Enkelte leverandører støtter en bakgrunnsmonitoreringsmodell i hvilken VPN-klienten er lagringsfast og alltid er klar for handling. Ethvert forsøk på å sende trafikk til det som defineres som å være det sikre domenet vil automatisk føre til kryptering. En anmodning om brukerautentisering kommer automatisk frem ved behov. Andre leverandører støtter seg på en eksplisitt "ring-opp-type"-modell i hvilken brukeren selv må etablere VPN-tunnelen når det er behov for kommunikasjon med det sikre domenet. Enkelte leverandører støtter begge driftsmodellene. Man skal også her merke seg at de fleste leverandører støtter både fulltunnerlings- og splittunneleringskonfigurasjoner i sine VPN-løsninger. I det førstnevnte tilfellet vil all trafikk sendes via det sikrede domenet selv om den har som mål et sted på utsiden. Med splittunnerling kan trafikk til stede på utsiden sendes direkte fra mobilnoden når den selv er på utsiden.

Endelig skal man merke seg at en mobil-IP-klient kan arbeide med overlagrede VPN-løsninger både i splitturmeleringsmodus og i fulltunneleringsmodus. I det sistnevnte tilfellet er kun mobil-IP-signaleirngsprotokollene den trafikksom tillates å gå utenom sikkerhetsløsningen.

Ved den foreliggende oppfinnelsen tilveiebringes en anordning for bruk i mobildataterminal for tilveiebringelse av en dobbelttunnelert pakkedataforbindelse mellom en første applikasjon i den mobile dataterminalen tilsluttet et ytre nett og en andre applikasjon i en vertsdatamaskin tilsluttet et indre nett, kjennetegnet ved de trekk som fremgår av det vedfølgende selvstendige patentkrav 1. Ytterligere fordelaktige trekk ved anordningen er gjengitt i de vedfølgende uselvstendige patentkravene 2 til og med 6.

Ved den foreliggende oppfinnelse tilveiebringes en mobil-IP-terminal kjennetegnet ved de trekk som fremgår av det vedfølgende patentkrav 7.

Ved den foreliggende oppfinnelse tilveiebringes en databærer omfattende datamaskinkode som er innlastbar eksekverbar i en teiminaldatarnaskin, som når den er innlastet og eksekveres i terminaldatamaskinen virker opprettelse av en anordning for bruk i mobil dataterminal for tilveiebringelse av en dobbelttunnelert pakkedataforbindelse mellom en første applikasjon i den mobile dataterminalen tilsluttet et ytre nett og en andre applikasjon i en vertsdatamaskin tilsluttet et indre nett, kjennetegnet ved de trekk som fremgår av det vedfølgende patentkrav 8.

Ved den foreliggende oppfinnelse tilveiebringes et datakommunikasjonssystem for tilveiebringelse av en mobil-IP-pakkedataforbindelse mellom første applikasjon i en mobil dataterminal tilsluttet et ytre nett og en andre applikasjon i en vertsdatamaskin tilsluttet et brannmurbeskyttet indre nett, kjennetegnet ved de trekk som fremgår av det vedfølgende patentkrav 9.

Ytterligere fordelaktige trekk ved datakommunikasjonssystemet er gjengitt i de vedfølgende uselvstendige patentkravene 10 til og med 14.

I det følgende beskrives det som ligger til grunn for foreliggende oppfinnelse. Arkitekturen vist i figur 4 representerer den nyeste teknikk for sømløs IP-mobilitet på tvers av en sikkerhetsgrense. Den realitet at mobil-IP-systemet virker på tvers av sikkerhetsgrensen i parallell med DPN-gatewayen er imidlertid uheldig. Proxyagenten representerer en sårbar komponent som må konstrueres svært nøye og bli utplassert i harmoni med VPN-gatewayen, den indre hjemmeagenten og den omsluttende brannveggen.

Oppfinnelsen som her er beskrevet har som hensikt å tilveiebringe en bedre tilnærmelse til problemet enn den arkitekturen som er vist i figur 4. Den foreslåtte fremgangsmåte kombinerer IP-mobilitet og IP-sikkerhetsteknologier på en ny måte for å løse problemet mer generelt. Et vesentlig aspekt ved oppfinnelsen er å anvende uavhengige IP-mobilitetssystemer på hver side sikkerhetsgrensen i stedet for et system som spenner over grensen. De to mobilitetsystemene er i sin tur rent adskilt ved hjelp av den mellomliggende IP-sikkerhetsløsningen. Det indre mobilitetssystemet rolle (som kjører innenfor brukerens sikrede domene) er å gjøre brukerapplikasjoner transparente for nettverksendringer internt. Det ytre mobilitetssystemet rolle er å gjøre fjemaksessikkerhetsløsningen transparent for nettverksendringer eksternt. Sammen legger de to mobilitetssystemene og fjemaksessikkerhetsløsningen til rette for sømløs IP-mobilitet også på tvers av sikkerhetsgrensen.

Som tidligere nevnt lider arkitekturen som er vist i figur 4 av den virkelighet at VPN-løsningen og mobil-IP-systemet er tett samenkoblet på forskjellige måter. Alt i alt skyldes dette den realitet at begge deler arbeider i det samme adressedomenet og at de begge er medvirkende ved ruting av den samme samling av mobilnodeadresser. Som nytt foreslår den foreliggende fremgangsmåten å skape et delingspunkt ved å anvende forskjellige adressesamlinger for mobilitetshåndtering på hver side av sikkerhetsgrensen. Etter som hver av de tre bestanddelene fungerer i separate adressedomener kan deres komponenter utplasseres hvor som helst i hvert domene. Dette skiller seg vesentlig fra det som er vist ved arkitekturen gjengitt i figur 4.

Foreliggende oppfinnelse representerer en tilnærmelse som er den beste i sitt slag og som innbefatter ekvivalenter av begge de arkitekturer som er vist i figurene 1 og figur 2 samtidig. Fordelen ved å lage klart skille for mobilitet og sikkerhet er en fremgangsmåte som er mer allsidig og anvendbar i et bredere omfang. Den foreslåtte fremgangsmåten er klientsentrert i stedet for nettverkssentrert. En klientsentrert tilnærmelse krever ikke endringer i eksisterende infrastruktur, med unntak av introduksjonen av et nytt mobilitetssystem. Fordi dette andre systemet allikevel er standardbasert, er den klientsentrerte tilnærmelsen enklere og hurtigere å utplassere enn en mer dyptgripende nettverkssentrert tilnærming. Fremgangsmåten har færre bivirkninger og mindre restriktive utplasseirngskrav enn andre alternativer som er kjent i dag. Skalerbarheten er også bedre etter som det ikke foreligger noen implisitte avhengigheter. Hvert system utplasseres individuelt og kan skaleres (og arbeide) uavhengige etter behov. Den kombinerte arkitekturens pålitelighet er også bedre enn arkitekturen som er vist i figur 4, etter som det ikke er noen avhengighet mellom de forskjellige delene. Spesielt skal man merke seg at det indre systemet vil være fullt operativt selv om det ytre systemet og sikkerhetsgatewaykomponentene er midlertidig tilgjengelige. Dessuten vil det indre systemet fremdeles være tilgjengelig fra utsiden selv om det ytre systemet midlertidig er nede.

Oppfinnelsen tilveiebringer sikker og sømløs IP-mobilitet i ethvert domene med uavhengig valg av IP-mobilitets- og sikkerhetsteknologier. Fremgangsmåten krever ikke noen endringer (tilpasninger eller utvidelser) i noen IP-mobilitets- eller sikkerhetsteknologi utover de eksisterende eller forestående standarder. Den krever heller ikke noen endringer i eksisterende nettverkskonstruksjon og infrastrukturkomponenter. Mobilitetsklientprogramvaren er den eneste komponent som påvirkes, og er således den komponent som muliggjør realiseringen. Fremgangsmåten gjelder både for den gjeldende IPv4-standard familien så vel som den kommende Ipv6-standard familien. Fremgangsmåten gjelder spesielt for mobil-IP- og IP-VPN-standardene, men ikke begrenset til disse teknologiene. Fremgangsmåten gjelder for enhver IP-mobilitets- og IP-sikkerhetsprotokoll, så lenge disse er basert på de samme få underliggende prinsipper.

I det følgende vil oppfinnelsen bli forklart med henvisning til vedfølgende tegninger, hvor: Figur 7 er en skjematisk representasjon av et eksempel på en mobil-IP-løsning i henhold til foreliggende oppfinnelse. Figur 8 er en skjematisk representasjon av et ytterligere eksempel på en mobil-IP-løsning i samsvar med foreliggende oppfinnelse. Figur 9 er en skjematisk lagmodellrepresentasjon av et eksempel på en klient- og nettverksadapter, -arrangement i samsvar med foreliggende oppfinnelse i en mobil-IP-dataterminal. Figur 10 er en skjematisk lagmodellrepresentasjon av et annet eksempel på en klient- og nettverksadapter, - arrangement i samsvar med foreliggende oppfinnelse i en mobil-IP-dataterminal. Figur 11 er en skjematisk lagmodellrepresentasjon av nok et eksempel på en klient- og nettverksadapter, -arrangement i samsvar med foreliggende oppfinnelse i en mobil-IP-dataterminal. Figur 12 er et flytskjema som representerer virkemåten til et eksempel på et klientarrangement i samsvar med foreliggende oppfinnelse for en mobil-IP-dataterminale. Figur 13 er en skjematisk representasjon av et eksempel på adressearrangementer i en mobil-IP-løsning i samsvar med foreliggende oppfinnelse.' Figur 14 er en skjematisk representasjon av et eksempel på et

datapakkeinnkapslingsarrangement i mobil-QMøsningen i samsvar med foreliggende oppfinnelse.

Figur 15 er en skjematisk representasjon av et eksempel på et

datapakkdekapsuleringsarrangement i en mobil-IP-løsning i samsvar med foreliggende oppfinnelse.

Figur 16 er en skjematisk illustrasjon av et eksempel på en utplassering av flere mobil-IP-hjemmeagenter langs et ytre nettverks kanter.

I det følgende beskrives først en fremgangsmåte og arrangement i samsvar med oppfinnelsen.

Den generelle fremgangsmåten beskrives best når den fremstilles i en mer bestemt sammenheng. Følgelig beskriver denne delen av oppfinnelsen idet det antas at mobil-IP ble anvendt for mobilhåndtering og at en IPSec VPN løsning anvendes for fjernaksess til det sikre domenet. Fremgangsmåtens generalitet og utvidbarhet beskrives i en senere del.

Som antydet i figur 7, er fremgangsmåten basert på den kombinerte bruk av uavhengige mobil-IP-systemer i det sikre domenet 105 henholdsvis det usikrede domenet 107. Hjemmeagenten, 130, som er tegnet med jevn grå farge, i det sikre domenet representerer det indre system. Hjemmeagenten 102 fremstilt skravert i tegningen, utfor det sikre domenet representerer det ytre systemet. Den komponent som muliggjør fremgangsmåten er mobil-IP-klientprogramvaren som kjører på brukerinnretningen som kan arbeide samtidig med begge mobil-IP-systemene. Dobbelt operasjonsevne er angitt ved til dels jevn grå farge og et til dels skravert mønster hos mobilnoden 103.

Det antas at brukerens ordinære VPN-løsning styrer all aksess til det sikre hjemmedomenet. Spesielt finner virksomheten til det indre mobil-IP-systemet sted over VPN-løsningen, det vil si mobil-IP-tunnelen 104, tegnet med tynn linje, for det indre systemet er omsluttet av VPN-tunnelen 123. Dette svarer til den arkitekturen som er vist i figur 2. Derimot er det ytre mobil-iP-systemets arbeidsmåte i samsvar med arkitekturen som er vist i figur 1, det vil si at VPN-tunnelen 123 er omsluttet av mobil-IP-tunnelen, 124, tegnet med tykk linje, hos det ytre systemet. Således er den foreslåtte fremgangsmåten en best-av-sitt-slagtilnærming, som innbefatter begge de nedarvede arkitekturene samtidig. Dette gjenspeiles av den realitet at det foreligger tre tunnelnivåer som er medvirkende når mobilnoden forbindes utenfra. Den "innfødte" brukertrafikken 125 transporteres til slutt av det indre systemets mobil-IP-tunnel 124.

Det indre mobil-IP-systemets rolle er å gjøre brukerapplikasjoner transparente for nettet og adresseendringer i det sikre domenet. Merk at dette innbefatter transisjonstilfellet når mobilnoden flytter seg fra det indre til det ytre. Da vil en VPN-tunnel bli etablert som i grunn er en forlenget arm av det sikre domenet. Et vesentlig trekk ved fremgangsmåten er å anvende den indre adressen som er assosiert med VPN-tunnelen 123 som c/o-adressen i den indre hjemmeagentens (130) i grå farge, bindingsliste. Den indre c/o-adressen vil ikke endre seg så lenge mobilnoden 103 forbinder seg fra utsiden via VPN-tunnelen. På dette punkt blir det ytre mobil-IP-systemet viktig. Det ytre systemets rolle er å gjøre selve VPN-tunnelen transparent for nettet og adresseendringer på utsiden. Alt i alt har de to mobil-IP-systemene forskjellige roller, men arbeider på naturlig måte sammen isolert av den mellomliggende VPN-løsningen.

Det indre systemet 130, tegnet i grå farge, er alltid i bruk for en mobilnode. Det ytre systemet 102, tegnet skravert, er i bruk kun når mobilnoden er på utsiden. I dette tilfellet blir det indre systemets arbeidsmåte triviell av den årsak som nettopp ble forklart. Dessuten vil det indre systemet alltid arbeide i samlokalisert modus når mobilnoden 103 er på utsiden. Ellers kan begge mobil-IP-systemene arbeide i samlokalisert modus og i fremmedagentmodus. Fremmedagenter som er utplassert på innsiden vil bli anvendt av de indre systemer. Fremmedagenter som er utplassert på utsiden vil bli anvendt av det ytre systemet.

Reverstunnelseringsspørsemålet for de to systemene drøftes i en senere del som tar for seg adresseringsdetaljer.

Det foreligger ingen bestemte krav til det adresseområdet som anvendes for mobilnoder i det indre systemet. Et hvilket som helst adresseområde kan også anvendes for det ytre systemet. Bruken av mobilnodeadresser i det ytre systemet er dog av en mer dynamisk karakter, etter som dette systemet kun er i bruk så lenge mobilnoden forbinder seg fra utsiden. I dette tidsrommet utstyres terminalen faktisk med to mobilnodeadresser, en fra hvert system. Mens mobilnodeadressen fra det indre systemet er permanent under operasjon, kan mobilnodeadressen fra det ytre systemet allokeres dynamisk etter behov. Det eneste krav er at disse to adressene aldri må være de samme. Hvis privatadresser anvendes for det ytre systemet må reverstunnelering som alltid anvendes.

Ethvert delnett (subnett) innenfor det sikre domenet kan utpekes som hjemmenettet for det indre mobil-IP-systemet. Et utpekt hjemmenett for det ytre systemet er imidlertid et åpent spørsmål. Hvis den ytre hjemmeagenten er utplassert i en bedrifts DMZ 106, vil systemet vanligvis kjøre med et virtuelt hjemmenett. Det er svært uvanlig å gi vertsmaskiner tillatelse til å forbinde seg direkte med DMZ. En interessant mulighet oppstår hvis bedriften allerede har et WLAN på sitt område som er forbundet med brannmuren på et adskilt segment. En slik konfigurasjon er vanlig i dag etter som WLAN er usikkert og ikke bør forbindes direkte innenfor bedriftens sikre domene. I stedet anvendes VPN-løsningen for forbindelse fra utsiden over det nevnte WLAN. Som antydet i figur 8 vil WLAN 109 i dette tilfellet være det perfekte sted for den ytre hjemmeagenten 102, vist med skravering. Det som her er viktig å observere er at enhver mobilnode 103 som forbinder seg med dette nettet vil fremstå som transparent for det ytre mobil-IP-systemet fordi det er det utpekte ytre hjem. Som foreslått i figur 8 vil en mobilnode i dette tilfellet forbinde seg med det indre systemet kun over VPN-løsningen. Sparing av den omsluttende ytre tunnelens 124 indirekte data vil bidra til en bedre ytelse, som er særdeles viktig i dette tilfellet fordi det er rimelig å forvente at mange brukere vil tilbringe stor del av sin arbeidsdag i dette trådløse miljøet.

Som en oppsummering av denne del følger en liste med nøkkelegenskaper for de to mobil-IP-systemene under forskjellige betingelse.

Det indre mobil-IP-systemet:

Er alltid i bruk

Fysisk hjemmenett på internt delnett

Brukerens applikasjon binder seg til dette systemets hjemmeadresse, følgelig med applikasjonsgjennomsiktighet og sømløs drift, både internt og på tvers av sikkerhetsgrensen.

Mobilnoden er på innsiden:

o VPN-løsningen blir slått av

o Arbeider på standardmåten (i samsvar med mobil-IP) ved bruk av den indre hjemmeagenten

Mobilnoden er på utsiden

o Blir slått på

o Signaleringsmeldinger utveksles med den indre hjemmeagenten over

VPN-tunnelen

o c/o-adressen er bindingslistene hos den indre hjemmeagenten er alltid adressen til mobilnodens adresse fra det sikre domenet (vedlikeholdt av VPN-løsningen)

o Det indre systemets arbeidsmåte blir triviell

Det ytre IP-systemet

• Anvendes etter behov

• Fysisk hjem på eksternt forbundet bedrifts-WLAN

Mobilnoden er på innsiden

o Det ytre systemet er ikke i bruk

Mobilnoden på utsiden

o Det ytre system er nødvendig

o Den ytre hjemmeagentens bindingsliste holder adressen til mobilnodens

gjeldende eksterne adresse

o VPN-tunnelen binder seg til det ytre systemets hjemmeadresse, følgelig VPN-transparent

I det følgende forklares en dobbeltklientimplementering.

Den foreliggende oppfinnelses muliggjørende komponent er en mobil-IP-klientprogramvare som kan arbeide to uavhengige mobil-IP-systemer samtidig, og på en slik måte at disse systemene adskilles ved hjelp av en ordinær VPN-løsning. I det følgende vil denne klienttypen omtales som en dualmobilitetsklient. Dette er en motsats til en enkeltmobilitetsklient som ellers er toppmoderne teknikk i dag. Når oppfinnelsens datamaskinprogramprodukt kjøres i en datamaskinretning hos mobilnoden etableres oppfinnelsens arrangement. Når oppfinnelsens datamaskinprogramprodukt kjøres i en datamaskininnretning hos mobilnoden bevirkes utførelse av oppfinnelsens fremgangsmåte.

Implementering av en dualklient på en innretning som kjører et moderne operativsystem (slik som medlemmer av Microsoft Windows familien) tar utgangspunkt i samme implementeringsprinsipper som tidligere er forklart med figurene 5 og 6. To anrikninger blir så foretatt for det første tilføyes en ytterligere virtuell mobilitetsadapter for å være verdt for det andre mobil-EP-systemets uforanderlige adresse. Så inkluderes et nytt mobil-IP-drivernivå over VPN-drivernivået. Den resulterende kjerneromsarkitekturen er vist i figur 9, hvor det antas at VPN-klienten anvender sitt eget virtuelle VPN-adapter 114. Den nye øvre mobil-IP-driveren 116 sammen med den nye virtuelle mobilitetsadapteren, nå kalt Intranettadapteren 113 står for det indre mobil-IP-systemet. Den nedre mobil-IP-driveren 115 sammen med den opprinnelige virtuelle mobilitetsadapteren 112 står for det ytre systemet. Det mellomliggende VPN-drivemivået 117 isolerer de to systemene og tar vare på all sikkerhet på vanlig måte. Pilene som er vist i figur 9 antyder hvordan trafikk veksles på sin vei gjennom drivestakken. Denne spesielle figuren svarer til det tilfellet hvor mobilnoden er utenfor det sikre domenet og begge systemer er i bruk.

Den sømløse drift kommer som resultat av den realitet at applikasjonsnivået over den øvre mobil-IP-driveren 116 forholder seg til Intranettadapteren 113 som alltid vil være tilstede og tilgjengelig som et transportendepunkt.

Figur 10 viser kjerneromsarkitekturen for dual-mobil-IP-klient når den mellomliggende VPN-løsningen ikke har sin egen virtuelle VPN-adapter. Igjen representerer den det tilfellet hvor mobilnoden er utenfor det sikre domenet. Pilenes sekvens som angir pakkeutvekslingen er noe annerledes som følge av den manglende virtuelle VPN-adapteren.

Som allerede pekt på er det indre systemet alltid i bruk mens det ytre systemet er i bruk kun når mobilnoden er utenfor det sikre domenet. Dessuten er det indre systemet arbeidsmåte triviell når mobilnoden er på utsiden etter som den indre c/o-adressen da alltid er intranettadressen som er assosiert med VPN-forbindelsen og vil ikke endres. Når mobilnoden er innenfor det sikre domenet blir det indre systemets arbeidsmåte mer sammensatt etter som det må håndtere virkelige nettverksoverleveringer og adresseendringer. Denne kompleksiteten er den samme som for det ytre systemet når det er i bruk. Figur 11 viser den resulterende kjerneromsarkitekturen som gjelder når mobilnoden er på innsiden. Komponentene 116,117,112 blir transparente eller i tunggang i dette tilfellet, som forklart under.

Nøkkelpunktet hva angår implementering er at den øvre mobil-IP-driveren 116 kan deaktiveres når mobilnoden er på innsiden. Samtidig begynner den nedre mobil-IP-driveren å støtte det indre systemet i stedet for å støtte det ytre systemet. Av dette følger at implementeringen av dualklienten hviler på den realitet at det foreligger en kontekstvender i operativmiljøet til den nedre mobil-IP-driveren 115. En del av denne kontekstvekslingen er å la den nedre driveren begynne å arbeide på intranettadapteren 113 i stedet for mobilitetsadapteren 112. Som følge av dette implementeres kun sann mobilitetshåndtering med pakkeflytting til fysiske adaptere i den nedre mobilitetsdriveren. Denne driveren anvendes for det indre eller ytre systemet, avhengig av om mobilnoden er på innsiden eller på utsiden. I det sistnevnte tilfellet starter den øvre mobil-IP-driveren virksomhet for å opprettholde det indre systemet inntil mobilnoden returnerer det sikre domenet. Av årsaker som allerede er forklart, er denne driverens kompleksitet triviell sammenlignet med den nedre driveren.

VPN løsningen 117 blir også slått av når mobilnoden er på innsiden. Enhver virtuell VPN-adapter som blir anvendt av VPN-løsningen vil da forsvinne fra de operative miljøene. Følgelig vil kjerneromarkitekturen være den samme uansett hvilket VPN-løsningsslag som anvendes.

Den forutgående beskrivelse basert på den antagelse at dualklienten implementeres på en "åpen plattform" innretning med et modulært operativsystemmiljø som innbefatter både brukerrom og kjemerom. Dessuten er konseptet med en driver og en adapter sentralt for drøftingen. Andre innretninger, og spesielt innebygde innretninger, kan ha operative miljøer som er svært forskjellige. Hvis det ikke foreligger noen modulær arkitektur må dualklienten implementeres som et monolittisk system. Avhengig av vertsinnretningens kvalifikasjoner kan et slikt system implementeres enten i brukerrommet eller i kjernerommet. I enkelte tilfeller kan det også inkluderes som en enhetlig del av vertsoperativsystemet og standardkjøretidsmiljøet.

Flytskjemaet i figur 12 representerer en mer abstrakt betraktning av trafikkstrømprinsippene som nettopp har blitt skildret i en bestemt sammenheng. De generelle prinsippene må understøtte enhver implementering av en dualklient, uten hensyn til den bestemte vertsinnretningens egenskaper. Flytskjemaet antar at verken vanlig reverstunnelering eller NAT-traversering er nødvendig når mobil-IP-klienten forbinder seg direkte til det indre systemet. Reverstunneleringens rolle drøftes ellers i en etterfølgende del som tar for seg adresseringen.

I det følgende forklares domenedeteksjon.

De prinsipper som er utpenslet i den foregående del innbefatter en dualklientimplementeirngstrafikkstrømdel. Styringsdelen (vanligvis implementert i en "daemon" må på tilsvarende måte anrikes for også å innbefatte støtte for et andre mobil-IP-system. Dessuten må denne kvalifikasjonen gjøres valgbar slik at den kan aktiveres etter behov (av de årsaker som allerede er forklart). Den avsluttende del er å la "daemon" iverksette kontekstvekslingen, avhengig av om mobilnoden er på innsiden eller utsiden av det sikre domenet. Dette er basert på en domenedeteksjonsmekanisme som er omhyggelig konstruert. Etter som denne beslutningen til slutt styrer VPN-klientens på/av-tilstand, er det altoverskyggende at deteksjonsalgoritmen er pålitelig og ikke kan kompromitteres. Samtidig er det viktig at beslutningen kan gjøres hurtig for å redusere ytelsesstraffen når mobilnoden flytter seg mellom nettverk, og spesielt når den flytter seg på tvers av sikkerhetsdomenet.

Domenedeteksjonsmekanismen er opptatt med de følgende to transisjonene:

• Når mobilnoden allerede var forbundet fra utsiden og en ny innsideforbindelse oppfattes (eller mistenkes). • Når mobilnoden allerede er forbundet på innsiden og en ny utsideforbindelse erkjennes (eller mistenkes).

I begge tilfeller kan den nye forbindelsen være over den samme adapteren som i den forutgående forbindelsen eller den gjøres over et annet adapter.

Til slutt er det eneste pålitelig bevis for at mobilnoden er forbundet til et av de to domene via en av sine fysiske adaptere når en registrering med den riktige hjemmeagenten er vellykket over denne adapteren. Påliteligheten hviler på sikkerhetsassosiasjonene mellom hjemmeagenten(ene) og mobilnoden som allerede er den del av mobil-IP-systemet(ene). Tilnærmelsen med bruk av rå kraft er alltid å forsøke registreringer med begge agentene når domenedeteksjon er påkrevd. Ulempen med denne tilnærmelsen er dårlig overleveringsytelse, spesielt på tvers av sikkerhetsgrensen. På den ene side skyldes dette at registreringer kanskje ikke kommer gjennom til den riktige hjemmeagenten når de utstedes fra den motsatte siden av sikkerhetsgrensen. Håndtering av ventende registreringer bidrar til kompleksiteten av operasjonen i den nevnte "daemon" og bør unngås når dette er mulig. På den annen side, hvis en registrering er vellykket er domenedeteksjonen fullført, men den aktive adapteren har da også endret seg. Det sistnevnte er i realiteten en uønsket bivirkning hvis adapteren viser seg ikke å være optimalt. Den nye registreringen vil da overstyres umiddelbart, som resulterer i en ytelsesstraff.

Behovet er her å oppnå en tilgjengelig hjemmeagenttjenesteoppdagelsesmekanisme som ikke er koblet til en virkelig registrering. En biproduktaktivitet av foreliggende oppfinnelse er å forsøke å standardisere en slik mekanisme. I mellomtiden kan ytelsesdegradeirngsvirkningene overvinnes ved å gjøre gjettinger om lokaliseringen som er grunnlagt på mindre pålitelighet, men hurtigere domenedeteksjonsmekanismer uten bivirkninger. Operasjonen kan da gå videre langt hurtigere med en rimelig høy sannsynlighet for at gjetningen til slutt viser seg å være korrekt. Hvis den innledende gjetningen var feil, vil råkrafttilnærmingen til slutt føre til den riktige konklusjonen. De mindre pålitelige domenedeteksjonsmekanismene som dekkes ved hjelp av oppfinnelsen er som følger: • Sammenligning av observert ff-adresseinformasjon med forhåndskonfigurerte adresseområder som ble anvendt innenfor det sikre domenet. • Utnyttelse av informasjon i styringsmeldinger slik som ICMP (innbefattende agentannonseringer) som er en bestanddel av den normale trafikkstrøm på nettet.

Utføring av upålitelig hjemmeagentdeteksjon ved å sende en registrering med bevisst feil sikkerhetsassosiasjon. Dette vil i virkeligheten "røke ut" enhver hjemmeagent hvis den kan nås uten faktisk å utføre en registrering.

Utnyttelse av nettverkskonteksthistorie som registreres og lagres under drift.

Slik informasjon samles for fremmedagenter, standardgatewayer, WLAN-aksesspunkter etc, ved bruk av deres lag-to-identifikatorer (slik som MAC-adresse) som grunnlaget for indeksering.

I det følgende forklares adresseringsdetaljer.

De tre forskjellige delene i den foreslåtte arkitekturen som er vist i figur 7, det vil si det indre mobil-IP-systemet, den mellomliggende VPN-løsningen og det ytre mobil-IP-systemet, resulterer i tre adressenivåer og tunnelinnkapslinger. Dette kan være vanskelig å forstå inntil det på eksplisitt vis blir uttalt. Utstyrt med en overgripende beskrivelse av fremgangsmåten sammen med prinsippene for en dualklientimplementering, beskriver denne detaljene som angår adresseringen.

Figur 13 viser de forskjellige komponentene som er involvert sammen med adresseutpekere som anvendes for de forskjellige komponentene. Merk at mobilnoden 103 er forsynt med fire forskjellige adresser, som svarer til de to mobil-IP-systemene, 130 og 102 som er vist i tegningen henholdsvis ved jevn grå og skravert farge, VPN-løsningen 104 og til slutt nettverkets fysiske adresse til hvilket mobilnoden for tiden er forbundet 107 i dette tilfellet. V-adressene og mobilnoden antyder at det foreligger en lokal-VPN-adapter i dette tilfellet. Hvis det ikke forekommer noe lokal-VPN-adapter vil V-adressene ikke eksistere lokalt. T-adressene for den ytre hjemmeagenten og VPN-gatewayen angir grensesnittene som kan nås fra utsiden.

Anvendelsen av reverstunnelering for hver av de to systemene er nært knyttet til adresseringen. Reverstunnelering kan være nødvendig for det indre systemet avhengig av VPN-løsningens egenskaper. VPN-løsninger som anvender en virtuell VPN-adapter kan håndheve stringente filtreringsregler, enten på klientsiden eller på gatewaysiden, som effektivt vil forhindre enhver trafikk over VPN-forbindelsen med en kildeadresse som er en annen enn V-adressen som er allokert til fjernforbindelsen. Benyttelse av reverstunnelering vil sikre at den toplogisk korrekte kildeadressen anvendes for reverstrafikk. Dette skiller seg ikke fra å anvende reverstunnelering for å overvinne inntregningsfiltrering i det utenforliggende domenet.

For VPN-løsninger som ikke anvender en virtuelt VPN-adapter, foreligger en tilsvarende logisk begrunnelse for å anvende reverstunnelering, men for dette tilfellet kun for å overvinne eventuelle handlinger foretatt på klientsiden. VPN-gatewayen bør ikke forvente noe bestemt kildeadresse etter som den ikke har distribuert noe slik til lokalinnretningen. Mange av disse gatewayene vil isteden utføre en NAT-operasjon for å omforme mellom en topologisk gyldig adresse på innsiden (det ekvivalente til en V-adresse) og den faktiske adressen som ble anvendt for forbindelsen på utsiden (T-adressen vil bli anvendt). I dette tilfellet kan c/o-adressen som er registrert i den indre hjemmeagenten (dvs. T-adressen) bli topologisk ugyldig hvis den ikke er rutbar i det sikre domenet. For å overvinne dette problemet må NAT-traversering av mobil-IP støttes av det indre systemet. En bestemt form for tunnelering anvendes da for det indre systemet, både i forover- og reversretning. Dette er ikke noe annet enn å anvende den samme mekanismen i det ytre systemet for å overvinne NAT-innretninger i det utenforliggende domenet.

Med unntak av de årsaker som nettopp er blitt forklart, bør reverstunnelering generelt ikke være nødvendig for det indre systemet når forbindelsen er på innsiden. Det antas at det gis rom for S-adressene som gyldige kildeadresser på ethvert innsidenettverk og at det ikke forekommer noen NAT-innretninger på innsiden. Mobilnoder på innsiden kan sende trafikk direkte i reversretningen. Behovet for reverstunnelering i det utenforliggende systemet er "som vanlig". Den er påkrevd enten hvis private

mobilnodeadresser anvendes eller hvis inntrengningsfiltrering utføres på en lokalaksess.

Betrakt nå sekvensen med trinn som finner sted i en eksternt tilknyttet mobilnode for en pakke som er bestemt for en korresponderende node på bedriftens innside. Dette er vist i figur 14, som også antyder de deler som deltar på de forskjellige nivåene. For

enkelthets skyld antas det at de korrekte registreringer allerede har blitt fullført for både de indre og ytre mobil-IP-systemene. Anta at reverstunnelering er nødvendig for det ytre systemet, og at pakken som til slutt forlater mobilnoden (over den aktive adapteren) er bestemt for den ytre hjemmeagenten. Denne pakkens struktur viser klart den ytre mobil-IP-reverstunnelinnkapslingen, så VPN- tunnelinnkapslingen, og til slutt den indre mobil-IP-reverstunnelinnkapslingen. Den indre reverstunnelens årsak er å sikre en korrekt topologisk kildeadresse som svarer til VPN-adressen.

Betrakt så trinnsekvensen som finner sted i den ytre hjemmeagenten, VPN-gatewayen og til slutt den indre hjemmeagenten etter som pakken passerer disse komponentene på sin vei til den korresponderende noden på innsiden av det sikre domenet. Dette er vist i figur 15.

Hvis en VPN-løsning uten en VPN-adapter anvendes, gjøres kun mindre endringer i det bildet som er vist. V-adressen vil da ikke eksistere i mobilnoden, og T-adressen anvendes midlertidig i dets sted. Normalt, når pakken ankommer hos VPN-gatewayen vil den korrekte V-adressen erstatte T-adressen, og effektivt utføre en NAT-operasjon. Av denne årsak kan det være behov for å innsette en UDP-basert reverstunnelering. Dette drøftes i nærmere detalj senere.

Pakker som har sin opprinnelse fra en korresponderende node og skal til en utenforliggende mobilnode følger den motsatte vei av den som nettopp har blitt beskrevet. Den resulterende figuren er ikke vist eksplisitt, men følger direkte fra å betrakte figurene 14 og 15 i revers, og samtidig ombytte adressene i alle kilde-/destinasjonspar. Reverstunnelinnkapslingene fra figurene 14 og 15 vil da selvfølgelig bli erstattet av tilsvarende forovertunnelkapslinger fra hjemmeagentene.

En tilsvarende øvelse for pakkestrømmen mellom en korresponderende node og mobilnoden på innsiden av det sikre domenet er triviell etter som den reduseres til vanlig mobil-IP-operasjon i et enkelt system uten involvering av en VPN-løsning.

Beskrivelsen av oppfinnelsen har så langt blitt fremstilt i en bestemt iscenesetting, det vil si i en bedrift som utplasserer sin egen mobil-IP-tjeneste i et IPv4-miljø ved bruk av en eksisterende IPSec VPN gateway. Den foreslåtte fremgangsmåte oppsto som en ny løsning for dette problemet, men har i seg selv et langt bredere anvendelsesomfang. For det første kan de involverte teknologier og komponenter erstattes av andre teknologier og komponenter så lenge erstatningene deler noen få felles egenskaper med komponentene og teknologiene som er omtalt i den opprinnelig beskrivelsen. For det andre kan fremgangsmåten anvendes i mange andre utplasseringsomstendigheter for å løse andre problemer enn det opprinnelig. Denne delen fokuserer på det første aspektet. Den påfølgende delen er viet beskrivelse av andre interessante utplasseringsscenarier.

Til slutt er den foreslåtte fremgangsmåten avhengig kun av noen få grunnleggende og generelle egenskaper:

At begge mobilitetssystemene kjører over en IP-transportinfrastruktur.

At begge mobilitetssystemene er basert på en klient-tjenermodell i hvilken tjenerkomponenten (dvs. agenten) er den autoritative kilden for mobilitetshåndteringen.

At fjemaksessikkerhetsløsningen (hvis slik forekommer) kjører over en IP-tr^sportinfrastruktur.

• At fjernaksessløsningen er basert på en klient-tjenermodell i hvilken tjenerkomponenten håndhever sikkerhetsplanen på domenegrensen. • At fjernaksessløsningen tilveiebringer et sikkert IP-transport-anlegg mellom klienten og tjeneren. • At tjenerkomponenten hos sikkerhetsløsningen er i stand til å skille mellom individuelle fjernforbindelser. Videre, at en unik adresse assosieres med hver slik forbindelse og at denne adressen er rutbar fra domenets innside. • At den aktuelle terminalinnretningen har kvalifikasjoner (maskinutmstning og programvare) som muliggjør implementering av et system med dualklientkvali fikasj oner.

Disse prinsippene er allerede innebygd i de grunnleggende mobil-IP-standardene for både IPv4 og IPv6, og dette følger at oppfinnelsen gjelder også når grunnstandardene er ledsaget av tilleggsstandarder som utvider grunnprotokollene. Merk spesielt at bindingsoppdateringer (som er en standarddel av mobil-IPv6 for å støtte rutingsoptimalisering) naturligvis imøtekommes av den foreslåtte fremgangsmåten. Det samme gjelder for enhver (fremtidig) anrikning og forbedring av mobil-IP-standardfamilien. Som et særdeles viktig eksempel støttes den kommende standarden for NAT-traversering ved bruk av UDP-innkapsling. I realiteten kan NAT-traversering Støttes individuelt i hvert av de to systemene. Likeledes støttes i begge systemene den viktige og forestående "authenication, authorisation and accounting" (AAA) - protokollutvidelsen for mobil-IP.

Prinsippene fra de ovenstående oversiktene er også allerede innbygd i de grunnleggende IPSec-standardene, igjen innbefattende både IPv4 og IPv6. Følgelig vil den foreslåtte fremgangsmåten virke med alle valgmuligheter, utvidelser og tillegg som er inkludert i begge IPSec-protokollstandardfamiliene. Merk spesielt at fremgangsmåten virker med IPSec både i tunnelmodus og transportmodus, hvis hver av disse modi ellers er gyldige i den bestemte kontekst. Den følgende, ikke-uttømmende, listen gir noen tilleggseksempler på det som dekkes av den foreslåtte fremgangsmåten.

• Andre tunneleringsmekanismer enn de som for tiden er legemliggjort i mobil-rP-standardenen. Spesielt foreligger en gevinst for tunneleringshodekompresjon for å redusere administrasjonsbyrden som påføres av de tre innkapslingslagene. • Andre IP-mobilitetsprotokoller enn mobil-IP, hvis de er i overensstemmelse med de prinsipper som er angitt i listen over. • Andre IP-sikkerhetsprotokoller enn IPSec, hvis de er i overensstemmelse med prinsipper som er angitt i listen over. Spesielt støttes både L2TP- og PPTP-protokollene.

• Det trivielle "null"-tilfellet uten noen som helst sikkerhetsløsning.

• Blandede systemer som anvender IPv4 og IPv6 i forskjellige deler (for eksempel IPv6 på innsiden og IPv4 på utsiden). Den eneste antagelse er at enhver av de kjente IPv4- IPv6-transisjonsmetodene ellers gjelder i den bestemte kontekst. Dessuten må mobilnoden være forsynt med en dobbeltstakkløsning i dette tilfellet. • Andre klientinnretningstyper enn bærbare datamaskiner, PDA'er og tilsvarende personlige terminalinnretninger. Spesielt kan fremgangsmåten anvendes når klientsiden implementeres som en del av en mobilruter som er i stand til å flytte et helt nett (med flere brukere) i stedet for bare en enkelt bruker.

I det følgende vil utplasseringer av oppfinnelsens fremgangsmåte bli forkalrt.

Den første anvendelsen av den foreslåtte fremgangsmåten er for å løse de kjente problemene med sømløs IP-mobilitet på tvers av en bedriftssikkerhetsgrense på en ny og mer fordelsgivende måte. Selv om fremgangsmåten oppsto som en ny løsning på dette problemet, har den i seg selv et langt videre anvendelsesomfang. I denne delen beskrives kort to andre utplasseringseksempler. Disse er begge løsninger på problemer som hittil ikke har blitt adressert eller løst av industrien. Det formodes at disse problemene begge vil fremstå som svært viktige i fremtiden.

Frem til nå har det på implisitt vis blitt antatt at begge IP-mobilitets-systemene kjøres og administreres av den samme enheten (bedriften). Uavhengigheten mellom systemene åpner dog for en svært interessant mulighet, nemlig den at systemene drives av forskjellige administrative enheter. En bedrift vil selv alltid være ansvarlig for det indre systemet etter som dette systemet er en del av det sikre domenet. Det ytre systemet er forskjellig og bedriften kan like gjeme utnytte en mobilitetstjeneste fra en operatør av et offentlig nett. Den offentlige operatøren kan på sin side tilby den samme tjeneste til mange bedrifter. Her ligger operatørens forretningsmulighet i å utplassere hjemmeagenter langs det offentlige nettets kanter, når til de steder hvor bedriftene har sine sikkerhetsgatewayer. En illustrasjon av denne tanken er vist i figur 16. Operatører kan også tilby dynamisk allokering av den ytre hjemmeagenten hvis denne tjenesten kobles til en AAA-infrastruktur. Bedriftsbrukeren vil da alltid anvende den mest optimale agenten i området hvor sikkerhetsgatewayen er lokalisert. Dette er særdeles viktig egenskap for en bruker fra en avansert bedrift etter som brukeren da kan anvende forskjellige sikkerhetsgatewayer avhengig av sin faktiske lokalisering på utsiden. En distribuert og redundant sikkerhetsgatewayarkitektur er i dag toppmoderne teknikk hos store bedrifter som er representert på flere steder og i flere land. Til sammen muliggjør uavhengig drift og administrasjon av de to mobilitetssystemene nye fremtidige forretningsmodeller mellom og på tvers av offentlige operatører og private bedrifter. Det eneste krav er å innbefatte håndtering av to adskilte administrative grensesnitt i dualmobilitetsklienten.

En annen interessant anvendelse av den foreslåtte fremgangsmåten er å bygge mobilitetsløsninger på tvers av nettverkene med forskjellige versjoner av IP-protokollen. I dag er mobil-IPv4 den teknologi som er mest moden. Mobil-IPv6 blir for tiden fremdeles standardisert, men formodes standig bli viktigere etter som overgang fra IPv4 til IPv6 nettverk ellers finner sted. Situasjonen på Internet i den første fasen av denne overgangsperioden vil være en antall IPv6-nettverksøyer som befinner seg i en stor "sjø" av IPv4-nettverk. Bygging av en mobilitetstjeneste på tvers av disse nettverksgrensene vil naturligvis være velegnet for en dualklientløsning. Den eneste antagelse er at terminalinnretningen som innbefatter mobilnoden vil ha en dobbeltstakkarkitektur. Det vil si, en innretning som innbefatter både et IPv4- og IPv6-protokollmiljø og som støtter begge protokoller samtidig. De nåtidige kommersielle implementeringene er vanligvis dobbeltstakkimplementeringer. Resultatet er en transisjonsrfemgangsmåte hvor endesystemene kan dra veksler på fordelene hos både mobil-IPv6 og mobil-IPv4 i et blandet miljø. Transisjonsgrensene kan selvfølgelig også være sikkerhetsgrenser, så lenge sikkerhetsgatewayen også er anordnet med dobbeltstakk. For en bedrift kan det tenkes to operasjonsmodi. Den første operasjonsmodus hvor det indre IP-mobilitetssystemet anvender mobil-IPv4, gjelder for bedrifter og andre organisasjoner som ønsker å opprettholde sine IPv4-baserte systemer mens de drar fordel av en mobil-IPv6-løsning på utsiden. Den andre operasjonsmodus hvor det indre IP-mobilitetssystemet er mobil-IPv6, gjelder for bedrifter eller organisasjoner som har gått over til IPv6, men hvor kjernenettet utover det sikrede domenet fremdeles anvender IPv4.

I det følgende gis et sammendrag av oppfinnelsens fordeler og egenskaper.

Denne siste delen gir en opplisting av den foreslåtte fremgangsmåtens nøkkelegenskaper. Her fokuseres det på oppfinnelsens bidrag sammenlignet med det som ellers er dagens moderne teknikk. Listen dekker fordeler ved selve fremgangsmåten så vel som fordeler ved hvordan fremgangsmåten kan anvendes for å løse forskjellige problemer ved forskjellige omstendigheter. • En tilnærming, som er en beste av sitt slag, som støtter enhver av de velkjente arkitekturer som er representert ved hjelp av figurene 1,2, og 4. • Grunnlagt på anvendelse av to samtidige, men virkelig uavhengige mobilitetssystemer som er isolert ved hjelp av en vanlig sikkerhetsløsning. • Den vanlige sikkerhetsløsningen har full styring med all fjernaksess til det sikre domenet, spesielt kjører det indre mobilitetssystemet via fjernaksessløsningen hvis mobilnoden kobler seg til fra utsiden. • De to systemene oppfyller forskjellige roller, idet det indre systemet er ansvar for brukerapplikasjonstransparens. Det ytre systemet er ansvarlig for transparens av selv sikkerhetsløsningen. • Konstruksjonen er åpen, og demonstrer uavhengighet mellom mobilitet og sikkerhet. • Det kombinerte systemet tilbyr fullstendig sømløs drift på begge sider, så vel som på tvers av sikkerhetsgrensen. • Kun klientsiden påvirkes. En dualmobilitetsklient er komponenten som muliggjør nyvinningen. • Dualklientprogramvarens kompleksitet er ikke større enn kompleksiteten til en enkelt klient. For det første er det andre mobilitetssystemet ikke alltid i bruk. For det andre, når det er i bruk er virkemåten nærmest triviell. • Den klientsentrerte tilnærmingen (i motsetning til en nettverkssentrert) muliggjør enkel, hurtigere og mer kosteffektiv utplassering. • Ingen krav til spesielle nettverkskonstruksjoner utover tilleggsmobilitetssystemet. Virker med eksisterende nettverkskonstruksjoner og krever ingen endringer i eksisterende infrastrukturkomponenter. • Muliggjør flerleverandørutplassering med uavhengig valg av mobilitetssystem og sikkerhetsløsninger. Særlig kan det dras fordel av tidligere investeringer. • Den kombinerte arkitektur er fleksibel og kan enkelt skaleres etter som hver av de tre bestanddelene kan utplasseres individuelt og skaleres uavhengig etter

behov.

• Krever ingen endringer (tilpasninger eller utvidelser) av mobilitets- eller sikkerhetsteknologi utover eksisterende standarder eller standarder som er under

utarbeidelse.

• Er basert på kun noen få fundamentale prinsipper som allerede inngår i alle relevante IPv4- og IPv6-standarder. Følgelig vil fremgangsmåten arbeide med

alle opsjoner, utvidelser og forsterkninger av disse protokollene.

• Fremgangsmåten virker også med andre mobilitets- og sikkerhetsprotokoller så lenge de deler den samme samling av grunnleggende egenskaper. • De indre og ytre mobilitetssystemene kan arbeide ved hjelp av forskjellige enheter, og har således ikke behov for å være deler av det samme administrative

domenet.

• Fremgangsmåten løser det kjente problem med å oppnå sømløs mobil-IP på tvers av en bedriftssikkerhetsgrense på en ny og bedre måte. • Fremgangsmåten kan anvendes til å løse tilsvarende problemer i et meget bredere omfang. Dette innbefatter nye forretningsmodeller for IP-mobilitet på tvers av offentlige operatører og private bedrifter.

Claims (14)

1. Anordning for bruk i mobil dataterminal (103) anordnet til kommunikasjon ved mobil-IP over et system som omfatter et ytre nett (107), et brannmurbeskyttet indre nett (105), i hvilket indre nett en indre hjemmeagent (130) er anordnet, og en ytre hjemmeagent (102) anordnet i det ytre nettet eller i en DMZ (106) i en brannmur (104) mellom det indre nettet og det ytre nettet, for tilveiebringelse av en dobbeltunnellert pakkedataforbindelse mellom en første applikasjon (121) i den mobile dataterminalen og en andre applikasjon (101) i en vertsdatamaskin tilsluttet det indre nettet, karakterisert vedat anordningen omfatter et dual-Mobil-IP-klientarrangement 115,116) innbefattende: en første mobil-IP-klientdel (116) konfigurerbar for assosiasjon med den indre hjemmeagenten, og en andre mobil-IP-klientdel (115) konfigurerbar for assosiasjon med den ytre hjemmeagenten, idet den første mobil-IP-klientdelen er anordnet til å videreformidle data mellom den første applikasjon og den andre mobil-IP-klientdelen, og den andre mobil-IP-klientdelen er anordnet til å formidle data mellom den første mobil-IP-klientdelen og det ytre nettet.

2. Anordning som angitt i krav 1, karakterisert ved at den andre mobil-IP-klientdelen er anordnet til også å formidle data mellom den første applikasjonen og det ytre nettet, og at den videre omfatter en innretning som: hvis terminalen aksesserer systemet via det ytre nettet, er anordnet til å tilveiebringe en første forbindelse mellom den første applikasjonen og den første mobil-IP-klientdelen, en andre forbindelse mellom den første mobil-IP-klientdelen og den andre mobil-IP-klientdelen, og en tredje forbindelse mellom den andre mobil-IP-klientdelen og det ytre nettet, og hvis terminalen aksesserer systemet via det indre nettet, er anordnet til å tilveiebringe en fjerde forbindelse mellom applikasjonen og den andre mobil-IP-klientdelen, og en femte forbindelse mellom den andre mobil-IP-klientdelen og det indre nettet.

3. Anordning som angitt i krav 1 eller 2, karakterisert ved at den første mobil-IP-klientdelen (116) er styrbar for aktivering og deaktivering, og at anordningen omfatter Mobil-IP-deteksjonsanordning innrettet til: å aktivere den første mobil-IP-klientdelen ved deteksjon av en kobling til det ytre nettet (107) ved en vellykket Mobil-IP-registrering fra den første mobil-IP-klientdelen til en ytre hjemmeagent (102) anordnet i brannmuren (104), og å deaktivere den første mobil-IP-klientdel (116) ved deteksjon av kobling til det indre nettet (105) ved en vellykket Mobil-IP-registrering fra den andre mobil-IP-klientdelen til en indre hjemmeagent (130).

4. Anordning som angitt i krav 1 eller 2, karakterisert ved at den første mobil-IP-klientdelen (116) er styrbar for aktivering og deaktivering, og at at anordningen omfatter Mobil-IP-deteksjonsanordning innrettet til å aktivere den første mobil-IP-klientdelen ved deteksjon av kobling til det ytre nettet (107) ved hjelp av en eller flere av følgende fire deteksjonsinnretninger: en første undersøkelsesinnretning som fastlegger en innkommende pakkes kilde-IP-adresse og som detekterer at adressen er utenfor konfigurert adresse-område for indre nett (105), en andre undersøkelsesinnretning som analyserer ICMP kontrollmeldinger og som detekterer at adressene er utenfor konfigurert adresse-område for indre nett (105), en tredje undersøkelsesinnretning som foretar en deteksjon av ytre hjemmeagent (102) ved utsending av registreringsmelding med feil sikkerhets-assosiasjon, og en fjerde undersøkelsesinnretning som sammenligner resultater fra første andre og tredje undersøkelsesfunksjon med historie samlet om MAC- og IP-adresser til Mobil-IP-fremmedagenter, -standardgateways, -WLAN-aksesspunkter, som angir at den mobile terminalen befinner seg i ytre nett, og at en eller flere av undersøkelsesinnretningene er anordnet til å indikere at den mobile terminalen (103) er koblet til et ytre nett.

5. Anordning som angitt i krav 1 eller 2, karakterisert ved at den første mobil-IP-klientdelen (116) er styrbar for deaktivering, og at at anordningen omfatter Mobil-IP-deteksjonsanordning innrettet til å deaktivere den første mobil-IP-klientdelen ved deteksjon av kobling til det ytre nettet (107) ved hjelp av en eller flere av følgende deteksjonsinnretninger: en første undersøkelsesinnretning som fastlegger en innkommende pakkes kilde-IP-adresse og som detekterer at adressen er innenfor konfigurert adresse-område for indre nett (105), en andre undersøkelsesinnretning som analyserer ICMP kontrollmeldinger og som detekterer at adressene er innenfor konfigurert adresse-område for indre nett (105), en tredje undersøkelsesinnretning som foretar en deteksjon av indre hjemmeagent (130) ved utsending av registreringsmelding med feil sikkerhets-assosiasjon, og en fjerde undersøkelsesinnretning som detekterer overenstemmelse i resultater fra den første, den andre og den tredje undersøkelsesinnretningen og historie samlet om MAC-og IP-adresser til Mobil-IP-fremmedagenter, -standardgateways, -WLAN-aksesspunkter, som angir at den mobile terminalen befinner seg i indre nett (105), og at en eller flere av undersøkelsesinnretningene er anordnet til å indikerer at den mobile terminalen (103) er koblet til et indre nett.

6. Anordning som angitt i et hvilket som helst av de foregående krav, karakterisert ved at anordningen videre omfatter: en sikkerhetsklientdel innskutt mellom de første og andre mobil-IP-klientdelene og konfigurerbar for over en sikkerhetsanordning anbrakt mellom de ytre og indre nettene å etablere en sikker forbindelse mellom den mobile datatreminalen og det indre nettet.

7. En Mobil-IP-terminal, karakterisert ved at den omfatter en anordning som angitt i et hvilket som helst av kravene 1 til og med 6.

8. En databærer omfattende datamaskinkode som er irmlastbar og eksekverbar i en terminaldatamaskin, karakterisert ved at når den er innlastet og eksekveres i terminaldatamaskinen bevirker opprettelsen av en anordning som angitt i et hvilket som helst av kravene 1 til og med 6.

9. Datakommunikasjonssystem for tilveiebringelse av en Mobil-IP pakkedataforbindelse mellom en første applikasjon (121) i en mobil dataterminal (103) med et dual-Mobil-IP-klientarrangement (115,116) og en andre applikasjon (101) i en vertsdatamaskin tilsluttet et brannmurbeskyttet indre nett (105), hvilket system innbefatter det indre nettet, et ytre nett (107) og en ytre hjemmeagent (102) anordnet i det ytre nettet eller i en DMZ (106) i en brannmur (104) mellom det indre nettet og det ytre nettet, karakterisert ved at systemet innbefatter en indre hjemmeagent (130) anordnet i det indre nettet, at en den indre hjemmeagenten er konfigurerbar for assosiasjon med en første mobil-IP-klientdel (116) i den mobile dataterminalen, og at den ytre hjemmeagenten er konfigurerbar for assosiasjon med en andre mobil-IP-klientdel (115) i den mobile dataterminalen, idet den første mobil-IP-klientdelen er anordnet til å videreformidle data mellom den første applikasjonen og den andre mobil-IP-klientdelen, og den andre mobil-IP-klientdelen er anordnet til å formidle data mellom den første mobil-IP-klientdelen og det ytre nettet.

10. System som angitt i krav 9, karakterisert ved at den andre mobil-IP-klientdelen er anordnet til også å formidle data mellom den første applikasjonen og det ytre nettet, og at systemet eller den mobile dataterminalen innbefatter en innretning som: hvis terminalen aksesserer systemet via det ytre nettet, er anordnet til å tilveiebringe en første forbindelse mellom den første applikasjonen og den første mobil-IP-klientdelen, en andre forbindelse mellom den første mobil-IP-klientdelen og den andre mobil-IP-klientdelen, og en tredje forbindelse mellom den andre mobil-IP-klientdelen og det ytre nettet, og hvis terminalen aksesserer systemet via det indre nettet, er anordnet til å tilveiebringe en fjerde forbindelse mellom applikasjonen og den andre mobil-IP-klientdelen, og en femte forbindelse mellom den andre mobil-IP-klientdelen og det indre nettet.

11. System som angitt i krav 9 eller 10, karakterisert ved at den første mobil-IP-klientdelen (116) er styrbar for aktivering og deaktivering, og at systemet eller den mobile dataterminalen innbefatter en Mobil-IP-deteksjonsanordning innrettet til: å aktivere den første mobil-IP-klientdelen ved deteksjon av en kobling til det ytre nettet (107) ved en vellykket Mobil-IP-registrering fra den første mobil-IP-klientdelen til en ytre hjemmeagent (102) anordnet brannmuren (104), og å deaktivere den første mobil-IP-klientdel (116) ved deteksjon av kobling til det indre nettet (105) ved en vellykket Mobil-IP-registrering fra den andre mobil-IP-klientdelen til en indre hjemmeagent (130).

12. System som angitt i krav 9 eller 10, karakterisert ved at den første mobil-IP-klientdelen (116) er styrbar for aktivering og deaktivering, og at systemet eller den mobile dataterminalen innbefatter en Mobil-IP-deteksjonsanordning innrettet til å aktivere den første mobil-IP-klientdelen ved deteksjon av kobling til det ytre nettet (107) ved hjelp av en eller flere av følgende fire deteksjonsinnretninger: en første undersøkelsesinnretning som fastlegger en innkommende pakkes kilde-IP-adresse og som detekterer at adressen er utenfor konfigurert adresse-område for indre nett (105), en andre undersøkelsesinnretning som analyserer ICMP kontrollmeldinger og som detekterer at adressene er utenfor konfigurert adresse-område for indre nett (105), en tredje undersøkelsesinnretning som foretar en deteksjon av ytre hjemmeagent (102) ved utsending av registreringsmelding med feil sikkerhets-assosiasjon, og en fjerde undersøkelsesinnretning som sammenligner resultater fra første andre og tredje undersøkelsesfunksjon med historie samlet om MAC- og IP-adresser til Mobil-IP-fremmedagenter, -standardgateways, -WLAN-aksesspunkter, som angir at den mobile terminalen befinner seg i ytre nett, og at en eller flere av undersøkelsesinnretningene er anordnet til å indikerer at den mobile terminalen (103) er koblet til et ytre nett.

13. System som angitt i krav 9 eller 10, karakterisert ved at den første mobil-IP-klientdelen (116) er styrbar for deaktivering, og at systemet eller den mobile dataterminalen innbefatter Mobil-IP-deteksjonsanordning innrettet til å deaktivere den første mobil-IP-klientdelen ved deteksjon av kobling til det ytre nettet (107) ved hjelp av en eller flere av følgende deteksjonsinnretninger: en første undersøkelsesinnretning som fastlegger en innkommende pakkes kilde-IP-adresse og som detekterer at adressen er innenfor konfigurert adresse-område for indre nett (105), en andre undersøkelsesinnretning som analyserer ICMP kontrollmeldinger og som detekterer at adressene er innenfor konfigurert adresse-område for indre nett (105), en tredje undersøkelsesinnretning som foretar en deteksjon av indre hjemmeagent (130) ved utsending av registreringsmelding med feil sikkerhets-assosiasjon, og en fjerde undersøkelsesinnretning som detekterer overenstemmelse i resultater fra den første, den andre og den tredje undersøkelsesinnretningen og historie samlet om MAC-og IP-adresser til Mobil-ff-fremmedagenter, -standardgateways, -WLAN-aksesspunkter, som angir at den mobile terminalen befinner seg i indre nett (105), og at en eller flere av undersøkelsesinnretningene er anordnet til å indikere at den mobile terminalen (103) er koblet til et indre nett.

14. System som angitt i krav 9,10,11,12 eller 13, karakterisert ved at det videre innbefatter: en sikkerhetsanordning anbrakt mellom det indre nettet og det ytre nettet for tilveiebringelse av en sikker forbindelse mellom den mobile dataterminalen (103) og det indre nettet, idet en sikkerhetsklientdel er anordnet i den mobile dataterminalen (103) og innskutt mellom den første mobil-IP-klientdelen og den andre mobil-IP-klientdelen, hvilken sikkerhetsklientdel er konfigurerbar til å etablere den sikre forbindelsen.