Migrationsszenarien ISDN -> VoIP/SIP (was: 1. RfD: de.comm.geraete.isdn.* (Loeschung))

Post by Paul Muster
Man kann auch auf unbestimmte Zeit eine derzeit
aktuelle Fritzbox (z.B. 7590) im internen Netz (d.h. hinter einem
vorgeschalteten Router/Gateway/...) betreiben, die sich beim Provider
per SIP registriert und nach innen ISDN-S0 bereitstellt.

Nicht wirklich. Die "unbestimmte Zeit" des Weiterbetriebs ist begrenzt
durch den ersten irreparablen Defekt der Fritzbox. Freilich könnte man
eine Dehnung des Zeitraums erreichen durch Einlagern einer (oder gar
einiger?) Fritzboxen...

MfG
Rupert

Ignatios Souvatzis

2022-04-11 14:55:44 UTC

Post by Rupert Haselbeck

Also, wenn du wirklich ISDN über das Ende der Erhätlichkeit
traditionell erhältlicher Chipsätze (etwa als Ersatzteil zur
Reparatur deines Gerätes) hinaus sprechen willst - moderne
Mikrocontroller sollten schnell genug sein, einen S0-Bus zu bitbangen.

Das Lowlevelformat war in den Nutzerdatenblaettern des Siemens-Chipsatzes
hinreichend beschreiben, um sich aus den Leitungen den D- und die beiden
B-Kanäle herauszufischen bzw. umgekehrt aus D+2xB einen S0 zu mischen.
Sind ja bloss 144 kbit/s netto (faktisch etwas mehr, da das Framing
dazukommt - mir spuken da 160 kbit/s im Kopf herum).

Dazu dann etwas HDLC (wenn ich mich recht entsinne) auf dem D-Kanal,
der Rest ist hoehere Ebene und sollte z.B. in Asterisk aufzufinden
sein.

-is

Marc Haber

2022-04-11 16:35:14 UTC

Post by Ignatios Souvatzis
Also, wenn du wirklich ISDN über das Ende der Erhätlichkeit
traditionell erhältlicher Chipsätze (etwa als Ersatzteil zur
Reparatur deines Gerätes) hinaus sprechen willst - moderne
Mikrocontroller sollten schnell genug sein, einen S0-Bus zu bitbangen.

"Software defined Uk0". Sehr schön. Gefällt mir.

Grüße
Marc

Kay Martinen

2022-04-19 17:05:20 UTC

Interessant. Noch interessanter wären konkrete durchgeführte Projekte
damit. Links? Wenn $Provider davon aber Rückwirkungen bemerkte
(Implementationsfehler?) könnte er sagen "Der Bus ist teil unseres
Netzes = Verbotene Manipulation" oder?

Die B-Kanäle übertragen ja nur je einen Datenstrom. Die ganze
Signalisierung dazu läuft über den D-Kanal. Wenn es da
Signalisierungs-Fehler gibt dürfte das $Techniker bei $Provider stutzig
machen.

Post by Marc Haber
"Software defined Uk0". Sehr schön. Gefällt mir.

Fehlt nur noch eine 48 Volt Quelle um den "Bus" auch treiben zu können. :)

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

Thomas Einzel

2022-04-20 17:26:43 UTC

...

Post by Marc Haber
"Software defined Uk0". Sehr schön. Gefällt mir.

Fehlt nur noch eine 48 Volt Quelle um den "Bus" auch treiben zu können. :)

PoE dafür nutzen?

--
Thomas

Paul Muster

2022-04-20 18:54:21 UTC

Interessant. Noch interessanter wären konkrete durchgeführte Projekte
damit. Links?

Hat noch keiner gemacht. Du darfst Vorreiter sein.

Post by Kay Martinen
Wenn $Provider davon aber Rückwirkungen bemerkte
(Implementationsfehler?) könnte er sagen "Der Bus ist teil unseres
Netzes = Verbotene Manipulation" oder?

Hä? Welcher Bus zu welchem Provider? Du hast doch gerade nebenan
nachgelesen, dass Provider nur noch VoIP (also SIP+RTP) anbieten. Es
geht also im Kontext ganz klar um die interne Telefonie, also den
Anschluss des guten alten ISDN-Telefons.

Post by Kay Martinen
Die B-Kanäle übertragen ja nur je einen Datenstrom. Die ganze
Signalisierung dazu läuft über den D-Kanal. Wenn es da
Signalisierungs-Fehler gibt dürfte das $Techniker bei $Provider stutzig
machen.

Quatsch. Da ist kein Provider am ISDN-Bus.

