Orchestrator/bahn/project-audit/data/confluence-export/pages/503112239_2025-10-27 Technische Bewertung Mail von IRFP.md

2025-10-27 Technische Bewertung Mail von IRFP

Confluence Page ID: 503112239 Version: 5 Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2025-10-27 Technische Bewertung Mail von IRFP Labels: meeting-notes

---

Teilnehmer

•  
•  
•  

Ziele

• Verständnis schaffen
• Technische Analyse 
• Einschätzung/Bewertung (für TTT)

Inhalt der Anfrage

ich beziehe mich auf ein Gespräch mit Ihnen, Herr Dello, von Anfang Juli sowie Ihre Nachfragen, Herr Kleinsteuber, vom 22.-30. September. Es ging dabei meinem Verständnis nach um eine Firewall-Regel der DB InfraGO AG, die wohl bewirkt, dass auf eingehende TTT-Nachrichten mit HTML geantwortet wird, wenn die eingehende Nachricht ein Null-Byte enthält. Auslöser der Gespräche waren vereinzelte "verschwundene" und/oder mit HTML beantwortete Nachrichten (Trassenanmeldungen) von iRFP.

Uns ist vor wenigen Tagen in völlig anderem Zusammenhang bei einem anderen Projekt bewusst gemacht worden, dass XML-Daten unter Umständen durchaus und möglicherweise sogar regulär Null-Bytes enthalten können. Ich möchte Ihnen diese Erkenntnis aus dem oben gegebenen Anlass nicht vorenthalten. An der konkreten Situation von TTT-Nachrichten hat sich unsererseits nichts geändert - es gibt kein uns bekanntes neues Auftreten und aus unserer Sicht keinen zwingenden Handlungsbedarf.

Die Erkenntnis betrifft Kommentare in XML-Daten: Scheinbar erfordert der XML-Standard keine spezielle Codierung von XML-Kommentaren. Insbesondere müssen sich Kommentare scheinbar nicht an die Codepage (encoding) des einleitenden XML-Tags halten (bei XML-Daten im TTT-Kontext wäre das m. E. immer UTF-8). TTT-XML-Kommentare müssen also möglicherweise nicht UTF-8-codiert sein. In der m. E. diesbezüglich entscheidenden Quelle https://www.w3.org/TR/xml/#sec-comments wird sogar ausdrücklich genannt: "They are not part of the document's character data".

Falls in einer im Allgemeinen UTF-8-codierten XML-Datenstruktur ein Kommentar regelkonform vorkommen darf, der UTF-16-codierten Text enthält, könnte das vielleicht erklären, dass tatsächlich mit Nullen im Datenstrom gerechnet werden müsste. (Ungeachtet dessen müssten Null-Bytes m. E. auch in eventuellen CDATA-Blöcken zulässig sein.) Zu bedenken wäre in dem Zusammenhang wohl auch, dass Kommentare nicht zwingend vom Programmierenden "hart-codiert" sein müssen. Sie könnten durchaus etwa zum leichteren Debugging auf Datenquellen der XML-Inhalte verweisen, z. B. auf Dateinamen oder Eingaben des Anwendenden, der die Daten (in unserem Kontext: die Trassenanmeldung) erzeugt hat. Microsoft Windows ist im Umfeld von Endanwendenden ein weit verbreitetes Betriebssystem und arbeitet inzwischen vollständig auf UTF-16-Basis. Ich könnte mir gut vorstellen, dass Kommentarinhalte aus einer solchen Umgebung leicht UTF-16-codiert sind. Und ("dummer Weise"?) zwingt scheinbar kein Standard einen Programmierer, das umzucodieren - auch nicht der TTT-Standard.

Ich möchte klarstellen, dass das alles auch für uns weit hergeholt klingt, durchaus unerwartet ist und wir nicht sicher sein können, ob es richtig interpretiert ist. Wir haben keine XML-Autorität dazu befragt und sind selbst auch keine. Im XML-Standard wird aber meiner Meinung nach auffallend regelmäßig Formulierungen wie "all XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode" zu finden. Und wenn o. g. Zusammenhänge zutreffen, wäre es möglicherweise nicht vermeidbar, sondern jederzeit zu erwarten, dass reguläre XML-Daten (Trassenanmeldungen) mit Kommentaren mit 0-Bytes eintreffen - und sei es nur etwa aus einem ausländischen Kontext (Spracheinstellung/Zeichencodierung) heraus.

Es kommen daher Zweifel bei uns auf, ob ein pauschales Ablehnen von XML-Daten mit Nullen tatsächlich regelkonform ist, wenn keine Regel solche Nullen wirklich ausschließt. Zumindest sollte vielleicht doch nicht mit HTML darauf reagiert werden (da HTML als Antwort auf TTT-Nachrichten m. E. nirgendwo regelkonform ist), sondern z. B. mit einer TTT-Error-Message?

Sofern gewünscht, können wir testweise eine Trassenbestellung mit einem UTF-16-codierten Kommentar (also mit Null-Bytes im Kommentar) senden.

Fragestellungen / Analyse

Unterstützen wir das? Haben wir - oder die RNE - evtl. irgendwo sogar hingeschrieben, dass wir UTF-8 erwarten? War der Bereich im XML Dokument der IRFP entsprechend ausgezeichnet? Kann die Inklusion von UTF-16 codierten Abschnitten tatsächlich zu null bytes im HTTP Request führen? → UTF-16 hat Null Bytes, aber die Inklusion an sich ist nicht möglich/zulässig Wieso sollten Eingaben von Endanwendern in XML-Kommentaren enden (unabhängig davon wie diese - z.B. unter Windows - eingeben werden)? XML-Kommentare haben keinerlei Relevanz und werden seitens der InfraGo nicht ausgewertet. ...

