DE602005006127T2 - Sicheres Kommunikationsverfahren- und gerät zur Verarbeitung von SEND-Datenpaketen - Google Patents

Sicheres Kommunikationsverfahren- und gerät zur Verarbeitung von SEND-Datenpaketen Download PDF

Info

Publication number
DE602005006127T2
DE602005006127T2 DE602005006127T DE602005006127T DE602005006127T2 DE 602005006127 T2 DE602005006127 T2 DE 602005006127T2 DE 602005006127 T DE602005006127 T DE 602005006127T DE 602005006127 T DE602005006127 T DE 602005006127T DE 602005006127 T2 DE602005006127 T2 DE 602005006127T2
Authority
DE
Germany
Prior art keywords
data packets
protocol
modules
ndp
communication device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE602005006127T
Other languages
English (en)
Other versions
DE602005006127D1 (de
Inventor
Laurent 28000 Clevy
Thierry 91460 Legras
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Publication of DE602005006127D1 publication Critical patent/DE602005006127D1/de
Application granted granted Critical
Publication of DE602005006127T2 publication Critical patent/DE602005006127T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Description

  • Die vorliegende Erfindung bezieht sich auf die Verwaltung von IPv6-Datenpaketen (Internet Protocole Version 6) in einem Kommunikationsgerät.
  • Manche dieser Datenpakete entsprechen dem so genannten „Network Discovery Protocol" (NDP) wie durch RFC 2461 der IETF (Internet Engineering Task Force) definiert.
  • Dieses Protokoll definiert „Autoconfiguration-" und „Network Discovery"-Pakete (ND) die es einem Gerät von einem IPv6-Kommunikationsnetz ermöglichen, seine Adresse zu bestimmen und die verschiedenen Geräte in Erfahrung zu bringen, die jeweils an diese Verbindungen angeschlossen sind. Dieses Protokoll ermöglicht es auch jedem Gerät, über die Änderungen informiert zu sein, die an diesen Verbindungen eintreten, beispielsweise wenn ein „benachbartes" Gerät unzugänglich wird. Bei diesem Gerät kann es sich um einen Router (oder Knoten), einen „Host" (das heißt ein Endgerät), ein Gateway oder eine beliebige Vorrichtung handeln, die die Mittel zum Senden und Empfangen der IPv6-Datenpakete besitzt.
  • Außerdem braucht der Betreiber des Kommunikationsnetzes dank dieses Protokolls nicht mehr jedes der Geräte seines Netzes manuell zu konfigurieren, denn dieses kann sich durch Austausch von Autoconfigurationpaketen gemäß dem Protokoll NDP autokonfigurieren.
  • Jedoch ist es erforderlich, diese Datenpakete zu sichern, damit insbesondere ein nicht berechtigter Host sich nicht an das Kommunikationsnetz anschließen kann. So ist es durch das NDP-Protokoll möglich, dass ein Host sich die Identität eines anderen Hosts widerrechtlich aneignet, indem er das Gerät für den Zugang zu diesem Netz glauben macht, dass es die MAC-Schnittstelle desselben besitzt.
  • Ein solcher Bedarf ist bei Funkkommunikationsnetzen entscheidend, in denen die Hosts mobil sind, und folglich nicht physisch und statisch an Zugangsgeräte angeschlossen sind.
  • Es ist also notwendig, das NDP-Protokoll mit Sicherungsmechanismen auszustatten. RFC 3756 mit dem Titel „IPv6 Neighbor Discovery (ND) Trust Models and Threats" vom Mai 2004 zeigt die Probleme und Anforderungen für die Scherung des NDP-Protokolls auf. Es unterstreicht dass die früheren Arbeiten auf dem Sicherungsprotokoll „IPsec" basierten, dass dieses Protokoll aber die manuelle Bestimmung der Codierungsschlüssel erfordert. Da dieser manuelle Schritt kaum mit dem automatischen Charakter des NDP-Protokolls kompatibel ist, ist ein anderer Ansatz erforderlich.
  • Dieser Ansatz wird durch RFC 3971 der IETF mit dem Titel „Secure Neighbor Discovery (SEND)" vom März 2005 vorgeschlagen. Vom technischen Gesichtspunkt aus besteht der SEND-Mechanismus darin, Sicherheitsinformationen enthaltende Felder in jeder der Mitteilungen des NDP-Protokolls hinzuzufügen, genauer gesagt am Ende selbiger. Diese Felder werden teilweise durch das RFC definiert: es handelt sich um die Felder „RSA Signature option", „CGA option", „Timestamp option" und „None option". Jedoch lassen die Spezifikationen von RFC 3971 die Möglichkeit offen, später neue „option"-Felder hinzuzufügen, um das NDP-Protokoll und den SEND-Mechanismus noch anzureichern.
  • Derzeit beginnt man gerade erst damit die ersten Implementierungen des SEND-Mechanismus zu definieren. Einige dieser Implementierungen basieren auf einem Betriebssystem vom Typ Linux. Es kann sich zum Beispiel um ein Linux- oder BSD-Betriebssystem handeln. Herkömmlich schließen die für Kommunikationsgeräte dedizierten Betriebssystemkerne einen oder mehrere Protokollstapel ein, welche die Übertragung der Datenpakete für die Anwendungen transparent managen. Diese Protokollstapel IPv6 implementieren also die Softwaremechanismen, die erforderlich sind, um das NDP-Protokoll und den SEND-Mechanismus zu verwalten.
  • Ein solcher Ansatz weist jedoch große Nachteile auf. Der SEND-Mechanismus ist entwicklungsfähig, insbesondere durch die Hinzufügung von neuen „Options"-feldern. Jede Entwicklung erfordert also die Abänderung des Kerns des Betriebssystems. Nun ist es so, dass die Änderung eines Betriebskerns (oder Kerns eines Betriebssystems) ein komplexer und somit teurer Arbeitsvorgang ist.
  • Zweck der Erfindung ist es also, diesen Nachteilen abzuhelfen, indem man ein Kommunikationsgerät vorschlägt, das den SEND-Mechanismus für das Betriebssystem transparent ausführt. Sie kommt zwischen dem Netz und dem Betriebssystem zum Einsatz, was ausbaufähig ist und vor allem nicht so kostspielig.
  • Ein erster Gegenstand der Erfindung ist somit ein Verfahren zur Sicherung eines Kommunikationsgeräts, das einen Betriebssystemkern und einen Komplex Softwareanwendungen einschließt, wobei dieser Kern mindestens einen IPv6-Protokollstapel enthält, der es ermöglicht, eingehende Datenpakete von einem Eingangsport aus zu einer Anwendung zu übertragen und ausgehende Datenpakete von einer (anderen oder identischen) Anwendung aus zu einem Ausgangsport zu übertragen, wobei diese Protokollstapel einen Komplex von Schnittstellen einschließen, die dafür vorgesehen sind, es externen Modulen, die an jene angeschlossen sind, zu ermöglichen, auf Datenpakete, die durch den oder die Protokollstapel übertragen werden, an bestimmten Punkten zuzugreifen, welche mit diesen Schnittstellen verknüpft sind. Das Verfahren ist dadurch gekennzeichnet, dass man Eingangsmodule und Ausgangsmodule mit einer Eingangsschnittselle (HIN) beziehungsweise einer Ausgangsschnittstelle des Kerns verbindet, und dadurch gekennzeichnet, dass die Module die Datenpakete des NDP-Protokolls auswählen, analysieren und eventuell modifizieren, gemäß dem SEND-Mechanismus, und zwar für den Kern transparent.
  • Gegenstand der Erfindung ist ebenfalls ein Kommunikationsgerät, das einen Betriebssystemkern und einen Komplex Softwareanwendungen einschließt, wobei der Kern mindestens einen Protokollstapel IPv6 enthält, der es ermöglicht, eingehende Datenpakete von einem Eingangsport aus zu einer Anwendung zu übertragen und ausgehende Datenpakete von einer (identischen oder anderen) Anwendung aus zu einem Ausgangsport (POUT) zu übertragen, wobei die Protokollstapel einen Komplex von Schnittstellen einschließen, die dafür vorgesehen sind, es externen Modulen, die an jene angeschlossen sind, zu ermöglichen, auf die Datenpakete, die durch den oder die Protokollstapel übertragen werden, an bestimmten Punkten zuzugreifen, welche mit diesen Schnittstellen verknüpft sind. Das Kommunikationsgerät ist dadurch gekennzeichnet, dass Eingangs- und Ausgangsmodule mit einer Eingangsschnittstelle beziehungsweise einer Ausgangsschnittstelle verbunden sind, und dafür vorgesehen sind, die Datenpakete des NDP-Protokolls auszuwählen, zu analysieren und zu modifizieren, gemäß dem SEND-Mechanismus, und zwar für diesen Kern transparent.
  • Gemäß einer Ausführung der Erfindung ist das Betriebssystem ein Linux-System und die bestimmten Punkte werden gemäß der Infrastruktur „NetFilter" definiert.
  • Außerdem analysieren und modifizieren die externen Module gemäß einer Ausführungsart die Optionen „CGA Option" und „RSA signature" dieser Datenpakete des NDP-Protokolls; die Modifizierung kann das Hinzufügen dieser Optionen einschließen.
  • Auf diese Art und Weise können Entwicklungen der SEND-Mechanismen dadurch erfolgen, dass man die Eingangs- und/oder Ausgangsmodule wechselt. Der Betriebskern an sich bleibt unverändert. Die Kosten für Entwicklung und Prüfung werden also erheblich verringert.
  • Das Verhalten des Kerns des Betriebssystems wird durch die Maßnahmen der Eingangs- und/oder Ausgangsmodule nicht beeinflusst. Für ihn sind diese Maßnahmen transparent.
  • Außerdem wird es möglich, Weiterentwicklungen des Mechanismus oder einfach den Austausch der Module durch leistungsfähigere oder „ausgetestete" neue Module direkt am Kommunikationsgerät vorzunehmen, ohne dass das System gestoppt, Änderungen vorgenommen, der Kern neu kompiliert und das System neu gestartet werden muss.
  • Die Darstellung und ihre Vorteile treten in der nachfolgenden Beschreibung in Verbindung mit den beigefügten Figuren deutlicher zutage.
  • 1 stellt schematisch ein Kommunikationsgerät gemäß der Erfindung dar.
  • 2 veranschaulicht eine auf einem Linux-Betriebssystem basierende besondere Ausführungsart der Erfindung.
  • 3 stellt ein Paket aus dem NDP-Protokoll dar, wobei ein SEND-Mechanismus zum Einsatz kommt.
  • Wie vorstehend gesagt kann ein Kommunikationsgerät sich aufgliedern lassen zwischen einem Betriebssystemkern (oder abgekürzt „Betriebskern") und Anwendungen, die dank dieses Kerns funktionieren. Die Rolle des Kerns ist es, es diesen Anwendungen zu ermöglichen, unabhängig von der Hardware (Hersteller des Kommunikationsgeräts, Modell, usw.) sowie von der Netzinfrastruktur (Version der Netzwerkprotokolle, Protokollart, usw.) zu funktionieren und die Entwicklung der Anwendungen zu erleichtern, indem ein Komplex von „Funktionen" angeboten wird, der von diesen Anwendungen nutzbar ist. Diese Funktionen sind dank klar definierter Schnittstellen für die Anwendungen zugänglich.
  • Auf 1 schließt das dargestellte Kommunikationsgerät also einen Kern K und einen für die Anwendungen dedizierten Raum AS („User space” oder „user land") ein.
  • Der Betriebskern K schließt einen (oder mehrere) Protokollstapel PS ein, sowie weitere nicht dargestellte Funktionen. Im Rahmen der Erfindung ist dieser Protokollstapel vorzugsweise entsprechend dem Protokoll IPv6 (Internet Protocole Version 6). Der Protokollstapel PS ist verbunden zum einen mit einem Eingangsport PIN und zum anderen mit einem Ausgangsport POUT. Die Datenpakete besitzen einen Kopf gemäß dem Protokoll IPv6, der mindestens die Empfängeradresse und die Quellenadresse präzisiert.
  • Die eingehenden Datenpakete sind Datenpakete, die als Empfängeradresse die IPv6-Adresse des Kommunikationsgeräts enthalten. Diese Pakete kommen durch den Eingangsport PIN herein und werden vom Protokollstapel PS bis zu einer Anwendung A übermittelt.
  • Eine Anwendung A (die gleiche oder eine andere) kann ebenfalls Datenpakete senden. Diese Datenpakete enthalten dann die IPv6-Adresse des Kommunikationsgeräts als Quellenadresse und werden vom Protokollstapel bis zum Ausgangsport POUT übertragen.
  • Der Protokollstapel PS schließt außerdem einen Komplex von Schnittstellen (HPRE, HIN, HOUT, HPOST) ein. Diese Schnittstellen sind dafür vorgesehen, es den externen Modulen MIN, MOUT zu ermöglichen, mit dem Protokollstapel verbunden zu werden, um auf die vom Protokollstapel übertragenen Datenpakete an bestimmten Punkten, die mit diesen Schnittstellen verknüpft sind, zuzugreifen.
  • 1 zeigt nur 4 Schnittstellen HPRE, HIN, HOUT, HPOST aber der Protokollstapel PS kann weitere davon besitzen. Diese Schnittstellen hängen von der Art des Betriebskerns K ab.
  • Bei einer Ausführung entsprechend dem Linux-Kern definiert die „NetFilter"-Infrastruktur fünf Schnittstellen entsprechend 5 bestimmten Punkten in der Übertragung der Datenpakete. Die „NetFilter"-Infrastruktur wird durch die Website www.netfilter.org beschrieben und diese fünf Punkte werden durch 2 veranschaulicht.
  • Die Erfindung kann jedoch nicht auf diese Ausführung beschränkt werden, denn sie kann auf andere Betriebssysteme (BSD, usw.) Anwendung finden, die ebenfalls bestimmte Punkte („hook”) bieten, die mit Schnittstellen verknüpft sind, die den Zugriff auf die Datenpakete durch externe Module ermöglichen.
  • Im Rahmen dieser auf dem Linux-System basierenden Ausführung ist jedes an einem Eingangsport eintreffende Datenpaket zunächst Gegenstand einer Vorverarbeitung PreP.
  • Diese Vorverarbeitung besteht insbesondere darin, zu überprüfen, dass das Datenpaket vollständig ist, dass der im Paket enthaltene Überprüfungswert („checksum") den empfangenen Daten entspricht, usw. Nach dieser Vorverarbeitung findet man einen ersten bestimmten Punkt „PRE".
  • Die Datenpakete durchlaufen dann eine zweite Verarbeitung „Routing", die darin besteht, zu bestimmen, ob ihr Ziel das Kommunikationsgerät ist oder ob sie zu einem Ausgangsport weiter übermittelt werden müssen. Hierfür vergleicht die Verarbeitung „Routing" die in jedem Datenpaket enthaltene Zieladresse mit der IPv6-Adresse des Kommunikationsgeräts. Wenn diese Adressen sich entsprechen kommt das Datenpaket an einem bestimmten Punkt „IN" an, dann wird es zu einer Zielanwendung übertragen.
  • Falls dieses nicht der Fall ist, gelangt es zu einem bestimmten Punkt „FWD", was bedeutet, dass es zu einem anderen Kommunikationsgerät übertragen werden soll (_"ForWarD" auf Englisch).
  • Die Datenpakete können dann Gegenstand weiterer Verarbeitungen „Poste" sein, bevor sie beim letzten bestimmten Punkt „POST" anlangen, was bedeutet, dass das Paket bereit für die Übertragung durch einen Ausgangsport ist.
  • Die vom Kommunikationsgerät herkommenden Datenpakete treffen durch einen ersten bestimmten Punkt „OUT” ein. Sie werden einer Verarbeitung „Routing" unterzogen, um zu bestimmen wohin (zu welchem Port) sie gesendet werden sollen, dann weitere etwaige Verarbeitungen „Poste", bevor sie zum bestimmten Punkt „POST" gelangen.
  • Mit anderen Worten: diese besonderen Punkte entsprechen „Status" der Verarbeitung der Datenpakete durch den Protokollstapel PS, Markierungen entlang ihres Verlaufs.
  • Mit diesen bestimmten Punkten „PRE", „IN", „FWD", „OUT" und „POST" sind Schnittstellen verknüpft, das heißt Mittel für den Zugriff auf Datenpakete durch Anwendungen (oder Module), die extern vom Protokollstapel sind. Diese Schnittstellen werden in dem der „NetFilter"-Infrastruktur eigenen Vokabular als „hook" (das englische Wort für „Haken") bezeichnet.
  • Die Anwendungen, die an die Schnittstellen des Protokollstapels angeschlossen sind, werden anschließend als „Module" bezeichnet, um sie von den anderen Anwendungen zu unterscheiden, wie diejenigen, die Endpunkte der Datenpaketströme (wie die Anwendungen A aus 1) sein können.
  • Die externen Module können dank eines Listenmechanismus an die Schnittstellen des Protokollstapels angeschlossen werden. Jeder Schnittstelle entsprechen mehrere Listen, wobei diese jeweils eine präzise Funktion haben. Mehrere Implementierungen sind hier möglich, die insbesondere von der Art des verwendeten Kerns (die Listen „mangle" und „filter" für Linux, die Liste „divert" für BSD, usw.) abhängen.
  • Externe Module können bei den Listen dieser Schnittstellen registriert werden. Wenn ein Datenpaket einen der bestimmten Punkte erreicht, wird die „NetFilter"-Infrastruktur aufgerufen. Diese verfügt über die notwendigen Mittel, um es den in ihren Listen registrierten externen Modulen zu ermöglichen, auf das Datenpaket zuzugreifen.
  • Jedoch hat die Patentanmelderin bemerkt, dass im Falle des Protokolls NDP die Empfängeradresse vom Typ „multi-cast" (oder auf Französisch „point à multipoint" = Punkt zu Mehrpunkt) ist: sie adressieren sämtliche Kommunikationsgeräte, die Teilnehmer bei dieser Gruppe sind („alle Knoten” oder „alle Router") auf ein und derselben Verbindung. Daher ist jedes Teilnehmer-Kommunikationsgerät Empfänger sämtlicher Pakete des Protokolls NDP. Folglich kann eine erste Auswahl hinsichtlich der Art des Datenpakets erfolgen, das die „NetFilter"-Infrastruktur passiert oder nicht, dank des Befehls „ipótables". Hier werden lediglich die Datenpakete des Protokolls NDP an die „NetFilter"-Infrastrukur gesendet; die anderen setzen ihren üblichen Weg fort.
  • Außerdem ist es zwecks Optimierung des Mechanismus und Einsparung von Ressourcen interessant sich nur für die bestimmten Punkte „IN" und „OUT" und ihre verknüpften Schnittstellen zu interessieren.
  • Wenn wir auf 1 zurückkommen, sind also zwei externe Module MIN und MOUT mit den Schnittstellen (oder „hook") HIN und HOUT verbunden. Um diese Schnittstellen zu nutzen, verwenden die externen Module die Funktionen, die von der Bibliothek „libipq" angeboten werden. Der diesen Funktionen entsprechende Code wird auf 1 schraffiert dargestellt.
  • Wie bereits gesagt ermöglichen es diese Funktionen dem Modul auf das Datenpaket zuzugreifen, wenn sie sich bei einer Schnittstelle HIN, HOUT des Protokollstapels PS präsentieren.
  • Die Einzelheiten der Bibliothek „libipq" werden in verschiedenen Dokumentationen dargelegt, die dem Fachmann zugänglich sind, darunter die „manuellen Seiten" der Betriebssysteme („manpages").
  • Ohne auf alle Einzelheiten eingehen zu wollen, ist es so, dass die Funktion „ipq_read()" es jedem externen Modul ermöglicht, das Eintreffen eines Datenpakets an der Schnittstelle abzuwarten. Die Funktion „ipq_get_packet()” ermöglicht es anschließend, dieses Datenpaket zu lesen, das heißt, es in einen Speicherbereich zu kopieren, der für das externe Modul vorbehalten ist. Dieses kann dann jede der im Datenpaket enthaltenen Informationen lesen.
  • Es kann dann die Pakete des Protokolls NDP aus den anderen Datenpaketen auswählen und kann die ausgewählten Datenpakete analysieren und eventuell modifizieren, gemäß dem SEND-Mechanismus.
  • Diese Auswahl und diese Analyse werden später detaillierter betrachtet, aber hier ist es wichtig zu wissen, dass gegebenenfalls der Speicherbereich, in den das Datenpaket kopiert wurde, modifiziert werden kann, um diese Verarbeitung widerzuspiegeln.
  • Nachdem dieses durchgeführt wurde, kann das externe Modul die Funktion „ipq_set_verdict()" verwenden. Diese Funktion ermöglicht es, mit dem Argument „ACCEPT" oder "MODIFIED" das Datenpaket im Protokollstapel PS durch die betreffende Schnittstelle HIN, HOUT intakt oder modifiziert wieder her zu stellen. Dieses Datenpaket ist eine Kopie des Speicherbereichs, in den es zuvor kopiert worden war.
  • Auf diese Art und Weise können die externen Module die Datenpakete modifizieren (Argument „MODIFIED"), die vom Protokollstapel PS auf für diesen transparente Art und Weise übertragen wurden.
  • Die Auswahl der Pakete des Protokolls NDP kann abhängig von den Spezifikationen des Protokolls NDP („Neighbor Discovery Protocol”) definiert durch RFC 2461 erfolgen.
  • 3 stellt schematisch das Format eines Datenpakets dar. Es beinhaltet einen Kopf „IP Header" so wie vorstehend genannt. Anschließend kommt ein zweiter „Kopf", ND, bestehend aus Feldern, die dem NDP-Protokoll eigen sind. Dieses Protokoll definiert 5 Arten von Datenpaketen: „Neighbor Solicitation", „Neighbor Advertisement", „Router Solicitation", „Router Advertisement", „Redirect".
  • Es ist möglich die Pakete gemäß dem Protokoll NDP durch die Analyse dieses Kopfes „ND" auszuwählen. So wie in Abschnitt 4 von RFC 2461 beschrieben beginnt der ND-Kopf mit einem Feld „Typ", das den Typ des Datenpakets gemäß der nachstehenden Tabelle definiert:
    Pakettyp Wert des Feldes „Typ"
    „Neighbor Solicitation" 135
    „Neighbor Advertisement" 136
    „Router Solicitation" 133
    „Router Advertisement" 134
    „Redirect" 137
  • Die Pakete gemäß dem Protokoll NDP besitzen außerdem einen Inhaltsbereich, der vom SEND-Mechanismus genutzt wird, um dort Optionen einzufügen. Der SEND-Mechanismus sieht insbesondere zwei Optionen vor: die Option RSA (oder genauer gesagt „RSA signature") und die Option CGA. Zwei weitere Optionen – die auf der Figur nicht dargestellt sind – sind ebenfalls vorgesehen: die Option „TimeStamp" und die Option „Nonce".
  • Die Option CGA ermöglicht es, Informationen im Zusammenhang mit der CGA-Technik (für auf Englisch „Cryptographically Generated Address") zu übertragen. Diese Technik wird in RFC 3972 vom März 2005 beschrieben und sie besteht darin, die IPv6-Adresse eine Netzknotens zu generieren, wobei eine irreversible Hash-Funktion ausgehend von mindestens dem Public-Key dieses Knotens generiert wird.
  • Die Option „RSA" ermöglicht es, an die NDP-Datenpakete Signaturen anzuhängen, die auf einem Public-Key basieren.
  • Diese Optionen sind nicht voneinander unabhängig. Wenn zum Beispiel die Optionen „CGA" und „RSA signature" vorhanden sind, dann ist es erforderlich, dass der Public-Key, der ausgehend von der Option „CGA" ermittelt wurde, derjenige ist, der im Feld „Key Hash" der Option „RSA signature" übertragen wird. Falls dieses nicht der Fall ist, muss das Paket unterdrückt werden.
  • Somit müssen zahlreiche Verarbeitungsregeln vom Kommunikationsgerät angewandt werden, und zwar für das Senden der NDP-Pakete oder das Empfangen.
  • Die Rolle der externen Module MIN und MOUT besteht dann darin, diese Verarbeitungsregeln für den zweiten beziehungsweise ersten Fall anzuwenden. Sie können diese Aufgabe für den Betriebskern vollkommen transparent erfüllen. Es geht also zum einen darum, die NDP-Datenpakete (hauptsächlich für MIN) zu analysieren, um sich davon zu überzeugen, dass sie den SEND-Mechanismus befolgen und zum anderen darum, die NDP-Datenpakete (hauptsächlich für MOUT) zu modifizieren, um sie an den SEND-Mechanismus anzupassen.
  • Wenn eine neue Version des Verarbeitungscodes des SEND-Mechanismus verfügbar ist, genügt es dann, diesen Code in diese externen Module einzubauen, ohne deshalb den Knoten selbst zu verändern. Ebenso, wenn der SEND-Mechanismus sich weiter entwickelt und neue Optionen festlegt: auch da genügt es, den Code bezüglich dieser Weiterentwicklungen in den externen Modulen einzufügen, ohne den Betriebskern anzutasten.
  • In der Situation, wo der Kern des Betriebssystems nicht über eine Infrastruktur vergleichbar der „NetFilter"-Infrastruktur verfügt, das heißt, wenn er Schnittstellen aufweist, die mit bestimmten Punkten verknüpft sind, bleibt es möglich, die Erfindung als „Programm mit Notfunktionen" auszuführen. Es ist nämlich möglich, die Pakete vor ihrem Eingang in den Protokollstapel und bei ihrem Ausgang zu beobachten. Softwaremodule MIN, MOUT können also mit dem Eingang und dem Ausgang dieses Protokollstapels verbunden werden, um gegebenenfalls die Pakete, die dem NDP-Protokoll entsprechen, gemäß dem SEND-Mechanismus zu modifizieren.

Claims (8)

  1. Verfahren zur Sicherung eines Kommunikationsgeräts (E), das einen Betriebssystemkern (K) und einen Komplex logischer Anwendungen (A) einschließt, wobei dieser Kern mindestens einen Protokollstapel IPv6 (PS) enthält, der es ermöglicht, eingehende Datenpakete von einem Eingangsport (PIN) aus zu einer Anwendung (A) zu übertragen und ausgehende Datenpakete von einer Anwendung (A) aus zu einem Ausgangsport (POUT) zu übertragen, wobei diese Protokollstapel einen Komplex von Schnittstellen (HPRE, HIN, HOUT, HPOST) einschließen, die dafür vorgesehen sind, es externen Modulen, die an jene angeschlossen sind, zu ermöglichen, auf diese Datenpakete, die durch diesen mindestens einen Protokollstapel übertragen werden, an bestimmten Punkten zuzugreifen, welche mit diesen Schnittstellen verknüpft sind, wobei dieses Verfahren dadurch gekennzeichnet ist, dass man Eingangsmodule (MIN) und Ausgangsmodule (MOUT) mit einer Eingangsschnittselle (HIN) beziehungsweise einer Ausgangsschnittstelle (HOUT) dieses Kerns (K) verbindet, und dadurch gekennzeichnet, dass diese Module die Datenpakete des Protokolls NDP auswählen, analysieren und eventuell modifizieren, gemäß dem Mechanismus SEND, und zwar für diesen Kern transparent.
  2. Sicherungsverfahren gemäß dem vorstehenden Anspruch, bei dem dieses Betriebssystem ein Linux-System ist und diese bestimmten Punkte gemäß der Infrastruktur „NetFilter" definiert werden.
  3. Sicherungsverfahren gemäß einem der vorstehenden Ansprüche, bei dem diese externen Module die Optionen „CGA Option" und „RSA signature" dieser Datenpakete des NDP-Protokolls analysieren und modifizieren.
  4. Sicherungsverfahren gemäß Anspruch 1, bei dem diese bestimmten Punkte am Eingang und am Ausgang dieses Protokollstapels (PS) gelegen sind.
  5. Kommunikationsgerät (E), das einen Betriebssystemkern (K) und einen Komplex Softwareanwendungen (A) einschließt, wobei dieser Kern mindestens einen Protokollstapel IPv6 (PS) enthält, der es ermöglicht, eingehende Datenpakete von einem Eingangsport (PIN) aus zu einer Anwendung (A) zu übertragen und ausgehende Datenpakete von einer Anwendung (A) aus zu einem Ausgangsport (POUT) zu übertragen, wobei diese Protokollstapel einen Komplex von Schnittstellen (HPRE, HIN, HOUT, HPOST) einschließen, die dafür vorgesehen sind, es externen Modulen, die an jene angeschlossen sind, zu ermöglichen, auf diese Datenpakete, die durch diesen mindestens einen Protokollstapel übertragen werden, an bestimmten Punkten zuzugreifen, welche mit diesen Schnittstellen verknüpft sind, dadurch gekennzeichnet, dass Eingangsmodule (MIN) und Ausgangsmodule (MOUT) mit einer Eingangsschnittselle (HIN) beziehungsweise einer Ausgangsschnittstelle (HOUT) dieses Kerns (K) verbunden sind, und dafür vorgesehen sind, die Datenpakete des Protokolls NDP auszuwählen, zu analysieren und zu modifizieren, gemäß dem Mechanismus SEND, und zwar für diesen Kern transparent.
  6. Kommunikationsgerät gemäß dem vorstehenden Anspruch, bei dem dieses Betriebssystem ein Linux-System ist und diese bestimmten Punkte gemäß der Infrastruktur „NetFilter" definiert werden.
  7. Kommunikationsgerät gemäß einem der Ansprüche 5 oder 6, bei dem diese externen Module die Optionen „CGA Option" und „RSA signature" dieser Datenpakete des Protokolls NDP analysieren und modifizieren.
  8. Kommunikationsgerät gemäß Anspruch 5, bei dem diese bestimmten Punkte am Eingang und am Ausgang dieses Protokollstapels (PS) gelegen sind.
DE602005006127T 2005-08-25 2005-08-25 Sicheres Kommunikationsverfahren- und gerät zur Verarbeitung von SEND-Datenpaketen Active DE602005006127T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP05300694A EP1758338B1 (de) 2005-08-25 2005-08-25 Sicheres Kommunikationsverfahren- und gerät zur Verarbeitung von SEND-Datenpaketen

Publications (2)

Publication Number Publication Date
DE602005006127D1 DE602005006127D1 (de) 2008-05-29
DE602005006127T2 true DE602005006127T2 (de) 2009-07-02

Family

ID=35686555

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602005006127T Active DE602005006127T2 (de) 2005-08-25 2005-08-25 Sicheres Kommunikationsverfahren- und gerät zur Verarbeitung von SEND-Datenpaketen

Country Status (5)

Country Link
US (1) US7747849B2 (de)
EP (1) EP1758338B1 (de)
CN (1) CN100586124C (de)
AT (1) ATE392769T1 (de)
DE (1) DE602005006127T2 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090129597A1 (en) * 2007-11-21 2009-05-21 Zimmer Vincent J Remote provisioning utilizing device identifier
CN101640631B (zh) * 2008-07-28 2011-11-16 成都市华为赛门铁克科技有限公司 一种数据包处理的方法和装置
US8050196B2 (en) 2009-07-09 2011-11-01 Itt Manufacturing Enterprises, Inc. Method and apparatus for controlling packet transmissions within wireless networks to enhance network formation
US8953798B2 (en) * 2010-10-29 2015-02-10 Telefonaktiebolaget L M Ericsson (Publ) Enhanced cryptographically generated addresses for secure route optimization in mobile internet protocol
US8826436B2 (en) 2010-12-08 2014-09-02 At&T Intellectual Property I, L.P. Systems, methods and apparatus to apply permissions to applications
US10367785B2 (en) * 2013-10-01 2019-07-30 Perfecta Federal Llc Software defined traffic modification system

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7299490B2 (en) * 2001-06-29 2007-11-20 Hewlett-Packard Development Company, L.P. Portable wireless device and software for printing by reference
AU2002366687A1 (en) * 2001-12-11 2003-06-23 Koninklijke Philips Electronics N.V. System for transmitting additional information via a network
US20040240669A1 (en) * 2002-02-19 2004-12-02 James Kempf Securing neighbor discovery using address based keys
US7305704B2 (en) * 2002-03-16 2007-12-04 Trustedflow Systems, Inc. Management of trusted flow system
US7450499B2 (en) * 2003-02-21 2008-11-11 Samsung Electronics Co., Ltd. Method and apparatus for interconnecting IPv4 and IPv6 networks
US7409544B2 (en) * 2003-03-27 2008-08-05 Microsoft Corporation Methods and systems for authenticating messages
US8261062B2 (en) * 2003-03-27 2012-09-04 Microsoft Corporation Non-cryptographic addressing
US7467214B2 (en) * 2003-06-20 2008-12-16 Motorola, Inc. Invoking protocol translation in a multicast network
JP4210168B2 (ja) * 2003-07-09 2009-01-14 株式会社エヌ・ティ・ティ・ドコモ 移動端末、制御装置、ホームエージェント及びパケット通信方法
US7860978B2 (en) * 2004-01-22 2010-12-28 Toshiba America Research, Inc. Establishing a secure tunnel to access router
CN1691668B (zh) * 2004-04-30 2010-04-28 华为技术有限公司 一种提供IPv6服务的系统和方法
KR100651715B1 (ko) * 2004-10-07 2006-12-01 한국전자통신연구원 차세대 인터넷에서 자동으로 주소를 생성하고 수락하는방법 및 이를 위한 데이터 구조
US20060285519A1 (en) * 2005-06-15 2006-12-21 Vidya Narayanan Method and apparatus to facilitate handover key derivation

Also Published As

Publication number Publication date
US7747849B2 (en) 2010-06-29
EP1758338A1 (de) 2007-02-28
ATE392769T1 (de) 2008-05-15
DE602005006127D1 (de) 2008-05-29
EP1758338B1 (de) 2008-04-16
US20070083765A1 (en) 2007-04-12
CN100586124C (zh) 2010-01-27
CN1921489A (zh) 2007-02-28

Similar Documents

Publication Publication Date Title
DE10052312B4 (de) Automatische Sperre gegen unberechtigten Zugriff im Internet (Snoop Avoider) für virtuelle private Netze
DE69929268T2 (de) Verfahren und System zur Überwachung und Steuerung der Netzzugriffe
DE10052311B4 (de) Manuelles Verhindern des unerlaubten Mithörens in einem virtuellen privaten Netzwerk über das Internet
DE60110311T2 (de) Verfahren und Vorrichtung zur Mehrfachsendung
DE102006012614B4 (de) Verfahren und Vorrichtung für den Durchlauf von Paketen durch eine Einrichtung zur Netzwerkadressenübersetzung
DE60115615T2 (de) System, einrichtung und verfahren zur schnellen paketfilterung und -verarbeitung
DE60225892T2 (de) Firewall zur Filtrierung von getunnelten Datenpaketen
DE69827201T2 (de) Verfahren und system zur server-netzwerkvermittlung-mehrverbindung
DE69727447T2 (de) Übertragungstrennung und Ebene-3-Netzwerk-Vermittlung
DE60111089T2 (de) Verfahren und Vorrichtung zum Analysieren von einer oder mehrerer Firewalls
DE69827351T2 (de) Mehrfach-virtuelle Wegsucher
DE602005006127T2 (de) Sicheres Kommunikationsverfahren- und gerät zur Verarbeitung von SEND-Datenpaketen
DE60121755T2 (de) Ipsec-verarbeitung
DE202016107377U1 (de) Systeme zur Auslagerung von Netzwerkfunktionen über Paket-Trunking
DE60311800T2 (de) Verfahren und vorrichtung zur verbesserung der netzwerkleitweglenkung
DE10205108A1 (de) System und Verfahren zum Zugreifen auf Softwarekomponenten in einer verteilten Netzwerkumgebung
DE60133175T2 (de) Kommunikationsnetz
DE102016222740A1 (de) Verfahren für ein Kommunikationsnetzwerk und elektronische Kontrolleinheit
DE60113019T2 (de) Automatisiertes internes Bussystem zur Unterstützung des TCP/IP Protokolls
WO2007025905A1 (de) Kommunikationssystem, vermittlungsknoten-rechner und verfahren zur bestimmung eines kontrollknotens
DE60318601T2 (de) Verfahren zur automatischen konfiguration einer ip-fernsprecheinrichtung und/oder daten, system und einrichtung zu ihrer implementierung
EP1494401A2 (de) Router and Verfahren zur Aktivierung eines deaktivierten Computers
DE10305413A1 (de) Verfahren und Anordnung zur transparenten Vermittlung des Datenverkehrs zwischen Datenverarbeitungseinrichtungen sowie ein entsprechendes Computerprogramm-Erzeugnis und ein entsprechendes computerlesbares Speichermedium
DE60316158T2 (de) Filter zur verkehrstrennung
DE602005002998T2 (de) Gerät zum Auswählen von Routing-Informationen für einen Router in einem Kommunikationsnetz

Legal Events

Date Code Title Description
8364 No opposition during term of opposition