PatentDe  


Dokumentenidentifikation DE102006014594A1 04.10.2007
Titel Verfahren zum Wiederherstellen einer mit IPsec kryptographisch gesicherten Verbindung
Anmelder Siemens AG, 80333 München, DE
Erfinder Cai, Li, 81379 München, DE;
Kroß, Joachim, 81377 München, DE;
Schopp, Michael, Dr., 81827 München, DE
DE-Anmeldedatum 29.03.2006
DE-Aktenzeichen 102006014594
Offenlegungstag 04.10.2007
Veröffentlichungstag im Patentblatt 04.10.2007
IPC-Hauptklasse H04L 9/00(2006.01)A, F, I, 20060329, B, H, DE
IPC-Nebenklasse H04L 12/54(2006.01)A, L, I, 20060329, B, H, DE   H04L 12/24(2006.01)A, L, I, 20060329, B, H, DE   H04L 29/08(2006.01)A, L, I, 20060329, B, H, DE   
Zusammenfassung Ein Verfahren zum Wiederherstellen einer kryptographisch sicheren IPsec-Verbindung zwischen einem zweiten Proxy-Server (P-CSCF2) und einer gegenüber einem Server (S-CSCF) registrierten Anwendereinheit (UE), nachdem ein erster Proxy-Server (P-CSCF1) in einem von der Anwendereinheit (UE) besuchten Netzwerk (VN) ausgefallen ist, welcher vor dem Ausfall zur Vermittlung von zwischen dem Server (S-CSCF) und der Anwendereinheit (UE) versandten Nachrichten eingerichtet war, umfasst die Schritte: Bereitstellen des zweiten Proxy-Servers (P-CSCF2) in dem besuchten Netzwerk (VN); Übernehmen einer IP-Adresse des ersten Proxy-Servers (P-CSCF1) durch den zweiten Proxy-Server (P-CSCF2), so dass dieser an die Stelle des ersten Proxy-Servers (P-CSCF1) bezüglich der Vermittlung von Nachrichten tritt; Replizieren von Informationen, betreffend die kryptographische Sicherheit der Verbindung, in dem zweiten Proxy-Server (P-CSCF2), welche zuletzt vor dem Ausfall in der Anwendungsschicht im ersten Proxy-Server (P-CSCF1) gespeichert waren; und Verwenden der replizierten Informationen zur Erstellung wenigstens einer Sicherheitsvereinbarung (SA) zwischen dem zweiten Proxy-Server (P-CSCF2) und der Anwendereinheit (UE) in dem Proxy-Server (P-CSCF2), anhand welcher nachfolgend eine Verschlüsselung der vermittelten Nachrichten durchgeführt wird.

Beschreibung[de]

Die Erfindung betrifft ein Verfahren zum Wiederherstellen einer mit IPsec kryptographisch gesicherte Verbindung zwischen zwei IPsec peers. Das kann in Mobilfunkbereich zwischen einem Proxy-CSCF (Proxy-Call Session Control Function) Server und einer gegenüber einem Serving-CSCF (S-CSCF) registrierten Anwendereinheit (UE), nachdem ein erster Proxy-Server (P-CSCF 1) in einem von der Anwendereinheit (UE) besuchten Netzwerk (VN) ausgefallen ist, welcher vor dem Ausfall zur Vermittlung von zwischen dem Proxy Server Cluster Node(P-CSCF 1) und der Anwendereinheit (UE) versandten Nachrichten eingerichtet war. Die Erfindung betrifft die allgemeine Thematik zum Wiederherstellen einer mit IPsec krytographisch gesicherte Verbindung, insbesondere die Sicherheit bei der Übertragung von Nachrichten im multimedialen Mobilfunkbereich.

Mobile Übertragungssysteme werden derzeit durch die 3GPP (third generation partnership project) standardisiert. Aus dem bisherigen System zweiter Generation, dem GSM (global System for mobile communications), hat sich dabei unter Berücksichtigung vor allem von Sicherheitsaspekten ein System dritter Generation entwickelt, das in Europa unter dem Namen UMTS (universal mobile telecommunication system) bekannt ist.

Die Sicherheitsaspekte betreffen sowohl die angreifbare Übertragung im leicht zugänglichen Radiofrequenzbereich zwischen Anwendereinheit (UE, user equipment) und dem Zugangspunkt (AN, access network), als auch die Infrastruktur für die Signalübertragung im Core-Netzwerk (Zugangspunkt bis zum Server des Heimatnetzwerks, dem die Anwendereinheit zugeordnet ist). Die Sicherheitsarchitektur mobiler Systeme der dritten Generation ist von der 3GPP unter anderem in „3GPP TS 33.102" spezifiziert.

Gemäß dem UMTS-Standard besteht ferner die Möglichkeit, multimediale Verbindungen (sessions) zwischen den beteiligten Kommunikationspartnern aufzubauen. Durch das so genannte IMS (IP multimedia core network subsystem) werden dabei von einer UMTS packet-domain Dienste für die IP-Konnektivität angeboten (IP: internet protocol). Es werden somit für die mobile Kommunikation bereits aus rechnerbasierten Netzwerkarchitekturen bekannte Lösungen übernommen. Als Protokoll für den Aufbau solcher Sessions ist das SIP (session initiation protocol, IETF RFC 3261) vorgesehen, das von der Internet Engineering Task Force (IETF) entwickelt wurde.

Das für IMS verwendete Sicherheitsschema heißt IMS-AKA (IMS authentication and key agreement). Die Sicherheitsarchitektur ist von der 3GPP in „3GPP TS 33.203" spezifiziert. Grundannahme bei IMS-AKA ist, dass Sicherheitsmechanismen nicht in der unterliegenden IP-Transportschicht sondern in der Anwendungsschicht realisiert werden. Der Grund liegt darin, dass z.B. im Hinblick auf den WLAN (wireless local area network) Standard IEEE 802.11 eine gewisse Unabhängigkeit dieser Mechanismen von Netzwerkarchitekturen jeweiliger Zugangspunkte (AN) und damit von der Realisierung der Transportschicht erreicht werden soll.

Die IMS-Architektur ist schematisch und beispielhaft in 1 gezeigt. Eine Anwendereinheit (UE) umfasst ein IP-Services Indentitätsmodul (ISIM), das eine Zusammenstellung von Sicherheitsfunktionen und -daten repräsentiert. Das Identitätsmodul unterstützt unter anderem die Authentikation gegenüber einem Subskriptionsserver (HSS, home subscriber service) des Heimatnetzwerks (HN) der Anwendereinheit. Das Identitätsmodul (ISIM) beinhaltet unter anderem eine (eindeutige und private) IMS-Identität (IMPI), den Domain-Namen des Heimatnetzwerks (HN), Unterstützung für die Überprüfung von Sequenznummern und Schlüssel für die Authentikation, den es mit dem Subskriptionsserver teilt (symmetrische Verschlüsselung aufgrund der im allgemeinen niedrigen Bandbreite bei der Übertragung freien Raum).

Ferner umfasst die Anwendereinheit (UE) einen User Agent (UA), der Funktionen gemäß dem SIP-Protokoll ausführt und mit einem Proxy-Server (P-CSCF, proxy-call session service function) kommuniziert. Der Proxy-Server unterstützt das SIP-Protokoll und wird der mobilen Anwendungseinheit zugewiesen, sobald sich dieses mit dem Zugangspunkt (AN, access network) verbindet. Auf Transportschichtebene findet die Kommunikation über die PS-Domain (packet switch domain) statt.

