Was passiert, wenn man weder TCP noch UDP verwendet?

• Die Netzwerkinfrastruktur besteht aus Switches, Bridges, Routern, Load Balancern, Firewalls usw.
• Das Betriebssystem steuert die Netzwerkkommunikation, indem es Pakete klassifiziert, in Queues einordnet, Firewall-Regeln anwendet usw.
• Was passiert also, wenn man ein nicht existentes Transportprotokoll verwendet?
• Lässt das OS es zu? Werden die Pakete tatsächlich zugestellt? Blockiert die Firewall sie?
• Das wurde durch ein direktes Experiment überprüft.

Überblick über Internetprotokolle

• Das Internet funktioniert so, dass Protokolle auf mehreren Schichten Daten weiterleiten.
• Wenn eine Anwendung eine Anfrage sendet, verpackt das OS sie beim Versand in Header mehrerer Netzwerkschichten.
• Transportschicht (Transport Layer): Hier befinden sich Protokolle wie TCP (6) und UDP (17).
• Was passiert, wenn man das Feld Protocol im IP-Header ändert und eine ungenutzte Nummer einträgt?

Experiment #1: Direkter Test auf meinem PC

Vorgehensweise

1. HDP (Fake-Protokoll) definieren: Entwurf eines neuen Transportprotokolls, das sich vollständig von bestehenden Protokollen unterscheidet
2. Server und Client implementieren: Entwicklung von Programmen zum Senden und Empfangen von Paketen
3. Loopback-Test: Beobachten, wie das OS Pakete intern verarbeitet

Ablauf

$ sudo cargo run --bin server  # Server starten  
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1  # Client starten  

Ergebnis

• Das OS verarbeitet HDP-Pakete normal und empfängt sie über das Loopback-Interface wieder.
• Anschließend wurden weitere Tests mit geänderter IP-Protokollnummer durchgeführt.
  • 1 (ICMP), 2 (IGMP), 6 (TCP) → Vom Server nicht erkannt
  • 50, 51 (IPSec-bezogene Protokolle) → Versand bereits auf Client-Seite blockiert
  • 256 (außerhalb des IP-Protokollnummernbereichs) → Fehler bereits beim Aufruf von socket()

Ursachenanalyse

• In manchen Fällen blockiert das OS bestimmte Protokollnummern, weil sie systemseitig reserviert sind.
• In Darwin (BSD-basiertes macOS) werden bei socket() mit protocol=0 einige Pakete automatisch gefiltert.
• IPSec-bezogene Protokolle werden aus Sicherheitsgründen wahrscheinlich blockiert.
• IPv4-Protokollnummern sind 8 Bit breit und daher nur von 0 bis 255 gültig.

Experiment #2: Paketübertragung über das Internet

Versuchsplan

1. DigitalOcean-VPS einrichten: Aufbau einer Testumgebung auf einem Cloud-Server in Frankfurt, Deutschland
2. HDP-Pakete senden: Versand von Paketen von meinem PC (Saudi-Arabien) an den DigitalOcean-Server
3. Reaktion der Netzwerkgeräte analysieren: Prüfen, ob die Pakete ankommen oder von der Firewall blockiert werden

Erwartetes Ergebnis

• Die HDP-Pakete werden normal zugestellt, oder einige ISPs bzw. die Firewall von DigitalOcean blockieren sie möglicherweise.

Tatsächliches Ergebnis

• Nur das erste Paket wurde zugestellt, danach wurden weitere Pakete blockiert
• Überprüfung mit tcpdump:
  • Auf meinem PC wurden die Pakete normal gesendet
  • Auf dem DigitalOcean-Server wurde nur das erste Paket erkannt
  • Danach wurden die Pakete irgendwo blockiert (NAT, Firewall, ISP usw.)

Ursachenanalyse

• DigitalOcean unterstützt keine nicht standardmäßigen IP-Protokolle.
• Wahrscheinlich sind die Firewall-Richtlinien des Cloud-Anbieters die Hauptursache.
• Warum nur das erste Paket ankam, ist unklar

Erneuter Test auf AWS

• Der Versuch wurde auf AWS mit zwei Instanzen erneut durchgeführt.
• Innerhalb desselben Rechenzentrums wurden HDP-Pakete normal gesendet und empfangen.
• Bei Übertragung über das Internet trat jedoch dasselbe Problem wie bei DigitalOcean auf: Nur das erste Paket kam an

Zentrale Probleme

• NAT (Network Address Translation): Arbeitet auf Basis von TCP-/UDP-Ports und hat daher keine Möglichkeit, mit neuen Protokollen wie HDP umzugehen
• Firewall-/Netzwerkfilterung: Die meisten ISPs und Cloud-Anbieter blockieren nicht genehmigte IP-Protokolle
• Optimierungsprobleme bei Netzwerkgeräten: Manche Netzwerkgeräte könnten nicht standardmäßige Pakete grundsätzlich verwerfen

Fazit: TCP und UDP zu verwenden ist die beste Wahl

