Philipp Nagl schrieb:

Der Schaden auf der Strecke Emmerich-Oberhausen konnte um 15:15 beseitigt werden, der Verkehr kann wieder normal durchgeführt werden.

Bei Netzbetreibern im Bereich Tekekommunikation ist eigentlich ein rund um sie Uhr besetztes Netzmanagenentcrnter üblich. Da werden solche Ausfälle sofort bemerkt und Gegenmaßnahmen eingeleitet. Bei der Telekom gab es schon Fälle, bei denen wurde in die Vermittlungsstelle eingebrochen und zwei Minuten später kamen Meldungen über ausfallende Leitungen. Aus der Erfahrung heraus wurde die Polizei verständigt und die fahren sofort verstärkt die Gegend an. So konnte ein Einbruch in einen Supermarkt verhindert werden. Das war das eigentliche Ziel gewesen, aber die Gegend war tagelang abgeschniiten, bis alles wieder lief.



1-mal bearbeitet. Zuletzt am 2021:01:07:12:48:11.

Philipp Nagl schrieb:

Hier noch die Details:

Bei MobiRail (Netzbetreiber GSM-R in den Niederlanden) gab es eine eine MST-Transmissionleitungsstörung in Deutschland. (Vandalismus)
Da sowohl Sprache als auch Signalisierung (Zugnummereingabe) mit den Niederlanden über diese innerdeutsche Leitung verkehren, konnten mit deutschen SIM-Karten versehenen GSM-R-Geräte in den Niederlanden nicht verwendet werden.

Danke, das ist nun eine klare Ausage, die das Problem nachvollziehbar erläutert. Wobei man schon über eine zweite Leitung oder Backup nachdenken sollte. Es gibt ja nicht nur einen Grenzübergang. Und gleich vorweg, ein Backup ohne dauernde Überwachung bringt nichts. Kunden von mir ließen über die Backupleitung gerne einen gewissen Grundverkehr laufen. So konnte das kostengünstig überwacht werden. Die gaben also einen Teil als Erstweg über das Backup geschickt.

Carsten Frank schrieb:

Der Zug meldet sich mit seiner Funktionalen Rufnummer im GSM-R ein.
Diese besteht aus „2“ als Vorwahl, der Zugnummer (5- oder ggf 6-Stellig) und einer Kennziffer (zb 01 für führendes Fahrzeug).
Der entsprechende Nummernblock wird dann als Zugnummer verwendet.
Und im Roaming wählt sich eine deutsche Karte dann wohl über einen deutschen Knoten ein.

Die deutsche Zentrale teilt dem ausländischen Netzbetreiber mit, dass die Karte mit der ID mit der Rufnummer betrieben wird. Die Rufnummer wird nämlich im HLR der Karte zugewiesen. Gerufen wird im Netz die Karte. Die Rufnummer wird umgewandelt.

kmueller schrieb:

Carsten Frank schrieb:

habe noch was interessantes zur Netzwerksarchitektur im internationalen GSM-R-Roaming gefunden wo genau solch ein Fehler auch beschrieben wird
[gsmr-conference.com]

Dort wird dargestellt wie Verbindungen im Roaming aufgebaut werden.
Außerdem wie die einzelnen nationalen Netze verknüpft sind.
Das soll eigentlich fehlertolerant sein, im Fehlerfall über die Nachbarländer. Es wird genau Fehler NL - D dargestellt, dann sollten sich die Netze „eigentlich“ zb über NL - B - D Verbinden können

Mich wundert schon, daß das gesamte NL-Roaming eines deutschen Anbieters über ein einziges grenzüberschreitendes Kabel laufen soll. Sind die Mobilfunknetze wirklich in diesem Ausmaß zentralisiert?

Die öffentlichen Mobilfunknetze sind da anders aufgebaut. Da läuft das über VPN-Tunnel und Internet bzw. Cross-Connector und dazwischen liegen redundante Verbindungen. Das ist aber bei den kleinen GSM-R-Netzen auch eine Kostenfrage.



1-mal bearbeitet. Zuletzt am 2021:01:07:13:19:01.

