Site icon bintorosoft.com

Customer Marking Abuse: Wie Telcos QoS Missbrauch verhindern

Red Snapper

Customer Marking Abuse ist ein zentrales Thema für Telcos, weil Quality of Service nur dann fair und stabil funktioniert, wenn Kunden QoS-Markierungen (DSCP, 802.1p/CoS) nicht beliebig als „Prioritätsjoker“ missbrauchen können. In IP-Netzen ist es technisch trivial, jedes Paket als „Voice“ oder „High Priority“ zu markieren. Würde ein Provider diese Markierungen ungeprüft übernehmen, hätte das gravierende Folgen: Best-Effort-Kunden könnten sich „auf Kosten anderer“ priorisieren, Echtzeitklassen würden überlaufen, und das gesamte QoS-Modell im Access- und Core-Netz würde an Aussagekraft verlieren. Deshalb arbeiten Telcos mit klaren Trust-Boundaries am Kundenübergabepunkt (UNI/NNI) und mit Traffic-Policies, die festlegen, welche Markierungen akzeptiert, umgeschrieben, begrenzt oder verworfen werden. In diesem Artikel erfahren Sie, wie Provider QoS Missbrauch verhindern, welche Mechanismen (Policing, Shaping, Re-Marking, Class-Based Admission) dabei typisch sind und wie Kunden ihre eigenen QoS-Designs so ausrichten, dass sie providerkonform bleiben – ohne die eigene Echtzeitqualität zu gefährden.

Warum QoS-Markierungen ein Missbrauchspotenzial haben

QoS-Markierungen sind nur Metadaten. Ein Paket mit DSCP EF ist technisch nicht „wertvoller“ als ein Paket mit DSCP 0 – es wird erst durch die Policy im Netz wertvoll. Genau deshalb ist Missbrauch so attraktiv: Wer seine Daten als „Premium“ markiert, könnte theoretisch bessere Behandlung erzwingen, wenn der Provider die Markierung vertraut. In der Praxis ist das nicht nur unfair, sondern destabilisiert das Netz. QoS-Klassen sind begrenzt, insbesondere echte Low-Latency-Queues (LLQ) und hoch priorisierte Scheduler. Wenn zu viel Traffic dort landet, steigt Queueing-Delay, und am Ende leiden gerade die Dienste, die QoS schützen soll: Sprache, Echtzeitvideo, Signalisierung.

Telco-Perspektive: QoS ist ein Produkt, kein „Feature zum Mitbringen“

Viele Provider bieten unterschiedliche Serviceklassen an: Best Effort Internet, Business-Internet, Ethernet-Services mit CoS, MPLS-VPN mit QoS-Profilen oder spezielle Sprach-/SIP-Produkte. In all diesen Angeboten ist QoS nicht automatisch ein „Durchreichen“ der Kundenmarkierung, sondern ein definierter Vertrag: Welche Klassen gibt es, wie viel Bandbreite pro Klasse ist erlaubt (CIR/PIR), wo wird priorisiert, und welche Markierungen sind zulässig? Der Provider muss dabei sein Netz schützen und gleichzeitig eine konsistente Behandlung im Core sicherstellen. Deshalb ist „Customer Marking Abuse“ weniger ein Sicherheitsproblem im klassischen Sinne, sondern ein Fairness- und Stabilitätsproblem des Dienstes.

Trust Boundary am UNI/NNI: Wo der Provider „nicht glaubt“, sondern „prüft“

Die wichtigste Maßnahme gegen QoS Missbrauch ist die Trust Boundary am Kundenübergabepunkt. Das kann ein Ethernet-UNI (z. B. Carrier Ethernet), ein Router-Interface am Provider Edge (PE), ein virtualisierter Übergabepunkt oder eine CPE/NTU-Lösung sein, die als definierter Demarkationspunkt fungiert. Dort entscheidet der Provider, welche Markierungen akzeptiert werden. In vielen Fällen wird DSCP grundsätzlich ignoriert oder auf definierte Werte zurückgesetzt. In QoS-fähigen Services kann der Provider Markierungen annehmen, aber nur innerhalb der gebuchten Profile und oft nur, wenn sie in eine erlaubte Menge von Klassen passen.

Re-Marking: Markierungen standardisieren statt blind übernehmen

Re-Marking ist eine der effektivsten Telco-Techniken gegen Customer Marking Abuse. Dabei werden eingehende DSCP- oder CoS-Werte in ein providerinternes Klassenmodell umgesetzt. Das hat zwei Vorteile: Erstens verhindert es, dass „kreative“ Kundenmarkierungen unkontrolliert im Core landen. Zweitens ermöglicht es dem Provider, intern konsistente QoS-Queues und Policies zu nutzen, unabhängig davon, wie Kunden ihre Markierungen gestalten. In der Praxis bedeutet das oft: Kunden dürfen beispielsweise nur eine kleine Menge von Markierungen verwenden (z. B. eine Voice- und eine Business-Klasse), der Provider übersetzt diese in seine internen Traffic Classes und setzt alles andere auf Best Effort.

