Nazwane sieci danych
Nazwane sieci danych ( NDN ) (związane z sieciami zorientowanymi na treść (CCN), sieciami opartymi na treści, sieciami zorientowanymi na dane lub sieciami zorientowanymi na informacje (ICN)) to proponowana architektura Internetu przyszłości , inspirowana latami empirycznych badań nad wykorzystaniem sieci oraz rosnąca świadomość nierozwiązanych problemów we współczesnych architekturach internetowych , takich jak IP . NDN ma swoje korzenie we wcześniejszym projekcie, Content-Centric Networking (CCN), którego autorem był Van Jacobson po raz pierwszy zaprezentowany publicznie w 2006 r. Projekt NDN bada proponowaną przez Jacobsona ewolucję od dzisiejszej architektury sieciowej zorientowanej na hosta IP do architektury sieci zorientowanej na dane (NDN). Uważa się, że ta koncepcyjnie prosta zmiana będzie miała dalekosiężne konsekwencje dla sposobu, w jaki ludzie projektują, rozwijają, wdrażają i używają sieci i aplikacji.
NDN ma trzy podstawowe koncepcje, które odróżniają NDN od innych architektur sieciowych. Po pierwsze, nazwy aplikacji i nazwy danych będą bezpośrednio wykorzystywane w przekazywaniu pakietów sieciowych; aplikacje konsumenckie żądają żądanych danych według ich nazwy, więc komunikacja w NDN jest napędzana przez konsumenta. Po drugie, komunikacja NDN jest zabezpieczona w sposób skoncentrowany na danych, to znaczy każda część danych (nazywana pakietem danych) będzie kryptograficznie podpisana przez producenta, a wrażliwy ładunek lub komponenty nazw mogą być również szyfrowane w celu zachowania prywatności; w ten sposób konsumenci mogą zweryfikować pakiet niezależnie od sposobu jego pobrania. Po trzecie, NDN przyjmuje stanową płaszczyznę przesyłania, w której usługi przesyłania dalej będą zachowywać stan dla każdego żądania danych (nazywanego pakietem odsetek) i usuwać stan, gdy powróci odpowiedni pakiet danych; Przekierowanie stanowe NDN umożliwia inteligentne strategie przekazywania i eliminuje pętle.
Jego założeniem jest to, że Internet jest używany przede wszystkim jako sieć dystrybucji informacji , co nie pasuje do IP, oraz że „cienka talia” przyszłego Internetu powinna opierać się na nazwanych danych, a nie hostach adresowanych numerycznie. Podstawową zasadą jest to, że sieć komunikacyjna powinna umożliwiać użytkownikowi skupienie się na danych, których potrzebuje, nazwanych treściach , zamiast konieczności odwoływania się do określonej, fizycznej lokalizacji, z której dane mają zostać pobrane, nazwanych hostów . Motywacja do tego wywodzi się z faktu, że zdecydowana większość obecnego korzystania z Internetu („wysoki 90-procentowy poziom ruchu”) polega na rozpowszechnianiu danych ze źródła do wielu użytkowników. Sieci nazwanych danych mogą przynieść wiele korzyści, takich jak buforowanie treści w celu zmniejszenia zatorów i poprawy szybkości dostarczania, prostsza konfiguracja urządzeń sieciowych i wbudowanie bezpieczeństwa w sieć na poziomie danych.
Przegląd
Dzisiejsza architektura klepsydry Internetu koncentruje się na uniwersalnej warstwie sieci, IP, która implementuje minimalną funkcjonalność niezbędną do globalnej łączności. Współczesna architektura Internetu opiera się na modelu konwersacji opartym na hostach, stworzonym w latach 70. XX wieku, aby umożliwić rozproszonym geograficznie użytkownikom korzystanie z kilku dużych, nieruchomych komputerów. Ta cienka talia umożliwiła gwałtowny rozwój Internetu, umożliwiając niezależne wprowadzanie innowacji zarówno w technologiach niższej, jak i wyższej warstwy. Jednak protokół IP został zaprojektowany w celu stworzenia sieci komunikacyjnej, w której pakiety nazywały tylko punkty końcowe komunikacji.
Stały rozwój handlu elektronicznego , mediów cyfrowych , sieci społecznościowych i aplikacji na smartfony doprowadził do dominującego wykorzystania Internetu jako sieci dystrybucji. Sieci dystrybucyjne są bardziej ogólne niż sieci komunikacyjne, a rozwiązywanie problemów z dystrybucją za pomocą typu punkt-punkt jest złożone i podatne na błędy.
W projekcie Named Data Networking (NDN) zaproponowano ewolucję architektury IP, która uogólnia rolę tej wąskiej talii, tak że pakiety mogą nazywać obiekty inne niż punkty końcowe komunikacji. Mówiąc dokładniej, NDN zmienia semantykę usługi sieciowej z dostarczania pakietu do określonego adresu docelowego na pobieranie danych identyfikowanych przez daną nazwę. Nazwa w pakiecie NDN może oznaczać wszystko – punkt końcowy, fragment danych w filmie lub książce, polecenie włączenia niektórych świateł itp. Mamy nadzieję, że ta koncepcyjnie prosta zmiana pozwoli sieciom NDN zastosować prawie wszystkie Dobrze przetestowane właściwości inżynieryjne Internetu do szerszego zakresu problemów wykraczających poza komunikację typu end-to-end. Przykłady NDN wykorzystujące wnioski wyciągnięte z 30 lat inżynierii sieci są takie, że samoregulacja ruchu sieciowego (poprzez równowagę przepływu między interesem (żądanie danych) a pakietami danych) oraz prymitywy bezpieczeństwa (poprzez podpisy na wszystkich nazwanych danych) są zintegrowane z protokołem od początku.
Historia
Wczesne badania
Filozofia stojąca za NDN została zapoczątkowana przez Teda Nelsona w 1979 r., a później przez Brenta Baccalę w 2002 r. W 1999 r. projekt TRIAD w Stanford zaproponował unikanie wyszukiwania DNS poprzez używanie nazwy obiektu do kierowania do jego bliskiej repliki. W 2006 roku projekt Data-Oriented Network Architecture ( DONA ) na Uniwersytecie Kalifornijskim w Berkeley i ICSI zaproponował architekturę sieci zorientowaną na zawartość, która udoskonaliła TRIAD poprzez włączenie bezpieczeństwa (autentyczności) i trwałości jako prymitywów pierwszej klasy w architekturze. Van Jacobson wygłosił Google Talk, A New Way to Look at Networking , w 2006 r. na temat ewolucji sieci i twierdził, że NDN to kolejny krok. W 2009 roku PARC ogłosił swoją architekturę skoncentrowaną na treści w ramach projektu CCNx, którym kierował Jacobson, wówczas pracownik naukowy w PARC. 21 września 2009 r. PARC opublikował specyfikacje interoperacyjności i udostępnił wstępną implementację open source (na licencji GPL ) projektu badawczego Content-Centric Networking w witrynie Project CCNx . NDN jest jednym z przykładów bardziej ogólnego kierunku badań sieciowych, zwanego sieciami zorientowanymi na informacje (ICN), w ramach którego powstały różne projekty architektoniczne. Internet Research Task Force (IRTF) utworzyła grupę roboczą ds. badań ICN w 2012 roku.
Stan aktulany
NDN obejmuje szesnastu głównych badaczy finansowanych przez NSF w dwunastu kampusach oraz rosnące zainteresowanie ze strony akademickich i przemysłowych społeczności badawczych. Ponad 30 instytucji tworzy globalne stanowisko testowe . Istnieje duża liczba badań i aktywnie rosnąca baza kodu. przyczynił się do NDN.
Usługa przesyłania dalej NDN jest obecnie obsługiwana w systemach Ubuntu 18.04 i 20.04, Fedorze 20+, CentOS 6+, Gentoo Linux, Raspberry Pi, OpenWRT, FreeBSD 10+ i kilku innych platformach. Wspólne biblioteki klienckie są aktywnie obsługiwane dla języków programowania C++, Java, Javascript, Python, .NET Framework (C#) i Squirrel. NDN -LITE to lekka biblioteka NDN przeznaczona dla sieci IoT i urządzeń z ograniczeniami. NDN-LITE jest aktywnie rozwijany i jak dotąd NDN-LITE został dostosowany do płyt POSIX, RIOT OS, NRF. Symulator i emulator NDN są również dostępne i aktywnie rozwijane. Kilka aplikacji klienckich jest opracowywanych w obszarach konferencji w czasie rzeczywistym, systemów plików przyjaznych NDN, czatu, udostępniania plików i IoT.
Kluczowe zasady architektoniczne
- Zasada „end-to-end” : umożliwia tworzenie niezawodnych aplikacji w przypadku awarii sieci. NDN zachowuje i rozszerza tę zasadę projektowania.
- Separacja płaszczyzn routingu i przesyłania: okazała się niezbędna do rozwoju Internetu. Umożliwia działanie płaszczyzny przekazywania, podczas gdy system trasowania ewoluuje w czasie. NDN wykorzystuje tę samą zasadę, aby umożliwić wdrożenie NDN z najlepszą dostępną technologią przekazywania, podczas gdy trwają badania nad nowym systemem routingu.
- Przekierowanie stanowe: routery NDN przechowują stan ostatnio przesłanych pakietów, co umożliwia inteligentne przekazywanie, wykrywanie pętli, równoważenie przepływu, wszechobecne buforowanie itp.
- Wbudowane zabezpieczenia: W sieci NDN transfer danych jest zabezpieczony w warstwie sieci poprzez podpisywanie i weryfikację dowolnych nazwanych danych.
- Umożliwić użytkownikowi wybór i konkurencję: architektura powinna ułatwiać użytkownikowi wybór i konkurencję tam, gdzie to możliwe. Chociaż nie był to istotny czynnik w pierwotnym projekcie Internetu, globalne wdrożenie pokazało, że „architektura nie jest neutralna”. NDN podejmuje świadomy wysiłek, aby wzmocnić pozycję użytkowników końcowych i umożliwić konkurencję.
Przegląd architektury
Rodzaje pakietów
Komunikacja w NDN jest napędzana przez odbiorniki, tj. konsumentów danych, poprzez wymianę dwóch rodzajów pakietów: odsetek i danych. Oba typy pakietów noszą nazwę, która identyfikuje fragment danych, który można przesłać w jednym pakiecie danych.
Typy pakietów
- Zainteresowanie: konsument umieszcza nazwę żądanego fragmentu danych w pakiecie odsetek i wysyła go do sieci. Routery używają tej nazwy do przekazywania zainteresowania producentowi danych.
- Dane: Gdy zainteresowanie dotrze do węzła, który ma żądane dane, węzeł zwróci pakiet danych, który zawiera zarówno nazwę, jak i treść, wraz z podpisem klucza producenta, który wiąże te dwa elementy. Ten pakiet danych podąża ścieżką odwrotną do ścieżki, którą podąża Zainteresowanie, aby wrócić do żądającego konsumenta.
Aby uzyskać pełną specyfikację, patrz Specyfikacja formatu pakietów NDN .
Architektura routera
Aby realizować funkcje przekazywania pakietów odsetek i danych, każdy router NDN utrzymuje trzy struktury danych i zasady przekazywania:
- Tabela oczekujących odsetek (PIT): przechowuje wszystkie zainteresowania, które router przekazał, ale nie zostały jeszcze spełnione. Każdy wpis PIT rejestruje nazwę danych przenoszonych w Odsetkach, wraz z ich interfejsem(ami) przychodzącym i wychodzącym.
- Forwarding Information Base (FIB): tablica routingu, która odwzorowuje komponenty nazw na interfejsy. Sam FIB jest wypełniony protokołem routingu opartym na prefiksie nazwy i może mieć wiele interfejsów wyjściowych dla każdego prefiksu.
- Content Store (CS): tymczasowa pamięć podręczna pakietów danych odebranych przez router. Ponieważ pakiet danych NDN ma znaczenie niezależnie od tego, skąd pochodzi lub dokąd jest przesyłany, można go przechowywać w pamięci podręcznej, aby zaspokoić przyszłe zainteresowania. Strategia zastępowania jest tradycyjnie stosowana najrzadziej, ale strategia zastępowania jest określana przez router i może się różnić.
- Forwarding Strategies: seria zasad i zasad dotyczących przesyłania pakietów danych i odsetek. Należy pamiętać, że strategia przekierowania może zdecydować o odrzuceniu zainteresowania w pewnych sytuacjach, np. jeśli wszystkie łącza upstream są przeciążone lub istnieje podejrzenie, że zainteresowanie jest częścią ataku DoS. Strategie te wykorzystują szereg wyzwalaczy w potoku przekazywania i są przypisywane do prefiksów nazw. Na przykład domyślnie /localhost używa strategii przekazywania multiemisji do przekazywania zainteresowań i danych do dowolnej aplikacji lokalnej działającej na kliencie NFD. Domyślną strategią przekierowania (tj. „/”) jest strategia przekierowania Najlepsza trasa.
Gdy nadejdzie pakiet Interest, router NDN najpierw sprawdza Content Store pod kątem pasujących danych; jeśli istnieje w routerze, zwraca pakiet danych na interfejsie, z którego nadeszło zainteresowanie. W przeciwnym razie router wyszukuje nazwę w swoim PIT, a jeśli istnieje pasujący wpis, po prostu rejestruje przychodzący interfejs tego zainteresowania we wpisie PIT. W przypadku braku pasującego wpisu PIT router przekaże odsetki producentowi danych na podstawie informacji w FIB oraz adaptacyjnej strategii przekazywania routera. Kiedy router odbiera Zainteresowania dla tej samej nazwy z wielu węzłów podrzędnych, przekazuje dalej tylko pierwszy z nich do producenta(ów) danych.
Po nadejściu pakietu danych router NDN znajduje pasujący wpis PIT i przekazuje dane do wszystkich interfejsów podrzędnych wymienionych w tym wpisie PIT. Następnie usuwa ten wpis PIT i buforuje dane w Content Store. Pakiety danych zawsze podążają odwrotną ścieżką Zainteresowań, a przy braku utraty pakietów jeden pakiet Zainteresowania skutkuje jednym pakietem danych na każdym łączu, zapewniając równowagę przepływu. Aby pobrać duże obiekty treści, które składają się z wielu pakietów, zainteresowania pełnią podobną rolę w kontrolowaniu przepływu ruchu jak ACK w dzisiejszym Internecie: drobnoziarnista pętla sprzężenia zwrotnego kontrolowana przez konsumenta danych.
Ani pakiety odsetek, ani pakiety danych nie zawierają żadnych adresów hosta ani interfejsu; routery przesyłają pakiety odsetek do producentów danych w oparciu o nazwy przenoszone w pakietach i przesyłają pakiety danych do konsumentów w oparciu o informacje o stanie PIT ustawione przez interesy w każdym przeskoku. Ta symetria wymiany pakietów odsetek/danych indukuje pętlę sterowania przeskok po przeskoku (nie mylić z trasowaniem symetrycznym lub w ogóle z trasowaniem!) i eliminuje potrzebę jakiegokolwiek pojęcia węzłów źródłowych lub docelowych w dostarczaniu danych, w przeciwieństwie do w modelu dostarczania pakietów IP od końca do końca.
Nazwy
Projekt
Nazwy NDN są nieprzejrzyste dla sieci. Dzięki temu każda aplikacja może wybrać schemat nazewnictwa, który odpowiada jej potrzebom, dzięki czemu nazewnictwo może ewoluować niezależnie od sieci.
Struktura
Projekt NDN zakłada nazwy o strukturze hierarchicznej, np. film wyprodukowany przez UCLA może mieć nazwę /ucla/videos/demo.mpg, gdzie „/” określa komponenty nazwy w reprezentacji tekstowej, podobnie jak adresy URL. Ta hierarchiczna struktura ma wiele potencjalnych zalet:
- Specyfikacja relacji: umożliwia aplikacjom reprezentowanie kontekstu i relacji między elementami danych. Np.: segment 3 wersji 1 filmu demonstracyjnego UCLA może nosić nazwę /ucla/videos/demo.mpg/1/3
- Agregacja nazw: /ucla może odpowiadać autonomicznemu systemowi, z którego pochodzi wideo
- Routing: umożliwia skalowanie systemu i pomaga w zapewnieniu niezbędnego kontekstu dla danych
Określanie nazwy
Aby pobrać dynamicznie generowane dane, konsumenci muszą być w stanie deterministycznie skonstruować nazwę żądanego fragmentu danych bez uprzedniego zobaczenia nazwy lub danych poprzez:
- algorytm pozwala producentowi i konsumentowi uzyskać tę samą nazwę na podstawie informacji dostępnych dla obu stron.
- Selektory zainteresowań w połączeniu z dopasowywaniem najdłuższego prefiksu pobierają żądane dane przez jedną lub więcej iteracji.
Bieżące badania badają, w jaki sposób aplikacje powinny wybierać nazwy, które mogą ułatwić zarówno tworzenie aplikacji, jak i dostarczanie sieci. Celem tej pracy jest rozwinięcie i udoskonalenie istniejących zasad i wytycznych dotyczących nazewnictwa, przekształcenie tych reguł w konwencje nazewnictwa zaimplementowane w bibliotekach systemowych w celu uproszczenia przyszłego tworzenia aplikacji.
Przestrzenie nazw
Dane, które mogą być pobierane globalnie, muszą mieć globalnie unikatowe nazwy, ale nazwy używane do komunikacji lokalnej mogą wymagać tylko lokalnego routingu (lub lokalnego rozgłaszania), aby znaleźć pasujące dane. Poszczególne nazwy danych mogą mieć znaczenie w różnych zakresach i kontekstach, począwszy od „włącznika światła w tym pokoju” po „nazwy wszystkich krajów na świecie”. Zarządzanie przestrzenią nazw nie jest częścią architektury NDN, podobnie jak zarządzanie przestrzenią adresową nie jest częścią architektury IP. Jednak nazewnictwo jest najważniejszą częścią projektów aplikacji NDN. Umożliwienie programistom aplikacji, a czasem użytkownikom, projektowania własnych przestrzeni nazw do wymiany danych ma kilka zalet:
- zwiększenie bliskości mapowania między danymi aplikacji a jej wykorzystaniem sieci.
- ograniczenie potrzeby dodatkowej notacji (prowadzenie rejestrów w celu odwzorowania konfiguracji aplikacji na konfigurację sieci).
- rozszerzenie zakresu abstrakcji dostępnych dla programistów.
- żądania treści oparte na nazwach również wprowadzają obawy dotyczące wycieku prywatności . Dzięki oddzieleniu zarządzania przestrzenią nazw od architektury NDN możliwe jest zapewnienie schematu nazewnictwa chroniącego prywatność poprzez wprowadzenie drobnych zmian w konwencjonalnym schemacie nazewnictwa NDN.
Rozgromienie
Rozwiązania problemów z IP
NDN trasuje i przekazuje pakiety na podstawie nazw, co eliminuje trzy problemy powodowane przez adresy w architekturze IP:
- Wyczerpanie przestrzeni adresowej : Przestrzeń nazw NDN jest zasadniczo nieograniczona. Przestrzeń nazw jest ograniczona jedynie maksymalnym rozmiarem pakietu zainteresowania wynoszącym 8 kb oraz liczbą możliwych unikalnych kombinacji znaków składających się na nazwy.
- NAT : NDN eliminuje adresy, publiczne lub prywatne, więc NAT jest niepotrzebny.
- Zarządzanie adresami: przydzielanie i zarządzanie adresami nie jest już wymagane w sieciach lokalnych.
- W multiemisji sieciowej : producent danych nie musi otrzymywać wielu odsetek za te same dane, ponieważ wpisy PIT u dostawców usług spedycyjnych będą agregować interesy. Producent odbiera pojedyncze zainteresowanie i odpowiada na nie, a te węzły przekazujące, w których otrzymano wiele przychodzących zapytań, będą rozsyłać odpowiedzi danych do interfejsów, z których otrzymano te zainteresowania.
- Wysoka niezawodność od końca do końca: sieci oparte na protokole IP wymagają ponownej transmisji utraconych lub porzuconych pakietów przez nadawcę. Jednak w NDN, jeśli zainteresowanie wygaśnie, zanim odpowiedź danych dotrze do żądającego, odpowiedź danych jest nadal buforowana przez usługi przesyłania dalej na ścieżce zwrotnej. Retransmitowane zainteresowanie musi tylko dotrzeć do dostawcy z kopią danych w pamięci podręcznej, zapewniając sieciom opartym na NDN wyższą przepustowość niż sieci oparte na protokole IP, gdy wskaźniki utraty pakietów są wysokie.
Protokoły
NDN może wykorzystywać konwencjonalne algorytmy routingu, takie jak stan łącza i wektor odległości . Zamiast ogłaszać prefiksy IP , router NDN ogłasza prefiksy nazw obejmujące dane, które router chce obsłużyć. Konwencjonalne protokoły routingu, takie jak OSPF i BGP , można dostosować do trasowania na podstawie prefiksów nazw, traktując nazwy jako sekwencję nieprzezroczystych komponentów i dopasowując najdłuższy prefiks nazwy w pakiecie odsetek do tabeli FIB . . Umożliwia to agregację szerokiego wachlarza danych wejściowych w czasie rzeczywistym i dystrybucję ich w wielu środowiskach interfejsów jednocześnie, bez naruszania szyfrowania treści. Kluczowe analizy interfejsu są również oszczędzane przez ten proces. Transfer aplikacji i udostępnianie danych w środowisku są definiowane przez multimodalną strukturę dystrybucji, tak że protokoły przekaźników w chmurze, których dotyczy problem, są unikalne dla indywidualnego identyfikatora środowiska uruchomieniowego.
stan PIT
Stan PIT na każdym routerze obsługuje przekazywanie przez płaszczyznę danych NDN, rejestrowanie każdego oczekującego zainteresowania i przychodzących interfejsów oraz usuwanie zainteresowania po otrzymaniu pasujących danych lub przekroczeniu limitu czasu. To na przeskok, na stan pakietu różni się od bezstanowej płaszczyzny danych IP. W oparciu o informacje z FIB i pomiary wydajności moduł adaptacyjnej strategii przekazywania w każdym routerze podejmuje świadome decyzje dotyczące:
- Przepływ sterowania: ponieważ każde zainteresowanie pobiera co najwyżej jeden pakiet danych, router może bezpośrednio kontrolować przepływ, kontrolując liczbę utrzymywanych oczekujących zainteresowań.
- Dostarczanie danych w trybie multiemisji: PIT rejestrujący zestaw interfejsów, na które dotarły te same dane, oczywiście obsługuje tę funkcję.
- Aktualizowanie ścieżek w celu uwzględnienia zmian w widoku sieci.
- Dostarczanie: router może wnioskować, które Zainteresowania przekazać do jakich interfejsów, ile niezaspokojonych Zainteresowań dopuścić w PIT, a także względny priorytet różnych Zainteresowań.
Odsetki
Jeśli router uzna, że Zainteresowanie nie może zostać zaspokojone, np. łącze upstream nie działa, w FIB nie ma wpisu przekierowującego lub występuje ekstremalne przeciążenie, router może wysłać NACK do swojego sąsiada (sąsiadów), którzy przesłali Zainteresowanie . Takie Negative Acknowledgment (NACK) może spowodować, że router odbierający przekaże zainteresowanie do innych interfejsów w celu zbadania alternatywnych ścieżek. Stan PIT umożliwia routerom identyfikowanie i odrzucanie zapętlonych pakietów, umożliwiając im swobodne korzystanie z wielu ścieżek w kierunku tego samego producenta danych. Pakiety nie mogą zapętlać się w NDN, co oznacza, że nie ma potrzeby stosowania czasu życia i innych środków zaimplementowanych w protokole IP i powiązanych protokołach w celu rozwiązania tych problemów.
Bezpieczeństwo
Przegląd
W przeciwieństwie do zabezpieczeń TCP/IP (np. TLS), które zabezpieczają komunikację poprzez zabezpieczanie kanałów IP-to-IP, NDN zabezpiecza same dane, wymagając od producentów danych kryptograficznego podpisania każdego pakietu danych. Podpis wydawcy zapewnia integralność i umożliwia uwierzytelnienie pochodzenia danych , umożliwiając oddzielenie zaufania konsumentów do danych od sposobu i miejsca ich pozyskiwania. NDN obsługuje również precyzyjne zaufanie, umożliwiając konsumentom wnioskowanie, czy właściciel klucza publicznego jest akceptowalnym wydawcą dla określonej części danych w określonym kontekście. Drugim głównym kierunkiem badań jest projektowanie i rozwijanie użytecznych mechanizmów zarządzania zaufaniem użytkowników. Przeprowadzono badania nad 3 różnymi typami modeli zaufania:
- hierarchiczny model zaufania: gdzie kluczowa przestrzeń nazw zezwala na użycie kluczy. Pakiet danych zawierający klucz publiczny jest w rzeczywistości certyfikatem, ponieważ jest podpisany przez stronę trzecią, a ten klucz publiczny służy do podpisywania określonych danych.
- sieć zaufania : aby umożliwić bezpieczną komunikację bez konieczności stosowania wcześniej uzgodnionych kotwic zaufania.
- lekkie zaufanie dla IoT : model zaufania NDN oparty głównie na kryptografii asymetrycznej , co jest niewykonalne w przypadku urządzeń z ograniczeniami zasobów w paradygmacie IoT.
Bezpieczeństwo aplikacji
Skoncentrowane na danych zabezpieczenia NDN mają naturalne zastosowanie w kontroli dostępu do treści i bezpieczeństwie infrastruktury. Aplikacje mogą szyfrować dane i dystrybuować klucze jako nazwane pakiety przy użyciu tej samej nazwanej infrastruktury do dystrybucji kluczy, skutecznie ograniczając granice bezpieczeństwa danych do kontekstu pojedynczej aplikacji. Aby zweryfikować podpis pakietu danych, aplikacja może pobrać odpowiedni klucz, identyfikowany w polu lokalizatora klucza pakietu, tak jak każda inna zawartość. Jednak zarządzanie zaufaniem, tj. określenie autentyczności danego klucza dla określonego pakietu w danej aplikacji, jest podstawowym wyzwaniem badawczym. Zgodnie z podejściem eksperymentalnym, badania zarządzania zaufaniem NDN opierają się na rozwoju i użytkowaniu aplikacji: najpierw rozwiązując określone problemy, a następnie identyfikując typowe wzorce. Na przykład potrzeby bezpieczeństwa NLSR wymagały opracowania prostego hierarchicznego modelu zaufania, z kluczami na niższych (bliższych rootowi) poziomach, używanych do podpisywania kluczy na wyższych poziomach, w których klucze są publikowane z nazwami odzwierciedlającymi ich relację zaufania. W tym modelu zaufania przestrzeń nazw odpowiada hierarchii delegowania zaufania, tj. /root/site/operator/router/proces. Publikowanie kluczy o określonej nazwie w hierarchii upoważnia je do podpisywania określonych pakietów danych i ogranicza ich zakres. Ten paradygmat można łatwo rozszerzyć na inne aplikacje, w których rzeczywiste zaufanie ma tendencję do hierarchicznego wzorca, na przykład w naszych systemach zarządzania budynkami (BMS). Ponieważ NDN pozostawia model zaufania pod kontrolą każdej aplikacji, można również wyrazić bardziej elastyczne i wyraziste relacje zaufania. Jednym z takich przykładów jest ChronoChat, który motywował do eksperymentowania z modelem sieci zaufania. Model bezpieczeństwa polega na tym, że obecny uczestnik czatu może przedstawić nowicjusza innym, podpisując klucz nowicjusza. Przyszłe aplikacje będą wdrażać model krzyżowej certyfikacji (SDSI) [13, 3], który zapewnia większą redundancję weryfikacji, pozwalając na niezależność danych i nazw kluczy, co łatwiej dostosowuje się do różnych rzeczywistych relacji zaufania.
Wydajność i bezpieczeństwo routingu
Co więcej, NDN traktuje routing sieciowy i komunikaty kontrolne jak wszystkie dane NDN, które wymagają podpisów. Zapewnia to solidną podstawę do zabezpieczenia protokołów routingu przed atakami, np. spoofingiem i manipulacją. Wykorzystanie przez NDN wielościeżkowego przekazywania, wraz z modułem adaptacyjnej strategii przekazywania, ogranicza przejmowanie prefiksów, ponieważ routery mogą wykrywać anomalie spowodowane przez przejmowanie i pobierać dane alternatywnymi ścieżkami. Dzięki wieloźródłowemu, multiemisyjnemu charakterowi dostarczania treści w Named Data Networking , losowe kodowanie liniowe może poprawić wydajność całej sieci. Ponieważ pakiety NDN odwołują się do treści, a nie do urządzeń, złośliwszy atak na określone urządzenie jest trudniejszy, chociaż potrzebne będą mechanizmy łagodzące przeciwko innym atakom specyficznym dla NDN, np. Interest flooding DoS. Co więcej, posiadanie Tabeli Oczekujących Odsetek, która przechowuje informacje o wcześniejszych żądaniach, która może podejmować świadome decyzje dotyczące sposobu obsługi odsetek, ma wiele zalet związanych z bezpieczeństwem:
- Równoważenie obciążenia: liczba wpisów PIT jest wskaźnikiem obciążenia routera; ograniczenie jego rozmiaru ogranicza efekt ataku DDoS.
- Limit czasu odsetek: limity czasu wejścia PIT oferują stosunkowo tanie wykrywanie ataków, a informacje interfejsu przybycia w każdym wpisie PIT mogą wspierać schemat wypychania, w którym routery podrzędne są informowane o nieobsługiwanych interesach, co pomaga w wykrywaniu ataków.
Zobacz też
- Zasady buforowania sieci skoncentrowane na informacjach
- Przyszłe badania i eksperymenty w Internecie (UE)
Linki zewnętrzne
- ŚMIERĆ TCP/IP woła Cisco, Intel, rząd USA i mnóstwo fachowców
- FIA-NP: Collaborative Research: Named Data Networking Next Phase (NDN-NP)
- Nazwana strona główna badania danych
- Nagrody NSF dla NDN 2
- FIA: Collaborative Research: Named Data Networking (NDN)
- Sieć nazwanych funkcji (NFN)
- NDN w Galileo ( migawka WebArchive )