ThomasR schrieb:

Carsten Frank schrieb:

Der Zug meldet sich mit seiner Funktionalen Rufnummer im GSM-R ein.
Diese besteht aus „2“ als Vorwahl, der Zugnummer (5- oder ggf 6-Stellig) und einer Kennziffer (zb 01 für führendes Fahrzeug).
Der entsprechende Nummernblock wird dann als Zugnummer verwendet.
Und im Roaming wählt sich eine deutsche Karte dann wohl über einen deutschen Knoten ein.

Die deutsche Zentrale teilt dem ausländischen Netzbetreiber mit, dass die Karte mit der ID mit der Rufnummer betrieben wird. Die Rufnummer wird nämlich im HLR der Karte zugewiesen. Gerufen wird im Netz die Karte. Die Rufnummer wird umgewandelt.

Wozu braucht es eigentlich noch SIM-Karten, geht das nicht auch "digital", sprich elektronisch?

VT605 schrieb:

Wozu braucht es eigentlich noch SIM-Karten ...?

Hallo VT605,

die SIM-Karte dient als Eintrittskarte in das Mobilfunknetz, damit identifiziert sich der Benutzer. Vor Benutzung muss sie aber erst "aufgeschlossen" werden mit dem PIN. Dieser ist mit Sicherheit im Fahrzeug hinterlegt und kann nicht einfach eingesehen werden. Man hat damit zwei "Faktoren" für die Sicherheitsüberprüfung: Man muß etwas besitzen (SIM) und man muss etwas wissen (PIN). Wenn dann das Fahrzeuggerät im Mobilnetz eingebucht ist, können die anderen internen Geräte über das Netz arbeiten, z.B. telefonieren.

Hier war eben für die Fahrzeuge "der Laden" verschlossen und sie konnten sich aus NL nicht anmelden. Das hätten entsprechend dem Thread-Eröffner auch unbezahlte Rechnungen und vieles mehr sein können. Am Ende ist das Verhalten nicht nur digital, sondern sogar binär.

Die SIM-Karte ist sicherlich als historisch zu betrachten und wird durch andere Bausteine ersetzt werden. Die Funktion wird aber in jedem Fall erhalten bleiben.

Viele Grüße, saxobav.

Zugsicherer schrieb:

Saxobav schrieb:

Es sind also für mich Szenarien vorstellbar, wo man beim Aufrüsten und beim normalen Betrieb eines ETCS-Fahrzeuges häufiger Kontakt zum KMC benötigt. Nicht für jede MA, aber eben parametrisierbar häufig (damit am Browser das Schloß grün bleibt...).

Für die Schlüssel ist eine Abfrage der Gültigkeit aber in Subset-137 ohnehin nicht vorgesehen.

Hallo Sven,
das könnte dann eine historische Spezifik haben.
ETCS regelt ja im starken Maße die Kommunikation zwischen den Fahrzeugen und der festen Infrastruktur. Und läßt dabei offen, wie Fahrzeuge und Infrastruktur intern die Daten verwalten. Man geht noch von einer starken Sicherheitsfunktion der GSM-internen Verschlüsselung aus. Und bei IP-freier Kommunikation (GSM/ISDN/S2M/ATM) muss auch die Verschlüsselung anders organisiert werden. Das betrifft die Vorab-Hinterlegung von Schlüsselteilen der Gegenstellen und deren Identifizierung, damit überhaupt Verschlüsselung stattfindet.
Bei der neumodischen Umstellung auf IP-Technik kann man sich dort an aktuellen Methoden bedienen und den Daten-Transportweg absichern. Die "historischen" Verfahren werden wohl erst verschwinden, wenn die RBC per Standard auf All-IP-Technik umgestellt sind und die bisherigen Verfahren ungültig sind. Dann wird es wohl einer neuen Baseline bedürfen, die zusammen mit FRMCS diese alten Standards ausholzt. Bis dahin wird der Ersatzteilmangel für alte RBC ein Motor für deren Modernisierung und IP-Anbindung sein.