Der Proxy-Server (P-CSCF) liegt in einem von der Anwendereinheit besuchten Netzwerk (VN, visited network), bei dem es sich unter Umständen auch gerade um das Heimatnetzwerk (HN, home network) handeln kann. Der Proxy-Server kommuniziert leitungsgebunden zunächst mit einem Abfrage-Server (I-CSCF) und dann mit dem eigentlichen SIP-Server (S-CSCF, serving CSCF) des Heimatnetzwerks (HN), letzteres auch als Server-Netzwerk (SN, serving network) bezeichnet.

Der Server (S-CSCF) des Heimatnetzwerks ist mit dem Subskriptionsserver (HSS) verbunden, von dem er auf Anfrage Authentikationsdaten gemäß SIP-Protokoll erhält. Der Subskriptionsserver (HSS) hält ferner Subskriptionsinformationen (z.B. die Authorisierung des Anwenders, überhaupt die Dienste nutzen zu dürfen).

1 zeigt anhand der linierten Pfeile diejenigen Verbindungen, die den Sicherheitsanforderungen gegenüber Angriffen Dritter genügen müssen. Es sind jeweils sogenannte Sicherheitsvereinbarungen (SA, security associations) erforderlich, die zwischen den Kommunikationspartnern auszuhandeln sind. In diesen ist unter anderem geregelt, welcher Schlüssel, welcher Algorithmus und welche IP-Adressen und Ports für die geschützte Kommunikation eingesetzt werden.

Der Zugang zu den Diensten des IMS erfolgt über die Registrierung einer öffentlichen Identität (IMPU, IMS public identity), einem ausgewählten Anwenderprofil unter vielen, welche der genau einen privaten Identität (IMPI) zugeordnet sein können, und Teil des Identitätsmoduls (ISIM) ist. Ferner muss die private Identität (IMPI) authentifiziert werden. Es wird dazu gemäß dem SIP-Protokoll und (darauf aufbauend) dem IMS-AKA Protokoll verfahren, wobei die Registrierung/Authentikation in einem Challenge-Response-Verfahren geregelt wird. Die verwendeten symmetrischen Schlüssel werden hier aus entsprechend jeweils privaten Geheimnissen erhalten (z.B. nach Art einer Diffie-Hellmann Schlüsselerzeugung).

Die Sicherheitsvereinbarungen (SA) werden zwischen der Anwendereinheit (UE) und dem Proxy-Server (P-CSCF) im Rahmen einer solchen IMS-AKA-Authentikation ausgehandelt.

In 1 wird die Trennung zwischen der Transportschicht (unten) und der Anwendungsschicht (oben) deutlich.

In der Praxis, um die Verfuegbarkeit zu erhöhen, wird der Proxy-Server in Cluster-Konfiguration ausgestattet. Ein Proxy-Server kann z.B. aus zwei Cluster Nodes bestehen und in einem „Hot"-Standby Modus betrieben werden. Ein erster Cluster Node befindet in aktivem Betriebszustand, wobei sich der andere Cluster Node in Standby-Zustand befindet. Falls der aktive Cluster Node ausfällt, wird der Standby Cluster Node die Aufgabe übernehmen. Im folgenden wird unter dem Begriff Proxy-Server jeweils auch nur ein Cluster Node verstanden, wenn Clusterkonfiguration vorliegt.

Es kann nun das Problem auftreten, dass ein Proxy-Server oder ggf. dessen Cluster Node insbesondere während einer laufenden Session zwischen zwei Kommunikationspartnern ausfällt. Im allgemeinen steht für solche Ereignisse ein Standby-Proxy-Server bzw. ein entsprechender Cluster Node zur Verfügung. Jedoch verfügt dieser für die laufenden Sessions nicht über die Sicherheitsvereinbarungen. Er wird daher nicht ohne weiteres die laufenden Verbindungen bzw. Sessions übernehmen können. Die Folge ist, dass die Verbindungen unterbrochen werden müssen. Die Verbindungen können erst wieder neu aufgebaut werden, wenn die Anwendereinheit (UE) sich im Netz neu registriert und die Sicherheitsvereinbarung neu ausgehandelt worden sind. Eine Neuregistrierung mit neu ausgehandelten Sicherheitsvereinbarungen (SA) würde nämlich zur Auswahl eines neuen Server-Ports auf Seiten der Anwendereinheit führen, jedoch adressiert die noch laufende Verbindung von dem mobilen Anwender (UE) aus gesehen immer noch den alten Server-Port.

Besonders problematisch ist dabei, dass die Anwendereinheit (UE), also etwa ein Benutzer eines Mobiltelefons etc., den Ausfall und damit den Abbruch der Verbindung nicht sofort erkennt. Gemäß 3GPP-Spezifiaktionen ist nämlich nicht vorgesehen, dass der Proxy-Server (P-CSCF) den mobilen Anwender über den Verlust der Sicherheitsvereinbarungen (SA) informiert. Die Zeitdauer für eine solche Unterbrechung, in denen der Proxy-Server keine SIP-Meldungen an die Anwendereinheit senden kann, beträgt dabei bis zu 2 Stunden.

Es ist daher die Aufgabe, ein Verfahren zum Wiederherstellen einer Verbindung zwischen einem Server und einer Anwendereinheit bei einem Ausfalls eines vermittelnden Proxy-Server anzugeben, dass die vorgenannten Nachteile umgeht und eine Fortsetzung einer Verbindung ohne Verluste an Daten, Sicherheit und Zeit ermöglicht.

Die Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1. Vorteilhafte Ausgestaltungen sind den abhängigen Ansprüchen zu entnehmen.

Es werden zur Lösung des Problems Vorgehensweisen vorgeschlagen, denen ein Grundgedanke gemeinsam ist: ein aktuell ausgefallener erster Proxy-Server wird durch einen zweiten Standby-Proxy-Server ersetzt, der dessen Position im IMS übernimmt, und auf dem die sicherheitsrelevanten Daten der Anwendungsschicht vom ersten Proxy-Server aus repliziert werden.

Der erste (und auch der zweite) Proxy-Server besitzen eine Rechnerarchitektur, bei welcher Daten der Anwendungsschicht z.B. in einem Hauptspeicher geladen sind. Üblicherweise werden im Fall von auftretenden Problemen Kopien von Daten der zuletzt vorliegenden Situation im Hauptspeicher geschaffen, anhand welcher zum Beispiel Diagnosen durchgeführt werden können. Die Kopiedaten können dabei auf Zweitrechnern zur Nachprüfung wiederhergestellt werden.

Diese Möglichkeit wird vorliegend ausgenutzt. Wie beschrieben befindet sich nämlich ein Großteil der Sicherheitsinformationen (gemäß IPsec) in der Anwendungsschicht. Zunächst tritt der neue Proxy-server (P-CSCF 2) durch Übernahme der IP-Adresse an die Stelle des ausgefallenen Proxy-Servers (P-CSCF 1). Als nächstes werden die Daten der Anwendungsschicht repliziert. Die ausgefallenen, aber früher ausgehandelten Sicherheitsvereinbarungen werden – soweit möglich – wieder hergestellt. Dazu gehören insbesondere die gemeinsamen Schlüssel, Verschlüsselungsalgorithmen, Port-, Quell- und Zieladressen.