• Die Implementierung der Netzwerk-Stacks unterscheidet sich zwischen Betriebssystemen
  • Das Verhalten von socket() unter Linux, macOS und Windows ist jeweils unterschiedlich
• Firewalls und NAT-Geräte blockieren nicht standardmäßige Protokolle
  • Selbst wenn es in einem privaten Netzwerk funktioniert, ist es im Internet fast unmöglich
• Kein Vorteil bei der Performance
  • Es gibt bereits erprobte Alternativen wie QUIC, das auf UDP basiert
• Verwendet TCP/UDP
  • Mit standardisierten Protokollen werden portbasiertes NAT, Firewalls, Routing usw. automatisch unterstützt

Weiteres Material

• UDP-Protokollspezifikation
• Liste der IP-Protokollnummern
• Plattformspezifische Unterschiede bei Raw Sockets

[junhochoi]

Es dürfte auch hilfreich sein, https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/ zu lesen.

[secret3056]

Ich erinnere mich noch daran, wie wir früher in StarCraft mit Hamachi Multiplayer gespielt haben und es IPX gab – damals habe ich mich wirklich gefragt, was das eigentlich ist.

[secret3056]

Wenn ich darüber nachdenke, blockiert NAT wohl alles ... Wenn sich IPv6 vollständig durchsetzt und NAT verschwindet (auch wenn das wohl nie passieren wird), könnte es vielleicht sogar möglich sein, mit einem selbst entwickelten Protokoll zu kommunizieren.

[tujuc]

Oh, ein guter Versuch ...
Der Versuch, an den Grundfesten des Netzwerks zu rütteln, war zwar gut, aber alle Netzwerkgeräte auf dieser Welt sind nur auf TCP/UDP spezialisierte Geräte ...

Solange man nicht weiß, dass Netzwerkgeräte Massenware sind ... scheint es möglich zu sein ... aber sobald man das weiß, erkennt man, dass es nicht machbar ist, es sei denn, man setzt sich selbst durch und bringt alle dazu, das eigene Protokoll zu verwenden ...

[GN⁺]

Hacker-News-Kommentare

• Es gibt SCTP, ein altes Protokoll, das TCP überlegen ist, sich aber nicht durchgesetzt hat
  • Der Grund ist, dass Netzwerkhardware alles außer TCP und UDP blockiert hat
• Als jemand, der verschiedene Transportprotokolle implementiert hat, ist das größte Hindernis beim Aufbau einer Schicht über IP nicht der WAN-Router, sondern Consumer-NAT-Geräte
  • Bei einem bestimmten Netgear-Router trat eine spezielle Beschädigung auf, bei der der Datenverkehr bis zum Ende durchkam, aber die ersten 4 Bytes zu 0 wurden
  • Es wurde zwar als TCP/UDP behandelt, stand aber vermutlich nicht auf dem tatsächlichen Übersetzungspfad
• Wenn man weder TCP noch UDP verwendet, wird Kommunikation schwierig sein
  • Das Internet basiert auf TCP und UDP als Standard
  • Es gibt viele Geräte, die andere Protokolle nicht verarbeiten können
  • Die gesamte Internet-Hardware auszutauschen würde länger dauern, als IPv4 abzuschaffen
  • Es müsste einen großen Vorteil eines neuen Protokolls geben, damit alle Unternehmen und Regierungen zu hohen Kosten Support dafür implementieren
• Das Ende des Artikels fühlt sich wie ein Cliffhanger an
  • Ich frage mich, warum nur ein einzelnes Paket des Custom-Protokolls durchkam und der Rest verworfen wurde
• Ich dachte, TCP/UDP-Pakete würden vom OS-Netzwerk-Stack nur an Prozesse weitergeleitet, die auf bestimmten Ports lauschen
  • Das könnte eine Sicherheitsfunktion sein, und nicht privilegierte Prozesse können manche Ports nicht abhören
  • Ich hätte nicht erwartet, dass ein anderer Prozess den gesamten Datenverkehr mitschneiden kann
  • Ich wusste nicht, dass man Datenverkehr mehrerer Transportprotokolle mitschneiden kann
  • Vermutlich würde der entsprechende Systemaufruf höhere Rechte erfordern
• Ich frage mich, wie Internetprotokolle und Routing-Hardware heute aussähen, wenn sie von Grund auf neu entworfen würden
  • Deutlich größere Pakete und ein grundlegendes UDP-artiges Protokoll hätten HTTP ersetzt
  • Ein einfaches Streaming-Protokoll hätte TCP ersetzt und Videowiedergabe unterstützt
  • Diese beiden Protokolle hätten den Großteil des Datenverkehrs effizienter verarbeitet
• Das ist die Annahme: „Was wäre, wenn man das Rad neu erfinden würde?“
• Man braucht Packet Sockets
  • IP-Netzwerke sollten alles weiterleiten, aber NAT ist das Hauptproblem
  • Es wäre interessant, das mit IPv6 zu versuchen
• Man hätte andere Protokolle verwendet, die es gab, bevor TCP/UDP/IP alles dominierten
• Alle hätten UUCP verwendet
  • Das hat schon vor TCP/UDP ähnliche Aufgaben erfüllt