Navngitt datanettverk - Named data networking

Navngitt datanettverk ( NDN ) (relatert til innholdssentrert nettverk (CCN), innholdsbasert nettverk, dataorientert nettverk eller informasjonssentrert nettverk (ICN)) er en foreslått fremtidig internettarkitektur inspirert av mange års empirisk forskning på nettverksbruk og en økende bevissthet om uløste problemer i moderne internettarkitekturer som IP . NDN har sine røtter i et tidligere prosjekt, Content-Centric Networking (CCN), som Van Jacobson først presenterte offentlig i 2006. NDN-prosjektet undersøker Jacobsons foreslåtte utvikling fra dagens vertssentriske nettverksarkitektur-IP til en datasentrisk nettverksarkitektur ( NDN). Troen er at dette konseptuelt enkle skiftet vil ha vidtrekkende implikasjoner for hvordan mennesker designer, utvikler, distribuerer og bruker nettverk og applikasjoner.

NDN har tre kjernekonsepter som skiller NDN fra andre nettverksarkitekturer. For det første vil applikasjonsnavn og datanavn brukes direkte i videresending av nettverkspakker; forbrukerapplikasjoner ber om ønskede data ved navn, så kommunikasjon i NDN er forbrukerstyrt. For det andre er NDN-kommunikasjon sikret på en datasentrisk måte, det vil si at hvert stykke data (kalt en datapakke) blir kryptografisk signert av produsenten, og sensitiv nyttelast eller navnekomponenter kan også krypteres av hensyn til personvernet; på denne måten kan forbrukerne verifisere pakken uavhengig av hvordan pakken hentes. For det tredje vedtar NDN et stateful -videresendelsesplan hvor speditører vil beholde en tilstand for hver dataforespørsel (kalt en interessepakke) og slette tilstanden når en tilsvarende datapakke kommer tilbake; NDNs stateful videresending tillater intelligente videresendingstrategier og eliminerer sløyfer.

Forutsetningen er at Internett først og fremst brukes som et informasjonsdistribusjonsnettverk , noe som ikke passer godt for IP, og at det fremtidige internettets "tynne midje" bør være basert på navngitte data i stedet for numerisk adresserte verter. Det underliggende prinsippet er at et kommunikasjonsnettverk skal tillate en bruker å fokusere på dataene de trenger, navngitt innhold , i stedet for å måtte referere til en bestemt, fysisk plassering der dataene skal hentes fra, navngitte verter . Motivasjonen for dette er avledet av det faktum at det store flertallet av dagens internettbruk (et "høyt 90% trafikknivå") består i at data formidles fra en kilde til et antall brukere. Navngitte datanettverk har potensial for en rekke fordeler, for eksempel innholdsbufring for å redusere overbelastning og forbedre leveringshastigheten, enklere konfigurasjon av nettverksenheter og bygge sikkerhet inn i nettverket på datanivå.

Oversikt

Dagens Internetts timeglassarkitektur fokuserer på et universelt nettverkslag, IP, som implementerer den minimale funksjonaliteten som er nødvendig for global inter-tilkobling. Den moderne internettarkitekturen kretser rundt en vertsbasert samtalemodell, opprettet på 1970-tallet for å tillate geografisk distribuerte brukere å bruke noen få store, immobile datamaskiner. Denne tynne midjen muliggjorde internettets eksplosive vekst ved at både lavere og øvre lagteknologi kunne innovere uavhengig. Imidlertid ble IP designet for å opprette et kommunikasjonsnettverk, der pakker bare navngav kommunikasjonens endepunkter.

Image
De viktigste byggesteinene i NDN-arkitekturen heter innholdsstykker, i motsetning til IP-arkitekturs grunnleggende kommunikasjonsenhet, som er en ende-til-ende-kanal mellom to endepunkt identifisert av IP-adresser.