Einem ersten Aspekt der Erfindung zufolge werden die regulären Sicherheitsvereinbarungen des ausgefallenen Proxy-Servers (P-CSCF 1) re-instantiiert, also für die Kommunikation mit der Anwendereinheit weiterverwendet. Ein Problem, das dabei auftritt und allen hier vorgestellten Aspekten zugrunde liegt, betrifft solche Sicherheitsparameter in den Sicherheitsvereinbarungen, die nicht aus der Anwendungsschicht repliziert werden können.

Die oben genannten Kopiedaten betreffen nämlich gerade ausschließlich jene Daten der Anwendungsschicht. Die sich auf der Transport- oder Netzwerkebene abspielenden Prozesse im Moment des Ausfalls sind dagegen unwiederbringlich verloren. Das gilt somit auch für sicherheitsrelevante Daten wie insbesondere die Sequenznummer einer jeweiligen Sicherheitsvereinbarung.

Die Sequenznummer dient vor allem dem Schutz vor Replay-Attacken. Mit jedem Nachrichtenaustausch wird die Sequenznummer um ein Datum hochgezählt, so dass die einfache Aufzeichnung und spätere Wiedergabe durch einen mitlauschenden Angreifer aufgrund einer wiederholten Sequenznummer erkannt werden kann. Die Sequenznummer ist Teil der Transportschicht im IPsec-Aufbau.

Eine Ausgestaltung dieses Aspekts sieht daher vor, beim Wiederherstellen einer auswärts gerichteten Sicherheitsvereinbarung (outbound SA: regelt Sicherheit bezüglich Nachrichten vom Proxy-Server and die Anwendereinheit) eine hinreichend große Sequenznummer ungleich Null einzurichten, die mit ausgehenden Nachrichten versandt wird. Es kann sich dabei um eine beliebig große Zahl handeln. Die Anwendereinheit (UE) vergleicht nämlich die eingehende Sequenznummer mit ihrem Zählerstand und verwirft die Nachricht, wenn die bei ihr eingehende Sequenznummer schon einmal verwendet wurde.

Beispielsweise kann die Sequenznummer vom API (application programming interface), welche die Beziehungen zwischen Betriebssystem und Anwendung auf dem Proxy-Server regelt, für diesen Fall festgesetzt werden.

Alternativ kann der Proxy-Server (P-CSCF 2) eine maximal darstellbare Zahl auswählen, oder er analysiert die replizierte Anwendungsschicht nach Daten, die ein Maß für die Sequenznummer darstellen und addiert einen festen Wert dazu. Zum Beispiel kann der Proxy-Server die Anzahl in der Vergangenheit übermittelter Nachrichten bestimmen oder die Anzahl gesendeter Bytes ermitteln. Eine entsprechend bereitgestellte Tabelle rechnet diese Werte in eine voraussichtlich im Zeitpunkt des Ausfalls gültige Sequenznummer um. Wichtig ist, dass hier der Wert der Sequenznummer höher gesetzt ist als der tatsächlich vorhandene, aber verlorene Wert.

Eine weitere Alternative zur Erzeugung einer angepassten Sequenznummer gemäß diesem ersten Aspekt besteht darin, kontinuierlich vor dem Ausfall vom Standby-Proxy-Server (P-CSCF 2) aus den ursprünglich aktiven Proxy-Server (P-CSCF 1) regelmäßig zu überwachen und die jeweils aktuelle Sequenznummer abzufragen.

Für eine einwärts gerichtete reguläre Sicherheitsvereinbarung (inbound SA) des Proxy-Servers sind gleichfalls Ausgestaltungen des erfindungsgemäßen Verfahrens gemäß dem ersten Aspekt vorgesehen: es besteht hier nämlich ein Problem dahingehend, dass bei der Instantiierung dieser Sicherheitsvereinbarung das Empfangsfenster für IPsec Nachrichten bei Null startet. Das bedeutet, dass alle eingehenden Nachrichten von der Anwendereinheit (UE) diese Hürde leicht nehmen können, so dass auch potentielle Replay-Attacken erfolgreich sein können.

Diese Ausgestaltung sieht daher vor, im Rahmen der Re-Instantiierung bzw. Wiederherstellung dieser regulären Inbound SA lediglich Registriernachrichten (REGISTER-messages) gemäß SIP-Protokoll zuzulassen. Alternativ kann auch eine Grenze der Anzahl der Nachrichten oder Bytes gesetzt werden, bei deren Überschreitung der Inbound SA und damit die Verbindung gelöscht wird. Durch diese Ausgestaltung gelingt zumindest eine Reduzierung der Angriffsmöglichkeiten.

Sicherheitsvereinbarungen werden vorliegend als regulär bezeichnet, wenn sie dem in 3GPP TS 33.203 (z.B. aktuelle Version 7.0.0 Rel. 7) insbesondere in Kapitel 7 spezifizierten Standardsatz von Vereinbarungen entsprechen. Grundsätzlich bestehen dabei auf jeder Seite, d.h. bei der Anwendereinheit (UE) und dem Proxy-Server (P-CSCF) jeweils eine inbound SA und eine outbound SA, zusammen also 4 Sicherheitsvereinbarungen.

Grundsätzlich besteht gemäß diesem ersten Aspekt nach Wiederherstellung der ausgefallenen Sicherheitsvereinbarungen die Möglichkeit, anhand dieser SAs die laufende Verbindung zwischen Anwendereinheit (UE) und Proxy-Server (P-CSCF 2) in nachfolgenden Schritten des Nachrichtenaustauschs aufrecht zu erhalten. Wie oben ausgeführt ist jedoch der Grad an Sicherheit gegenüber Replay-Attacken in diesem Fall nur eingeschränkt vorhanden, weil die ursprünglich im ersten Proxy-Server (P-CSCF 1) bekannten Sequenznummern dem zweiten Proxy-Server (P-CSCF 2) unbekannt sind und dieser daher nur mit groben Abschätzungen rechnen kann.

Eine weitergehende Ausführungsform sieht daher vor, die reinstanzierten SAs nur temporär solange einzusetzen, bis neu aufgestellte, auch bezüglich Replay-Attacken abgesicherte Sicherheitsvereinbarungen sowohl seitens der Anwendereinheit (UE) als auch seitens des Proxy-Servers (P-CSCF 2) vorliegen.