Über die GSM-Transportschicht hinaus können moderne Triebfahrzeuge natürlich IP-Verbindungen (EDGE) haben, die kryptografisch gesichert werden und damit an die KMC-Infrastruktur andocken. Das Schlüsselmanagement wird dann aber individuell parametrisiert, wozu auch die Caching-Parameter gehören. Das ist dann aber kaum noch ETCS (Zugbeeinflussung/Zugsicherung), sondern schon im Bereich Transportmanagement (ETML).

Viele Grüße, saxobav.

Hallo,

Saxobav schrieb:

ich betrachte das KMC als nationale (hier deutsche) Certificate Authority (CA). Dort werden nicht nur Schlüssel ausgegeben und verwaltet, sondern ist als Teil der Publicity Key Infrastructure (PKI) auch die Gültigkeit der herausgegebenen Schlüssel abfragbar. Das ist zumindest bei normaler TLS/SSL-Verschlüsselung so.

mal davon abgesehen, dass bei normaler TLS-Verschlüsselung eine zwingende Gültigkeitsüberprüfung nur bei EV-Zertifikaten vorgeschrieben ist, der Rest Einstellungssache des Browsers ist sowie die Überprüfung der Gültigkeit nicht zwingend bei der CA erfolgen muss sondern im Zertifikat hinterlegt ist, hat man dort die Verbindung zur Zertifikatsüberprüfung als Single point of failiure erkannt und daher OCSP-stapling entwickelt. Vereinfacht dargestellt holt sich dort der Zertifikatsinhaber schon vorab die Bestätigung der Gültigkeit und liefert diese dann zusammen aus. So kann dann derjenige, der das Zertifikat überprüfen muss, auf eine sofortige Verbindung zur CA verzichten. Damit sind Verbindungsfehler/Ausfälle bis zur in der Bestätigung angegebenen Länge überbrückbar. Natürlich muss der Zertifikatsnutzer diese Bestätigung öfter erneuern als dessen Gültigkeit (Stunden bis wenige Tage) läuft.

ThomasR schrieb:

Philipp Nagl schrieb:

Hier noch die Details:

Bei MobiRail (Netzbetreiber GSM-R in den Niederlanden) gab es eine eine MST-Transmissionleitungsstörung in Deutschland. (Vandalismus)
Da sowohl Sprache als auch Signalisierung (Zugnummereingabe) mit den Niederlanden über diese innerdeutsche Leitung verkehren, konnten mit deutschen SIM-Karten versehenen GSM-R-Geräte in den Niederlanden nicht verwendet werden.

Danke, das ist nun eine klare Ausage, die das Problem nachvollziehbar erläutert. Wobei man schon über eine zweite Leitung oder Backup nachdenken sollte. Es gibt ja nicht nur einen Grenzübergang. Und gleich vorweg, ein Backup ohne dauernde Überwachung bringt nichts. Kunden von mir ließen über die Backupleitung gerne einen gewissen Grundverkehr laufen. So konnte das kostengünstig überwacht werden. Die gaben also einen Teil als Erstweg über das Backup geschickt.

Na ja, ein Backup gibt es ja eigentlich (die Verbindung über Belgien), es hat nur nicht funktioniert. Und hier wird (davon gehe ich einfach mal aus) untersucht werden, warum das nicht funktioniert hat und nachgebessert werden. So läuft das jedenfalls bei uns in der Firma, da habe ich einschlägige Ausfälle schon öfter untersuchen "dürfen" um Vorschläge zur künftigen Vermeidung zu machen. Nur leider war es (zumindest bei uns) immer so, dass Ausfälle nie eine einzige Ursache hatten, sondern immer etwas dazu kam, womit man nicht gerechnet hatte.

VT605 schrieb:

Wozu braucht es eigentlich noch SIM-Karten, geht das nicht auch "digital", sprich elektronisch?

Es gibt schon eSIM. Die werden zum Teil in Autos eingebaut und meines Wissen haben einige wenige gehobene Smartphones das auch drin. Die können teilweise trotzdem eine Karte aufnehmen und sind damit Dual-SIM. Technisch gibt es das schon länger, allein die Netzbetreiber wollten das nicht haben.

