IPv6 - En Maginot Linie ?

IPSec er godt til VPN og ikke så meget andet. Systemet er besværligt at sætte op og virker kun mellem to på forhånd aftalte punkter.

Det vil aldrig kunne beskytte e-handel da forbrugeren og butikken ikke på forhånd har haft mulighed for at aftale kryptering.

Der var på et tidspunkt et forsøg på at promovere "opportunistisk kryptering". Ideen var at bruge DNS til at kommunikere certifikater og krypteringsmetode. Hvis systemet havde været en succes, kunne det have gjort logningbekendtgørelsen mindre effektiv. I dag logger man port, protokol, UDP hver 500. pakke, TCP sessoner start/slut, IP src/dest. IPSec kan reducere det til kun IP src/dest.

Identification i IPv6 er tilsvarende IPv4 med NAT. De sidste 64 bit i adressen ignoreres. Da har du nok til at finde adressen på ejeren (hvis du er advokat for pladebranchen) men du kan ikke pege på en bestemt computer. Ligesom du heller ikke kan med IPv4+NAT. Forudsat at der benyttes privacy extensions men det er også slået til som standard på Windows Vista og Windows 7.

Privacy extension i Linux kernen er i øvrigt buggy. Det virker i et par timer indtil det går i stå og man ender med en IP adresse baseret på MAC-adressen. Og så er det ikke standard slået til, i hvert fald ikke på Ubuntu 10.04. Linux er bagefter her. Hvordan ser det ud i BSD verdenen?

Emnet er diskuteret før.

For god ordens skyld samler jeg op på problemerne.

a) Det er en grov fejl at fastlåse sikkerhed i netværkslaget. Sikkerhed skal være forhandlet og ikke fastlåst af en eller anden forældet lukket standard som IPv6 - og det skal slet ikke bygge på serverside Identifikation.

b) /64 mekanismen tilfører ingen væsentlig værdi fordi den første del af adressen ikke kan randomiseres. HELE adressen skal være totalt random så man ikke får sammenblandet hel eller delvis identifikation ind i processen.

I praksis betyder det at alle væsentlige installationer som minimum skal være bag en NAT, dvs. det er løgn at IPv6 kan spare en NAT.

I HYDRA-projektet om interoperabilitet var vi nødt at bygge en post-IPv6 adresse randomisering ind for at isolere IPv6-fejlene.

c) IPv6 prøver at fratage devicen kontrollen over identity management.

Fordi perimetersikkerheden og navnlig databasesikkerheden bryder ned, vil identifikation af Devices gøre både devices, servicen og personer stadigt mere sårbare.

Modtrækket hertil er at de fleste devices logisk vil skal fremstå som forskellige devices afhængig af den kontekst, de indgår i.

Bedst eksemplificeret med RFID, hvor forsøget på kunstigt at begrænse adresse-rummet for at skabe en kommerciel central gatekeeperkontrol (EPC Global) fik intens modstand fra alle sider.

En RFID-device må slet ikke må kunne detekteres identificerbart efter point-of-sales. Hvis det ikke skal føre til totalt deaktivering, så forudsætter det at enheden hele tiden kan antage nye repræsentationer, dvs. ikke er fastlåst til en persistent identifier.

Hvordan den konkrete adressing (f.eks. peer-to-peer) fungerer kan antage mange forskellige måder som alle skal resolves på et højere lag end netværksprotokollen. For at muliggøre nye løsninger er det vigtigt at det er model-drevet, dvs. først afgøres runtime i henhold til den model-beskrivelse som devicen udpeger.

Vi kørte i HYDRA-projektet en interoperabilitets-demonstration med fokus på sikkerhed, hvor vi model-drevet resovlede en RFID direkte i en Cloud repræsentation mod en vilkårlig service uden noget sted at lække persistente identifiers.

Der er sikkert mange gode ting ved IPv6, men forsøget på at fastlåse sikkerhed i metoder som allerede er forældede og ikke kan tilpasse sig kontinuert er en alvorlig og kritisk fejl. Specielt for man blander det ind i den grundliggende infrastruktur, hvor alt og alle rammes af fejlene.

IPV6 er ikke interoperabel og vil de fakto diktere en verdensforståelse som vi allerede ved ikke er holdbar fordi det koncentrerer magt i stadigt færre og større enheder. Problemet er at dem som træffer beslutningerne umiddelbart tror at de gerne vil have en sådan verden - lige indtil de erkender at det også rammer dem selv og de ikke er den største fisk i dammen.

PHK

Hvorfor så aggressiv? "alle mine kæpheste" er en både urimelig og forfejlet kritik.

Jeg eksemplificerer med udvikling som er gjort og med faktiske problemer hvor markedet har reagerer imod de fejl som også indgå i IPv6 - det er vel bedre end rent teoretiske betragtninger !?

Pointen var ikke RFID, men device-adgang til nettet som sådan. De små enheder vil under alle omstændigheder skulle via en enhed som kan køre IP. Hvis readeren fastlåses med IPv6 så flytter problemet bare og vi skal se reader-delen og RFID som en samlet logisk enhed.

Det logiske problem i RFID-protokollen er ikke anderledes end for enheden koblet på IP. Det vigtige er at vi skal koble disse spørgsmål helt ud af netværkslaget. Generel etablering af sessions må ikke begrænse eller diktere applikationen.

