22. IAB Considerations (IAB-Überlegungen)
Das IAB hat das Problem der "einseitigen Selbstadressenkorrektur" (Unilateral Self-Address Fixing) untersucht, das der allgemeine Prozess ist, durch den ein Agent versucht, seine Adresse in einem anderen Bereich auf der anderen Seite eines NAT durch einen kollaborativen Protokollreflexionsmechanismus [RFC3424] zu bestimmen. ICE ist ein Beispiel für ein Protokoll, das diese Art von Funktion ausführt. Interessanterweise ist der Prozess für ICE nicht einseitig, sondern zweiseitig, und der Unterschied hat erhebliche Auswirkungen auf die vom IAB aufgeworfenen Probleme. Tatsächlich kann ICE als B-SAF-Protokoll (Bilateral Self-Address Fixing) und nicht als UNSAF-Protokoll betrachtet werden. Ungeachtet dessen hat das IAB vorgeschrieben, dass alle für diesen Zweck entwickelten Protokolle eine bestimmte Reihe von Überlegungen dokumentieren müssen. Dieser Abschnitt erfüllt diese Anforderungen.
22.1. Problem Definition (Problemdefinition)
Aus RFC 3424 muss jeder UNSAF-Vorschlag Folgendes enthalten:
Präzise Definition eines spezifischen, begrenzten Problems, das mit dem UNSAF-Vorschlag gelöst werden soll. Eine kurzfristige Lösung sollte nicht verallgemeinert werden, um andere Probleme zu lösen; deshalb sind "kurzfristige Lösungen normalerweise keine".
Die spezifischen Probleme, die von ICE gelöst werden, sind:
-
Bereitstellung eines Mittels für zwei Peers, um den Satz von Transportadressen zu bestimmen, der für die Kommunikation verwendet werden kann.
-
Bereitstellung eines Mittels für einen Agenten, um eine Adresse zu bestimmen, die von einem anderen Peer erreichbar ist, mit dem er kommunizieren möchte.
22.2. Exit Strategy (Ausstiegsstrategie)
Aus RFC 3424 muss jeder UNSAF-Vorschlag Folgendes enthalten:
Beschreibung einer Ausstiegsstrategie/eines Übergangsplans. Die besseren kurzfristigen Lösungen sind diejenigen, die natürlich immer weniger Verwendung finden, wenn die entsprechende Technologie eingesetzt wird.
ICE selbst lässt sich nicht leicht auslaufen. Es ist jedoch auch in einem global verbundenen Internet nützlich, um beispielsweise zu erkennen, ob ein Routerausfall die Konnektivität vorübergehend unterbrochen hat. ICE hilft auch, bestimmte Sicherheitsangriffe zu verhindern, die nichts mit NAT zu tun haben. Was ICE jedoch tut, ist, andere UNSAF-Mechanismen auslaufen zu lassen. ICE wählt effektiv unter diesen Mechanismen aus, priorisiert diejenigen, die besser sind, und depriorisiert diejenigen, die schlechter sind. Lokale IPv6-Adressen können bevorzugt werden. Da NATs mit der Einführung von IPv6 zu verschwinden beginnen, werden serverreflexive und weitergeleitete Kandidaten (beides Formen von UNSAF-Adressen) einfach nie verwendet, da eine Konnektivität mit höherer Priorität zu den nativen Hostkandidaten besteht. Daher werden die Server immer weniger verwendet und können schließlich entfernt werden, wenn ihre Nutzung auf null geht.
Tatsächlich kann ICE beim Übergang von IPv4 zu IPv6 helfen. Es kann verwendet werden, um zu bestimmen, ob IPv6 oder IPv4 verwendet werden soll, wenn zwei Dual-Stack-Hosts mit SIP kommunizieren (IPv6 wird verwendet). Es kann auch einem Netzwerk mit sowohl 6to4- als auch nativer v6-Konnektivität ermöglichen, zu bestimmen, welche Adresse bei der Kommunikation mit einem Peer verwendet werden soll.
22.3. Brittleness Introduced by ICE (Durch ICE eingeführte Sprödigkeit)
Aus RFC 3424 muss jeder UNSAF-Vorschlag Folgendes enthalten:
Diskussion spezifischer Probleme, die Systeme "spröder" machen können. Zum Beispiel schaffen Ansätze, die die Verwendung von Daten auf mehreren Netzwerkschichten beinhalten, mehr Abhängigkeiten, erhöhen die Debugging-Herausforderungen und erschweren den Übergang.
ICE entfernt tatsächlich Sprödigkeit aus bestehenden UNSAF-Mechanismen. Insbesondere klassisches STUN (wie in RFC 3489 [RFC3489] beschrieben) hat mehrere Punkte der Sprödigkeit. Einer davon ist der Erkennungsprozess, der erfordert, dass ein Agent versucht, den Typ des NAT zu klassifizieren, hinter dem er sich befindet. Dieser Prozess ist fehleranfällig. Mit ICE wird dieser Erkennungsprozess einfach nicht verwendet. Anstatt die Gültigkeit der Adresse einseitig zu bewerten, wird ihre Gültigkeit dynamisch durch Messung der Konnektivität zu einem Peer bestimmt. Der Prozess der Bestimmung der Konnektivität ist sehr robust.
Ein weiterer Punkt der Sprödigkeit bei klassischem STUN und jedem anderen einseitigen Mechanismus ist seine absolute Abhängigkeit von einem zusätzlichen Server. ICE nutzt einen Server für die Zuweisung einseitiger Adressen, erlaubt Agenten jedoch, sich direkt zu verbinden, wenn dies möglich ist. Daher würde in einigen Fällen der Ausfall eines STUN-Servers immer noch zulassen, dass ein Anruf fortschreitet, wenn ICE verwendet wird.
Ein weiterer Punkt der Sprödigkeit bei klassischem STUN ist, dass es davon ausgeht, dass sich der STUN-Server im öffentlichen Internet befindet. Interessanterweise ist dies bei ICE nicht notwendig. Es kann eine Vielzahl von STUN-Servern in einer Vielzahl von Adressbereichen geben. ICE wird denjenigen entdecken, der eine verwendbare Adresse bereitgestellt hat.
Der beunruhigendste Punkt der Sprödigkeit bei klassischem STUN ist, dass es nicht in allen Netzwerktopologien funktioniert. In Fällen, in denen zwischen jedem Agenten und dem STUN-Server ein gemeinsames NAT vorhanden ist, funktioniert traditionelles STUN möglicherweise nicht. Mit ICE wird diese Einschränkung aufgehoben.
Klassisches STUN führt auch einige Sicherheitsüberlegungen ein. Glücklicherweise werden diese Sicherheitsüberlegungen auch durch ICE gemindert.
Folglich dient ICE dazu, die in klassischem STUN eingeführte Sprödigkeit zu reparieren, und führt keine zusätzliche Sprödigkeit in das System ein.
Die Strafe für diese Verbesserungen ist, dass ICE die Sitzungsaufbauzeiten erhöht.
22.4. Requirements for a Long-Term Solution (Anforderungen an eine langfristige Lösung)
Aus RFC 3424 muss jeder UNSAF-Vorschlag Folgendes enthalten:
... Anforderungen an längerfristige, solide technische Lösungen -- tragen zum Prozess bei, die richtige längerfristige Lösung zu finden.
Unsere Schlussfolgerungen aus RFC 3489 bleiben unverändert. Wir sind jedoch der Meinung, dass ICE tatsächlich hilft, weil wir glauben, dass es Teil der langfristigen Lösung sein kann.
22.5. Issues with Existing NAPT Boxes (Probleme mit vorhandenen NAPT-Boxen)
Aus RFC 3424 muss jeder UNSAF-Vorschlag Folgendes enthalten:
Diskussion der Auswirkungen der festgestellten praktischen Probleme mit bestehenden, eingesetzten NA[P]Ts und Erfahrungsberichte.
Es werden jetzt eine Reihe von NAT-Boxen auf dem Markt eingesetzt, die versuchen, "generische" ALG-Funktionalität bereitzustellen. Diese generischen ALGs suchen nach IP-Adressen, entweder in Text- oder Binärform innerhalb eines Pakets, und schreiben sie um, wenn sie mit einer Bindung übereinstimmen. Dies stört klassisches STUN. Das Update auf STUN [RFC5389] verwendet jedoch eine Codierung, die diese binären Adressen vor generischen ALGs verbirgt.
Vorhandene NAPT-Boxen haben nicht deterministische und typischerweise kurze Ablaufzeiten für UDP-basierte Bindungen. Dies erfordert, dass Implementierungen periodische Keepalives senden, um diese Bindungen aufrechtzuerhalten. ICE verwendet einen Standardwert von 15 s, was eine sehr konservative Schätzung ist. Schließlich, im Laufe der Zeit, wenn NAT-Boxen behave [RFC4787]-konform werden, wird dieser minimale Keepalive deterministisch und wohlbekannt, und die ICE-Timer können angepasst werden. Eine Möglichkeit zu haben, das minimale Keepalive-Intervall zu entdecken und zu steuern, wäre noch weitaus besser.