Einschätzung / Antworten

Dreistufige Bewertung/Einschätzung:

Grundsätzlich ist gemäß ERA und InfraGo-Spec immer UTF-8 zu verwenden. Das steht sehr klar in den Specs von ERA und InfraGo. Die Ablehnung abweichender Requests (mit UTF-16 etc.) ist also korrekt. 

Das in der Mail präsentierte Szenario (mit UTF-16-Inhalten innerhalb eines UTF-8-Dokumentes) ist aus mehreren Gründen technisch nicht valide.

Unabhängig davon: die betroffene FW-Regel ist nicht "in Stein gemeißelt" und kann daher kein einführungsverhinderndes Problem werden.

Stufe 1: UTF-8 ist gemäß Spec(s) zwingend zu verwenden

Die ERA schreibt UTF-8 zwingend als einzige zulässige Codierung für die Nachrichten vor. Siehe https://www.era.europa.eu/system/files/2023-06/ERA_Technical_Document_TAF-TD-104_D_2_Appendix_E.pdf

Auch bei der InfraGo ist die Schnittstellenspezifikation CI da sehr deutlich: https://www.dbinfrago.com/resource/blob/13508606/d05beb056bb40ea1237afe577c5c929a/Anlage-2-Technische-Funktionsbeschreibung-data.pdf "Bitte verwenden Sie zur Kodierung der XML-Daten ausschließlich den Unicode Zeichensatz UTF8 und geben Sie dies entsprechend im XML-Header an. Siehe [1] Kapitel 5.2.2. Die Verwendung abweichender Zeichensätze ist ausgeschlossen und führt zur technischen Zurückweisung der Nachricht."

Stufe 2: Von IRFP genannter Usecase (UTF-16 als Encoding für XML-Kommentare innerhalb eines UTF-8 Dokumentes) ist nicht zulässig

Grundsätzlich: Da die XML-Kommentare teil der SOAP Nachricht wären müssten diese gemäß ERA- und InfraGo-Vorgaben (siehe oben) auch UTF-8 codiert sein. Die genannte Problematik kann unserer Einschätzung nach daher in der Praxis nicht auftreten. Weiteres zur Invalidität des Szenarios:

• Es ist erst einmal nicht nachvollziehbar, dass Nutzereingaben in die EVU-seitige Software überhaupt in XML Kommentaren in den Requests an die InfraGo enden sollten. XML Kommentare werden von der DB InfraGo nicht ausgewertet, EVU-interne Kommentare sollten unseres Erachtens nicht an uns geschickt werden.
• Der XML-Standard lässt hier nur ein Encoding pro XML Dokument zu. Kommentare in UTF-16 in einem UTF-8 Dokumente sind schon daher nicht zulässig. Der Standard schreibt hier sehr klar vor, dass es keine zwei unterschiedlichen Encoding-Deklarationen in einem Dokument geben darf, dafür bräuchte es ja u.a. eine weitere Deklaration, was nicht zulässig ist: "The text declaration MUST NOT appear at any position other than the beginning of an external parsed entity. "
• Ergänzend: Da wir SOAP über HTTP verwenden, ist zwingend erforderlich, dass der gesamte Request das gleiche Encoding hat, da die Angabe des Content-Type auf HTTP-Ebene erfolgt. Das geforderte Encoding (s.o.) für die Nachricht ist UTF-8 und gilt für den gesamten Payload. Eine Mischung von Encodings in einer SOAP-Nachricht ist schon aus diesem Grund kein valides Szenario.  Hinweis: in den im Sommer analysierten Requests wurde seitens IRFP immer explizit UTF-8 gesetzt ("Content-Type: text/xml; charset="utf-8"), das steht so in den Firewall-Logsauszug.
• Wir vermuten hier auch eine fehlende Interpretation des XML-Standards durch IRFP: Die Aussage ""They are not part of the document's character data". in der XML-Spec bedeutet nach unserer Lesart lediglich, dass Kommentare in Abgrenzung von Character Data als Markup zu betrachten sind. Siehe Abschnitt 2.4, dort heißt es: "Definition: Markup takes the form of start-tags, end-tags, empty-element tags, entity references, character references, comment,....." An keiner Stelle wird hier erkennbar, dass gemäß XML Spec ein anderes Encoding zulässig wäre.  Auf den von IRFP genannten Vorschlag, uns einen Testrequest mit UTF-16-Inhalten zu schicken können wir unter Verweis auf die Spezifikationen der ERA und der InfraGo gerne verzichten, das erwartete Ergebnis gemäß Spec ist ja eben genau, dass wir diesen ablehnen.

Stufe 3: FW-Regeln können eigentlich nicht einführungsverhindernd wirken

(Weichmacher - brauchen wir den)? Da sie in kritischen und begründeten Fällen anpassbar sind 

• Wir behalten uns vor - nach eingängiger Prüfung gegen Security-Aspekte und genauer Abwägung - die hier betroffene und ggf. auch andere FW-Regel zu deaktivieren, falls gravierende Probleme mit Requests von Consumern auftauchen, die Consumer nicht zu vertreten haben. 
• So bleiben wir handlungsfähig falls solche Probleme auftreten sollten. Dies wird aber immer die Ausnahme sein. 
• Der Kundentest hat jedoch mit keinem einzigen Consumer Hinweise geliefert, dass es ein Problem mit der Firewall geben würde. Die singulären abgelehnten Requests bei IRFP konnten IRFP-seitig nicht analysiert oder der InfraGo zur Analyse bereitgestellt werden. Sie sind seitdem auch nicht mehr aufgetreten.