HYDRA er all-IP middleware baseret på virtualisering. Vores konklusion var at vi IKKE kunne nøjes med IPv6, men var nødt til - af hensyn til sikkerhed og interoperabilitet - at gå videre allerede inden IPv6 er implementeret. Vi var nødt til at pakke IPv6 ind, så vi kunne undgå at de åbne model-drevne interfaces blev fastlåst til IPv6 fejlene.

Rent logisk betyder det f.eks. IPSEC mappes op i et højere lag, dvs. funktionaltieten er der stadig end-to-end, men det må ikke være en del af netværkslaget fordi nøglehåhdteringen ikke er virtuel (nok).

Hvorfor mener du ikke at det er relevant?

Hvorfor så aggressiv? "alle mine kæpheste" er en både urimelig og forfejlet kritik.

Kunne det være fordi vi skal udsættes for dit pladder gang på gang?

Lange, forvrøvlede indlæg, der kun marginalt rører ved emnet, men fordi der har været et eller andet keyword der har triggered dig, skal der absolut sendes en lang smøre afsted.

At der ofte er sandheder gemt et eller andet sted, bliver mere og mere overset, fordi det bliver kastet efter alt, og man bliver så træt af det.

Du kvæler din egen sag.

Hvad er det relevante emne !?

IPv6 er en Maginot linje - dvs. som antages, men reelt ikke sikrer.

Jeg fokuserede eksplicit på sikkerhedsproblemer ved IPv6 og hvordan vi i praksis har arbejdet på at håndtere dem.

I IPv6 kan addresser enten bruges til mere identifikation end godt er, fordi de indeholder MAC addressen, eller overhovedet ikke, fordi de er transiente indenfor /64 blokken.

Jeg giver dig ret i første del, men påpeger at den sidste del er misforstået - /64 lækker stadig data som vi ikke vil have kodet ind i addressen.

Det medfører direkte at vi IKKE slipper af med NAT fordi sikkerheden ikke er på plads - NAT giver mulighed for at dekoble devicens interface fra det synlige online og det tjener flere formål end blot mapping af IP-adresser. Det beskytter også devices fra omgivelserne.

Man har begravet end-to-end kryptering nede i IPv6 netværkstakken, af hensyn til sikkerheden

Og her ligger styringen for lavt i stakken hvor den ikke er fleksibel nok. Den er ikke interoperabel eller åben for kontinuert opgradering.

Problemet med IPv6 er primært at man prøver at løse noget i netværkslaget som ikke hører til i netværkslaget. Den type problemer kan du ikke løses ved at ændre lidt i IPv6.

Og høfligst - så er det ikke "noget som lige irriterer dig nu" - det er varige faktiske problemer ved IPv6 som vi kommer til at slås med. Uanset om man ser dem eller blot lider under dem fordi de forhindrer det som burde ske.

@ Dennis

??

Problemerne går ikke væk fordi du vælger at ignorere dem eller ikke forstår dem. De bliver kun større.

Min erfaring er at folk er blinde for de aspekter som går udover deres snævert indstuderede og implicitte fagopfattelser. Der er stadig nogle som tror at man kan basere sikkerhed på identifikation, nogle som tror at man kan effektivisere ved at flytte kontrollen væk fra dem som har og kender behovet og nogle som tror at open source giver åbne standarder.

Hvordan vil du adressere problemerne, hvis ikke når de komme til udtryk?

Jeg har svært ved at se hvordan Hydra er relevant i en debat om IPv6. En søgning på IPv6 på Hydra webside viser meget lidt aktivitet omkring IPv6 i det projekt:

http://www.google.dk/search?q=site:www.hydramiddleware.eu+ipv6

Det der står om IPv6 på hydramiddleware er positivt.

P2P approach is going to be used, fulfilling all HYDRA special requirements, and using all the advantages IPv6 can offer to this kind of communication. ...

Baldur

Et i denne sammenhæng signifikant aspekt ved HYDRA er, at man IKKE bare valgte IPv6 på netværkslaget, men selv byggede netværksstakken og random adressegenering OVENPÅ Ipv6. Det skyldes at vi netop var stødt på og gået videre end de problemer, PHK påpegede.

Du skal længere ned i deliverables for at se de konkrete argumenter og løsninger. Men HYDRA burde også snart komme i en open source udgave.

I HYDRA flytter vi de opgaver op i de højere og dermed fleksible/udskiftelige lag eller rettere skiller dem i en session-relateret del og en logisk devicerelateret del.

Du kan godt have IPSEC på sessiongenererede nøgler uden at det reelt siger noget om den bagvedliggende device - der udestår bare vigtige sikkerhedsspørgsmål som skal håndteres og forhandles i de højere lag. Det er ikke simple spørgsmål fordi HYDRA behandler alle devices som virtuelle devices, dvs. de kan bestå af mange devices elementer hvoraf nogle kan være rene softwaremoduller (kritisk for at kunne opgradere gamle hardwaredevices med ny funktionalitet). Det rejser en del spørgsmål om f.eks. deviceintegritet eller intra-device man-in-the-middle.

I praksis er man selvfølgelig nødt til at bruge både IPv4 og IPv6 på transportlagene. Og devices kan ikke mere end devices kan, dvs. har de ikke mekanismer til at beskytte sig selv, så kan man højst "pakke dem ind" og isolere dem med ydre firewalls.

Der hvor vi skiller er, at IPv6 ikke løfter sin opgave med at beskytte hverken device eller applikation.

Det undrer mig så at både PHK og Dennis går efter manden (og påberåber out of topic) istedet for efter bolden.