Policing: Missbrauch durch harte Grenzen verhindern

Policing ist die klassische Telco-Maßnahme, um sicherzustellen, dass ein Kunde nicht mehr „Premium-Traffic“ sendet als vereinbart. Selbst wenn Markierungen akzeptiert werden, ist die Menge pro Klasse in der Regel begrenzt. Der Provider kann pro Klasse einen CIR (Committed Information Rate) und ggf. PIR (Peak) definieren. Überschreitet der Kunde diese Grenzen, kann der Provider pakete droppen oder in eine niedrigere Klasse re-markieren. Das ist aus Provider-Sicht notwendig, weil sonst einzelne Kunden Premium-Queues fluten könnten. Aus Kundensicht ist es kritisch, weil Policers bei Echtzeit sehr schnell hör- und sichtbar werden – daher muss der Kunde sein eigenes QoS so dimensionieren, dass priorisierte Klassen im Vertrag bleiben.

Warum Policing für Echtzeit besonders heikel ist

Echtzeittraffic reagiert empfindlich auf Drops. Wenn ein Provider Voice als eigene Klasse anbietet, ist das Profil meist konservativ dimensioniert. Kunden sollten daher vermeiden, Voice-Klassen am Limit zu betreiben oder „alles Medien“ als Voice zu markieren. Sonst entstehen Policer Drops, die sich wie „Providerproblem“ anfühlen, aber eigentlich ein Vertrags- bzw. Markierungsproblem sind.

Shaping und Scheduling im Provider-Access: Fairness über mehrere Kunden

Policing allein verhindert Missbrauch, löst aber nicht das Access-Problem: In Access- und Aggregationsnetzen teilen sich viele Kunden dieselben Ressourcen. Telcos nutzen daher Scheduling-Mechanismen, die pro Kunde und pro Klasse fair teilen. Das kann in Form von Hierarchical QoS (HQoS) passieren: Ein übergeordnetes Kundenprofil begrenzt die Gesamtbandbreite, darunter werden Klassen (Voice, Business, Best Effort) mit eigenen Anteilen gescheduled. So stellt der Provider sicher, dass selbst bei hoher Last die vereinbarte Behandlung eingehalten wird, ohne dass ein Kunde durch Marking-Tricks die anderen verdrängt.

„QoS im Internet“: Warum Telcos Markierungen oft neutralisieren

Bei klassischen Internet-Services ist Ende-zu-Ende QoS über mehrere Provider hinweg nicht zuverlässig, weil DSCP nicht überall gleich behandelt wird. Viele Netzbetreiber neutralisieren Markierungen deshalb bewusst, um Fairness herzustellen und Missbrauch zu verhindern. Das bedeutet nicht, dass QoS im Kundennetz sinnlos ist – im Gegenteil: Kunden sollten ihre eigenen Engpässe (Standort-Uplink, WLAN, VPN, SD-WAN Edge) kontrollieren. Nur sollten sie nicht erwarten, dass DSCP im öffentlichen Internet durchgängig priorisiert wird, wenn der Service nicht explizit dafür ausgelegt ist.

Missbrauch erkennen: Wie Provider „auffälliges Marking“ identifizieren

Telcos verlassen sich nicht nur auf statische Regeln. In großen Netzen ist es üblich, Telemetry und Counters zu nutzen, um auffällige Muster zu erkennen: ungewöhnlich hoher Anteil an EF-markiertem Traffic, plötzliche Peak-Raten in Premiumklassen, oder wiederkehrende Policer Drops in bestimmten Klassen. Solche Signale können zu automatischen Re-Markings, restriktiveren Profilen oder zu Kundenkommunikation führen. Für SLA-Services ist das auch operativ wichtig, weil Policer Drops direkt die QoE beeinflussen.

Kundenperspektive: So bauen Sie providerkonforme QoS-Designs ohne Überraschungen

Für Kunden ist das Wichtigste: QoS muss zum Providerprofil passen. Wenn der Provider nur bestimmte Markierungen akzeptiert oder Premiumtraffic pro Klasse policed, müssen Kunden ihr eigenes Klassenmodell und ihre Markierungsstrategie entsprechend ausrichten. Außerdem sollten Kunden nicht versuchen, „mehr Priorität“ durch Marking zu erschleichen – das führt meist zu Re-Marking oder Policer Drops und verschlechtert genau die Echtzeitqualität, die sie verbessern wollen. Stattdessen ist ein sauberer Ansatz: Trust Boundary im eigenen Netz, korrekte Klassifizierung, Uplink-Shaping, und klare Absprachen mit dem Provider über akzeptierte DSCP/CoS-Werte und Bandbreitenprofile.

Typische Telco-Mechanismen im Überblick: Vom „Zero Trust“ bis zum SLA-QoS

Pragmatische Leitlinien: QoS Missbrauch verhindern, ohne legitime Echtzeit zu beschädigen

Exit mobile version