-
GEBIET DER ERFINDUNG
-
Die
Erfindung bezieht sich auf ein Verfahren zum Aktualisieren eines
Leitweglenkungseintrags. Insbesondere bezieht sich die Erfindung
auf ein Verfahren zum Aktualisieren eines Leitweglenkungseintrags
für einen
Kommunikationspartnerknoten, der mit einem Kommunikationsursprungsknoten über ein
Netzwerk kommuniziert, welches zumindest einen Leitweglenkungsknoten
enthält.
-
HINTERGRUND DER ERFINDUNG
-
Wie
vorstehend ausgeführt
bezieht sich die Erfindung auf ein Verfahren zum Aktualisieren eines
Routing- bzw. Leitweglenkungseintrags für einen Kommunikationspartnerknoten,
der mit einem Kommunikationsursprungsknoten über ein Netzwerk kommuniziert,
welches zumindest einen Routing- bzw. Leitweglenkungsknoten enthält.
-
In
diesem Zusammenhang ist zu beachten, dass die Erfindung nicht auf
einen speziellen Netzwerktyp beschränkt ist, sondern auf jeden
Netzwerktyp angewandt werden kann, der es ermöglicht, dass ein Kommunikationspartnerknoten
mit einem Kommunikationsursprungsknoten über zumindest einen Leitweglenkungsknoten
kommuniziert. Zum Beispiel ist die Erfindung auf ein Kommunikationsnetzwerk
anwendbar, das auf der Grundlage des Internet-Protokolls IP betrieben
wird, ungeachtet der Version des Internet-Protokolls, d.h. ob es IPv4
oder IPv6 ist. Ebenso ist die Erfindung anwendbar, falls die Kommunikationsknoten
(Ursprungs- und Partnerknoten) stationäre Knoten und/oder mobile Knoten
sind, die frei an einem beliebigen Zugangspunkt mit dem Netzwerk
verbunden werden können.
Für den
Zweck der Erfindung ist der Verbindungstyp, d.h. ob drahtgebunden
oder drahtlos, ebenso nicht von Bedeutung. Im Falle eines drahtlosen
Netzwerkzugangs und unter der Annahme eines IP-basierten Netzwerks
wird zum Beispiel das so genannte Mobile-IP-/MIP-Protokoll verwendet
(MIPv4 oder MIPv6). Gleichwohl können
andere IP-Protokollversionen oder sogar andere Protokolltypen verwendet
werden.
-
Um
die Erfindung zu veranschaulichen und zu erläutern, wird sich die anschließende Beschreibung jedoch – ohne jede
Beschränkung
des Umfangs der Erfindung – auf
einen Fall richten, bei dem zumindest die Kommunikationsursprungsknoten
mobile Knoten sind und das zur Kommunikation verwendete Protokoll MIPv6
ist.
-
Mit
Bezugnahme auf die bei der vorliegenden Erfindung verwendete Terminologie
im Vergleich zu den MIPv6-Spezifikationen
wird es daher für
einen fachmännischen
Leser offensichtlich sein, dass ein Kommunikationsursprungsknoten
einem mobilen Knoten MN entsprechen wird, ein Kommunikationspartnerknoten
einem Korrespondenzknoten CN entsprechen wird, ein Routing- bzw. Leitweglenkungsknoten
einem Heimat-Agent HA (des mobilen Knotens MN) entsprechen wird
und der zu aktualisierende Routing- bzw. Leitweglenkungseintrag
einem Bindungscache bzw. -puffer an dem Korrespondenzknoten CN entsprechen
wird. Gleichwohl ist die Erfindung nicht auf eine Aktualisierung
eines Leitweglenkungseintrags an dem Kommunikationspartnerknoten
eingeschränkt,
sondern ist zu beachten, dass der Leitweglenkungseintrag physikalisch
von dem Kommunikationspartnerknoten getrennt sein kann, der entfernt
auf den Leitweglenkungseintrag zugreift, so dass der Leitweglenkungseintrag
für den
Kommunikationspartnerknoten betroffen ist.
-
Im
Falle von mobilen Knoten, die befähigt sind, an unterschiedlichen
Zugangspunkten auf das Netzwerk zuzugreifen, wird der Kommunikationsursprungsknoten
bzw. der mobile Knoten MN durch eine feste Adresse, die auch als
Heimat-Adresse HoA bekannt ist, und eine variable Adresse, die auch
als Care-of-Adresse CoA bekannt ist, identifiziert. Die feste Adresse ändert sich
nicht, sondern vielmehr identifiziert sie den Knoten („logischer
Standort"), während sich
die variable Adresse abhängig
von dem Zugangspunkt des Netzwerks ändert (z.B. nachdem der mobile
Knoten MN innerhalb des Netzwerks umhergewandert ist) und einem „physikalischen
Standort" entspricht,
an den für
den mobilen Knoten bestimmte Nachrichten zu liefern sind.
-
Der
Artikel „Mobile
IP" von C.E. Perkins,
veröffentlicht
in dem IEEE Communications Magazine, IEEE Service Center, Piscataway,
N.J., US, am 1. Mai 1997, beschreibt die Grundlagen von Mobile-IP
und skizziert Routen- bzw. Leitwegoptimierungsvorgänge ebenso
wie eine Erweiterung zu IP, die es ermöglicht, dass mobile Knoten
auf transparente Weise innerhalb des Internets ohne Dienstunterbrechung
von Ort zu Ort umherwandern. Diese Druckschrift stellt eine Anordnung
vor, bei der nach wie vor Firewalls bzw. Zugangsschutzsysteme und
Paketfilterungsprobleme gewahr bzw. gegenwärtig sind. Um Bindungsaktualisierungen
zu sichern, werden bestimmte Verfahren zum Beschaffen eines Registrierungsschlüssels vorgeschlagen
und müssen
auch Authentisierungserweiterungen in jede Registrierungsanforderung
bzw. Bindungsaktualisierungsanforderung einbezogen werden.
-
Wie
vorhergehend erwähnt
ist die Erfindung auf Mobile-IPv6
bezogen und insbesondere befasst mit einem Verfahren zum sicheren
Aktualisieren eines Leitweglenkungseintrags für einen Kommunikationspartnerknoten,
d.h. eine Übertragung
von Bindungsaktualisierungsnachrichten und den Bindungscache für den Kommunikationspartnerknoten
zu sichern. Die Erfindung gehört
somit zu dem gleichen Gebiet wie der in Mobile-IP definierte Return-Routability- bzw.
Rückwärtsleitweglenkungsfähigkeit-Mechanismus, wobei
erwartet wird, dass ein Fachmann mit diesem vertraut ist, so dass
eine Beschreibung von diesem hier ausgelassen wird, aber der fachmännische
Leser auf Mobile-IP-Definitionen verwiesen wird.
-
Genauer
gesagt hebt diese Erfindung auf die Fragen bzw. Probleme ab, die
beschrieben sind in dem IETF-Draft „Threat Models introduced
by Mobile IPv6 and Requirements for Security in Mobile IPv6" von Allison Mankin,
Basavaraj Patil, Dan Harkins, Erik Nordmark, Pekka Nikander, Phil
Roberts und Thomas Narten, der datiert ist am 5. November 2001 und
veröffentlicht
und/oder abzurufen ist über
www.ietf.org/proceedings/02mar/I-D/draft-ietf-mobileip-mipv6-scrty-reqts-02.txt.
-
Um
die Frage bzw. das Problem zusammenzufassen, sollte der Korrespondenzknoten
CN bei Mobile-IPv6 nur Bindungsaktualisierungsnachrichten (BU's) von zulässigen mobilen
Knoten MN akzeptieren, d.h. dem MN, dem die Care-of-Adresse CoA tatsächlich gehört, die in der Bindungsaktualisierungsnachricht
gesendet wird; andernfalls könnte
ein Eindringling oder ein böswilliger
Knoten den Bindungscache für
den und/oder in dem CN abändern,
der mit dem MN korrespondiert, was zu mehreren Arten von Angriffen
führt,
wie etwa denjenigen, die zum Beispiel bekannt sind als Angriffe
mit den Namen „man
in the middle", „reflection", „bombing" und „denial
of service" (z.B.
wird durch Änderung
des Inhalts von dem Bindungscache in dem CN von der aktuellen Care-of-Adresse
CoA in eine andere Adresse der CN ein Senden der Pakete an die neue
Adresse beginnen und der MN diese nicht mehr empfangen).
-
Die
aktuellen Mobile-IPv6-Spezifikationen ordnen den Rückwärtsleitweglenkungsfähigkeit-
(RR-) Test an, um die vorstehend erwähnten bezeichneten Angriffe
zu verhindern, aber die Sicherheit von diesem Protokoll beruht stark
auf der Vertraulichkeit von dem Heimat-Cookie bzw. der -Profildatei,
das/die von dem CN über dessen
Heimat-Agent HA an den MN gesendet wird. Um sicher zu stellen, dass
Eindringlinge dessen Wert (der ihnen ermöglichen wird, gefälschte Bindungsaktualisierungsnachrichten
zu senden und den Bindungscache für den bzw. an dem CN zu aktualisieren)
nicht erfahren können,
empfehlen die MIPv6-Spezifikationen dringend, dass zwischen dem
MN und dessen HA das Einkapselungssicherheitsprotokoll (ESP) angewandt
werden sollte. Ein verschlüsselter
Tunnel, der zwischen diesen beiden Knoten angewandt wird, wird eine
sichere Übertragung
von dem Heimat-Cookie ermöglichen.
-
Diese
Annahme bzw. Voraussetzung ist jedoch nur in einigen Umgebungen
gültig.
Wenn der MN an einem durch Firewalls geschützten Netzwerk angeschlossen
ist, müssen
Firewalls dennoch in der Lage sein, die Pakete basierend auf der
Quell-IP-Adresse, der Ziel-IP-Adresse, dem Nächste-Kopffeld, den Portnummern und
schließlich
bzw. eventuell anderen Feldern/Parametern zu filtern (um z.B. zu
verhindern, dass Eindringlinge Finger, NFS verwenden oder DNS- (DNS: "Domain Name Server") Zonentransfer,
TCP-SYN-Flood, usw. durchführen). ESP
kann nicht angewandt werden: In solchen Fällen werden die Firewalls vielmehr
alle diese Pakete fallen lassen müssen, da in Folge der Anwendung
von ESP die Firewall nicht im Stande ist, z.B. die Werte in dem
TCP-Kopffeld (TCP: „Transmission
Control Protocol")
zu verifizieren. Daher wird der MN nicht in der Lage sein, irgendwelche
Bindungsaktualisierungs-/BU-Nachrichten
sicher zu senden.
-
Um
die Bindungsaktualisierungsnachrichten zu schützen, wurden bisher zwei Lösungen vorgeschlagen:
- 1) Der Rückwärtsleitweglenkungsfähigkeit-
(RR-) Test, der in den Mobile-IPv6-Spezifikationen definiert und obligatorisch
ist; aber wie vorstehend beschrieben ist dieses Protokoll nicht
in Umgebungen mit Firewalls anwendbar (d.h. in den meisten Netzwerken
nicht anwendbar).
- 2) Der „CGA"-Vorschlag, auch „sucv" genannt. Diese Lösung beruht
jedoch auf öffentlichen
Schlüsseln,
und Operationen mit öffentlichen
Schlüsseln
können
ein Problem für
mobile Knoten sein: Sie können
nicht die notwendigen Rechenfähigkeiten
aufweisen, um die erforderlichen digitalen Signaturen und andere
erforderliche Operationen durchzuführen. Das ist der Grund, warum
RR in den MIPv6-Spezifikationen übernommen
wurde.
-
Wie
vorstehend erläutert
und zusammenfassend sollte der Korrespondenzknoten (CN) bei Mobile-IPv6
daher nur Bindungsaktualisierungs-/BU-Nachrichten von einem zulässigen mobilen
Knoten (MN) akzeptieren. Die aktuellen Mobile-IPv6-Spezifikationen
ordnen den Rückwärtsleitweglenkungsfähigkeit-
(RR-) Test an, um bezeichnete Angriffe zu verhindern, aber die Sicherheit
von diesem Protokoll beruht stark auf der Vertraulichkeit von dem
Heimat-Cookie, das von dem CN über
dessen Heimat-Agent
HA an den MN gesendet wird. Um sicher zu stellen, dass Eindringlinge
dessen Wert (der ihnen ermöglichen
wird, gefälschte
Bindungsaktualisierungsnachrichten zu senden und den Bindungscache
an dem CN zu aktualisieren) nicht erfahren können, sollte der IPSec-Einkapselungssicherheitsprotokoll-(ESP)
Modus zwischen dem MN und seinem HA angewandt werden. Ein verschlüsselter
Tunnel, der zwischen diesen beiden Knoten angewandt wird, ermöglicht eine
sichere Übertragung
von dem Heimat-Cookie. Falls der MN an einem durch Firewalls geschützten Netzwerk
angeschlossen ist, müssen
Firewalls jedoch in der Lage sein, die Pakete basierend auf der Quell-IP-Adresse
der Ziel-IP-Adresse, dem Nächste-Kopffeld, den Portnummern
und schließlich
bzw. eventuell anderen Feldern/Parametern zu filtern. ESP kann nicht
angewandt werden und die Firewalls werden diese Pakete fallen lassen
müssen,
da die Firewall in Folge der Anwendung von ESP nicht im Stande ist,
z.B. die Werte in dem TCP-Kopffeld zu verifizieren. Daher wird der
MN nicht in der Lage sein, irgendwelche BU-Nachrichten sicher zu
senden.
-
KURZFASSUNG DER ERFINDUNG
-
Folglich
ist es eine Aufgabe der Erfindung, ein verbessertes Verfahren zum
Aktualisieren eines Leitweglenkungseintrags bereitzustellen, das
frei von vorstehend beschriebenen Problemen ist.
-
Gemäß der Erfindung
wird die vorstehende Aufgabe zum Beispiel durch ein Verfahren zum
Aktualisieren eines Leitweglenkungseintrags an einem Kommunikationspartnerknoten
erreicht, der mit einem Kommunikationsursprungsknoten kommuniziert,
wie es gemäß Anspruch
1 definiert ist.
-
Günstige weitere
Ausprägungen
sind in den abhängigen
Ansprüchen
definiert.
-
Auf
Grund der vorliegenden Erfindung können grundsätzlich die folgenden Vorteile
erzielt werden:
- 1. Diese Erfindung definiert
einen grundlegenden neuen Mechanismus, um eine Leitweglenkungseintrag-Aktualisierungsnachricht
wie etwa Bindungsaktualisierungsnachrichten sicher von dem MN an
die CNs zu senden.
- 2. Insbesondere ermöglicht
sie dem CN, durch eine Interaktion mit dem Heimat-Agent des MN zu
verifizieren, dass die von dem MN empfangene Bindungsaktualisierungsnachricht
tatsächlich
von dem legitimen MN kommt, während
sie nach wie vor einen Netzwerkschutz durch die Verwendung von Firewalls
ermöglicht.
- 3. Die durch diese Erfindung beschriebene Lösung stellt den gleichen Grad
an Sicherheit bereit (sie verhindert zukünftige Angriffe – zukünftige Angriffe
sind eine neue Art von Angriffen, die unlängst in der Mobile-IP-Arbeitsgruppe festgelegt
sind – wie
RR verhindert, während
jedoch RR diese durch eine periodische Neuausführung des RR-Protokolls verhindert).
- 4. Sie reduziert maßgeblich
die Anzahl von Nachrichten: RR erfordert 6 Nachrichten zwischen
dem MN und dem HA und dem CN. Die Lösung gemäß der Erfindung erfordert höchstens
nur 4 Nachrichten. Und zwar erfordert sie, wenn man eine Verifikationsbestätigung von
HA an MN als verzichtbar betrachtet, in der Tat nur 3 Nachrichten
und somit nur die Hälfte
der Anzahl von Nachrichten im Vergleich zu dem RR-Test.
- 5. Tatsächlich
benötigt
RR zwei vollständige
Umläufe
zwischen dem MN und dem CN, wogegen diese Lösung nur einen erfordert. Als
Ergebnis hiervon werden die Verzögerung
und der Overhead reduziert, die durch den Vorgang eingeführt werden.
- 6. Was den Overhead betrifft, wird auch die Anzahl von über die
Luftschnittstelle zu sendenden Bytes auf Grund der Erfindung maßgeblich
reduziert, wie es aus der folgenden Tabelle leicht verständlich sein
wird, die den RR-Test mit der Erfindung vergleicht:
| Rückwärtsleitweglenkungsfähigkeit | Erfindung |
| Heimattest-Anfangsnachricht
(HoTI) | Verifikationssatz |
| 92
Oktette (HoTI 52 + Einkapselung 40) | 84
Oktette (64 + AH 20) |
| Care-of-Test-Anfangsnachricht
(CoTI) | Verifikationsbestätigung |
| 52
Oktette | 44
Oktette |
| Heimattest-Nachricht
(HoT) | Verifikationsanforderung |
| 132
Oktette (HoT 72 + Einkapselung 40 + ESP 20) | 48
Oktette |
| Care-of-Test-Nachricht
(CoT) | Verifikationsantwort |
| 72
Oktette | 60
Oktette |
| Bindungsaktualisierung
(BU) | Bindungsaktualisierung |
| 72
Oktette | 76
Oktette |
| Bindungsbestätigung | Bindungsbestätigung |
| 64
Oktette | 64
Oktette |
| RR
gesamt: 484 Oktette | Gesamt:
376 Oktette |
-
Augenscheinlich
werden für
jede gesendete BU über
die Luftschnittstelle 108 Oktette eingespart, wenn das Verfahren
gemäß der Erfindung
angewandt wird; und während
mobile Knoten MN sich schnell bewegen können, werden sie viele BUs
zu senden haben. MNs können
Kommunikationen mit mehreren CNs haben, weshalb sogar noch mehr
BUs gesendet werden müssen.
- 7. Rechenanforderung: Der RR-Test verwendet
mehrere Cookies und benötigt
mehrere Anwendungen der Hash-Funktion,
wogegen diese Lösung
nur eine Hash-Operation pro Bindungsaktualisierung erfordert.
- 8. Verfahrenskomplexität:
RR erfordert, dass der CN unterschiedliche Cookies und Indizes von
einem Nonce verwaltet. Diese Komplexität kann den CN abschrecken bzw.
entmutigen, den RR-Test zu implementieren, womit jede Leitwegoptimierung
verhindert wird. Die in dieser Druckschrift beschriebene Lösung ist
viel einfacher: Sie erfordert nicht, dass der CN irgendeinen Index
oder ein internes Geheimnis verwaltet, wodurch eine Leitwegoptimierung
einfacher gemacht wird. (Es ist zu beachten, dass Indizes von einem
Nonce ein Bestandteil des RR-Vorgangs sind, und ausführlichere
Informationen darüber
können
aus den Definitionen von diesem erlangt werden.)
- 9. Schließlich
ist es wie vorstehend erläutert
dringend empfohlen, die HoT-Nachricht einzukapseln und zu verschlüsseln, um
zu verhindern, dass irgendein Eindringling den Heimat-Cookie-Wert
erfährt,
und müssen Firewalls
in der Lage sein, die Pakete basierend auf der Quell-IP-Adresse,
der Ziel-IP-Adresse, dem Nächste-Kopffeld, den Portnummern
zu filtern, damit eine ausreichende Sicherheit für RR bereitgestellt wird.
-
Im
Gegensatz dazu erfordert die Lösung
gemäß der Erfindung
keine Verschlüsselung
zwischen dem MN und dessen HA, sondern nur eine Authentisierung.
Daher sind Firewalls, die das Netzwerk an einer Stelle schützen, wo
der MN verbunden ist (auf das Netzwerk in einer drahtlosen oder
drahtgebundenen Weise zugreift), fähig zum Filtern von Paketen,
die die Bindungsaktualisierung und Sicherheits-„Material” transportieren, das in dieser
Anmeldung spezifiziert ist, ohne das Erfordernis zum Fallenlassen
der Pakete.
- 10. Somit definiert diese Erfindung
einen neuen Mechanismus, um die Bindungsaktualisierungsnachrichten sicher
von dem MN an die CNs zu senden. Insbesondere ermöglicht sie
dem CN, durch eine Interaktion mit dem Heimat-Agent des MN zu verifizieren,
dass die von dem MN empfangene Bindungsaktualisierungsnachricht
tatsächlich
von dem legitimen MN kommt, während
sie einen Netzwerkschutz durch die Verwendung von Firewalls ermöglicht.
Die Erfindung schlägt
3 (oder höchstens
4) neue Nachrichten vor, die in MIPv6 oder einen entsprechenden
Protokollstandard einzuführen
sind.
-
KURZE BESCHREIBUNG DER ZEICHNUNG
-
Im
Folgenden wird die Erfindung unter Bezugnahme auf die begleitende
Zeichnung ausführlicher
beschrieben, bei der gilt:
-
1 zeigt
ein Signalisierungsszenario gemäß dem vorgeschlagenen
Verfahren gemäß der Erfindung.
-
AUSFÜHRLICHE BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE
-
Wie
aus der anschließenden
Beschreibung offensichtlich wird, definiert diese Erfindung einen
neuen Vorgang zum sicheren Senden der Bindungsaktualisierungsnachrichten
(Leitweglenkungseintrag-Aktualisierungsnachrichten) von dem Kommunikationsursprungsknoten
oder mobilen Knoten MN an den Kommunikationspartnerknoten oder Korrespondenzknoten
CN. In diesem Zusammenhang spezifiziert sie eine Erweiterung zu
momentanen Bindungsaktualisierungsnachrichten, d.h. eine Identifikation
(Identifikationsnummer) einer entsprechenden Bindungsaktualisierungsnachricht,
die als RUIN bezeichnet wird.
-
Zusätzlich wird
eine Ausgabe einer kryptografischen Funktion wie etwa der Hash-Funktion,
die auf eine Bindungsaktualisierungsnachricht angewandt wird, als
ein Feld von neu eingeführten
Nachrichten eingeführt,
die als „Verifikationssatz"- und „Verifikationsantwort"-Nachrichten benannt sind. Es ist zu
beachten, dass für
eine reduzierte Komplexität
die kryptografische Funktion (z.B. Hash-Funktion) auf die „herkömmliche" Bindungsaktualisierungsnachricht
angewandt wird, d.h. diejenigen Teile der gemäß der Erfindung gesendeten BU- Nachricht, die „nur" die Heimat-Adresse
(HoA) und die Care-of-Adresse von dem MN enthalten, und nicht auf
die zusätzlich
eingebundene Identifikation RUIN. Dennoch kann gemäß einer
Modifikation der Erfindung auch die vollständige BU-Nachricht einschließlich der
RUIN der kryptografischen Funktion unterzogen werden.
-
Die
Erfindung schlägt
3, höchstens
4, neue Nachrichten vor, die hierin nachstehend als Verifikationssatz,
Verifikationsbestätigung
(welche optional ist), Verifikationsanforderung und Verifikationsantwort
bezeichnet werden. Die Nachrichten sind gemäß 1 veranschaulicht
und durch Bezugszeichen 2 bis 5 bezeichnet. Es ist zu beachten,
dass 1 nur diejenigen Instanzen, die bei Durchführung der
Erfindung beteiligt sind, und die Signalisierung zwischen diesen
zeigt. Eine Signalisierung ist in horizontaler Richtung zwischen
den Instanzen bildlich dargestellt, und in vertikaler Richtung bzw.
mit ansteigenden Nummerierung der Schrittnummern ist die zeitliche
Abfolge der Schritte dargestellt.
-
Der
folgende Signalisierungsablauf wie gemäß 1 veranschaulicht
beschreibt somit den Vorgang in näheren Einzelheiten, d.h. das
Verfahren zum Aktualisierung von einem Leitweglenkungseintrag wie
etwa einem Bindungscache BC an einem Kommunikationspartnerknoten
CN, der mit einem Kommunikationsursprungsknoten MN über ein
Netzwerk kommuniziert, welches zumindest einen Leitweglenkungsknoten
wie etwa einen Heimat-Agent HA enthält, wird anschließend ausführlich beschrieben: Bei
Bezugnahme auf 1 sollte berücksichtigt werden, dass RUIN
die Bindungsaktualisierung-Identifikationsnummer
ist, Hash (...) die Ausgabe einer Hash-Funktion bezeichnet, die
auf das Argument (...) der Hash-Funktion angewandt wird, hier die
Bindungsaktualisierungsnachricht einschließlich CoA und HoA von dem MN,
und eine Zufallsherausforderung (oder RAND) verwendet wird, um Replay-
bzw. Wiedergabeangriffe zu verhindern, und um Scheinknoten (böswillige
Knoten bzw. „Bösewichte") zu vermeiden, die
den MN imitieren, um als der HA zu agieren und die Erwiderung im
Namen eines legitimen HA an den CN zu senden.
-
Schritt 1.
-
Wenn
der MN eine Bindungsaktualisierung an einen Korrespondenzknoten
senden muss (z.B. im Falle einer Änderung einer Care-of-Adresse
(z.B. beim Umherwandern), abgelaufener Bindungsaktualisierung-Lebensdauer
usw.), erzeugt der MN die Bindungsaktualisierungsnachricht wie in
den MIPv6-Spezifikationen spezifiziert, und wendet er eine kryptografische
Funktion wie etwa die Hash-Funktion H auf diese an.
-
Die
resultierende Ausgabe wird mit einer Bindungsaktualisierung-Identifikationsnummer
(RUIN) in Zusammenhang gebracht. Der MN sendet die Bindungsaktualisierung
einschließlich
der RUIN an den CN. Mit anderen Worten umfasst die BU, die gemäß der Erfindung
von dem MN an den CN gesendet wird, die Datenelemente einer herkömmlichen
BU-Nachricht, wie etwa HoA und CoA, und zusätzlich die RUIN als eine Identifikation
der BU-Nachricht. Das Ergebnis der Hash-Funktion, die auf die „herkömmliche" BU-Nachricht angewandt
wird, wird nicht an den CN übertragen.
Wahlweise könnte
die Hash-Funktion auf die gesamte BU-Nachricht angewandt werden, die HoA,
CoA und RUIN enthält.
-
Demnach
findet in Schritt 1. ein Anfordern einer Leitweglenkungseintrag-Aktualisierung
von dem Kommunikationsursprungsknoten MN an dem Kommunikationspartnerknoten
CN statt, wobei die Aktualisierungsanforderung zumindest eine Identifikation
RUIN der Anforderung enthält.
-
Schritt 2.
-
Der
MN sendet eine BU-Verifikationssatz-Nachricht an seinen Heimat-Agent
HA. Diese Nachricht enthält
(als Anforderungsverifikationsinformation) die mittels der Hash-Funktion
verarbeitete bzw. gehashte (herkömmliche)
BU und die entsprechende RUIN. (Es ist zu beachten, dass wie vorstehend
erwähnt
die Hash-Funktion auf die gesamte Nachricht, die auch die RUIN umfasst,
angewandt werden könnte).
Die Verifikationssatz-Nachricht wird unter Verwendung des MN-HA-Sicherheitsschlüssels authentisiert.
-
Demnach
findet in Schritt 2. ein übergeben
von Anforderungsverifikationsinformationen, die mit der Identifikation
RUIN der Aktualisierungsanforderung in Zusammenhang stehen, von
dem Kommunikationsursprungsknoten MN an den zumindest einen Leitweglenkungsknoten
statt.
-
Schritt 3.
-
Der
Heimat-Agent bestätigt
(optional) den Empfang dieser Nachricht durch eine Verifikationsbestätigung-Nachricht.
-
Schritt 4.
-
Auf
Empfang der BU extrahiert der CN die Identifikationsnummer RUIN
und sendet diese in einer Verifikationsanforderung-Nachricht an
den Heimat-Agent des MN. Die Nachricht umfasst eine durch den CN
erzeugte Zufallsherausforderung bzw. Random-Challenge. Die Nachricht
wird an die MN-Heimatadresse gesendet, und der Heimat-Agent erfasst
die Nachricht und verarbeitet sie.
-
Demnach
findet in Schritt 4. ein Anfordern einer Verifikation der Leitweglenkungseintrag-Aktualisierung
durch den Kommunikationspartnerknoten CN an dem Leitweglenkungsknoten
HA unter Verwendung der Identifikation RUIN der Aktualisierungsanforderung
statt.
-
Schritt 5.
-
Der
Heimat-Agent antwortet dem CN mit der Ausgabe der gehashten BU,
die er vorher von dem MN empfangen hat, und indem er die von dem
CN empfangene Zufallsherausforderung in eine Verifikationsantwortnachricht
einbindet.
-
Demnach
findet in Schritt 5. ein Abrufen der Anforderungsverifikationsinformationen
von dem Leitweglenkungsknoten HA basierend auf der Identifikation
RUIN der Aktualisierungsanforderung statt.
-
Auf
Empfang der Antwort bzw. Erwiderung wendet der CN (in einem Verarbeitungsschritt,
der intern an dem CN durchgeführt
wird und in dem Signalisierungsdiagramm gemäß 1 nicht
gezeigt ist) die kryptografische Funktion, d.h. die Hash-Funktion
H, auf die Bindungsaktualisierungsnachricht an, die ursprünglich von dem
MN empfangen wurde (siehe Schritt 1.), und vergleicht er das Ergebnis
mit dem gehashten Wert, der von dem HA (in Schritt 5.) empfangen
wurde. Sind die erhaltenen Werte gleich, erzeugt der CN den Bindungscacheeintrag,
der die MN-HoA mit der in der BU angegebenen MN-CoA in Zusammenhang
bringt.
-
Demnach
findet ein Erzeugen der Anforderungsverifikationsinformationen an
dem Kommunikationspartnerknoten CN basierend auf der empfangenen
Leitweglenkungseintrag-Aktualisierung, ein Vergleichen der erzeugten
Anforderungsverifikationsinformationen mit den abgerufenen Anforderungsverifikationsinformationen,
und ein Aktualisieren des Leitweglenkungseintrags statt, falls der
Vergleich ergibt, dass die erzeugten Anforderungsverifikationsinformationen
und die abgerufenen Anforderungsverifikationsinformationen identisch
sind.
-
Aus
der vorangehenden Beschreibung der Erfindung wird deutlich, dass
sie somit auf einfache Weise als neue Mobile-IP-Nachrichten und/oder
als Erweiterungen zu bestehenden Mobile-IP-Nachrichten implementiert
werden kann.
-
Falls
die Erfindung auf ein im Vergleich zu Mobile-IP anderes Protokoll
angewandt wird, ist natürlich eine ähnliche
Implementierung möglich.
-
Dementsprechend
betrifft die Erfindung, wie es hierin vorstehend beschrieben wurde,
ein Verfahren zum Aktualisieren eines Leitweglenkungseintrags BC
für einen Kommunikationspartnerknoten
CN, der mit einem Kommunikationsursprungsknoten MN über ein
Netzwerk kommuniziert, welches zumindest einen Leitweglenkungsknoten
HA enthält,
wobei das Verfahren die Schritte aufweist: 1. Anfordern einer Leitweglenkungseintrag-Aktualisierung
von dem Kommunikationsursprungsknoten MN an dem Kommunikationspartnerknoten
CN, wobei die Aktualisierungsanforderung zumindest eine Identifikation
RUIN der Anforderung enthält, 2. Übergeben
von Anforderungsverifikationsinformationen, die mit der Identifikation
RUIN der Aktualisierungsanforderung in Zusammenhang stehen, von
dem Kommunikationsursprungsknoten MN an den zumindest einen Leitweglenkungsknoten,
4. Anfordern einer Verifikation der Leitweglenkungseintrag-Aktualisierung
durch den Kommunikationspartnerknoten CN an dem Leitweglenkungsknoten
HA unter Verwendung der Identifikation RUIN der Aktualisierungsanforderung,
5. Abrufen der Anforderungsverifikationsinformationen von dem Leitweglenkungsknoten
basierend auf der Identifikation RUIN der Aktualisierungsanforderung.
-
Während die
Erfindung unter Bezugnahme auf ein bevorzugtes Ausführungsbeispiel
beschrieben wurde, ist die Beschreibung für die Erfindung veranschaulichend
und nicht als die Erfindung beschränkend auszulegen. Einem Fachmann
können
verschiedene Modifikationen und Anwendungen einfallen, ohne von
der Erfindung abzuweichen, wie sie durch die anhängenden Ansprüche definiert
ist.