Der er en udpræget misforståelse om, at NAT er svaret på al netværkssikkerhed: "Når man er bag NAT, kan man ikke rammes af noget som helst".

Det passer jo bare ikke. Malware kan komme ind på mange måder - USB-nøgler, fejl i applikationer med internet-adgang (browsere og PDF-læsere) og så videre.

Hvad værre er: hvis én maskine bag en NAT bliver inficeret, kan den sprede sit malware internt på det "sikre netværk", ofte ganske uhindret, da brugeren mener, at han med NAT har løst alle sine sikkerhedsproblemer én gang for alle.

Malware kan også etablere forbindelser gennem NAT ved at "vende" trafikken om: for eksempel ved at lade den berørte klient kontakte en maskine på nettet. Det tillader de fleste NATs ret ukritisk, og om ikke andet kan man bruge port 80 (web-trafik), som er åben praktisk talt alle steder. Via denne forbindelse til malware-bagmanden, der er foretaget INDE FRA det sikre netværk, kan bagmanden nu i ro og mag udnytte den angrebne maskine og kontakte alle øvrige enheder på det "sikre" netværk.

NAT er altså i mange tilfælde (jeg vil endda vove at sige hovedparten) falsk sikkerhed. Man kan ikke med god samvittighed læne sig tilbage og erklære noget som helst sikkert, blot der er NAT involveret.

IPv6 har - i modsætning til IPv4 - en mekaniske indbygget til lokal kommunikation: Link-local. Det er et adresserum, der er beregnet til kommunikation mellem enheder på et lokalt netværk, som IKKE har behov for at komme i forbindelse med andet end netværket selv. Man kan drage en forsigtig parallel til RFC1918-adresser i IPv4, så længe man ikke blander NAT ind i det. Link-local bliver endda sat op helt automatisk, så denne feature findes uden at man skal røre en finger. Fantastisk!

Link-local er ikke sikkert i sig selv, og det er sårbart over for præcis det samme scenarie som NAT ovenfor: at hvis en maskine med adgang udadtil (en routed IPv6-adresse for eksempel) bliver hacket eller inficeret, så er der også adgang fra denne maskine til link-local-enheder på samme netværk.

Det ændrer dog ikke på pointen: Med brugen af link-local kan man i mange tilfælde undgå NAT i de situationer, hvor man har behov for både lokal og global trafik på samme netværk.

Jeg har imidlertid svært ved at se den ekstra udfordring ved, at alle "personlige" enheder er på Internettet og i et eller andet omfang kan identificeres og kontaktes. Der er selvfølgelig "privacy", men det bliver ikke værre eller bedre med en /64 end en IPv4-adresse (med eller uden NAT bagved). At man i værste fald kan identificere det anvende netkort til at være et 3Com, ser jeg heller ikke noget stort problem i.

Selv hvis man via MAC-adressen kan identificere en enhed til at være et Siemens køleskab, har jeg svært ved at se problemet. Det er for det første slet ikke sikkert, at det er et køleskab - det kan også være 3Com-netkortet fra før, der blot ikke anvender MAC-adressen som "forventet".

Og hvis det endelig er et køleskab, som måske endda kan styres, bør køleskabet have sin egen sikkerhed, og ikke noget der er baseret på tvivlsom "obfuscation" såsom hemmelig IP-adresse eller et mislykket forsøg på at "gemme" IP-adressen og applikationen bag en "defekt" NAT.

Alt, der er på et netværk, skal i sig selv være sikkert. Man kan ikke forvente, at netværket løser den opgave for én. Hvilket også betyder, at fremtidens køleskabe må få sig en USB-port, så man kan opgradere deres firmware. Hvis de altså skal på nettet.

Præcis samme betragtninger gælder for netværksenheder, styresystemer og applikationer. Den generelle tilstand er yderst sørgelig i dag, men det er ikke IPv6's skyld. Det er heller ikke IPv6's opgave at løse det problem.

Løsningen(tm) er først og fremmest at få leverandørerne af software til at fokusere endnu mere på sikkerhed, end de gør i dag. Og at konstatere, at hvis noget er designet til at køre bag en NAT, er det sikkerhedsmæssigt uforsvarligt og bør undgås for enhver pris, medmindre det udelukkende bliver kørt på et helt lukket netværk uden nogen som helst form for adgang til omverdenen (inklusiv andre maskiner med adgang til omverdenen).

Udrulning af IPv6 vil med garanti skabe et marked for tumpede NAT-løsninger, nye "personlige firewalls" og en masse andet snake oil. Man kan håbe på, at det i praksis også vil betyde et større fokus på sikkerhed tæt på kilden (OS, applikationer), efterhånden som flere og flere netop fravælger NAT. Det giver jo heller ikke leverandørerne god reklame, at deres OS/applikation bliver angrebet med succes i stort omfang.

Klaus

Jeg er som sådan ikke uenig i dine betragtninger omkring at man ikke skal have naive antagelser om hvor megen sikkerhed NAT bibringer. Omvendt giver NAT en masse sikkerhed, hvor det f.eks. tilsikres at dårligt designede devices (i forhold til behovet) kan pakkes ind i ydre firewalls (skabe en virtuel device udvidet med en device-specifik firewell og evt. yderligere funktionalitet) så man både kan tunnellere adgangen ud, opgradere devicen, filtrere uønskede leak ud (f.eks. MAC) og kan blokere adgangen ind.

Det tekniske problem er at IPV6 er one-size-fits-all, men klart ikke løser problemener og skaber nye. At låse alting til en fastlåst og ufleksibel standard er dumt.