Zum Teil werden die Datenkarten in den Autos beim Grenzübertritt einfach umprogrammiert und sind dann Teilnehmer im ausländischen Netz. So fallen keine Roamingentgelte an. Das müssen die Netzbetreiber nämlich untereinander weiterhin zahlen.

dt8.de schrieb:Saxobav schrieb:

Saxobav schrieb:Zitat:

ich betrachte das KMC als nationale (hier deutsche) Certificate Authority (CA). Dort werden nicht nur Schlüssel ausgegeben und verwaltet, sondern ist als Teil der Publicity Key Infrastructure (PKI) auch die Gültigkeit der herausgegebenen Schlüssel abfragbar. Das ist zumindest bei normaler TLS/SSL-Verschlüsselung so.

mal davon abgesehen, dass bei normaler TLS-Verschlüsselung eine zwingende Gültigkeitsüberprüfung nur bei EV-Zertifikaten vorgeschrieben ist, der Rest Einstellungssache des Browsers ist sowie die Überprüfung der Gültigkeit nicht zwingend bei der CA erfolgen muss sondern im Zertifikat hinterlegt ist, hat man dort die Verbindung zur Zertifikatsüberprüfung als Single point of failiure erkannt und daher OCSP-stapling entwickelt. Vereinfacht dargestellt holt sich dort der Zertifikatsinhaber schon vorab die Bestätigung der Gültigkeit und liefert diese dann zusammen aus. So kann dann derjenige, der das Zertifikat überprüfen muss, auf eine sofortige Verbindung zur CA verzichten. Damit sind Verbindungsfehler/Ausfälle bis zur in der Bestätigung angegebenen Länge überbrückbar. Natürlich muss der Zertifikatsnutzer diese Bestätigung öfter erneuern als dessen Gültigkeit (Stunden bis wenige Tage) läuft.

Hallo dt8,
danke für die vertiefende Erläuterung der Handhabung bei der Bahn. Ich habe meine Handhabung bei einer größeren Verbund-Firma, wo nicht alles porentief sauber ist, gelernt. Immerhin ist alles IP-basiert. Und so habe ich den öffentlichen Begriff KMC auch eher als Platzhalter für die gesamte Infrastruktur einer CA gesehen.

Zwischen zwingender Gültigkeitsüberprüfung und fakultativer Benutzung bei Verfügbarkeit liegen auch noch Welten. Nach meiner Erfahrung funktionieren die Wege zur CRL/OCSP-Überprüfung häufig firmenintern nicht (jenseits von Kleingärtnereien). Wenn mal ein Blitz einschlagen würde und man Zertifikate zwangsweise schnell austauschen müßte (Kompromittierung), ist man Handlungsunfähig. Ersatzweise kann natürlich auch eine unbürokratische Überprüfung ins Haus kommen (bei uns BaFin), wo man das dann unter Aufsicht abarbeitet. Vorbereitend ist es eine Sisyphus-Arbeit, die wenig Anerkennung findet.

Viele Grüße, saxobav.

Saxobav schrieb:

dt8.de schrieb:Saxobav schrieb:

Saxobav schrieb:Zitat:

ich betrachte das KMC als nationale (hier deutsche) Certificate Authority (CA). Dort werden nicht nur Schlüssel ausgegeben und verwaltet, sondern ist als Teil der Publicity Key Infrastructure (PKI) auch die Gültigkeit der herausgegebenen Schlüssel abfragbar. Das ist zumindest bei normaler TLS/SSL-Verschlüsselung so.

mal davon abgesehen, dass bei normaler TLS-Verschlüsselung eine zwingende Gültigkeitsüberprüfung nur bei EV-Zertifikaten vorgeschrieben ist, der Rest Einstellungssache des Browsers ist sowie die Überprüfung der Gültigkeit nicht zwingend bei der CA erfolgen muss sondern im Zertifikat hinterlegt ist, hat man dort die Verbindung zur Zertifikatsüberprüfung als Single point of failiure erkannt und daher OCSP-stapling entwickelt. Vereinfacht dargestellt holt sich dort der Zertifikatsinhaber schon vorab die Bestätigung der Gültigkeit und liefert diese dann zusammen aus. So kann dann derjenige, der das Zertifikat überprüfen muss, auf eine sofortige Verbindung zur CA verzichten. Damit sind Verbindungsfehler/Ausfälle bis zur in der Bestätigung angegebenen Länge überbrückbar. Natürlich muss der Zertifikatsnutzer diese Bestätigung öfter erneuern als dessen Gültigkeit (Stunden bis wenige Tage) läuft.

