Zusammenfassung

  • Der IETF-Entwurf beantragt UDP-Port 8738 als gemeinsamen Multicast-Zugang, definiert eine ASM-Anwendung aber über die Zielgruppe und eine SSM-Anwendung über Quelle und Zielgruppe zusammen.
  • Eine reine Portfreigabe bezeichnet deshalb nicht die zugelassene Anwendung. Ein lokaler Multicast-Zulassungsbeleg kann Selektor, Hostverhalten, Sicherheit und Lebenszyklus beweisbar verbinden.

Portnummern sind beliebte Stellvertreter. Sie machen eine Anwendung in einer Firewall, einem QoS-Profil oder einem Inventar scheinbar mit einem Feld sichtbar. draft-ietf-intarea-multicast-application-port-08 will bei Multicast gerade die Kosten dieser Zuordnung verringern. Statt jeder Anwendung oder jeder Verwendung eines Protokolls einen eigenen Port zu geben, beantragt der Entwurf UDP 8738 mit dem Dienstnamen multicast-app.

Der gemeinsame Port spart Registrierung, weil die Unterscheidung bereits anderswo stattfindet. Bei Any-Source Multicast identifiziert die Multicast-Zieladresse die Anwendung. Bei Source-Specific Multicast besteht der Identifikator aus Unicast-Quelladresse und Multicast-Zieladresse. Port 8738 schafft einen mit vorhandenen Stacks und Socket-APIs kompatiblen Treffpunkt; er ist nicht selbst der Anwendungsname.

Damit entsteht eine klare Arbeitsteilung. Das globale Register hält nur den gemeinsamen technischen Nenner. Es muss nicht wissen, welche Organisation welche Gruppe zu welchem Zweck nutzt. Die lokale Zulassung darf diese Informationen aber nicht ebenfalls verwerfen. Sie muss Quelle, Gruppe, Geltungsbereich, Schnittstelle, VRF, Eigentümer und Widerruf erhalten.

Wenn die Regel enger klingt, als sie tatsächlich ist

Angenommen, Telemetrie, Discovery und Medienverteilung benutzen im gleichen Netz 8738. Eine Firewallregel, die nur den Zielport prüft, lässt alle drei Anwendungen zu. Ein QoS-Klassifikator gibt ihnen die gleiche Behandlung. Ein Alarm mit Portangabe kann nicht sagen, welcher Kanal betroffen ist. Die Regel funktioniert technisch, doch ihr Label täuscht eine Anwendungsgrenze vor, die es nicht gibt.

Der Sicherheitsabschnitt des Entwurfs benennt das Problem: Eine Regel für den Multicast Application Port ohne Berücksichtigung der Multicast-Zieladresse erfasst alle Anwendungen an diesem Port und ist zu weit. Im laufenden IESG-Ballot wird die Grenze für SSM noch präziser diskutiert. Der Entwurf definiert SSM über Quelle und Ziel, während einzelne Filterhinweise nur das Ziel erwähnen. Eine Stellungnahme verlangt deshalb die Quelle auch für Anwendungs- und Firewallfilter und weist darauf hin, dass Netzwerkklassifikatoren wie QoS Kriterien jenseits des Ports brauchen.

Diese Stellungnahme ist kein verabschiedeter Standard. Revision 08 erschien am 19. Juli 2026. Das Dokument ist weiterhin ein Internet-Draft der INTAREA-Arbeitsgruppe, mit angestrebtem Status Proposed Standard, in IESG-Evaluation und mit angeforderter Überarbeitung. Der Ballot-Eintrag belegt eine offene Prüfung, keinen Produktionsfehler und kein endgültiges Ergebnis.

Die belastbare Aussage bleibt enger: Eine Portregel belegt die Freigabe des gemeinsamen Transportzugangs. Sie belegt nicht die Freigabe einer bestimmten ASM-Gruppe oder eines bestimmten SSM-Kanals.

Dieselbe Netzregel kann zwei verschiedene Hostgrenzen verbergen

Die gemeinsame Nutzung verlangt nicht-exklusive Socket-Bindings. Ein konformer Host muss Anwendungen dazu zwingen; in POSIX-ähnlichen Umgebungen geschieht das mit Optionen wie SO_REUSEADDR oder SO_REUSEPORT. Er soll außerdem Wildcard-Bindings an diesem Port verhindern, Nicht-Multicast-Sendungen blockieren und eingehenden Nicht-Multicast-Verkehr mit diesem Port verwerfen.

Da bestehende Plattformen diese Regeln nur schrittweise übernehmen werden, definiert der Entwurf auch Pflichten für Anwendungen auf nicht konformen Hosts. Sie dürfen andere Anwendungen nicht vom Port ausschließen und müssen Datagramme für fremde Gruppen verwerfen. Bei SSM gehört gemäß dem Identitätsmodell auch die Quelle zur Abgrenzung.

Hinter derselben Firewallregel kann daher einmal der Kernel und einmal die Anwendung die entscheidende Filterung leisten. Ein Plattformwechsel, Container-Umzug oder Bibliotheksupdate kann diese Verantwortung verändern, ohne dass der Netzwerkselektor anders aussieht. Die Angabe „nutzt 8738“ reicht für ein kontrollierbares Inventar nicht aus.