Det markedsmæssige problem er bl.a. at leverandørne er for langt fra behovet og behovet ikke kan udtrykkes ex ante. I praksis dominerer systeminteresser over slutbehov, dvs. de tekniske design forhindrer de frie valg MELLEM TEKNISKE ALTERNATIVER i at komme til udtryk runtime. Sikkerhed er ikke kun hvad producenten kan og den 3. parts kriminelle ikke kan, men meget ofte også hvad producenten eller operatøren ikke kan eller ikke kan forhindre.

Omvendt giver NAT en masse sikkerhed, hvor det f.eks. tilsikres at dårligt designede devices (i forhold til behovet) kan pakkes ind i ydre firewalls (skabe en virtuel device udvidet med en device-specifik firewell og evt. yderligere funktionalitet) så man både kan tunnellere adgangen ud, opgradere devicen, filtrere uønskede leak ud (f.eks. MAC) og kan blokere adgangen ind.

Udfordringen er, at man med NAT giver enhver hacker mulighed for at administrere disse devices, blot han kan finde en vej ind gennem NAT'en. Det er ren "security by obscurity". Man har gravet sin hovednøgle ned i et blomsterbed og håber, at indbrudstyven ikke gider lede efter den.

Intet af dette skyldes IPv4 eller IPv6. Det skyldes, at løsningen(s delkomponenter) er dårlige. Årsagen hertil er sådan set underordnet.

Udfordringen er, at man med NAT giver enhver hacker mulighed for at administrere disse devices, blot han kan finde en vej ind gennem NAT'en. Det er ren "security by obscurity". Man har gravet sin hovednøgle ned i et blomsterbed og håber, at indbrudstyven ikke gider lede efter den.

Det er fordi du antager mere end jeg siger.

Faktum er at der er "gamle" devices. Du kan vælge at smide dem ud eller pakke dem ind. Du vil ALDRIG være i en situation hvor alle devices kører det samme og selv hvis man teoretisk kunne det, så ville det være noget fastlåst skidt.

Om du vælger at købe en ny device med funktionalitet indbygget eller sampakke en fysisk enhed med logiske services afhænger af mange ting.

Men selvfølgelig vil modparters sikkerhed også afhænger heraf, dvs. de vil VIDE om det f.eks. er en tamperresistent nøglekort eller blot noget softkey.

Sikkerhed skal passe til formålet. Det er hverken rationelt at have for megen sikkerhed uden behov eller for lidt som ikke dækker behovet. Man virtualsiering (og navnlig IKKE-identifikation) er klart den måde man får mest sikkerhed for pengene i en all-digital world (jeg vil gå så vidt som til at kalde det en forudsætning for sikkerhed) - og det kan IPv6 IKKE levere.

Eller du vil måske låse alle til en opgraderingsfilosofi hvor man skal købe nyt hvert andet år?

Man virtualsiering (og navnlig IKKE-identifikation) er klart den måde man får mest sikkerhed for pengene i en all-digital world (jeg vil gå så vidt som til at kalde det en forudsætning for sikkerhed) - og det kan IPv6 IKKE levere.

Nej, og ret beset er det heller ikke IPv6's opgave. Det var tænkt ind engang, men det var dengang, hvor IPv4 stadig havde masser af adresser og NAT næsten var et ukendt fænomen. Verden har ændret sig på mange fronter siden da.

IP er et transportlag. Sikkerhed er den enkelte komponents ansvar. Hvis man uddelegerer ansvaret, skal man være sikker på, at den uddelegerede enhed giver den nødvendige sikkerhed.

Som jeg skrev, er det næsten garanteret, at NAT ikke løser den opgave i hovedparten af de eksisterende installationer. Hvilket giver NAT et ret dårligt ry. Samtidig er NAT en elendig teknologi, der kun er opfundet for at løse problemet med manglende adresserum i IPv4. NAT introducerer langt flere problemer, end det "løser". Omend man altid kan finde nogle specialtilfælde, hvor det virker helt fint.

Hvis man endelig skal lave noget på IPv6, bør det være en stateful firewall (1:1). Det er stadig en ualmindeligt ringe løsning i forhold til at sikre enhederne, men det er bedre end NAT.

Problemet er at IPv6 blander sig i og forværrer problemstillingen voldsomt ved at trække problemstillinger ned i netværkslaget hvor de ikke hører hjemme.

IPv4 var neutral herom, dvs. det er en voldsom forværring.

Enig omkring NAT som en simpel implementering af en stateful firewall, men at der er mange flere aspekter heri. Avanceret 2-vej forhandling og resolution af sikkerhedsregler er pt. ikke standardiseret. XACML er pt. kun envejs, dvs. ignorerer device, location og device-owner

Ideelt set hører denne firewall hjemme i devicen, men de færreste devices og protokoller er designet til den digitale verden, vi allerede er godt på vej ind i.

IPv4 var neutral herom, dvs. det er en voldsom forværring.

Den er jeg ikke med på. Hvilken nyskabelse i IPv6 er det du tænker på?

Om noget, så er IPv6 bare mere af det gamle. 128 bit i stedet for 32 bit, men ellers ingen forskel.

Alt du kunne med IPv4 kan du også med IPv6. Og næsten alt du kan med IPv6 kan du allerede i dag med IPv4 (bortset fra nok adresser til alle). IPSec - findes også til IPv4. Source specifik multicast - findes også til IPv4. Faktisk kan jeg ikke på stående fod nævne en teknologi der ikke er blevet backported fra IPv6 til IPv4.