Post by Marc Haber
"Software defined Uk0". Sehr schön. Gefällt mir.

Fehlt nur noch eine 48 Volt Quelle um den "Bus" auch treiben zu können. :)

Was soll das Problem sein? Du bist doch Elektriker.

mfG Paul

Kay Martinen

2022-04-21 20:06:43 UTC

Wenn $Provider davon aber Rückwirkungen bemerkte
(Implementationsfehler?) könnte er sagen "Der Bus ist teil unseres
Netzes = Verbotene Manipulation" oder?

Und den Internen S0 Bus willst du dann auch nur Intern benutzen? Weder
von "außen" angerufen werden können noch nach "draußen" telefonieren,
Faxen, Daten übertragen??? Ein Interner Bus für sich allein ist nix wert.

So wie heute Computer ohne Netzwerk als Defekt gelten könnten (Den
Spruch las ich kürzlich und fand ihn treffend). Und das Netzwerk KANN
intern sein. Aber bei den meisten dient es der WAN-Verbindung und die
ist "draußen".

Post by Kay Martinen
Signalisierung dazu läuft über den D-Kanal. Wenn es da
Signalisierungs-Fehler gibt dürfte das $Techniker bei $Provider stutzig
machen.

Quatsch. Da ist kein Provider am ISDN-Bus.

Der S0 Bus mag ja passiv sein, einen NTBA brauchte es früher dennoch.

Und wenn der nicht nur-lokal ist muß "etwas" von D-Kanal auf SIP
dolmetschen. Bei einer eigenbau-µC Lösung und nur einem Fehler darin
sehe ich hier das Potential das dem SIP-Provider eine ungültige, Falsche
oder Fehlende Signalisierung auffällt. Und dann? "der tut nix, der
wollte nur spielen" oder klemmen sie dich dann ab? SIP-Gegenstelle
antwortet nicht mehr...

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

Paul Muster

2022-04-22 03:43:28 UTC

Post by Kay Martinen
Wenn $Provider davon aber Rückwirkungen bemerkte
(Implementationsfehler?) könnte er sagen "Der Bus ist teil unseres
Netzes = Verbotene Manipulation" oder?

Du befürchtest also Implementierungsfehler beim hypothetischen
*internen* 'software defined S0-Bus', die sich auf der
SIP-Schnittstelle, die zum Provider zeigt, Auswirkungen haben? Da müsste
jemand aber ganz arg Schrott verzapfen, nicht nur beim S0-Bus, sondern
auch bei der Signalling-/Media-Gateway-Funktionalität. Klar, ist
/theoretisch/ möglich. Wird beim Test im Rahmen der Entwicklung
hoffentlich auffallen.

Post by Kay Martinen
Signalisierung dazu läuft über den D-Kanal. Wenn es da
Signalisierungs-Fehler gibt dürfte das $Techniker bei $Provider stutzig
machen.

Quatsch. Da ist kein Provider am ISDN-Bus.

Der S0 Bus mag ja passiv sein, einen NTBA brauchte es früher dennoch.
Und wenn der nicht nur-lokal ist muß "etwas" von D-Kanal auf SIP
dolmetschen. Bei einer eigenbau-µC Lösung und nur einem Fehler darin
sehe ich hier das Potential das dem SIP-Provider eine ungültige, Falsche
oder Fehlende Signalisierung auffällt. Und dann? "der tut nix, der
wollte nur spielen" oder klemmen sie dich dann ab? SIP-Gegenstelle
antwortet nicht mehr...

Quatsch. Die Provider wollen, dass die Kunden telefonieren können und
ziehen fehlerhafte Signalisierung gerade. Die klemmen niemanden ab, wenn
der nicht entweder selbst missbraucht ("Fraud") oder missbraucht wird
(auch heutzutage werden TkA "gehackt" und Rufumleitungen z.B. nach
Nigeria geschaltet).

mfG Paul

Marc Haber

2022-04-04 05:55:34 UTC

Post by Paul Muster
Irgendwann bekommt die 7590 dann keine Updates mehr, aber sie steht ja
im internen Netz und hat lediglich per SIP Kontakt zum - hoffentlich
vertrauenswürdigen - Telefonprovider.

RTP kann direkt mit einer (nicht notwendigerweise vertrauenswürdigen)
Gegenstelle geprochen werden, das halte ich für nicht ungefährlich.

Grüße
Marc

Paul Muster

2022-04-04 12:31:07 UTC

RTP kann direkt mit einer (nicht notwendigerweise vertrauenswürdigen)
Gegenstelle geprochen werden, das halte ich für nicht ungefährlich.

