Da ECN nun mal nur ein Mechanismus zur "Regelung des Verkehrs" ist und bei IP auf die Hilfe eines darüber angesiedelten Protokolls angewiesen ist, damit eine Drosselung überhaupt möglich wird, macht es bei UDP-Paketen nur bedingt Sinn überhaupt zu taggen, nämlich dann, wenn eine Schicht darüber damit etwas anfangen kann (das kann so ein Router ja aber nicht entscheiden/wissen).
In
RFC 3168 wurde mal explizit die Forderung aufgestellt (S. 7, letzter Absatz), daß ein Paket mit gesetzter CE-Kennzeichnung so zu behandeln wäre, wie ein von einem Router auf dem Transportweg
verworfenes Paket und der "congestion avoidance"-Mechanismus
des darüberliegenden Protokolls zu aktivieren wäre. Bei TCP wäre das eben die Annahme "congestion" und das Wiederholen des verworfenen Pakets (inkl. "slow start" von vorne), bei UDP an sich gibt es da gar keine Festlegungen.
Nachdem es so etwas bei einer "UDP-Verbindung" (auch das ist schon fast ein Euphemismus) nicht gibt und schon die Erkennung von Paketverlusten bei UDP nur durch eine entsprechende Nummerierung und/oder Absicherung auf einer höheren Ebene erfolgen kann (die darunter bieten weder Wiederholung noch Sortierung nach Reihenfolge), ist es auch nicht ganz so simpel. Die ganze Problematik wird für UDP in
RFC 5404 in Punkt 3.1 (S. 6) ausführlich abgehandelt.
Auch RFC 3168 beschäftigt sich in Punkt 9.2 (Seite 29) explizit mit der Problematik bei der Verwendung von ECN in Kombination mit IPSec - das sollte aber bei ESP und NAT-T (also UDP-Kapselung), wo die Transportheader ohnehin keine Rolle spielen, nur sehr bedingt zu berücksichtigen sein, falls da irgendjemand (m.E. fälschlicherweise) die ECN-Konditionen aus den äußeren Paketen in die inneren kopieren würde.
Was jetzt Apple davon wie umsetzt bei den Änderungen in iOS9 (und wo UM ggf. noch dazwischenfunkt), sollte sich ja irgendwie an diesem Standard orientieren (oder ggf. an einem anderen, dann wäre die Frage an welchem).
Selbst mit Linux und "iptables" ist jedenfalls das Manipulieren der ECN-Bits eines Paketes nur für TCP-Pakete (und auch nur für die entsprechenden Bits im TCP-Header) möglich ... auch eine Linux-basierte Firewall kann (m.W., um das zu betonen, ich lasse mich gerne korrigieren) mit normalen Werkzeugen keine Manipulation an den ECN-Bits im IP-Header vornehmen (man kann sie nur bei einem recvmsg()-Aufruf mit auslesen als Empfänger). Selbst das Setzen der ECN-Bits im IP-Header irgendeiner Antwort (das wäre Aufgabe des Programms bei ECN für UDP) ist für ein Programm auf einer Schicht oberhalb der Netzwerkschicht (OSI 3) nicht trivial ... wie so ein IP-Stack für sich selbst an dieser Stelle reagieren müßte, ist m.W. nirgendwo festgelegt (anders als bei TCP).
Da eigentlich ECN-Bits per Definition zu ignorieren wären, wenn eine der beiden Seiten damit nichts anfangen kann (dann greift eben irgendwann bei echtem Stau ein Paketverlust regulierend ein), würde ich - dabei bleibe ich - das Problem tatsächlich eher bei Apple verorten. Wenn die UDP-Pakete mit gesetztem "ECN capable" verschicken und auf ständig gesetzte "congestion occured"-Bedingungen unglücklich reagieren, sehe ich - nur meine eigene Meinung - eben die Verantwortung für die korrekte Behandlung eines "Dauerstaus" (auch macht es eben nach RFC 3168 einen Unterschied, ob ein einzelnes Paket oder mehrere mit CE-Signalisierung eintreffen) bei Apple. Das generelles Taggen durch UM ist zwar sicherlich auch "fragwürdig" (wenn es wirklich immer erfolgt), aber wenn Apple die Unterstützung/Auswertung von ECN auf andere Protokolle ausdehnt, dann muß man wohl auch damit zurecht kommen, ohne daß gleich alles zusammenbricht. Während eben bei TCP-Verbindungen das Ganze damit zwar stark (und hoffentlich in der Regel unnötigerweise) gedrosselt würde (deshalb juckt das auch die prinzipielle Funktion einer FTP-Verbindung nicht, allerdings dürfte es sie erheblich verlangsamen) und auch bei bestimmten RTP-Verbindungen (
RFC 6679) noch standardisiert ist, ist es bei IPSec-Implementierungen eine Frage der höheren Schichten, ob und wie das ausgewertet und behandelt wird. Diese Behandlung der Pakete bei UM ist ja sicherlich auch nichts wirklich Neues und andere Systeme kommen damit ja offenbar auch klar. Wenn also Apple der Meinung ist, sie machten es richtig und alle anderen falsch, sollten sie das ja mit einem entsprechenden Statement und dem Verweis auf den als Basis der Implementierung verwendeten Standard leicht klarstellen können.
Der Unterschied zwischen einem verworfenen Paket (dafür gibt es normalerweise gar keine Benachrichtigung, vielleicht noch ein "source quench", obwohl das seit RFC 6633 auch "deprecated" ist und das käme normalerweise auch von einem Endpoint und nicht von einem Router) und einem mit CE-Warnung ist es eben, daß ersteres den Empfänger gar nicht erreicht und zweiteres ihn eigentlich dazu veranlassen sollte, auf einer höheren Ebene (so es eine solche überhaupt gibt, siehe oben) dem Sender mit einer Quittung (oder dem nächsten eigenen Paket, wenn es wie bei UDP keine Quittungen gibt) diesen Umstand seinerseits mitzuteilen und ihn dazu aufzufordern, etwas langsamer zu machen (bis zu einem minimalen Niveau > 0).
Während also im ersteren Fall unbedingt ein Paket wiederholt werden müßte (wurde ja schließlich "discarded", bei IPSec kann auch nicht einfach eines ausfallen wie bei irgendwelchen RTP-Verbindungen), muß/soll das im zweiten Falle angekommene Paket eben noch verarbeitet werden. Das ist ein Widerspruch zum RFC 3168, wenn man es flüchtig liest ... aber das bezieht sich dort eben auf ein einzelnes Paket (single packet) mit gesetztem CE.
Insofern stimme ich KunterBunter auch nur bedingt zu, denn bei IPSec hat der Empfänger (der kriegt so ein "CE" als erster zu sehen, wenn das der Router am EP ist) gar keine Möglichkeit, dem Sender über irgendeine Flußsteuerung das "mach mal langsamer" zu signalisieren. Diese Signalisierung per ECN geht eben an den
Empfänger eines IP-Paketes und der Sender erfährt davon nur dann, wenn es der Empfänger ihm irgendwie (ooB oder mit der nächsten regulären Meldung) mitteilen kann.
Also sollte/müßte Apple bei IP-Verbindungen, bei denen nicht bekanntermaßen auf einer höheren Schicht eine Flußkontrolle möglich ist, im IP-Stack an sich einfach mal gar nichts unternehmen und nur die Bits entsprechend auf Anforderung bereitstellen. Wenn hingegen der IPSec-Stack im iOS (nicht mit dem IP-Stack zu verwechseln) irgendwie diese ECN-Bits seit neuestem setzt und/oder auswertet, sollte ja irgendwo eine Dokumentation existieren, wie er mit welchen Konditionen umgeht.
Wenn der neue IP-Stack von OS X dasselbe Problem haben sollte, kann man dort aber wenigstens mit einem Packetdump noch feststellen, wie Apple mit solchen UDP-Paketen mit gesetztem CE überhaupt umgeht. Wenn es sie einfach verwirft, sollte ja in einem Packetdump kein "decapsulated packet" mit dem Payload zu sehen sein. Mit einem simplen "ping" (give me a ping, Vassili ... one ping only please) zwischen den Endpoints (ohne zusätzlichen Traffic) sollte sich das sogar wieder anhand der Anzahl der Pakete verifizieren lassen, ob so ein "echo request" über die IPSec-Strecke auch zu einem "echo reply" des Apple-Devices führt und dann nur dieses nicht richtig verarbeitet wird.
Interessant wäre es u.U. noch (damit kann man auch weitere Schlüsse ziehen, wo der Fehler nun eigentlich sitzen könnte, im IP- oder im IPSec-Stack), wie iOS 9 auf andere UDP-Pakete mit CE-Signalisierung reagiert (DNS gehörte da ja auch dazu) bzw. ob UM diese "ECN=3"-Tags tatsächlich vollkommen wahllos und für jeden Traffic setzt. Zwischen zwei UM-Anschlüssen könnte man dann ggf. sogar noch ermitteln, ob dieses Tagging nur für Traffic gilt, der das UM-Netz verläßt oder auch innerhalb des UM-Netzes ständig stattfindet.
Dem "chapeau" für salamihawk schließe ich mich an ... das war und ist genau das, was ich meinte und mir vorgestellt habe, als ich auf die Notwendigkeit einer Analyse des Traffics verwiesen habe.
PS: Interessant fand ich noch den Schlußsatz einer
Studie u.a. zur Verwendung von ECN mit UDP im heutigen Internet:
Whether the use of ECN with UDP offers any benefit has not been determined, but it seems to cause no significant harm.
Wobei es darin wohlgemerkt nur um die Verwendung von ECN an sich geht und nicht um die (eher fragwürdige - in meinen Augen) Verwendung durch UM.