NAT? Ja, det kan du også med IPv6, selvom jeg tvivler på at du finder ret mange følgesvende der gider.

NAT? Ja, det kan du også med IPv6, selvom jeg tvivler på at du finder ret mange følgesvende der gider.

Men uden NAT skal serveren i den anden ende vel vide præcist hvilken klient på dit LAN som svaret skal sendes til? Hvis det beskytter mit privatliv, gider jeg godt NAT og dets ulemper.

Tanken om at sende en MAC adresse til den fremmede server (som en del af IPv6 adressen) synes jeg er temmelig problematisk når man ved hvor meget geolocation profiling der bliver lavet på grundlag af MAC adresser (af firmaer som Google).

En anden ting er at mange husstande vil have en del "legacy" media players, PVR boxe, BD afspillere etc med netværk som næppe understøtter IPv6. WAN siden af folks routere bliver formentlig IPv6 længe før LAN siden.

Apropos svagheder i IPv6 mv., så har van Hauser har netop frigivet en (længe ventet) opdatering til THC-IPV6 Attack Toolkit - se http://freeworld.thc.org/thc-ipv6:

A complete tool set to attack the inherent protocol weaknesses of IPV6 and ICMP6, and includes an easy to use packet factory library.

Men uden NAT skal serveren i den anden ende vel vide præcist hvilken klient på dit LAN som svaret skal sendes til? Hvis det beskytter mit privatliv, gider jeg godt NAT og dets ulemper.

Ja, hvis du synes kan du sagtens have en router der laver NAT. Eller for den sags skyld kan du køre med en god gammeldags proxy server.

Men der er opfundet bedre løsninger - "privacy extension". Det går ud på at din computer med jævne mellemrum skifter de sidste 64 bit i IP-adressen til en ny tilfældig værdi.

Tanken om at sende en MAC adresse til den fremmede server (som en del af IPv6 adressen) synes jeg er temmelig problematisk når man ved hvor meget geolocation profiling der bliver lavet på grundlag af MAC adresser (af firmaer som Google).

MAC adressen bruges kun i din IPv6 adresse hvis du IKKE bruger DHCPv6 og IKKE bruger privacy extensions og IKKE har valgt en anden metode (for eksempel manuel tildeling).

Som tidligere nævnt, så bruger moderne Windows operativsystemer privacy extension som standard. Dermed kommer du ikke til at se MAC-adressen på mange Windows brugere.

En anden ting er at mange husstande vil have en del "legacy" media players, PVR boxe, BD afspillere etc med netværk som næppe understøtter IPv6. WAN siden af folks routere bliver formentlig IPv6 længe før LAN siden.

Alt tyder på at dette bedst løses med dual stack. Det vil sige, du får både et IPv6 subnet og en IPv4 adresse. Din IPv4 adresse bliver muligvis udsat for NAT på ISP niveau. Man har reserveret IPv4 adresser til ISP-NAT så nye ISP'er også i fremtiden kan få tildelt adresser til dette formål.

Men der er opfundet bedre løsninger - "privacy extension". Det går ud på at din computer med jævne mellemrum skifter de sidste 64 bit i IP-adressen til en ny tilfældig værdi.

Sorry - det løser ikke problemet eftersom det kun er halvdelen af adressen som skiftes. I praksis giver det kun en reduceret mulighed for denail of service, men ingen brugbar privacy sikring.

Et af problemerne med Ipv6 er at det giver producenten alt for stærke værktøjer og intet som sikrer ejeren kontrollen.

De oprindelige internet protokoller er stærke fordi de netop ikke er dikterende, men ekstremt åbne på netværkslaget. Man glemte bare at bygge tilstrækkeligt gode og interoperable sikkerhedsprotokoller ovenpå. Nu bygger IPv6 dårlige sikkehredsmekanismer ind i netværkslaget og derme for vi det værste af begge verdener - hverken åbent eller sikkert.

NAT giver ingen ekstra beskyttelse ud over hvad du får ved privacy extension.

Privacy extension giver derimod den ekstra beskyttelse, at det også virker "inden for muren".

Jeg tvivler på at det er muligt at udvikle et effektivt net, med de egenskaber du ønsker.

Du har endnu ikke forklaret hvor du mener IPv6 adskiller sig fra IPv4 med hensyn til åbenhed i netværkslaget.

IPv6 tilfører ingen nye sikkerhedsprotokoller. Der er tale om IPsec, som i et årti også har været brugt på IPv4.

For det første er jeg enig i at sikkerheden hører hjemme i selve devicen - men ikke på den måde IPv6 gør det og sikkerhed er altid under forandring. Privacy extentions regner jeg ikke for meget - det er hverken fugl eller fisk.

For det andet er antagelsen af en NAT nok til at man kan indbygge ikke bare en "statefull firewall" (som Klaus kaldte det), men også mixnet og alt det andet (ressourcesvage trådløse devices vil delegere meget til andre devices). Se "NAT" som en placeholder til noget som nødvendigvis skal udbygges snarere end som en løsning som du kender den.

For det tredje er IPsec fint hvis det er sessionbaseret og ikke dikterer identity management. Netværkslaget skal holde sig til sessioner. Device/IDMgt kan ikke afgøres på det lag. F.eks. bør der gøres meget mere ud af sessioninitiering peer-to-peer i en åben forhandling.

For det fjerde er et "effektivt" net absolut ikke et totalt homogent og transparent net som nærmest garanterer at kontrollen ligger forkert. Tværtimod.