Das ist bei keinem großen deutschen Provider üblich, denn wäre es so,
könnte dieser die Anforderungen bzgl. Lawful Interception/G19
("Abhören") nicht erfüllen:
Eine der Anforderungen ist, dass der Betroffene die Maßnahme nicht
bemerken kann, somit leiten alle Provider immer RTP über ihre SBCs - und
erstellen dort ggf. die Kopie des Datenstroms für die Behörde. Würde der
Provider den RTP-Strom direkt von Kunde zu Kunde ermöglichen, könnte der
von einer Maßnahme Betroffene bemerken, wenn sich das plötzlich ändert
(d.h. der RTP-Strom über den Provider geführt wird), und daraus
ableiten, dass er eben gerade Betroffener einer Abhörmaßnahme ist.

(Obiges gilt und greift natürlich dann nicht, wenn Leute ohne Nutzung
von Providern direkt zwischen Fritzboxen telefonieren (also
***@fritzbox1.dyndns.tld mit ***@fritzbox2.dyn.tld, ggf. unterstützt
durch public ENUM e164.arpa). Aber das ist sehr sehr selten.)

mfG Paul

Marc Haber

2022-04-04 13:57:34 UTC

RTP kann direkt mit einer (nicht notwendigerweise vertrauenswürdigen)
Gegenstelle geprochen werden, das halte ich für nicht ungefährlich.

Das ist bei keinem großen deutschen Provider üblich, denn wäre es so,
könnte dieser die Anforderungen bzgl. Lawful Interception/G19
Eine der Anforderungen ist, dass der Betroffene die Maßnahme nicht
bemerken kann, somit leiten alle Provider immer RTP über ihre SBCs - und
erstellen dort ggf. die Kopie des Datenstroms für die Behörde. Würde der
Provider den RTP-Strom direkt von Kunde zu Kunde ermöglichen, könnte der
von einer Maßnahme Betroffene bemerken, wenn sich das plötzlich ändert
(d.h. der RTP-Strom über den Provider geführt wird), und daraus
ableiten, dass er eben gerade Betroffener einer Abhörmaßnahme ist.

Aber größere VoIP-Plattformen haben durchaus mehrere (hunderte?) SBCs,
die müsste man alle einzeln berücksichtigen wenn man RTP nicht
generell freischalten möchte.

Post by Paul Muster
(Obiges gilt und greift natürlich dann nicht, wenn Leute ohne Nutzung
von Providern direkt zwischen Fritzboxen telefonieren (also
durch public ENUM e164.arpa). Aber das ist sehr sehr selten.)

Das müsste man tatsächlich mal probieren ;-) Gibt es da Webseiten mit
Anleitung?

Grüße
Marc

Paul Muster

2022-04-04 14:49:34 UTC

RTP kann direkt mit einer (nicht notwendigerweise vertrauenswürdigen)
Gegenstelle geprochen werden, das halte ich für nicht ungefährlich.

Das ist bei keinem großen deutschen Provider üblich, denn wäre es so,
könnte dieser die Anforderungen bzgl. Lawful Interception/G19

G 10, sorry. https://de.wikipedia.org/wiki/Artikel_10-Gesetz

Post by Paul Muster
Eine der Anforderungen ist, dass der Betroffene die Maßnahme nicht
bemerken kann, somit leiten alle Provider immer RTP über ihre SBCs - und
erstellen dort ggf. die Kopie des Datenstroms für die Behörde. Würde der
Provider den RTP-Strom direkt von Kunde zu Kunde ermöglichen, könnte der
von einer Maßnahme Betroffene bemerken, wenn sich das plötzlich ändert
(d.h. der RTP-Strom über den Provider geführt wird), und daraus
ableiten, dass er eben gerade Betroffener einer Abhörmaßnahme ist.

Aber größere VoIP-Plattformen haben durchaus mehrere (hunderte?) SBCs,
die müsste man alle einzeln berücksichtigen wenn man RTP nicht
generell freischalten möchte.

"RTP nicht generell freischalten"? Wohin RTP gesendet bzw. von wo RTP
empfangen wird, wird per SDP mitgeteilt (c-line). Diese Info kommt von
den SBCs des Providers, die man - vgl. Nutzung von Google/Android- oder
Apple-Handys - definitiv als vertrauenswürdig ansehen muss, wenn man sie
nutzt.

Es gibt somit kein Szenario (oder ich sehe zumindest aktuell keines),
bei dem die fragliche, nicht mehr mit Updates versorgte Fritzbox mit
nicht vertrauenswürdigen Systemen per SIP und/oder RTP kommuniziert.

