@ElvQuant:
Man muß es ja auch nicht übertreiben ... ich wollte Dich weder vorführen noch unbedingt recht behalten - nur darauf hinweisen, daß teilweise Annahmen getroffen wurden und dann immer wieder wiederholt werden, die nicht gesichert sind. Das einzige, was dank der Analyse (und des Scrub-Tests) von salamihawk feststeht, ist ein Zusammenhang zwischen
einem Problem und den ECN-Bits, die von UM nicht standardkonform verwendet werden.
Mir fiel nur auf, daß immer wieder ohne entsprechende Be- oder Nachweise davon ausgegangen wurde/wird, daß es sich um genau zwei verschiedene Probleme mit der IPSec-Implementierung von Apple (und auch erst ab iOS9 bzw. El Capitan) handeln würde. Die These, daß Apple da noch einige weitere Bugs (die sich sehr unterschiedlich auswirken können) in der neuen Implementierung hat und daß diese alle durchaus auch miteinander zu tun haben könnten, ist aber in meinen Augen ebenso vertretbar (und entspricht der Formulierung des Cisco-Posts auf Facebook auch eher), wenn man die diversen Berichte zusammennimmt und da nicht nur zwei eng umgrenzte Probleme sieht, die jedes für sich gelöst werden müßten/sollten (deshalb auch die Nachfrage, ob das "most notable problem" von Cisco nachweislich gelöst ist (wohlgemerkt von Apple und nicht seitens Cisco, aber der AnyConnect-Client im Store ist vom Juli), denn das wäre ja tatsächlich ein Indiz für unterschiedliche Probleme gewesen).
Meine (ebenfalls nur durch Indizien und Berichte Dritter gestützte) These ist es, daß Apple eben etwas geändert hat (das wird ja offen zugegeben/angesagt:
https://developer.apple.com/videos/play/wwdc2015-719/) und dabei aber insgesamt über das Ziel hinausgeschossen ist, was sich bei der Aus-/Einleitung des per IPSec übertragenen Verkehrs manifestiert, also an der Stelle, wo im Linux-Kernel die Transform-Tables ansetzen würden. Aber wie gesagt ... das ist genauso hypothetisch und geht von der Überlegung aus, daß Apple ja nicht die gesamte IPSec-Implementierung neu erfunden hat und eine (oder meinetwegen auch mehrere) kleinere Änderung(en), die sich auf alle diese Stellen auswirkt und die unterschiedlichen Symptome hervorruft, irgendeine gemeinsame Stelle im Ablauf einer IPSec-Verbindung betreffen müßte(n).
PS: Auch die UM-Core-Router müssen ja irgendein OS haben, das seinerseits das permanente Setzen dieser Bits vornimmt, wenn es nicht vom Traffic abhängig ist. Das kann ja ebenso eine falsche Einstellung sein wie auch ein simpler Fehler im betreffenden OS des Routers. Selbst wenn der Hersteller des Routers das inzwischen gefixt haben sollte, hieße auch das ja noch lange nicht, daß jeder Provider in seinem Kernnetz immer sofort solche Fixes ausrollt, solange das nicht noch mit einer "security warning" verbunden ist (was hier sicherlich nicht der Fall wäre). Und bisher gab es ja auch im UM-Netz nur ab und an mal Probleme mit dem ECN, auch wenn die älteren Berichte dazu bis 2008 zurückgehen, wenn ich alles dazu gefunden habe.
PPS: Ich weiß ja nicht, wer da Schreibrechte in der englischen Wikipedia hat, aber inzwischen ist das Problem mit den ECN-Bits auch dort angekommen:
https://en.wikipedia.org/wiki/Explicit_Congestion_Notification#iOS
, tatsächlich dazu dienen, Datenverlust zu vermeiden. Protokolle wie TCP und Applikationen wie TFTP können Paketverluste merken, indem die Sender immer wieder Rückmeldungen oder Acknowledgements vom Empfänger bekommen, dass die Pakete alle angekommen sind, aber dann ist es zu spät, da schon Paketverlust geschehen ist. Paketverlust impliziert schlechte Bedingungen im Netzwerk (Bandbreitenmangel, kaputte Netzwerkstrecken, etc..), und die Protokolle/Applikationen gehen damit um. Explicit (Explizit) Congestion Notification soll auf der Strecke verwendet werden, um Infos über die Bendingungen in der Netzwerkstrecke zu übermitteln, nämlich ob es vielleicht bald zu Paketverlust kommen könnte.
