Appendix A. Interaction with Regular ICE (Interaktion mit regulärem ICE)

Das ICE-Protokoll wurde so konzipiert, dass es flexibel genug ist, um in möglichst vielen Netzwerkumgebungen zu funktionieren und sich daran anzupassen. Trotz dieser Flexibilität unterstützt ICE, wie in [RFC8445] spezifiziert, Trickle ICE nicht von sich aus. Dieser Abschnitt beschreibt, wie das Trickeln von Kandidaten mit ICE interagiert.

[RFC8445] beschreibt die erforderlichen Bedingungen zum Aktualisieren von Checklisten und Timer-Zuständen, während sich ein ICE-Agent im Zustand Laufend (Running) befindet. Diese Bedingungen werden bei Transaktionsabschluss überprüft, und eine davon legt fest:

Wenn es kein gültiges Paar in der gültigen Liste für jede Komponente des mit der Checkliste verbundenen Datenstroms gibt, wird der Zustand der Checkliste auf Fehlgeschlagen (Failed) gesetzt.

Dies könnte ein Problem sein und die ICE-Verarbeitung in einer Reihe von Szenarien vorzeitig zum Scheitern bringen. Betrachten Sie den folgenden Fall:

Szenario 1: Kollision privater Adressblöcke

1. Alice und Bob befinden sich beide in verschiedenen Netzwerken mit Netzwerkadressübersetzung (NAT). Alice und Bob selbst haben unterschiedliche Adressen, aber beide Netzwerke verwenden denselben privaten Internetblock (z. B. den in [RFC1918] angegebenen „20-Bit-Block" 172.16/12).
2. Alice übermittelt Bob den Kandidaten 172.16.0.1, der auch zufällig einem vorhandenen Host in Bobs Netzwerk entspricht.
3. Bob erstellt ein Kandidatenpaar aus seinem Host-Kandidaten und 172.16.0.1, stellt dieses eine Paar in eine Checkliste und startet Prüfungen.
4. Diese Prüfungen erreichen den Host bei 172.16.0.1 in Bobs Netzwerk, der mit einem ICMP-Fehler „Port nicht erreichbar" antwortet; gemäß [RFC8445] markiert Bob die Transaktion als Fehlgeschlagen.

Zu diesem Zeitpunkt enthält die Checkliste nur ein fehlgeschlagenes Paar, und die gültige Liste ist leer. Dies führt dazu, dass der Datenstrom und möglicherweise die gesamte ICE-Verarbeitung fehlschlagen, obwohl Trickle-ICE-Agents nachträglich Kandidaten übermitteln können, die erfolgreich sein könnten.

Szenario 2: Nichtübereinstimmung der Adressfamilie

Eine ähnliche Wettlaufsituation würde auftreten, wenn die anfängliche ICE-Beschreibung von Alice nur Kandidaten enthält, die aus allen von Bob gesammelten Kandidaten als unerreichbar bestimmt werden können (z. B. wäre dies der Fall, wenn Bobs Kandidaten nur IPv4-Adressen enthalten und der erste Kandidat, den er von Alice erhält, eine IPv6-Adresse ist).

Szenario 3: Nicht-Trickle-ICE-Interaktion

Ein weiteres potenzielles Problem könnte auftreten, wenn eine Nicht-Trickle-ICE-Implementierung eine Interaktion mit einer Trickle-ICE-Implementierung initiiert. Betrachten Sie den folgenden Fall:

1. Alices Client hat eine Nicht-Trickle-ICE-Implementierung.
2. Bobs Client unterstützt Trickle ICE.
3. Alice und Bob befinden sich hinter NATs mit adressabhängiger Filterung [RFC4787].
4. Bob hat zwei STUN-Server, aber einer davon ist derzeit nicht erreichbar.

Nachdem Bobs Agent Alices anfängliche ICE-Beschreibung erhalten hat, würde er sofort Konnektivitätsprüfungen starten. Er würde auch mit dem Sammeln von Kandidaten beginnen, was aufgrund des nicht erreichbaren STUN-Servers lange dauern würde. Bis Bobs Antwort fertig ist und an Alice übermittelt wird, könnten Bobs Konnektivitätsprüfungen fehlgeschlagen sein: Bis Alice Bobs Antwort erhält, kann sie keine Konnektivitätsprüfungen starten und Löcher in ihrem NAT stanzen. Das NAT würde daher Bobs Prüfungen als von einem unbekannten Endpunkt stammend filtern.

---