Gewisse Einbußen bei der Sicherheit könnten zum Tragen kommen, wenn
irgendwann seitens der Provider neue, sehr starke
Verschlüsselungsalgorithmen/Ciphers möglich werden, die die "alte"
Fritzbox nicht mehr kann, wodurch sie ältere, eher angreifbare Verfahren
nutzen muss.
Aber da stellt sich mMn sehr die Frage, wie realistisch ein Angriff auf
SIP/TLS und SRTP eines Endkundenanschlusses ist oder ob da nicht andere
Methoden (Wanze vor Ort) eingesetzt würden.

Das müsste man tatsächlich mal probieren ;-) Gibt es da Webseiten mit
Anleitung?

<https://wiki.zebradem.com/wiki/index.php?title=Fritzbox:_Anonyme_SIP-Adresse>
Keine Ahnung, ob das heute noch so geht. Insbesondere die Manipulation
der voip.cfg über telnet - fraglich.

mfG Paul

Kay Martinen

2022-04-19 16:57:56 UTC

RTP kann direkt mit einer (nicht notwendigerweise vertrauenswürdigen)
Gegenstelle geprochen werden, das halte ich für nicht ungefährlich.

Das ist bei keinem großen deutschen Provider üblich, denn wäre es so,
könnte dieser die Anforderungen bzgl. Lawful Interception/G19

G 10, sorry. https://de.wikipedia.org/wiki/Artikel_10-Gesetz
Aber da stellt sich mMn sehr die Frage, wie realistisch ein Angriff auf
SIP/TLS und SRTP eines Endkundenanschlusses ist oder ob da nicht andere
Methoden (Wanze vor Ort) eingesetzt würden.

Optimist! Ich werde ja das Gefühl nicht los werden das die gesamte VoIP
Technik vor allem zu zwei Zwecken propagiert wird (und die Alte folglich
obsolet zu werden hat).

1. Zentralisierung durch Software.
2. Dadurch möglich werdende Einfache Massenüberwachung - durch Software.

Öffentlich wird da natürlich nur von den Vorzügen geredet die es bringen
soll und maximal eingestanden das man die Teure und Veraltende Hardware
in den Vermittlungen dadurch entfernen könnte. Was zugleich ja auch
wieder als Argument Pro Innovativer Techniken die dann möglich sind
kolportiert wird. Welche das wohl sein werden...

"Wanze vor Ort" ist der Klassische Ansatz aus Analog-Zeiten als
Leitungen noch knackten und Knirzten wenn da ein Lauscher mit dran hing. ;-)

Das will doch heute eh keiner mehr bezahlen und die Unfähigkeit solches
zu tun scheint mir auch an zu steigen.

Ich sehe da eher einen Globalen (nicht nur DE & EU) Trend hin zur
Konzentration von Kontrolle & Überwachung.

Und da die Geld-/Macht-gierigen und möchtegern-Diktatoren nicht
aussterben kann das leicht zu einem Big-Brother Staat führen wo Macht
durch Kontrolle und Geld durch Gier erzeugt wird.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

Thomas Einzel

2022-04-20 17:29:34 UTC

...

Post by Paul Muster
G 10, sorry. https://de.wikipedia.org/wiki/Artikel_10-Gesetz
Aber da stellt sich mMn sehr die Frage, wie realistisch ein Angriff auf
SIP/TLS und SRTP eines Endkundenanschlusses ist oder ob da nicht andere
Methoden (Wanze vor Ort) eingesetzt würden.

Die TLS Verbindung ist nicht bei jeweiligen Provider terminiert?

Post by Kay Martinen
Optimist! Ich werde ja das Gefühl nicht los werden das die gesamte VoIP
Technik vor allem zu zwei Zwecken propagiert wird (und die Alte folglich
obsolet zu werden hat).
1. Zentralisierung durch Software.
2. Dadurch möglich werdende Einfache Massenüberwachung - durch Software.

Seit spätestens 1998 (seit es Call by Call und Preselection gibt) ist
das prinzipiell Geschichte, es wird mit IP Telefonie über die Provider
nur einfacher.

Soweit ich gehört habe, sind allein die Wartungskosten der alten
digitalen Vermittlungsstellen *so* hoch, dass das mit dem kleiner
gewordenen Festnetz-Gesprächen nicht mehr bezahlbar wäre. Dazu kommt
dass rangieren an den Verteilern nur per Hand (mit Fahrtaufwand und
hohen Personalkosten) möglich war. Angeblich soll ja Big-T vor einigen
Jahren u.a. viele Fernmeldemonteure - ähm - Personal-umgebaut haben, man
VTS.
...