Vedvarende vekst i netthandel , digitale medier , sosiale nettverk og smarttelefonapplikasjoner har ført til dominerende bruk av Internett som distribusjonsnettverk. Distribusjonsnettverk er mer generelle enn kommunikasjonsnettverk, og å løse distribusjonsproblemer via en punkt-til-punkt- kommunikasjonsprotokoll er kompleks og utsatt for feil.

Prosjektet Named Data Networking (NDN) foreslo en utvikling av IP -arkitekturen som generaliserer rollen til denne tynne midjen, slik at pakker kan navngi andre objekter enn kommunikasjonens endepunkter. NDN endrer mer spesifikt semantikken i nettverkstjenesten fra å levere pakken til en gitt destinasjonsadresse til å hente data identifisert med et gitt navn. Navnet i en NDN -pakke kan navngi alt - et endepunkt, en dataklump i en film eller en bok, en kommando for å slå på noen lys osv. Håpet er at denne konseptuelt enkle endringen lar NDN -nettverk bruke nesten alle Internetts velprøvde ingeniøregenskaper til et bredere spekter av problemer utover ende-til-ende-kommunikasjon. Eksempler på at NDN bruker erfaringer fra 30 års nettverksteknikk er at selvregulering av nettverkstrafikk (via strømningsbalanse mellom interesser (dataforespørsel) og datapakker) og sikkerhetsprimitiver (via signaturer på alle navngitte data) er integrert i protokollen fra starten.

Historie

Tidlig forskning

Filosofien bak NDN ble banebrytende av Ted Nelson i 1979 og senere av Brent Baccala i 2002. I 1999 foreslo TRIAD -prosjektet på Stanford å unngå DNS ​​-oppslag ved å bruke navnet på et objekt for å rute mot en nær kopi av det. I 2006 foreslo det Data-Oriented Network Architecture ( DONA ) -prosjektet ved UC Berkeley og ICSI en innholdssentrert nettverksarkitektur, som forbedret TRIAD ved å innlemme sikkerhet (autentisitet) og utholdenhet som førsteklasses primitiver i arkitekturen. Van Jacobson ga i 2006 en Google Talk, A New Way to Look on Networking , om utviklingen av nettverket, og hevdet at NDN var det neste trinnet. I 2009 kunngjorde PARC sin innholdssentriske arkitektur innenfor CCNx-prosjektet, som ble ledet av Jacobson, den gang en stipendiat ved PARC. September 2009 publiserte PARC spesifikasjonene for interoperabilitet og ga ut en første åpen kildekode-implementering (under GPL ) av forskningsprosjektet Content-Centric Networking på Project CCNx-området . NDN er en forekomst av en mer generell nettverksforskningsretning kalt informasjonssentrisk nettverk (ICN), der forskjellige arkitekturdesigner har dukket opp. Internet Research Task Force (IRTF) opprettet en arbeidsgruppe for forskningsarbeid i 2012.

Nåværende tilstand

NDN inkluderer seksten NSF-finansierte hovedforskere på tolv campus, og økende interesse fra de akademiske og industrielle forskningsmiljøene. Mer enn 30 institusjoner danner et globalt testbed . Det finnes en stor mengde forskning og en aktivt voksende kodebase. bidro til NDN.