Der er i min optik reelt kun 2 forskellige topologier - den hvor infrastrukturen kan identificere enheder som går på nettet og den hvor infrastrukturen IKKE kan identificere Endpoints. Dvs. ligger kontrollen centralt i nettet eller udenfor nettet. Førstnævnte er efter opfattelse destabiliserende. Eftersom vi kun har et net, så vil enhver fysisk device skulle have mange logiske repræsentationer. IPv6 antager en device - en adresse.

Stephan måske du kunne overtales til faktisk at svare på mine spørgsmål? Hvori ligger forskellen på IPv4 vs IPv6? (hint: der er ingen)

NAT kan ses som en 64 bit adresse bestående af 32 bit fra NAT routerens adresse og 32 bit fra klientens adresse. Kun halvdelen af bitsne skjules. Præcis det samme som privacy extensens.

Billige NAT routere, som dem folk har stående hjemme, har typisk IKKE stateful firewall. En stateful firewall holder styr på TCP sessoner og blokerer pakker der ikke hører til nogen sesson. En billig NAT nøjes med at huske port-IP relationen og interesserer sig ikke for sessoner. Det er forudsætningen for at teknikker som NAT traversals virker.

Konsekvensen er blandt andet at hvis man portscanner en typisk hjemme-ADSL så finder man, måske til ejerens overraskelse, masser af åbne porte som fører direkte til de aktive computere inde på nettet. Den fremmede trafik bliver IKKE stoppet.

Det er meget uheldigt at tro at NAT i sig selv har en firewall funktion, for det er ikke tilfældet.

Baldur

At IPv6 har meget tilfælles med IPv4 plus backporting ændrer ikke på problemet. Den basale IPv4 har ikke sikkerhed i netværkslaget og sådan skal det være - medmindre det er ren sessionsupport for en virtualiseret device. Men Ipv6 kan ikke understøtte virtualisere devices.

Jeg prøver ikke at blæse sikkerhedsværdien af de simple NATs op - det er dig som argumenterer mod din egen stråmand. Men behovet starter med de simple NAT og eskalerer derfra afhængig af device, lokation og transaktion.

En kritisk funktion kunne være at isolere en device fra nettet og flytte exit-punktet så man ikke kan se en persistent deviceid eller hvor den er lokaliseret, dvs. devicen kan serviceres selvom man ikke ved HVEM som bruger/ejer devicen.

Det bliver f.eks. åbenlyst kritisk ved kombinationan af Cloud og Telemedicin. Her må cloud-servicen slet ikke kunne detektere en persistent deviceadresse/identificer/location etc.

Jeg forventer f.eks. at man i fremtiden vil gøre udstrakt brug af WIFI eller lignende som led i routningen for netop at eliminere endpoint traceability. Du kan altid i de højere lag tilføre de ønskede beviser, men du har en udfordring med at dekoble lokation effektivt for stationære devices.

At IPv6 har meget tilfælles med IPv4 plus backporting ændrer ikke på problemet.

Men så er vi tilbage ved PHKs indsigelse - hvad laver du i denne debat om IPv6 når de emner du fremfører ikke har en skid at gøre med IPv6 vs IPv4? Hvorfor bliver du ved med at nævne NAT, selvom NAT ingen forskel gør?

Vi kan hurtigt bliver enige om at IPSec ikke er meget værd (til andet end VPN). Det vil derfor ikke blive brugt. Dermed er situationen den samme som ved IPv4, nemlig at der ikke er noget (brugbart) sikkerhedslag i netstakken.

Den eneste forskel på IPSec i IPv6 i forhold til IPSec i IPv4 er at det nu er en krævet del. Det har dog ikke forhindret massere i at implementere IPv6 uden IPSec. Så det er vist ikke andet end værdiløse ord i en RFC.

ZZZZZZZZzzzzzzz....... (Jeg er klar over nogle måske bliver fortørnet over dette indlæg)

Bare lige for saglighedens skyld.

Jeg forstår ikke hvorfor folk har lyst til at komme med så meget urelevant ordgøgl gang på gang? Kan I ikke bruge jeres tid lidt bedre og gør jeres indlæg noget kortere og holde dem til sagens kerne. Når I gør som I gør, forhindrer I alle andre i at deltage i debatten og stille opklarende spørgsmål til debattørerne. Der er ikke nogen der gider læse sådan nogle lange sludderhistorier.

Baldur

Nu konkluderer du udelukkende på basis af dine egne påstande - det er en cirkelargumentation.

Uden NAT/firewalls kan alle devices adresseres på basis af den IP som de er født med. Med IPsec kan de kontrolleres på afstand som ukontrollabel spyware. Ingen af de 2 elementer er forenelige med en fri og sikker verden.

Hvilken "påstand" har du et problem med?

Ingen har sagt at der ikke er brug for firewalls.

Jeg har fortalt dig under hvilke omstændigheder at alle devices kan adresseres selvom NAT bruges. Ingen grund til at gentage sig selv.

Det er noget vrøvl at IPsec kan kontrolleres på afstand (du må godt få min IPv6 adresse - jeg udfordrer dig til at få min "ipsec" til at gøre noget uventet - inklusiv at sende så meget som en eneste pakke tilbage til dig). IPsec bliver ikke brugt i dag og kommer heller ikke til at blive brugt mere i fremtiden efter at IPv6 er indført. Hvilket basalt set er det PHKs blogindlæg er en opinion om.

Baldur