Hallo dt8,
danke für die vertiefende Erläuterung der Handhabung bei der Bahn. Ich habe meine Handhabung bei einer größeren Verbund-Firma, wo nicht alles porentief sauber ist, gelernt. Immerhin ist alles IP-basiert. Und so habe ich den öffentlichen Begriff KMC auch eher als Platzhalter für die gesamte Infrastruktur einer CA gesehen.

Stop! Ich habe nichts von der Bahn geschrieben, sondern von TLS/SSL allgemein. Ich wollte nur das SSL-Thema richtigstellen bzw. vertiefen. Sollte hierbei der Eindruck entstanden sein, dass das bei der Bahn so sei, dann muss ich das widerrufen! Da ich nicht bei der Bahn bin, weiß ich nichts darüber.

Saxobav schrieb:

Zwischen zwingender Gültigkeitsüberprüfung und fakultativer Benutzung bei Verfügbarkeit liegen auch noch Welten. Nach meiner Erfahrung funktionieren die Wege zur CRL/OCSP-Überprüfung häufig firmenintern nicht (jenseits von Kleingärtnereien). Wenn mal ein Blitz einschlagen würde und man Zertifikate zwangsweise schnell austauschen müßte (Kompromittierung), ist man Handlungsunfähig. Ersatzweise kann natürlich auch eine unbürokratische Überprüfung ins Haus kommen (bei uns BaFin), wo man das dann unter Aufsicht abarbeitet. Vorbereitend ist es eine Sisyphus-Arbeit, die wenig Anerkennung findet.

BaFin sagt mir, dass wir aus derselben Branche sind ;-)
CRL funktioniert eh nicht, das ist in normalen Browsern nicht implemetiert. OCSP muss bei EV-Zertifikaten eigentlich funktionieren, das ist eine Voraussetzung bei EV. Und ja, wir können alle Zertifikate in wenigen Tagen tauschen. Wir waren im Sommer mit einer dreistelligen Zahl von dem Digicert-Rückruf [www.heise.de] betroffen und "durften" ausprobieren, wie wir das hinbekommen.





1-mal bearbeitet. Zuletzt am 2021:01:07:22:25:49.

Saxobav schrieb:

Zugsicherer schrieb:

Für die Schlüssel ist eine Abfrage der Gültigkeit aber in Subset-137 ohnehin nicht vorgesehen.

das könnte dann eine historische Spezifik haben.

Historisch würde ich das nicht nennen, sondern aus ETCS-Sicht nagelneu. Subset-137 gibt es erst in Baseline 3 Release 2, also in der letzten ETCS-Version. Vorher gab es nur Offline Key Management nach Subset-114 oder proprietäre Lösungen. Gut, das Dokument trägt als Erstellungsdatum den 17.12.2015, in der HInsicht ist es nicht mehr ganz frisch ...

Saxobav schrieb:

Über die GSM-Transportschicht hinaus können moderne Triebfahrzeuge natürlich IP-Verbindungen (EDGE) haben, die kryptografisch gesichert werden und damit an die KMC-Infrastruktur andocken.

Wie Du schon scheibst, wäre das dann aber kein ETCS mehr.

Carsten Frank schrieb:

Edit: gerade noch was interessantes zur Netzwerksarchitektur gefunden wo genau solch ein Fehler auch beschrieben wird
[gsmr-conference.com]

Schöner Fund!
Auf den Folien 8 und 9 sieht die Verbindung NL nach D aber recht redundant aus.
Entweder entsprechen die Abbildungen nicht den tatsächlichen Gegebenheit oder die redundante Anbindung hat nicht getan, was sie sollte.