Den NDN speditør støttes på Ubuntu 18.04 og 20.04, Fedora 20 +, CentOS 6+, Gentoo Linux, Raspberry Pi, OpenWRT, FreeBSD 10+, og flere andre plattformer. Felles klientbiblioteker støttes aktivt for programmeringsspråk C ++, Java, Javascript, Python, .NET Framework (C#) og Squirrel. Den NDN-LITE er et lett NDN bibliotek designet for IOT nettverk og begrenset enheter. NDN-LITE utvikles aktivt, og så langt har NDN-LITE blitt tilpasset POSIX, RIOT OS, NRF-tavler. En NDN -simulator og emulator er også tilgjengelig og aktivt utviklet. Flere klientprogrammer utvikles innen sanntidskonferanser, NDN-vennlige filsystemer, chat, fildeling og IoT.

Viktige arkitektoniske prinsipper

  • Ende-til-ende-prinsipp : Muliggjør utvikling av robuste applikasjoner i møte med nettverksfeil. NDN beholder og utvider dette designprinsippet.
  • Ruting og videresending av flyseparasjon: Dette har vist seg nødvendig for internettutvikling. Det lar videresendingsplanet fungere mens rutingsystemet fortsetter å utvikle seg over tid. NDN bruker det samme prinsippet for å tillate distribusjon av NDN med den beste tilgjengelige videresendingsteknologien mens ny rutingsystemforskning pågår.
  • Stateful videresending: NDN -rutere beholder tilstanden til nylig videresendte pakker, som tillater smart videresending, sløyfedeteksjon, strømningsbalanse, allestedsnærværende caching, etc.
  • Innebygd sikkerhet: I NDN er dataoverføring sikret på nettverkslaget ved å signere og verifisere alle navngitte data.
  • Aktiver brukervalg og konkurranse: Arkitekturen bør legge til rette for brukervalg og konkurranse der det er mulig. Selv om det ikke er en relevant faktor i det opprinnelige internettdesignet, har global distribusjon vist at "arkitektur er ikke nøytral". NDN gjør en bevisst innsats for å styrke sluttbrukere og muliggjøre konkurranse.

Arkitektur oversikt

Typer pakker

Kommunikasjon i NDN drives av mottakere, dvs. datakonsumenter, gjennom utveksling av to typer pakker: Renter og data. Begge typer pakker har et navn som identifiserer et stykke data som kan overføres i en datapakke.

Image
Oversikt over pakkeinnholdet for NDN -pakken

Pakketyper

  • Interesse: En forbruker legger navnet på en ønsket del av data i en interessepakke og sender den til nettverket. Rutere bruker dette navnet til å videresende interessen til dataprodusentene.
  • Data: Når interessen når en node som har de forespurte dataene, vil noden returnere en datapakke som inneholder både navnet og innholdet, sammen med en signatur av produsentens nøkkel som binder de to. Denne datapakken følger omvendt banen som interessen tar for å komme tilbake til den forespurende forbrukeren.

For den komplette spesifikasjonen, se NDN Packet Format Specification .

Routerarkitektur

For å utføre funksjonene for videresending av renter og datapakker, har hver NDN -ruter tre datastrukturer og en videresendingspolicy:

  • Ventende rentetabell (PIT): lagrer alle interessene som en ruter har videresendt, men ikke er fornøyd med ennå. Hver PIT -oppføring registrerer datanavnet som bæres i interessen, sammen med innkommende og utgående grensesnitt (er).
  • Forwarding Information Base (FIB): en rutingtabell som kartlegger navnekomponenter til grensesnitt. Selve FIB er befolket av en navneprefiksbasert rutingprotokoll, og kan ha flere utgangsgrensesnitt for hvert prefiks.
  • Content Store (CS): en midlertidig buffer for datapakker som ruteren har mottatt. Fordi en NDN -datapakke er meningsfull uavhengig av hvor den kommer fra eller hvor den videresendes, kan den lagres i bufringen for å tilfredsstille fremtidige interesser. Erstatningsstrategi er tradisjonelt minst nylig brukt, men erstatningsstrategien bestemmes av ruteren og kan variere.
  • Videresendelsesstrategier: en rekke retningslinjer og regler om videresending av interesse- og datapakker. Vær oppmerksom på at videresendingsstrategien kan bestemme å droppe en interesse i visse situasjoner, f.eks. Hvis alle oppstrøms lenker er overbelastet eller det er mistanke om at interessen er en del av et DoS -angrep. Disse strategiene bruker en rekke utløsere i videresendingsrørledningen og er tilordnet navneprefikser. For eksempel bruker standard /localhost Multicast -videresendingsstrategien til å videresende interesser og data til alle lokale applikasjoner som kjører på en klient -NFD. Standard videresendingsstrategi (dvs. "/") er strategien for videresending av beste ruter.

Når en interessepakke kommer, sjekker en NDN -ruter først innholdsbutikken for å finne matchende data. hvis den finnes i ruteren returnerer datapakken på grensesnittet som interessen kom fra. Ellers slår ruteren opp navnet i PIT, og hvis det finnes en matchende oppføring, registrerer den ganske enkelt det innkommende grensesnittet for denne interessen i PIT -oppføringen. I mangel av en matchende PIT -oppføring, vil ruteren videresende interessen til dataprodusent (er) basert på informasjon i FIB så vel som routerens adaptive videresendingsstrategi. Når en ruter mottar interesser for samme navn fra flere nedstrøms noder, videresender den bare den første oppstrøms mot dataprodusent (er).

Når en datapakke kommer, finner en NDN-ruter den samsvarende PIT-oppføringen og videresender dataene til alle nedstrømsgrensesnitt som er oppført i den PIT-oppføringen. Den fjerner deretter PIT -oppføringen og lagrer dataene i Content Store. Datapakker tar alltid den motsatte banen til interesser, og i fravær av tapstap resulterer en rentepakke i en datapakke på hver lenke, noe som gir strømningsbalanse. For å hente store innholdsobjekter som består av flere pakker, gir Interesser en lignende rolle i å kontrollere trafikkflyten som TCP ACKer i dagens internett: en finkornet tilbakekoblingssløyfe kontrollert av forbrukeren av dataene.

Verken rente- eller datapakker har noen verts- eller grensesnittadresser; rutere videresender rentepakker til dataprodusenter basert på navnene i pakkene, og videresender datapakker til forbrukere basert på PIT -tilstandsinformasjonen som er satt opp av interessene ved hvert hopp. Denne rente-/datapakkeutvekslingssymmetrien induserer en hop-by-hop-kontrollløkke (ikke å forveksle med symmetrisk ruting, eller med ruting i det hele tatt!), Og eliminerer behovet for enhver forestilling om kilde- eller destinasjonsnoder i datalevering, i motsetning til i IPs ende-til-ende-pakkeleveringsmodell.

Navn

Design

NDN -navn er ugjennomsiktige for nettverket. Dette gjør at hver applikasjon kan velge navnesystemet som passer dets behov, og navngivning kan dermed utvikle seg uavhengig av nettverket.

Struktur

NDN -designet antar hierarkisk strukturerte navn, f.eks. Kan en video produsert av UCLA ha navnet /ucla/videos/demo.mpg, hvor '/' avgrenser navnekomponenter i tekstrepresentasjoner, som ligner på URL -er. Denne hierarkiske strukturen har mange potensielle fordeler:

  • Forholdsspesifikasjon: lar applikasjoner representere konteksten og relasjonene til dataelementer. EX: segment 3 av versjon 1 av en UCLA -demo -video kan ha navnet /ucla/videos/demo.mpg/1/3.
  • Navneaggregering: /ucla kan svare til et autonomt system som stammer fra videoen
  • Ruting: lar systemet skalere og hjelpe til med å gi den nødvendige konteksten for dataene

Angi et navn

For å hente dynamisk genererte data må forbrukerne kunne deterministisk konstruere navnet på et ønsket stykke data uten å ha sett navnet eller dataene gjennom noen av følgende:

  • en algoritme lar produsent og forbruker komme frem til samme navn basert på informasjon som er tilgjengelig for begge
  • Rentevelgere i forbindelse med lengste prefiksmatching henter de ønskede dataene gjennom en eller flere iterasjoner.

Gjeldende forskning undersøker hvordan applikasjoner skal velge navn som kan lette både applikasjonsutvikling og nettverkslevering. Målet med dette arbeidet er å utvikle og forfine eksisterende prinsipper og retningslinjer for navngivning, konvertere disse reglene til navngivningskonvensjoner implementert i systembiblioteker for å forenkle fremtidig applikasjonsutvikling.

Navneplasser

Data som kan hentes globalt må ha globalt unike navn, men navn som brukes for lokal kommunikasjon kan bare kreve lokal ruting (eller lokal kringkasting) for å finne matchende data. Individuelle datanavn kan være meningsfulle i ulike omfang og kontekster, alt fra "lysbryteren i dette rommet" til "alle landnavn i verden". Navneplassbehandling er ikke en del av NDN -arkitekturen, på samme måte som adresseromstyring ikke er en del av IP -arkitekturen. Navngivning er imidlertid den viktigste delen av NDN -applikasjonsdesigner. Å gjøre applikasjonsutviklere, og noen ganger brukere, i stand til å designe sine egne navneområder for datautveksling har flere fordeler:

  • øke nærheten av kartlegging mellom en applikasjons data og bruken av nettverket
  • redusere behovet for sekundær notasjon (journalføring for å kartlegge applikasjonskonfigurasjon til nettverkskonfigurasjon)
  • utvide utvalget av abstraksjoner som er tilgjengelig for utviklerne.
  • navngitte baserte innholdsforespørsler introduserer også bekymringene for personvernlekkasje . Takket være adskillelse av navneromadministrasjon fra NDN -arkitektur, er det mulig å tilby personvernbevarende navnesystem ved å gjøre mindre endringer i konvensjonell NDN -navnesystem.

Ruting

Løsninger på IP -problemer

NDN ruter og videresender pakker basert på navn, noe som eliminerer tre problemer forårsaket av adresser i IP -arkitekturen:

  • Utmattelse av adresserommet : NDN -navneområdet er i hovedsak ubegrenset. Navneområdet er bare avgrenset av pakkestørrelsen på maks. 8kb og antallet mulige unike kombinasjoner av tegn som lager navn.
  • NAT -traversal: NDN gjør unna adresser, offentlige eller private, så NAT er unødvendig.
  • Adresseadministrasjon: adressetildeling og administrasjon er ikke lenger nødvendig i lokale nettverk.
  • I multicasting i nettverk : En produsent av data trenger ikke å motta flere interesser for de samme dataene siden PIT -oppføringene hos nedstrøms speditører vil samle interesser. Produsenten mottar og svarer på en enkelt interesse, og de videresendingsnodene der det ble mottatt flere innkommende interesser, vil multisending av datasvarene til grensesnittene interessene ble mottatt fra.
  • Høy pålitelighet ende -til -ende -pålitelighet: IP -baserte nettverk krever at tapte eller tapte pakker sendes på nytt av avsenderen. Men i NDN hvis en interesse utløper før et datasvar når forespørselen, blir datasvaret fortsatt bufret av speditører langs returbanen. Den gjenutsendte interessen trenger bare å nå en videresender med en bufret kopi av dataene som gir NDN -baserte nettverk høyere gjennomstrømning enn IP -baserte nettverk når pakketapstallene er høye.

Protokoller

NDN kan bruke konvensjonelle rutingalgoritmer som lenketilstand og avstandsvektor . I stedet for å kunngjøre IP -prefikser , kunngjør en NDN -ruter navneprefikser som dekker dataene ruteren er villig til å vise. Konvensjonelle rutingsprotokoller, for eksempel OSPF og BGP , kan tilpasses til å rute på navnets prefikser ved å behandle navn som en sekvens av ugjennomsiktige komponenter og gjøre komponentmessig lengste prefiksmatch av et navn i en interessepakke mot FIB-tabellen . Dette gjør at et bredt spekter av innganger kan samles i sanntid og distribueres over flere grensesnittmiljøer samtidig uten at det går ut over innholdskryptering. Nøkkelgrensesnittanalyse blir på samme måte spart av prosessen. Applikasjonsoverføring og datadeling i miljøet er definert av et multimodalt distribusjonsrammeverk, slik at de berørte skyreléprotokollene er unike for den individuelle kjøretidsidentifikatoren.

PIT -tilstand

PIT -tilstanden på hver ruter støtter videresending over NDNs dataplan, registrerer hver ventende interesse og innkommende grensesnitt (er) og fjerner interessen etter at matchende data er mottatt eller det oppstår en timeout. Dette per hop, per pakkestatus skiller seg fra IPs statsløse dataplan. Basert på informasjon i FIB og ytelsesmålinger, tar en adaptiv videresendingstrategimodul i hver ruter informerte beslutninger om:

  • Kontrollflyt: siden hver rente maksimalt henter én datapakke, kan en ruter styre flyten direkte ved å kontrollere antall ventende interesser den beholder.
  • Multicast data levering: PIT registrerer settet med grensesnitt som de samme dataene kommer til, støtter naturligvis denne funksjonen.
  • Oppdaterer stier for å imøtekomme endringer i visningen av nettverket.
  • Levering: en ruter kan begrense hvilke interesser som skal videresendes til hvilke grensesnitt, hvor mange utilfredse interesser som skal tillates i PIT, samt den relative prioriteten til forskjellige interesser.

Renter

Hvis en ruter bestemmer at interessen ikke kan tilfredsstilles, for eksempel at oppstrøms -lenken er nede, det ikke er noen videresendingsoppføring i FIB, eller det oppstår ekstrem overbelastning, kan ruteren sende en NACK til naboen (e) som overførte interessen . En slik negativ anerkjennelse (NACK) kan få mottakerruteren til å videresende interessen til andre grensesnitt for å utforske alternative stier. PIT -tilstanden gjør at rutere kan identifisere og kaste looping -pakker, slik at de fritt kan bruke flere veier mot den samme dataprodusenten. Pakker kan ikke sløyfe i NDN, noe som betyr at det ikke er behov for levetid og andre tiltak implementert i IP og relaterte protokoller for å løse disse problemene.

Sikkerhet

Oversikt

I motsetning til TCP/IP-sikkerhet (f.eks. TLS) som sikrer kommunikasjon ved å sikre IP-til-IP-kanaler, sikrer NDN selve dataene ved å kreve dataprodusenter å signere hver datapakke kryptografisk. Utgivers signaturen sikrer integritet og tillates vanligvis autentifisering av data proveniens , slik at en forbruker tillit til data som skal frakobles fra hvordan eller hvor det er oppnådd. NDN støtter også finkornet tillit, slik at forbrukere kan tenke på om en eier av en offentlig nøkkel er en akseptabel utgiver for et bestemt stykke data i en bestemt kontekst. Det andre primære forskningsprosjektet er å designe og utvikle brukbare mekanismer for å håndtere brukertillit. Det har blitt forsket på tre forskjellige typer tillitsmodeller:

  • hierarkisk tillitsmodell: der et nøkkelnavnområde tillater bruk av nøkler. En datapakke som bærer en offentlig nøkkel er effektivt et sertifikat, siden den er signert av en tredjepart, og denne offentlige nøkkelen brukes til å signere spesifikke data
  • nett av tillit : for å muliggjøre sikker kommunikasjon uten å kreve forhåndsavtalte tillitsankre.
  • lett tillit for IoT : NDN -tillitsmodellen hovedsakelig basert på asymmetrisk kryptografi , som er umulig for ressursbegrensende enheter i IoT -paradigme.

Applikasjonssikkerhet

NDNs datasentriske sikkerhet har naturlige applikasjoner for innholdstilgangskontroll og infrastruktursikkerhet. Applikasjoner kan kryptere data og distribuere nøkler som navngitte pakker ved hjelp av den samme navngitte infrastrukturen for å distribuere nøkler, og effektivt begrense datasikkerhetsomkretsen til konteksten til en enkelt applikasjon. For å bekrefte en datapakkes signatur, kan et program hente den riktige nøkkelen, identifisert i pakkens nøkkelfinnerfelt, akkurat som alt annet innhold. Men tillitsforvaltning, dvs. hvordan man bestemmer ektheten til en gitt nøkkel for en bestemt pakke i en gitt applikasjon, er en hovedforskningsutfordring. I samsvar med en eksperimentell tilnærming, er NDN tillitsstyringsforskning drevet av applikasjonsutvikling og bruk: først å løse spesifikke problemer og deretter identifisere vanlige mønstre. For eksempel krever sikkerhetsbehovet til NLSR utvikling av en enkel hierarkisk tillitsmodell, med nøkler på lavere (nærmere rot) nivåer, som brukes til å signere nøkler på høyere nivåer der nøkler publiseres med navn som gjenspeiler deres tillitsforhold. I denne tillitsmodellen samsvarer navneområdet med hierarkiet for tillitsdelegering, dvs./root/site/operator/router/process. Publisering av nøkler med et bestemt navn i hierarkiet gir dem fullmakt til å signere bestemte datapakker og begrenser omfanget. Dette paradigmet kan lett utvides til Andre applikasjoner der virkelige tillit har en tendens til å følge et hierarkisk mønster, for eksempel i våre bygningsstyringssystemer (BMS) Siden NDN overlater tillitsmodellen under kontroll av hver applikasjon, mer fleksible og uttrykksfulle tillitsforhold, kan også komme til uttrykk. Et slikt eksempel er ChronoChat, som motiverte eksperimentering med en web-of-trust-modell. Sikkerhetsmodellen er at en nåværende chatroom -deltaker kan introdusere en nykommer for andre ved å signere nykommerens nøkkel. Fremtidige applikasjoner vil implementere en kryssertifiseringsmodell (SDSI) [13, 3], som gir mer redundans av verifikasjon, slik at data og nøkkelnavn kan være uavhengige, noe som lettere rommer en rekke virkelige tillitsforhold.

Ruting effektivitet og sikkerhet

Videre behandler NDN nettverksruting og kontrollmeldinger som alle NDN -data, og krever signaturer. Dette gir et solid grunnlag for å sikre rutingsprotokoller mot angrep, f.eks. Spoofing og manipulering. NDNs bruk av flerveisvideresending, sammen med den modulen for adaptiv videresending, reduserer kapring av prefiks fordi rutere kan oppdage avvik forårsaket av kapringer og hente data gjennom alternative stier. På grunn av multi-source, multicast-innholdsleveringskarakteren til Named Data Networking , kan den tilfeldige lineære kodingen forbedre seg over all nettverkseffektivitet. Siden NDN-pakker refererer til innhold i stedet for enheter, er det vanskeligere å skadelig målrette mot en bestemt enhet, selv om det vil være nødvendig med avbøtningsmekanismer mot andre NDN-spesifikke angrep, f.eks. Interesseflow DoS., Videre å ha en ventende rentetabell, som holder tilstanden angående tidligere forespørsler, som kan ta informerte beslutninger om hvordan du skal håndtere interesser, har mange sikkerhetsfordeler:

  • Lastbalansering: Antallet PIT -oppføringer er en indikator på routerbelastning; begrensning av størrelsen begrenser effekten av et DDoS -angrep.
  • Tidsavbrudd for renter: Tidsavbrudd for PIT-oppføring tilbyr relativt billig angrepsdeteksjon, og ankomstgrensesnittinformasjonen i hver PIT-oppføring kan støtte en tilbakeslagsplan der nedstrømningsrutere blir informert om uinteresserte interesser, som hjelper til med å oppdage angrep.

Se også

Referanser

Eksterne linker