Jeg har et problem med dine stråmandspåstande, hvor du udlægger noget andet end jeg siger og så argumenterer med dig selv - så er det nemt at nå til dine konklusioner.

Jeg sagde ikke, at JEG kan styre devicen via IPSec, men at producenten kan. Dvs. at der ikke er noget som default overfører kontrollen til ejeren.

En NAT er i princippet alt fra den mest simple IP-proxy over firewalls med ip-proxy til en fullscale virtual repræsentation af den bagvedliggende device.

Pointen er at dårlig devicedesign og ringe protokoldesign må kunne kompenseres med kontol mekanismer som f.eks. at ejeren etablerer en ydre firewall som forhindrer devices i at lave en "Phone Home" på samme måde som man gør med applikationer.

Hvis det er dit hus, din virksomhed eller din bil, må ingen kunne adressere eller kommunikere med dine devices udenfor din kontrol. Hvis du vælger at lade devices fungere med samme rettigheder som trojanske heste og spyware så skal det være et valg og ikke default som IPv6 ligger op til.

At IPv4 med extentions gradvist ligner IPv6 mere og mere ændrer ikke på pointen. Det er ikke en vej at gå og Privacy extensions er glasur mere end indhold.

Jeg sagde ikke, at JEG kan styre devicen via IPSec, men at producenten kan. Dvs. at der ikke er noget som default overfører kontrollen til ejeren.

Men det er også forkert. Det er ejeren og ingen anden som har kontrol over IPSEC. Der er ingen bagdøre der giver producenter adgang til dine ting.

Hvis det er dit hus, din virksomhed eller din bil, må ingen kunne adressere eller kommunikere med dine devices udenfor din kontrol.

Det opnår du med en stateful firewall.

Baldur

Hvordan mener du at have kontrol med IPSEC medmindre det er ren sessionbaseret (random nøgler og identifers) og du styrer præcist hvad devicen lækker af data ?

Bortset fra den inddirekte indflydelse eller illusion herom som producentens interfaces mere eller mindre tilfældigt giver dig, så har du ikke kontrol over dine devices i dag - og det bliver gradvist værre med Internet of Things, hvor mange devices ikke har userinterfaces.

Det reelle er at IPv6 styrker producentens kontrol men meget lidt/intet for at sikre ejerens i en udvikling hvor behovet herfor vokser eksplosivt. SÅ hellere usikkerheden ved IPv4.

Det opnår du med en stateful firewall.

Kun delvis - En statefull firewall åbner/lukker, men sikrer ikke indholdet og bygger kun en perimetersikkerhed.

Det stærkeste er at du slet ikke kan adressere devicen (hvis ejeren ikke ønsker at devicen kan adresseres) og herunder at devices ikke lækker persistente identificers når de kommunikere.

Tunge spillere bruger mange ressourcer på f.eks. med at geolocate devices via IP-adresser og andet - det nødvendige modtræk er en total dekobling af IP-addresse og lokation. Hvis lokation kan bidrage til servicen så kan devicen selv opgive den med den grad af unøjagtighed som gavner formålet.

Hvordan mener du at have kontrol med IPSEC medmindre det er ren sessionbaseret (random nøgler og identifers) og du styrer præcist hvad devicen lækker af data ?

IPSEC er inaktiv indtil specifikt konfigureret til at sikre trafik mellem to maskiner. Uden aktion fra brugeren af begge maskiner sker der intet. Modsat SSL skal begge parter have aftalt på forhånd hvordan der krypteres ved at udveksle nøgler med mere.

Til alle praktiske formål kan du derfor rolig lade som om IPSEC ikke eksisterer. Du kommer ikke til at bruge det. Det er kun for virksomheder som ønsker at kryptere trafik mellem to afdelinger. Eller en medarbejder som skal have sikret trafikken til hans hjemmearbejdsplads.

IPSEC kan under ingen omstændigheder bruges til kommunikation med en ukendt trediepart.

Jeg forstår derfor ikke din interesse for IPSEC, da det synes at være et værktøj der falder uden for det du skriver om.

Det reelle er at IPv6 styrker producentens kontrol

Hvordan? Hvem er producenten? Linux Torvalds? PHK?

Det stærkeste er at du slet ikke kan adressere devicen

Det er muligt, men det er vigtigt at indse at NAT ikke sikrer dette. Når en maskine bag en NAT-router kommunikerer med en trediepart, bliver maskinen kendt hos trediepart som et (IP adresse, portnummer) par. Dette (IP adresse, portnummer) par kan trediepart give videre til en anden trediepart, som så også kan kommunikere med den beskyttede maskine. Du har altså en adresse på maskinen, det er bare en 48 bit adresse (32 bit fra NAT routerens IP adresse og 16 bit fra portnummeret).

Baldur

Dette (IP adresse, portnummer) par kan trediepart give videre til en anden trediepart, som så også kan kommunikere med den beskyttede maskine. Du har altså en adresse på maskinen, det er bare en 48 bit adresse (32 bit fra NAT routerens IP adresse og 16 bit fra portnummeret).

Nej, du har en addresse på en session med devicen. Hvem siger den genbruges?

Producenten er den som producerer hardwaren, antaget at brugeren som ikke har indflydelse på de fleste devices software

Nej, du har en addresse på en session med devicen. Hvem siger den genbruges?

Genbruges kan den uheldigvis. Læs for eksempel op på STUN http://en.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT for et eksempel på en protokol der udnytter dette faktum.

Producenten er den som producerer hardwaren, antaget at brugeren som ikke har indflydelse på de fleste devices software

