Fefes Blog

Fragen? Antworten! Siehe auch: Alternativlos

Sun Jun 7 2009

• [l] Für Techniker habe ich ein Leckerli heute: Die Abhörspec der Bundesnetzagentur. Guckt euch das mal an. Das hat alles widerliche auf Erden. RFC2822, ASN.1, XML, TLV, und das Protokolldesign ist unterirdisch. Und all die Komplexität ist "mandatory", muss also implementiert werden. Das kriegen die mit Sicherheit nicht hin, schon gar nicht wenn die üblichen Spezialexperten (*hust* T-Systems *röchel* accenture *spuck*) das implementieren sollen.

  Spannend wird es z.B. auf Seite 17, wo man die Formeln für das Sizing findet. Mal 5000 Kunden angenommen, soll ein Anbieter folgende Abhörkapazitäten anbieten: Festnetz: 3%. GSM: 27%. Für diese Werte nimmt man die Formeln von Seite 17, und rechnet die erwartete Ausnutzung des Netzes aus, indem man den sogenannten Verkehrswert in Erlang (ich habe meine Zahlen von hier) mit der Anzahl der Anschlüsse multipliziert (bei Festnetz geht die Rechnung in B-Kanälen, von denen jeder ISDN-Kunde zwei hat).

  Spannenderweise ist die Formel nicht linear sondern ungefähr wie die Quadratwurzel, so dass kleine Anbieter stark benachteiligt werden. Hier ist mal ein Plot für GSM nach Kundenanzahl (Achtung: bei mir beginnt die Y-Achse da nicht bei 0 sondern bei 2, das wird nicht wirklich negativ). Der Wert an der Y-Achse ist der Prozentsatz des Traffics, für den sie Ausleit-Kapazitäten halten sollen. Man sieht sehr gut, wie unfair das verteilt ist.

  Auch lustig ist Seite 26 mit der Liste der zulässigen Anbieter für das IPsec-Gateway. Die Liste ist eher übersichtlich.

  Aber zu dem Protokolldesign. Für die Übertragung der Daten supporten die FTP (hahaha) und FTAM (HAHAHAHAHA). Da ist ja schon mal aus Obskuritätsgründen so gut wie ausgeschlossen, dass da die Fehler gefunden wurden, und dann stehen da noch so Dinge dran wie

  Der Initiator soll die QoS-Klasse 0 verwenden, da der Responder die Recovery-Prozeduren nicht unterstützt

  Alles sehr vertrauenswürdig. Die haben da ASN.1 als Basis für den Bulk ihres Protokolls, übertragen aber die Nutzdaten alle als ASCII-Strings. Z.B. gibt es da eine Notification, in der optional (!!) auch das Ziel der Überwachungsmaßnahme benannt wird, zu der gerade die Notification reinkommt, und das ist ein ASCII-String der Maximallänge 256. Das ist nicht schlau, da Email-Adressen schon 320 Zeichen lang werden können. Warum ist der optional (Seite 29)?

  -- Aus Gründen der Rückwärtskompatibilität als optional

  Aber auch Datum, Uhrzeit und optionale zusätzliche Nachrichtenteile werden per in-band-signaling als ASCII übertragen (das Datum humoristischerweise nicht Y2K compliant als TT/MM/JJ). Besonders grob wird das dann auf Seite 44, "Anlage B.2.5 Zuordnungsnummer". Pro Vorgang innerhalb einer Schnüffelanordnung gibt es eine Zuordnungsnummer, wenn sie z.B. den Wiefelspütz überwachen würden wäre das dann eine Nummer pro Telefongespräch. Die Nummer wird auch als ASCII übertragen (OH DIE SCHMERZEN!!), und hat einen Wertebereich von 1 bis 65535. Wenn ich also glaube, dass ich überwacht werde, rufe ich einfach 65535 Mal von meinem Telefon aus eine 0800 Nummer an, z.B. die Störungsstelle oder die Korruptionshotline des LKA Westfalen, und schon ist dieses Feld übergelaufen und weitere Telefonate können nicht mehr abgebildet werden. Bei Protokolldesignern, die sowas verbrechen, ist die Grenze erreicht, bei der man noch einen Freitod anbietet. Aber wartet, wird noch besser! Gut, dass sie das als ASCII schicken, denn so konnten sie es wie folgt erweitern:

  Zusätzlich (optional) kann von der TKA-V eine weitere Nummer hinzugefügt werden (z. B. in Mobilfunknetzen die Kennung der MSC), die zusammen mit der Zuordnungsnummer die Eindeutigkeit garantiert. Diese zweite Nummer hat Werte von 0 bis 65535. Wird von der TKA-V diese Variante genutzt, ist die zweite Nummer getrennt durch das Zeichen ‘#’ hinter die Zuordnungsnummer zu setzen.

  Da fällt die Unterdrückung des Brechreizes nicht leicht. Und wo wir gerade bei Freitod waren (Seite 30):

  common [4] CommonMode OPTIONAL,
  -- moduls of the manufactures
      alcatel [5] OCTET STRING (SIZE (1..256)) OPTIONAL,
    -- the manufacturer has to provide an ASN.1 Specification
      ericsson [6] OCTET STRING (SIZE (1..256)) OPTIONAL,
    -- the manufacturer has to provide an ASN.1 Specification

  und so geht das munter weiter. So, liebe Leser, macht man es NICHT. Pfusch am Bau. Das läßt die ganze Branche schlecht aussehen, wenn Einzelne sowas verbrechen.

  Ganz großes Kino auch folgender Abschnitt von Seite 41:

  Authentifizierung bei der berechtigten Stelle

  Die technische Einrichtung der bS überprüft, ob die Rufnummer der TKA-V (Anschlussnummer an das Transitnetz), die im Informationselement ‘Calling Party Number’ übertragen wird, gültig ist. Daher darf die TKA-V zum Aufbau der Verbindungen zur bS nicht das Dienstmerkmal ‘Calling Line Identification Restriction’ nach ETS 300 090 [4] benutzen.

  Ein echter Schenkelklopfer! Und das waren nur die bis Seite 60. Das Dokument hat 180 Seiten. Viel Spaß beim Schmökern! Für Unterhaltung ist gesorgt. Und so gilt mal wieder, was auch sonst schon immer gegolten hat: die Inkompetenz der Unterdrücker ist der beste Schutz vor dem Unterdrückungsstaat. Prost!