Der Entwurf verweist auf Prototypen für Linux, macOS und Windows, die eine ausgewählte Gruppe empfangen und Nachrichten einer anderen Gruppe nicht anzeigen. Der Implementierungsabschnitt begrenzt die Aussagekraft ausdrücklich: Die Angaben stammen von Mitwirkenden, wurden nicht unabhängig geprüft und bilden keinen Katalog verfügbarer Implementierungen. Laufender Beispielcode ist kein Nachweis allgemeiner Einführung.

Unicast-Antworten setzen dem gemeinsamen Modell eine praktische Grenze

Eine Multicast-Nachricht kann eine spätere Unicast-Antwort über dynamische Ports auslösen. Eine zustandsbehaftete Firewall kann diese Antwort nicht ohne Weiteres dem ursprünglichen Multicast zuordnen. Würde sie automatisch jeden im Ausgangspaket verwendeten Quellport öffnen, könnte eine bösartige Anwendung wiederholt große Löcher erzeugen.

Der Entwurf folgert deshalb, dass ein dedizierter Port für Anwendungen, die in Firewall-Umgebungen Multicast und Unicast mischen, praktischer bleiben kann. Die Nutzung von 8738 ist optional. Das ist keine Niederlage der gemeinsamen Lösung, sondern eine wichtige Einsatzgrenze.

Vor der Freigabe sollte geklärt werden, ob die Anwendung rein multicast arbeitet, ob dynamische Unicast-Antworten nötig sind, ob die Geräte Gruppen und Quellen ausdrücken und ob sich der Rückweg ohne pauschale Öffnung automatisieren lässt. Wenn das nicht gelingt, kann ein dedizierter Port der kleinere und leichter widerrufbare Vertrag sein.

Nicht-Exklusivität verändert den Sicherheitsbeweis

Ein exklusives Binding kann auf manchen Systemen eine grobe lokale Schutzwirkung haben: Ein weiterer Prozess kann nicht denselben Port übernehmen und den Strom empfangen. Die für den gemeinsamen Port notwendige Wiederverwendung entfernt diese Annahme. Der Entwurf empfiehlt zusätzliche Schutzmaßnahmen und merkt an, dass ein Schutz gegen Mithören auf dem Netz oft auch lokales Mithören adressieren kann.

Daraus folgt nicht, dass 8738 grundsätzlich unsicher ist. Es folgt, dass der Besitz des Ports keine Exklusivität mehr beweist. Nachrichtenauthentisierung, Integrität, Vertraulichkeit und Schlüsselbereich müssen auf den wirklichen Kanal bezogen sein. Ein lokaler Prozess kann ein Datagramm empfangen, ohne es entschlüsseln, validieren oder legitim erzeugen zu können.

Auch eine Gruppenadresse ist keine globale Organisationsidentität. Scope, Interface, VRF und Verwaltungsdomäne geben ihr Kontext; dieselbe Adresse kann an anderer Stelle anders verwendet werden. Die SSM-Quelle verengt den Kanal, beweist aber allein weder Eigentum noch Anwendungsautorität. Der Verkehrsselektor und die verantwortliche Stelle bleiben getrennte Fakten.

Der Multicast-Zulassungsbeleg

Für ASM hält der Beleg Adressfamilie, Zielgruppe, UDP 8738, Scope, Interface und VRF fest. Für SSM ergänzt er die genaue Quelle oder eine begrenzte, geprüfte Quellmenge. Diesen Selektor bindet er an den Anwendungsnamen und die Protokollversion, für die die Freigabe beantragt wurde.

Danach dokumentiert er die Hostgrenze: Erzwingt das Betriebssystem Wildcard-, Unicast- und Sharing-Regeln, oder kompensiert die Anwendung einen nicht konformen Host? Welche Socket-Optionen und Negativtests wurden verwendet? Firewall- und QoS-Projektionen sollten aus dem Beleg entstehen oder auf ihn zurückverweisen, damit eine breitere Implementierung sofort auffällt.

Die Anwendungssicherheit wird separat, aber in derselben Evidenzkette erfasst: Authentisierung, Verschlüsselung, Schlüsseleigentümer, Rotation und Widerruf. Antragsteller, Prüfer, Zweck, Aktivierung, Ablauf und Rollback geben dem Entscheid einen Lebenszyklus. Neue Gruppe, Quelle, VRF, Version oder neues Antwortmuster erzeugen einen neuen Beleg statt stiller Vererbung.

Dieser Beleg ist weder ein IETF-Protokollfeld noch eine neue IANA-Spalte. Er hält die gemeinsame Spezifikation klein und bewahrt zugleich lokal jene Autorität und Reversibilität, die nie in den einzelnen Datagrammen stehen sollten.

Quellen

  1. Aktueller Entwurf, Historie und Datatracker-API
  2. Revision 08 als HTML, Text, XML und Versionsvergleich
  3. IESG-Ballot, Shepherd-Bericht und INTAREA-Arbeitsgruppe
  4. Prototyp-Repository und IANA-Register
  5. RFC 7605, RFC 6335, RFC 1122 und RFC 1112
  6. RFC 4607, RFC 3493, RFC 3678, RFC 7288 und RFC 7942
  7. Minimum Initial Specification und The Policy Mirror