Post by Kay Martinen
Ich sehe da eher einen Globalen (nicht nur DE & EU) Trend hin zur
Konzentration von Kontrolle & Überwachung.

In Israel z.B. soll wohl "nicht am Telefon!" schon immer üblich sein,
aber vielleicht habe ich das auch nur falsch verstanden.

--
Thomas

Paul Muster

2022-04-20 18:43:53 UTC

Die TLS Verbindung ist nicht bei jeweiligen Provider terminiert?

Doch, klar, sonst könnte der seinen Verpflichtungen bzgl. LI ja nicht
nachkommen.
Es ging darum, welches Szenario eines Angriffs durch Dritte(!) von einer
Fritzbox mit veralteter Firmware, die moderne Ciphers oder
Hashalgorithmen ggf. irgendwann nicht mehr kann, begünstigt wird.

Seit spätestens 1998 (seit es Call by Call und Preselection gibt) ist
das prinzipiell Geschichte, es wird mit IP Telefonie über die Provider
nur einfacher.

Welches "das" ist seitdem Geschichte?

Post by Thomas Einzel
Soweit ich gehört habe, sind allein die Wartungskosten der alten
digitalen Vermittlungsstellen *so* hoch, dass das mit dem kleiner
gewordenen Festnetz-Gesprächen nicht mehr bezahlbar wäre.

Gut möglich. Die Leute, die noch an EWSD-Baugruppen herumzulöten bereit
sind (um diese zu reparieren), wollen dafür richtig viel Schmerzensgeld.
Zu Recht mMn.
Und auf der anderen Seite vertickt der Vertrieb überall
Festnetzflatrates!!1111elf ;-)

mfG Paul

Thomas Einzel

2022-04-21 18:53:54 UTC

Die TLS Verbindung ist nicht bei jeweiligen Provider terminiert?

Doch, klar, sonst könnte der seinen Verpflichtungen bzgl. LI ja nicht
nachkommen.

Und damit ist es bezüglich der end2end TLS Verbindungs-Integrität *)
äquivalent zum MITM. *)Es gibt keine.

Post by Paul Muster
Es ging darum, welches Szenario eines Angriffs durch Dritte(!) von einer
Fritzbox mit veralteter Firmware, die moderne Ciphers oder
Hashalgorithmen ggf. irgendwann nicht mehr kann, begünstigt wird.

Achso, ja, IMO auch ein Thema, aber ein anderes.

Seit spätestens 1998 (seit es Call by Call und Preselection gibt) ist
das prinzipiell Geschichte, es wird mit IP Telefonie über die Provider
nur einfacher.

Welches "das" ist seitdem Geschichte?

die zentralisierte G10 Telefon-Überwachung ohne Kabel anklemmen u.ä.

"Geschichte" im Sinne von realisiert, dafür war IP Telefonie nicht nötig

--
Thomas

Paul Muster

2022-04-21 19:07:52 UTC

Post by Thomas Einzel
Die TLS Verbindung ist nicht bei jeweiligen Provider terminiert?

Doch, klar, sonst könnte der seinen Verpflichtungen bzgl. LI ja nicht
nachkommen.

Und damit ist es bezüglich der end2end TLS Verbindungs-Integrität *)
äquivalent zum MITM. *)Es gibt keine.

Ja, korrekt. Aber hatte denn irgendwer behauptet, SIP-Telefonie über dt.
Provider umfasse Ende-zu-Ende-Verschlüsselung, sodass du das widerlegen
zu müssen glaubst?

Post by Paul Muster
Es ging darum, welches Szenario eines Angriffs durch Dritte(!) von
einer Fritzbox mit veralteter Firmware, die moderne Ciphers oder
Hashalgorithmen ggf. irgendwann nicht mehr kann, begünstigt wird.

Achso, ja, IMO auch ein Thema, aber ein anderes.

In der Tat ein anderes Thema, allerdings *das* Thema, um das es eben
ging: Die TLS-Verschlüsselung der SIP-Kommunikation mit dem Provider und
deren Schutz gegen Dritte.

Post by Thomas Einzel
Seit spätestens 1998 (seit es Call by Call und Preselection gibt) ist
das prinzipiell Geschichte, es wird mit IP Telefonie über die
Provider nur einfacher.

Welches "das" ist seitdem Geschichte?

die zentralisierte G10 Telefon-Überwachung ohne Kabel anklemmen u.ä.

Ah, ok.

Post by Thomas Einzel
"Geschichte" im Sinne von realisiert, dafür war IP Telefonie nicht nötig

Jap, sagte ich ja. War auch bei der EWSD schon umfassend möglich.

mfG Paul

Paul Muster

2022-04-20 18:37:45 UTC