Dit køleskab kommer ikke til at køre IPSEC. Sorry :-).

Stun Fordi en metode/protokol genbruger et NAT/Proxy exit-point det intet som siger at alle genbruger. Det er bare et dårlig protokoldesign som ikke løser opgaven.

Køleskab/IP Jo, mit køleskab kommer til at køre IP og også en form for IPSEC. Alt kører IP - enten direkte eller via et relay på den nærmeste RF/LAN connection. Hvis det ikke er IPsec direkte så noget som kan mappes ind i noget tilsvarende. Selv de mindste devices har brug for sikkerhed - som selvfølgelig skal passe til brugen.

Det som diskussionen drejer sig om er på hvilket lag man kører med hvilke nøgler/identifiers. Jeg advokerer for at persistente nøgler/identifiers skal ud af netværkslaget og isoleres i højere lag. I netværkslaget vil vi kun se ikke-informationsbærende session-nøgler.

Stun Fordi en metode/protokol genbruger et NAT/Proxy exit-point det intet som siger at alle genbruger. Det er bare et dårlig protokoldesign som ikke løser opgaven.

Stephan, pointen er det at STUN virker viser at NAT ikke er sikker. Der slipper trafik igennem som du tror er blokkeret, og det er den værste form for sikkerhedsbrist.

Jo, mit køleskab kommer til at køre IP og også en form for IPSEC

Måske du skal læse op på hvad IPSEC er før vi fortsætter.

Baldur

Tror vi skal til at stoppe - du argumenterer i cirkler om dine egne påstande.

Jeg kan ikke se STUN viser noget særligt. Kun at den samme device kan etablere kobling af 2 uafhængige sesssions og måske lære noget om NAT-strukturen - big surprise.

Problemet med IPSEC kan isoleres til at den antager persistente og dermed reelt genbrug af authentikeringsnøgler. Det er fyføj i netværkslaget. Bortset fra det er IPsec fint.

Jeg kan ikke se STUN viser noget særligt.

Du har så ikke forstået det så.

Lad mig prøve en sidste gang.

STUN er en server som du sender en pakke. STUN svarer hvilken IP+port den ser. Du fortæller derefter trediepart denne IP+port hvorefter trediepart er i stand til at initiere forbindelser ind til dig.

Ok siger Stephen. Det er jo ikke noget problem, jeg bad selv om det. Nej, Stephen. STUN serveren kunne være en ondsindet server som du tilfældigvis kommunikere med og i stedet for at give DIG IP+port kan den give IP+port til trediepart direkte, som herefter er i stand til at kommunikere (adressere) dig direkte UDEN din accept.

STUN er bare en praktisk anvendelse af min "påstand" af at IP+port kan genbruges og fungere som en 48 bit adresse af din enhed helt uden for din kontrol.

Du burde tage på kursus og prøve at sætte en IPSEC forbindelse op før du udtaler dig videre. Det vil være en øjenåbner for dig.

Hej Baldur

Mig bekendt, er STUN en måde at opdage om man bliver NAT'tet og hvilken type. Der er ingen form for usikkerhed i det. F.eks. bliver det brugt i SIP som fortæller modparten sin egen IP - som den derfor er nød til at vide noget om.

Hilsen Klaus

Hej Klaus

Citat fra Wikipedia:

"The STUN protocol allows applications operating through a network address translator (NAT) to discover the presence of a network address translator and to obtain the mapped (public) IP address (NAT address) and port number that the NAT has allocated for the application's User Datagram Protocol (UDP) connections to remote hosts.".

Det er den sidste del der er interessant. "IP address and port number that NAT has allocated...".

"When a client has discovered its external address, it can communicate with communication peers by advertising its external NAT address to its peers"

Altså når nogen kender "IP address and port number" så kan de kommunikere med dig.

Hvem kan "advertise"? Det har du ikke kontrol over, intet forhindrer trediepart at give den information videre. Nogle typer peer to peer netværk gør det automatisk.

Hvordan kan en ondsindet angriber få oplysninger? Han kan få det af en anden. Han kan selv opdage dem, hvis klienten kommunikere med ham i anden forbindelse. Eller han kan gætte - port nummer er kun 16 bit (65536 muligheder).

Nogle NAT routere har checks for at forhindre fremmed trafik. Men den mest simple og mest udbredte NAT type er en åben port ind i dit net. Og det er i virkligheden ok, for formålet med NAT har aldrig været at fungere som firewall. Det er bare en almindelig misforståelse.

Baldur

For det første - jeg forholder mig primært til den logiske model. Om implementeringen er god eller dårlig overlader jeg gladeligt til PHK og andre. En god logisk sikkerhedsmodel skal forebygge implementeringsfejl, men ingen nok så god implementering kan kompensere for en dårlig logisk model.

Omkring NATs Jeg kan ærligt ikke se relevansen. Ja, NATs kan være primitive uden sikkerhed eller firewalls. Det betyder da ikke at man skal forværre situationen, men sørge for at få forbedret NATs.

Faktum er at det at fjerne persistent adressering i netværkslaget er den absolut stærkeste måde at beskytte både svage enheder, mennesker og alle de systemer som skal servicere dem.

Samtidig er det stadigt mere vigtigt at undgå at devices - grundet et fejldesignet netværkslag - lækker data og latent bidrager til (un)Trustworthy computing, hvor du ikke har kontrol over dine egne devices.

IPv6 mantraet - en device, en adresse - er en forældet forståelse af den digitale verden.