Eine Idee besteht darin, eine Anforderung (im folgenden auch Recovery Request oder abgekürzt „RR" genannt) zur Wiederherstellung der Verbindung vom Proxy-Server (P-CSCF 2) an die Anwendereinheit (UE) zu senden.

Die Anforderung (RR) wird mit Hilfe der Parameter gemäß der temporären, auswärts gerichteten Sicherheitsvereinbarung (outbound SA) des Proxy-Servers (P-CSCF 2) geschützt. Gemäß dem ersten Aspekt der Erfindung geschieht die Übermittlung der Anforderung (RR) an die UE z.B. einschließlich der berechneten oder festgesetzten Sequenznummer.

Bevorzugt kann aber auch eine sog. „Network-Initiated Re-Registration" (übersetzt mit netzwerk-initiierter Re-Registrierung) ausgenutzt werden, die durch die Serving-CSCF (S-CSCF) angestoßen wird. Dazu wird, anstatt eine Anforderung (RR) an die Anwendereinheit (UE) abzusenden, eine entsprechende Anforderung oder Nachricht an die Serving-CSCF gesendet mit dem Ziel, die Serving-CSCF (S-CSCF) anzutriggern, so dass diese die genannte Netzwerk-Re-Registrierung anstößt. Die nachfolgenden Schritte können analog zur Registrierung wie bei Anstoßen der Re-registrierung über die Anwendereinheit (UE) verlaufen.

Einer ersten Ausgestaltung dieses Erfindungsgedankens zufolge wird der Aufbau neuer, abgesicherter SAs auf beiden Seiten (UE und P-CSCF 2) anhand eines speziellen Handshakes bewerkstelligt. Ausgangspunkt ist bereits ein fest eingerichteter inbound SA sowie ein noch temporärer outbound SA beim Proxy-Server (P-CSCF 2).

Auf die oben beschriebene Anforderung (RR) hin, mit welcher in diesem Fall zusätzlich auch SPI-indizes übermittelt werden, die auf die wiederhergestellten inbound SAs des Proxy-Servers (P-CSCF 2) zeigen, wird bei der Anwendereinheit (UE) deren alte, auswärts gerichtete Sicherheitsvereinbarung (outbound SA) gelöscht. Des weiteren wird eine entsprechend neue inbound SA und eine neue outbound SA aufgestellt, die mit den wiederhergestellten SAs des zweiten Proxy-Servers (P-CSCF 2) kompatibel sind. Alte und neue inbound SA koexistieren zeitweilig auf Seite der Anwendereinheit (UE). Sie können gemäß IPsec Spezifikation (RFC 2401) anhand ihrer unterschiedlichen SPI-Indizes auseinander gehalten werden. Die SPI-Indizes dienen der gegenseitigen Auswahl und Referenzierung von Sicherheitsvereinbarungen zwischen den Kommunikationspartnern.

Anschließend sendet die Anwendereinheit (UE) eine Antwort (Response to RR) an den Proxy-Server (P-CSCF 2) mit ihren entsprechenden SPI-Indizes. Anhand derer kann der Proxy-Server (P-CSCF 2) seine auswärtsgerichtete Sicherheitsvereinbarung (outbound SA) anpassen, d.h. erneuern. Mit anderen Worten, die alte outbound SA, anhand welcher der Recovery Request (RR) geschützt wurde, wird nun gelöscht und ein neuer outbound SA seitens des Proxy-Servers (P-CSCF 2) wird aufgestellt, der mit den von der Anwendereinheit übermittelten SPI-Indizes kompatibel ist.

Der Proxy-Server (P-CSCF 2) bestätigt den Erhalt der Antwort gegenüber der Anwendereinheit (UE), so dass letztere nun auch ihren alten inbound SA löschen kann.

Es ist anzumerken, dass je nach Verwendung von TCP oder UDP als Transportschicht-Protokoll entweder ein oder zwei reguläre SAs je Typ (outbound – inbound) und Partner (UE oder P-CSCF) vorliegen. Die Erfindung (alle Aspekte) schließt beide Fälle (UDP, TCP) ein, auch wenn in diesem Dokument jeweilige Sicherheitsvereinbarungen eines Typs und Partners häufig nur im Singular bezeichnet werden.

Eine zweite Ausgestaltung des Erfindungsgedankens bzgl. des Recovery Requests (RR) besteht darin, eine teils ungeschützte Re-Registrierung nach Absendung der Anforderung durchzuführen, die wie oben ausgeführt anhand der wiederhergestellten outbound SA durch den Proxy-Server (P-CSCF 2) geschützt wird. Die Anwendereinheit (UE) antwortet auf die Anforderung mit einer REGISTER-Anfrage gemäß SIP-Protokoll.

Eine Re-Registrierung dient allgemein dem Wechsel zu neuen Sicherheitsvereinbarungen während einer Session. Die Re-Registrierung unterscheidet sich von der anfänglichen Registrierung dadurch, dass sie authentifiziert durchgeführt wird. Insbesondere werden dabei normalerweise geschützte Ports verwendet, wobei die jeweils geschützten Server-Ports beim Wechsel von alten zu neuen Sicherheitsvereinbarungen sogar erhalten bleiben. Die konventionelle Registrierung ist im Standard 3GPP TS 33.203 in Kapitel 6.1.1, das Aufsetzen von SAs in Kapitel 7.2. und die Re-Registrierung in Kapitel 7.4. spezifiziert.

Vorliegend wird die an den Zielserver S-CSCF gerichtete REGISTER-Anfrage gemäß SIP-Protokoll über einen ungeschützten (unprotected) Client Port der Anwendereinheit (UE) zunächst an einen ungeschützten Server-Port des Proxy-Servers (P-CSCF 2) gesendet. Die Antwort vom Proxy-Server (P-CSCF 2) weist im Rahmen des IMS-AKA Protokolls für die Authentikation einen vom Server (S-CSCF) des Heimatnetzwerks erstellten Challenge-Wert auf (vgl. 3GPP TS 33.203, Kapitel 6.1.1). Der Unterschied zur geltenden Re-Registrierung besteht folglich in der Verwendung ungeschützter Ports sowie in einer Authentikation, die ähnlich wie bei der initialen Registrierung abläuft. Dabei markiert der Proxy-Server vor Weiterleitung der REGISTER-Anfrage and den Server (S-CSCF) diese als ungeschützt.

Der Heimatnetzwerk-Server (S-CSCF) erkennt bzgl. der REGISTER-Anfrage, dass sie Teil einer Re-Registrierung in einer laufenden Verbindung ist. Er erkennt dies z.B. daran, dass einige der Registrierzustände unverändert bleiben, bzw. dass der Proxy-Server (P-CSCF) ihm die Authentikation der UE mitteilt. Der Zielserver S-CSCF führt eine Re-Registrierung immer dann durch, wenn der Proxy-Server diesem mitteilt, dass es sich um eine geschützte REGISTER-Nachricht handelt. Gleichwohl erkennt der Server (S-CSCF), dass die Anfrage als ungeschützt markiert ist.

Entscheidend ist, dass die Serving-CSCF (S-CSCF) anhand einer Markierung der Nachricht durch den Proxy-Server (P-CSCF 2) ohne weiteres erkennen kann, welche Schritte nachfolgend durchzuführen sind.

Gemäß dieser Ausgestaltung behandelt der Server (S-CSCF) des Heimatnetzwerks die REGISTER-Anfrage als Teil einer Re-Registrierungsprozedur und nicht einer initialen Registrierung, denn diese würde den Abbruch der bisherigen SIP-Session bedeuten. Dennoch führt der Server (S-CSCF) eine erneute Pflichtauthentikation durch, die konventionell bei der Re-Registrierung nur optional durchgeführt wird.

Die Sicherheitsvereinbarungen (SA) zwischen Anwendereinheit (UE) und Proxy-Server (P-CSCF 2) werden bei der hier vorgeschlagenen Re-Registrierung neu ausgehandelt. Die neu ausgehandelten Sicherheitsvereinbarungen ersetzen demnach die alten SAs.

Ein zweiter Aspekt der Erfindung sieht vor, im Unterschied zum ersten Aspekt nicht die alten, regulären, wiederhergestellten Sicherheitsvereinbarungen (SA) zum Zweck der Verschlüsselung weiter zu verwenden, sondern vielmehr dedizierte Ausfall-Sicherheitsvereinbarungen (fail-over SAs) zu schaffen. Diese dienen ausschließlich der Wiederherstellung der laufenden Verbindung nach Ausfall des primären Proxy-Servers (P-CSCF 1).

Ein besonderer Vorteil, der sich durch solche von den regulären SAs separaten Ausfall-Sicherheitsvereinbarungen (fail-over SAs) bietet, ist der, dass mangels Verwendung dieser fail-over SAs vor einem Ausfall die Sequenznummer für abgesandte Nachrichten in vereinbarter Weise auf beiden Seiten (UE und P-CSCF 2) auf einem festen Wert, beispielsweise Null, steht. Dadurch besteht bei diesem Aspekt ein besonders hoher Grad an Sicherheit, insbesondere gegenüber Replay-Attacken nach Ausfall eines Proxy-Servers (P-CSCF 1) – ein Ereignis, das möglicherweise von Angreifern abgepasst werden könnte.

Die zum ersten Aspekt beschriebenen Ausgestaltungen, welche zum einen die Aufstellung neuer regulärer SAs im Rahmen eines (two-way) Handshakes beschreiben, zum anderen die Aufstellung neuer regulärer SAs im Rahmen einer angepassten, aber grundsätzlich dem standardisierten Fall ähnlichen Re-Registrierung beschrieben, gelten auch für den Aspekt der fail-over SAs, nur dass eben letztere als zusätzliche SAs aufgebaut bzw. gehalten werden müssen.

Wie beschrieben dienen die fail-over SAs der Verschlüsselung und Sicherung des Recovery Requests (RR). Es liegt in beiden (zum ersten Aspekt analogen) Ausgestaltungen seitens des Proxy-Servers (P-CSCF 2) eine outbound fail-over SA vor, seitens der Anwendereinheit eine inbound fail-over SA. Beide fail-over SAs bilden ein zusammengehöriges Paar.

Auf Seite der Anwendereinheit (UE) wird die fail-over SA dauerhaft gehalten, bis der Ausfall des Kommunikationspartners eintritt. Die fail-over SA wird dabei eingesetzt und verbraucht. D.h., sie wird nach Einsatz gelöscht und durch eine neue fail-over SA ersetzt, die mit dem Proxy-Server (P-CSCF 2) ausgehandelt wird.

Auf Seite der Proxy-Server (P-CSCF 1 und 2) wird die Information lediglich in der Anwendungsschicht im ersten Proxy-Server (P-CSCF 1) gehalten, d.h., es findet kein dauerhafter Aufbau einer fail-over SA statt. Sie kann und soll nämlich während einer noch nicht ausgefallenen Verbindung nicht eingesetzt werden. Erst nach dem Ausfall und dem Replizieren der Sicherheitsinformationen auf dem zweiten und bisherigen Standby-Proxy-Server (P-CSCF 2) wird aus diesen Informationen der Anwendungsschicht heraus eine dedizierte fail-over SA aufgestellt. Der Unterschied zwischen einem alleinigen Halten der fail-over SA-Information in der Anwendnungsschicht und einer expliziten Aufstellung der fail-over SA nach dem Ausfall besteht in der Abspeicherung in einer gesonderten Sicherheitsdatenbank, in der SAs von außen durch Referenzieren anhand von SPI-Zeigern angesprochen werden können.

Ein dritter Aspekt der Erfindung betrifft das Anstoßen (Triggern) einer angepassten Re-Registrierung, so wie eingangs beim ersten Aspekt beschrieben, jedoch ohne dass hierbei eine Verschlüsselung der Anforderung bzw. des Recovery Requests (RR) über Sicherheitsvereinbarungen – weder über reguläre noch über fail-over SAs – erfolgt.

Eine Ausgestaltung des dritten Aspekts sieht vor, ein separates, vorab abgestimmtes Geheimnis, das auf shared-key-Material basiert, einzurichten, mit dem die Verschlüsselung der Triggernachricht (Anforderung RR) erfolgt.

Eine weitere Ausgestaltung des dritten Aspekts sieht vor, keine weitere Zustandsänderung der Registrierung nach Wiederherstellung mehr zuzulassen, d.h. ein Verbot weiterer Re-Registrierungen der laufenden Session. Dies kann beispielsweise durch Setzen eines Flags auf Seite des Proxy-Servers (P-CSCF 2) geschehen, der die laufende Session kennzeichnet und nach Beendigung der Verbindung wieder gelöscht wird.

Ein weitere Ausgestaltung des dritten Aspekts sieht vor, die Anzahl der zulässigen Anforderungen auf Wiederherstellung einer Session bzw. Verbindung innerhalb eines festgelegten Zeitraums nach dem Ausfall zu begrenzen.

Die Erfindung soll nun anhand eines Ausführungsbeispiels mit Hilfe von Zeichnungen näher erläutert werden. Darin zeigen:

1: den grundsätzlichen Aufbau eines IMS-Systems gemäß 3GPP;

24: Flussdiagramme mit aufeinanderfolgenden Schritten eines two-way-Handshakes für die Wiederherstellung von SAs einer laufenden Verbindung zwischen Anwendereinheit (UE) und Proxy-Server (P-CSCF 2) unter Verwendung vorab vereinbarter fail-over SAs.

1 zeigt den grundsätzlichen Aufbau eines IMS-Systems gemäß 3GPP, so wie er in diesem Dokument eingangs beschrieben ist. Die Massnahmen gemäß dem nun zu beschreibenden Ausführungsbeispiel beziehen sich auf einen Handshake, d.h. einem Informationsaustausch, zwischen der Anwendereinheit (UE), genauer gesagt: dessen User Agent (UA), und dem zweiten Proxy-Server (P-CSCF 2), der nach einem Ausfall eines ersten Proxy-Servers (P-CSCF 1) dessen Funktion der Vermittlung von Nachrichten vom und zum Server (S-CSCF) übernimmt. Die im folgenden beschriebenen SAs beziehen sich also auf den die Verbindung UA – P-CSCF darstellenden Pfeil in 1.

2 zeigt einen ersten Teil eines Flussdiagramms, mit welchem dieser Handshake erläutert werden soll. Der Handshake wird außerhalb einer Registrierung oder Re-Registrierung durchgeführt und läuft daher außerhalb derzeit festgelegter Standards ab.

Vor dem Ausfall des ersten Proxy-Servers (P-CSCF 1) liegen auf beiden Seiten (UE und P-CSCF 1) jeweils Paare von regulären inbound und outbound SAs vor. Darüber hinaus wurde eine fail-over SA vereinbart, die auch als solche bei der Anwendereinheit (UE) hinterlegt ist. Die in der fail-over SA vorhandenen serverseitigen Informationen (Sicherheitsparameter) sind auch in der Anwendungsschicht beim Proxy-Server (P-CSCF 1) vorhanden, ohne dass daraus aber eine eigene fail-over SA im Proxy-Server (P-CSCF 1) erstellt wird.

Die Art und Weise, wie der fail-over SA erstellt wird, geht aus dem weiteren Ablauf gemäß 24 hervor. Die alten, regulären SAs vor dem Ausfall werden gemäß dem Stand der Technik im Rahmen einer Erstregistrierung im Security-Mode erstellt (vgl. 3GPP TS 33.203 (Kapitel 7.2) und RFC 3329).

Die Sicherheitsparameter der regulären SAs umfassen: sog. Selectors, z.B. IP-Adressen (Source und Destination, gebunden an SIP-Fluss), Transportprotokolle (TCP oder UDP, wird ausgehandelt), geschützte Portadressen (Source und Destination, gebunden an SIP-Fluss), weiter Algorithmen (encryption und integrity), zugeordnete SPI-Zeiger für inbound SAs, Lebensdauer (in Sekunden, wird ausgehandelt), aktuelle und maximale Sequenznummer (letzteres wird ausgehandelt, z.B. 231 – 1), Länge des Schlüssels für Integritätsalgorithmus (wird ausgehandelt, z.B. 128 bit für HMAC-MD5-96 oder 160 bit für HMAC-SHA-1-96), Länge des Schlüssels für Encyption (wird ausgehandelt, z.B. für DES-EDE3-CBC (RFC 2451) oder AES-CBC (RFC 3602) mit mindestens 128 bit).

Der Ausfall des ersten Proxy-Servers (P-CSCF 1) wird dem zweiten Standby-Proxy-Server (P-CSCF 2) signalisiert. Dieser übernimmt sofort die IP-Adresse des ersten Proxy-Servers (P-CSCF 1).

Des weiteren repliziert er die Daten der Anwendungsschicht des ersten Proxy-Servers (P-CSCF 1), insbesondere der sicherheitsrelevanten Informationen der regulären SAs, wie sie vor dem Ausfall bestand hatten.

Basierend auf diesen Informationen werden vom zweiten Proxy-Server (P-CSCF 2) neue reguläre inbound SAs erstellt.

Auch eine fail-over SA wird erstellt. Für die outbound fail-over SA des Proxy-Servers (P-CSCF 2) sind z.B. folgende Sicherheitsparameter erforderlich: eigene Source- und fremde Destination-Port-Nummer der Anwendereinheit (UE), der durch die Anwendereinheit (UE) dieser fail-over SA zugeordnete SPI-Wert. Die IP-Adressen sind die gleichen wie für die regulären SAs. Der geschützte (protected) Server-Port der UE ist durch die Replikation der Anwendungsschicht bekannt und wird für die fail-over SA vorzugsweise als Destination-Port gewählt. Der geschützte Client-Port des Proxy-Servers (P-CSCF 2) dieser fail-over SA muss dann aus Gründen der Eindeutigkeit anders als derjenige für die regulären SAs gewählt werden. Als Sequenznummer gilt der Wert Null.

Der Proxy-Server (P-CSCF 2) alloziiert neue SPI-indizes (spi-pc und spi-ps) für die regulären inbound SAs (wg. ausgewähltem UDP-Protokoll sind dies hier zwei anstatt nur eines SAs (TCP) an der Zahl).

Anhand des mittels der Replikation ebenfalls bekannten Schlüssels und des zugehörigen Algorithmus der fail-over SA wird eine Anforderung (RR) erzeugt und an die Anwendereinheit (UE) gesandt. Mit der Nachricht werden auch die SPI-Indizes (spi-pc und spi-ps) übermittelt. Die Sequenznummer zählt durch diese Verwendung um den Zähler „1" hoch.

3 zeigt die Fortsetzung des Flussdiagrams aus 2. Der Recovers-Request (RR) wird empfangen und aufgrund der noch bestehenden alten fail-over SA zugelassen (entschlüsselt, verifiziert, authentifiziert etc.). Insbesondere ist die empfangene Sequenznummern größer als die bei der UE vorhandene, denn die inbound failover SA der UE ist bisher noch nicht eingesetzt worden. In der Anwendereinheit (UE) werden daraufhin die alten regulären SAs entfernt, da sie nicht mehr benötigt werden. Neue inbound und outbound SAs werden aufgestellt. Erstere werden eigens zu diesem Zweck alloziierten SPI-Indizes (spi-uc und spi-us) zugeordnet.

Es wird ferner eine neue inbound fail-over SA aufgestellt und ebenfalls einem alloziierten SPI-Index (spi-f) zugeordnet.

Die SPI-Indizes (spi-uc, spi-us und spi-f) werden nun in eine Antwort (response) auf die Anforderung (recovery request) gefasst und geschützt (Integrity und Encryption) gemäß den Vereinbarungen, auf die der Index spi-ps zeigt. Die Antwort wird an den Proxy-Server (P-CSCF 2) übermittelt. Dabei wird die Nachricht vom Port port_uc der Anwendereinheit UE via UDP an den port_ps des Proxy-Servers (P-CSCF 2) gesendet (zu den Portbezeichnungen siehe 3GPP TS 33.203 Version 7.0.0 Release 7, Seite 21–23).

Der Proxy-Server (P-CSCF 2) erstellt seinerseits neue reguläre outbound SAs anhand der erhaltenen Informationen (SPI-Zeiger). Außerdem wird der eingangs erstellte, aber nunmehr veraltete outbound failover SA des Proxy-Servers (P-CSCF 2) gelöscht. Nunmehr liegen auf Seite der Anwendereinheit zwei parallel existierende fail-over SAs vor (alt und neu), und auf Seite des Proxy-Servers (P-CSCF 2) liegt keine fail-over SA mehr vor. Dagegen besitzt der Proxy-Server (P-CSCF 2) aufgrund der durch spi-f aufgezeigten Informationen Zugang zu den Sicherheitsparametern der neuen fail-over SA der UE, wobei er diese Parameter lediglich in der Anwendungsschicht hält.

Die Situation ist in 4 dargestellt, deren gezeigtes Flussdiagramm sich an dasjenige aus 3 anschließt. Gemäß SIP-Nachricht wird vom Proxy-Server (P-CSCF 2) der Empfang von spi-f an die Anwendereinheit (UE) bestätigt. Dazu wird anhand der neuen outbound SA und nicht mehr der alten failover SA vorgegangen, was die Verschlüsselung betrifft. Die Anwendereinheit (UE) entfernt infolgedessen die alte failover SA, so dass nur noch die neue inbound fail-over SA verbleibt.

Somit ist wieder die Situation hergestellt, die zu Anfang des Flussdiagramms in 2 bestand. Das System würde also auch auf einen zweiten Ausfall reagieren können.

Es ist anzumerken, dass die vorgenannten Ausgestaltungen und Beispiele in diesem Dokument auch für bidirektionale Sicherheitsvereinbarungen (reguläre und fail-over SAs) anwendbar sind und dass die entsprechend möglichen Ausführungsformen von der Erfindung mit umfasst sein sollen.


Anspruch[de]
Verfahren zum Wiederherstellen einer mit IPsec kryptographisch gesicherten Verbindung zwischen einem zweiten Proxy-Server (P-CSCF 2) und einer gegenüber einem Server (S-CSCF) registrierten Anwendereinheit (UE), nachdem ein erster Proxy-Server (P-CSCF 1) in einem von der Anwendereinheit (UE) besuchten Netzwerk (VN) ausgefallen ist, welcher vor dem Ausfall zur Vermittlung von zwischen dem Server (S-CSCF) und der Anwendereinheit (UE) versandten Nachrichten eingerichtet war, umfassend:

– Bereitstellen eines zweiten Proxy-Servers (P-CSCF 2) in dem besuchten Netzwerk (VN);,

– Übernehmen einer IP-Adresse des ersten Proxy-Servers (P-CSCF 1) durch den zweiten Proxy-Server (P-CSCF 2), so dass dieser an die Stelle des ersten Proxy-Servers (P-CSCF 1) bezüglich der Vermittlung von Nachrichten tritt;

– Replizieren von Informationen betreffend die kryptographische Sicherheit der Verbindung in dem zweiten Proxy-Server (P-CSCF 2), welche zuletzt vor dem Ausfall in der Anwendungsschicht im ersten Proxy-Server (P-CSCF 1) gespeichert waren;

– Verwenden der replizierten Informationen zur Erstellung wenigstens einer Sicherheitsvereinbarung (SA) zwischen dem zweiten Proxy-Server (P-CSCF 2) und der Anwendereinheit (UE) in dem Proxy-Server (P-CSCF 2), anhand welcher nachfolgend eine Verschlüsselung der vermittelten Nachrichten durchgeführt wird.
Verfahren nach Anspruch 1, bei dem vom zweiten Proxy-Server (P-CSCF 2) wenigstens zwei reguläre Sicherheitsvereinbarungen (inbound SA, outbound SA) erstellt werden, indem Sicherheitsparameter mit Ausnahme jeweils des Sicherheitsparameters Sequenznummer aus denjenigen regulären Sicherheitsvereinbarungen aus den replizierten Informationen übernommen werden, die vor dem Ausfall im ersten Proxy-Server (P-CSCF 1) bestand hatten. Verfahren nach Anspruch 2, bei dem bei der Wiederherstellung einer auswärts gerichteten regulären Sicherheitsvereinbarung (outbound SA) der Sicherheitsparameter Sequenznummer vom Proxy-Server (P-CSCF 2) mit einer Zahl besetzt wird, die größer als der Wert Null ist, so dass eine mit der Sequenznummer versehene Nachricht nicht aufgrund eines Zahlenvergleichs mit einer dem zweiten Proxy-Server (P-CSCF 2) unbekannten, aber der Anwendereinheit (UE) bekannten Sequenznummer, die Gegenstand einer regulären Sicherheitsvereinbarung war, die vor dem Ausfall im ersten Proxy-Server (P-CSCF 1) bestand hatte, von der Anwendereinheit (UE) zurückgewiesen wird. Verfahren nach Anspruch 3, bei dem die zu setzende Zahl für die Sequenznummer ausgehender Nachrichten in einem API-Interface zwischen Anwendung und Betriebssystem auf dem Proxy-Server (P-CSCF 2) fest hinterlegt wird. Verfahren nach Anspruch 3, bei dem die zu setzende Zahl für die Sequenznummer ausgehender Nachrichten vom Proxy-Server (P-CSCF 2) als lokal größter darstellbarer Wert ausgewählt wird. Verfahren nach Anspruch 3, bei dem die zu setzende Zahl für die Sequenznummer ausgehender Nachrichten vom Proxy-Server (P-CSCF 2) aus Angaben über die Zahl innerhalb der laufenden Verbindung versendeter Nachrichten oder Bytes, die er aus den replizierten Informationen ausliest, berechnet wird. Verfahren nach Anspruch 3, bei dem eine frühere Sequenznummer ausgehender Nachrichten, die Gegenstand einer regulären Sicherheitsvereinbarung war, die vor dem Ausfall im ersten Proxy-Server (P-CSCF 1) bestand hatte, vom Proxy-Server (P-CSCF 2) vor dem Ausfall in regelmäßigen Abständen von dem noch nicht ausgefallenen Proxy-Server (P-CSCF 1) abgefragt und gespeichert wird, und bei dem der Schritt der Wiederherstellung der auswärtsgerichteten Sicherheitsvereinbarung (outbound SA) die Berechnung der zu setzenden Zahl anhand der ausgelesenen und gespeicherten, früheren Sequenznummer durch den zweiten Proxy-Server (P-CSCF 2) umfasst. Verfahren nach Anspruch 2, bei dem bei der Wiederherstellung einer einwärts gerichteten regulären Sicherheitsvereinbarung (inbound SA) ein Anfangswert für die Sequenznummer eingehender Nachrichten auf Null gesetzt wird. Verfahren nach Anspruch 8, bei dem der zweite Proxy-Server (P-CSCF 2) nach der Wiederherstellung lediglich noch solche die Registrierung der Anwendereinheit (UE) gegenüber dem Server (S-CSCF) betreffenden Nachrichten zulässt und weitervermittelt und die übrigen Nachrichten zurückweist. Verfahren nach einem der Ansprüche 2 bis 9, bei dem der zweite Proxy-Server (P-CSCF 2) nach Wiederherstellung der regulären Sicherheitsvereinbarungen (inbound SA, outbound SA) eine Anforderung (RR) zur Wiederherstellung der Verbindung an die Anwendereinheit sendet. Verfahren nach einem der Ansprüche 2 bis 9, bei dem der zweite Proxy-Server (P-CSCF 2) nach Wiederherstellung der regulären Sicherheitsvereinbarungen (inbound SA, outbound SA) durch Übermittlung einer Nachricht an den Serving CSCF (S-CSCF) eine netzwerk-initiierte Re-Registration anstößt, die vom Serving CSCF (S-CSCF) gestartet wird. Verfahren nach Anspruch 10, bei dem die Anforderung (RR) mit einem Schlüssel und einem Algorithmus geschützt wird, welche Sicherheitsparameter einer der wiederhergestellten Sicherheitsvereinbarungen (outbound SA) sind. Verfahren nach Anspruch 12, bei dem nach Empfang der Anforderung (RR) durch die Anwendereinheit (UE) eine Re-Registrierung gegenüber dem Serving-CSCF (S-CSCF) angestoßen wird, so dass in dessen Verlauf die wiederhergestellten Sicherheitsvereinbarungen (inbound SA, outbound SA) in dem zweiten Proxy-Server (P-CSCF 2) durch neu vereinbarte Sicherheitsvereinbarungen ersetzt, und auch in der Anwendereinheit (UE) vorhandene alte Sicherheitsvereinbarungen durch neue Sicherheitsvereinbarungen werden. Verfahren nach Anspruch 13, bei dem die Re-Registrierung über ungeschützte Ports der Anwendereinheit (UE) und des Proxy-Servers (P-CSCF 2) über eine REGISTER-Anfrage gemäß SIP-Protokoll initialisiert wird, und bei dem der zweite Proxy-Server (P-CSCF 2) die REGISTER-Anfrage als ungeschützt markiert und an den Serving-CSCF (S-CSCF) weiterleitet. Verfahren nach Anspruch 14, bei dem der Serving-CSCF (S-CSCF) aus der REGISTER-Anfrage erkennt, dass eine als ungeschützt markierte Re-Registrierung erfolgen soll und in Antwort darauf eine Pflichtauthentikation mit einem erneuten Aushandeln von Sicherheitsvereinbarungen durchführt. Verfahren nach Anspruch 12, bei dem lediglich auswärtsgerichtete, reguläre Sicherheitsvereinbarungen (outbound SA) beim Proxy-Server (P-CSCF 2) wiederhergestellt werden. Verfahren nach Anspruch 16, bei dem mit der Anforderung (RR) SPI-Indizes (spi-pc, spi-ps) wenigstens einer zusätzlichen, neu aufgestellten, einwärts gerichteten Sicherheitsvereinbarung (inbound SA) vom Proxy-Server (P-CSCF 2) an die Anwendereinheit (UE) versendet werden. Verfahren nach Anspruch 17, bei dem die Anwendereinheit (UE) unter Verwendung wenigstens einer alten, von ihr vor dem Ausfall aufgestellten, einwärts gerichteten, regulären Sicherheitsvereinbarung (inbound SA) die Anfrage empfängt. Verfahren nach Anspruch 18, bei dem die Anwendereinheit (UE) wenigstens eine neue, einwärts gerichtete Sicherheitsvereinbarung (inbound SA) sowie wenigstens eine neue auswärts gerichtete Sicherheitsvereinbarung (outbound SA) aufstellt, und der wenigstens einen einwärts gerichteten Sicherheitsvereinbarung (inbound SA) jeweils einen SPI-Index (spi-uc, spi-us) zuordnet. Verfahren nach Anspruch 19, bei dem die Anwendereinheit (UE) eine Antwort (response) an den Proxy-Server (P-CSCF 2) sendet, welche anhand einer der vom zweiten Proxy-Server (P-CSCF 2) empfangenen SPI-Indizes (spi-ps) geschützt wird und welche die den einwärts gerichteten Sicherheitsvereinbarungen (inbound SA) der Anwendereinheit (UE) zugeordneten SPI-Indizes (spi-uc, spi-us) enthält. Verfahren nach Anspruch 20, bei dem der Proxy-Server (P-CSCF 2) die Antwort (response) unter Verwendung der wenigstens einen einwärts gerichteten regulären Sicherheitsvereinbarung (inbound SA) empfängt und den gesicherten Inhalt entnimmt. Verfahren nach Anspruch 21, bei dem der Proxy-Server (P-CSCF 2) auf den Empfang der Antwort (response) hin eine Bestätigung an die Anwendereinheit (UE) sendet. Verfahren nach Anspruch 22, bei dem die Anwendereinheit (UE) auf den Empfang der Bestätigung von dem zweiten Proxy-Server (P-CSCF 2) hin die alte, von ihr vor dem Ausfall aufgestellte, einwärts gerichtete, regulären Sicherheitsvereinbarung (inbound SA) löscht. Verfahren nach Anspruch 1, bei dem vom zweiten Proxy-Server (P-CSCF 2) wenigstens eine auswärtsgerichtete Ausfall-Sicherheitsvereinbarung (outbound fail-over SA) erstellt wird, indem Sicherheitsparameter aus denjenigen regulären Sicherheitsvereinbarungen aus den replizierten Informationen übernommen werden, die vor dem Ausfall im ersten Proxy-Server (P-CSCF 1) bestand hatten, wobei der Ausfall-Sicherheitsvereinbarung (fail-over SA) zusätzlich eine Sequenznummer mit festem Wert zugeordnet ist. Verfahren nach Anspruch 24, bei dem die erstellte, auswärtsgerichtete Ausfall-Sicherheitsvereinbarung (outbound fail-over SA) des Proxy-Servers (P-CSCF 2) einer bereits vor dem Ausfall vorhandenen einwärts gerichteten Sicherheitsvereinbarung (inbound fail-over SA) der Anwendereinheit (UE) zugeordnet ist. Verfahren nach Anspruch 25, bei dem eine Anforderung (RR) zur Wiederherstellung der Verbindung vom Proxy-Server (P-CSCF 2) an die Anwendereinheit (UE) gesendet wird. Verfahren nach Anspruch 26, bei dem die Anforderung (RR) mit einem Schlüssel und einem Algorithmus geschützt wird, welche Sicherheitsparameter der auswärts gerichteten Ausfall-Sicherheitsvereinbarung (outbound fail-over SA) des Proxy-Servers (P-CSCF 2) sind. Verfahren nach Anspruch 27, bei dem nach Empfang der Anforderung (RR) durch die Anwendereinheit (UE) eine Re-Registrierung gegenüber dem Server (S-CSCF) angestoßen wird, so dass in dessen Verlauf in dem zweiten Proxy-Server (P-CSCF 2) neue reguläre Sicherheitsvereinbarungen (inbound SA, outbound SA) erstellt, und auch in der Anwendereinheit (UE) neue reguläre Sicherheitsvereinbarungen (inbound SA, outbound SA) erstellt werden. Verfahren nach Anspruch 28, bei dem die Re-Registrierung über ungeschützte Ports der Anwendereinheit (UE) und des Proxy-Servers (P-CSCF 2) über eine REGISTER-Anfrage gemäß SIP-Protokoll initialisiert wird, und bei dem der zweite Proxy-Server (P-CSCF 2) die REGISTER-Anfrage als ungeschützt markiert und an den Server (S-CSCF) weiterleitet. Verfahren nach Anspruch 29, bei dem der Server (S-CSCF) aus der REGISTER-Anfrage erkennt, dass eine als ungeschützt markierte Re-Registrierung erfolgen soll und in Antwort darauf eine Pflichtauthentikation mit einem erneuten Aushandeln zum Aufstellen der neuen Sicherheitsvereinbarungen in der Anwendereinheit (UE) und dem zweiten Proxy-Server (P-CSCF 2) durchführt. Verfahren nach Anspruch 27, bei dem mit der Anforderung (RR) SPI-Indizes (spi-pc, spi-ps) wenigstens einer zusätzlichen, neu aufgestellten, einwärts gerichteten Sicherheitsvereinbarung (inbound SA) vom Proxy-Server (P-CSCF 2) an die Anwendereinheit (UE) versendet werden. Verfahren nach Anspruch 31, bei dem die Anwendereinheit (UE) unter Verwendung der einwärts gerichteten, regulären Sicherheitsvereinbarung (inbound SA) die Anfrage empfängt. Verfahren nach Anspruch 32, bei dem die Anwendereinheit (UE) wenigstens eine neue, einwärts gerichtete Sicherheitsvereinbarung (inbound SA), wenigstens eine neue auswärts gerichtete Sicherheitsvereinbarung (outbound SA) und eine neue einwärts gerichtete Ausfall-Sicherheitsvereinbarung (inbound fail-over SA) aufstellt, wobei sie der wenigstens einen einwärts gerichteten Sicherheitsvereinbarung (inbound SA) jeweils einen SPI-Index (spi-uc, spi-us) und der einwärts gerichteten Ausfall-Sicherheitsvereinbarung einen SPI-Index (spi-f) zuordnet. Verfahren nach Anspruch 33, bei dem die Anwendereinheit (UE) eine Antwort (response) an den Proxy-Server (P-CSCF 2) sendet, welche anhand einer der vom zweiten Proxy-Server (P-CSCF 2) empfangenen SPI-Indizes (spi-ps) geschützt wird und welche die den einwärts gerichteten Sicherheitsvereinbarungen (inbound SA) der Anwendereinheit (UE) zugeordneten SPI-Indizes (spi-uc, spi-us) sowie den der Ausfall-Sicherheitsvereinbarung (inbound fail-over SA) zugeordneten SPI-Index (spi-f) enthält. Verfahren nach Anspruch 34, bei dem der Proxy-Server (P-CSCF 2) die Antwort (response) unter Verwendung der wenigstens einen einwärts gerichteten regulären Sicherheitsvereinbarung (inbound SA) empfängt und den gesicherten Inhalt entnimmt. Verfahren nach Anspruch 35, bei dem der Proxy-Server (P-CSCF 2) auf den Empfang der Antwort (response) hin eine Bestätigung implizit im Rahmen einer nachfolgenden Nachricht an die Anwendereinheit (UE) sendet. Verfahren nach Anspruch 36, bei dem der Proxy-Server (P-CSCF 2) die durch den der Ausfall-Sicherheitsvereinbarung (inbound fail-over SA) zugeordneten SPI-Index (spi-f) enthaltenen Sicherheitsinformationen in der Anwendungsschicht gespeichert hält, so dass sie bei einem erneuten Ausfall repliziert werden können. Verfahren nach Anspruch 37, bei dem die Anwendereinheit (UE) auf den Empfang der Bestätigung von dem zweiten Proxy-Server (P-CSCF 2) hin die alte, einwärts gerichtete Ausfall-Sicherheitsvereinbarung (inbound fail-over SA) löscht. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der erste und der zweite Proxy-Server (P-CSCF 1, P-CSCF 2) Cluster Nodes desselben physikalischen Servers in Cluster-Konfiguration repräsentieren.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com