Warum ich QUIC blocke
Google ist schnell bei der Hand, wenn es um ein besseres Weberlebnis geht. Leider machen sie nicht einfach ihre Webseiten kleiner, sondern erfinden neue Kommunikationsprotokolle, um den Bloat effizienter ausliefern zu können. Eines dieser Protokolle ist QUIC. Und das macht auf Firewalls erhebliche Probleme.
State
QUIC transportiert alle Daten in UDP statt TCP, damit es sich um Paketverlust oder Latenzen selbst kümmern kann. Das ist per se legitim.
Firewalls sind auf der anderen Seite in der Regel stateful, d.h. sie führen Buch über die Art der Verbindung und versuchen die Kommunkationsformen zu erraten. Nur auf diese Weise sind sie in der Lage, von extern ankommende Pakete halbwegs korrekt zu klassifizieren und nur erwünschte Pakete ins geschützte Netz zu lassen.
Mit TCP hat es eine Firewall einfach. Sie kennt das Protokoll und kann die Ressoucen nach Ende der Verbindung auch sofort freigeben.
Bei UDP ist das nicht so einfach. UDP kennt keinen State. Ob eine UDP-Kommunikation beendet ist oder nicht, entscheidet die Applikation, die UDP benutzt. Der Firewall bleibt nicht viel mehr als ein Idle-Timeout zu verwalten: Wenn sich so und so lange nichts mehr tut, scheint auch zukünftig nichts mehr zu kommen.
Hat die Firewall allerdings Ahnung vom dem Protokoll, das in UDP gesprochen wird, kann sie diesen Vorteil ausnutzen und die Ressourcen schon freigeben. Besonders häufig ist diese Methode bei DNS, das nur aus einem einzigen Paketwechsel besteht.
In der Praxis sieht das dann so aus, dass die Firewall, hinter der sich mehrere SEO- und Web-Entwickler-Firmen befinden, eine Unmenge an offenen UDP-Verbindungen im zum Port UDP/443 und UDP/80 hat. Sie meisten dieser Verbindungen sind idle.
Das Recyceln von QUIC Verbindungen scheint nicht zu funktionieren. Das mag an der Arbeitsweise der Mitarbeiter liegen. Evtl. macht der Browser pro Webseite und Tab neue QUIC Verbindungen auf. Evtl. auch mehrere pro Host.
Verschärft wird das Problem dadurch, dass alle Firmen mit IPv6 versorgt sind und die Arbeitsplatzrechner fast alle privacy extensions aktiviert haben. Dies führt dazu, dass ein konkreter Arbeitsplatz alle paar Minuten mit einer neuen Quelladresse daher kommt und neue Verbindungen aufmacht.
Accounting
Faires Accounting bedeutet, dass man dem Kunden nur das in Rechnung stellt, was er auch tatsächlich tut. Ein Accounting am Port würde Quertraffic zwischen den oft kooperierenden Kleinfirmen und zu ihren eignen Servern (bei uns im Hosting) mit abrechen.
Also accounten wir den Traffic, dernach außen geht. Und diese Unterscheidung trifft die Firewall.
Im Log der Firewall stehen Einträge wie:
Teardown UDP connection ... for outside:2001:.../123 to kunde:2001:.../123 duration 0:02:02 bytes 48
Wie man schön sieht, ist der UDP Timeout zwei Minuten. Erst dann wurde die Ressource freigegeben. Die Firewall nutzt die Kenntnis des NTP Protokoll für UDP Verbindungen nicht, sie timen also einfach aus. Da NTP keine derartigen Massen an Verbindungen generiert, ist das auch kein Problem.
Allerdings gibt es da auch ein Problem. Immer dann, wenn keine Antwort vom Server kommt, zählt die ASA falsch:
Teardown UDP connection ... for outside:2001:.../53 to kunde:2001:.../49753 duration 0:02:01 bytes 1742763406
Offensichtlich handelt es sich um einen Initialisierungsfehler des Accountingsystem. Leider Counter-Bug sind bei Cisco ein sehr verbreitetes Phänomen.
Also hab ich dafür den Bug CSCto33406 aufgemacht. Und zwar im Oktober 2014. Selbstverständlich ist der Bug noch offen.
Man kann ja spaßeshalber mal selbst suchen, ob auch andere den Fehler haben: Das Ergebnis berichtet von einem Nutzer, der sich darüber beschwert, dass man die Cisco-Notifications zu dem Bug jährlich neu setzen muss, weil die dann von alleine verschwinden. Und ratet mal, wer das berichtet …
Wir filtern solche Accounting-Fehler aus, weil man das dem Kunden nicht berechnen kann.
Und was passiert mit QUIC? Genau der gleiche Fehler.
Nur kann man das nicht ohne weiteres ausfiltern, denn QUIC ist für hohe Bandbreiten durchaus gedacht.
Selbst wenn man die so gemessene QUIC Geschwindigkeit versucht auf die Anschluss-Bandbreite des Kunden zu limitieren, sind die Werte immer noch unrealistisch hoch.
Ganz offensichtlich ist es bei QUIC normal, dass auf einige gesendete Pakete keine Antwort kommt. Das kann an inzwischen veralteten Crypto-Schlüsseln liegen, so dass andere Verbindungen zum gleichen Host nicht mehr beantwortet werden. Es kann daran liegen, dass nach einem QUIC Timeout (der höher sein kann, als der der Firewall) ein finales Abschlusspaket kommt (was nicht beantwortet wird). Es gibt viele Möglichkeiten.
Unglücklicherweise ist QUIC auch nicht offiziell spezifiziert. Vor einigen Wochen waren selbst diese Drafts ungültig. Aktives Development sieht anders aus.
Fazit
Es ist aus. Ich verbiete auf der Firewall UDP/80 und UDP/443.
Wenn ihr das wieder zum Laufen bekommen wollt, dann
- liebes Google-Team, macht den Standard fertig und
- tretet die Cisco-Abteilung, dass sie den Bug beheben.
- liebes ASA-Team, fixed den Bug, denn das ist inzwischen peinlich und
- implementiert early timeout für QUIC, sobald es fertig ist.
Danke.
https://heise.de/-6058718
Und? Sind die Problem jetzt gelöst? Ich fürchte nein.
1 Kommentare