Zum Hauptinhalt springen

RFC 8838 - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol

  • Status: Proposed Standard
  • Veröffentlicht: January 2021
  • Stream: IETF
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Dieses Dokument beschreibt „Trickle ICE", eine Erweiterung des Interactive Connectivity Establishment (ICE)-Protokolls, die es ICE-Agents ermöglicht, Konnektivitätsprüfungen zu beginnen, während sie noch Kandidaten sammeln, indem Kandidaten schrittweise über die Zeit ausgetauscht werden, anstatt alle auf einmal. Diese Methode kann den Prozess der Herstellung einer Kommunikationssitzung erheblich beschleunigen.

Inhaltsverzeichnis (Table of Contents)​

Anhänge (Appendices)​

1. Introduction (Einleitung)​

Das Interactive Connectivity Establishment (ICE)-Protokoll [RFC8445] beschreibt, wie ein ICE-Agent Kandidaten sammelt, Kandidaten mit einem Peer-ICE-Agent austauscht und Kandidatenpaare erstellt. Sobald die Paare gesammelt wurden, führt der ICE-Agent Konnektivitätsprüfungen durch und nominiert und wählt schließlich Paare aus, die zum Senden und Empfangen von Daten innerhalb einer Kommunikationssitzung verwendet werden.

Das Befolgen der Verfahren in [RFC8445] kann zu etwas längeren Aufbauzeiten für Kommunikationssitzungen führen, da das Sammeln von Kandidaten häufig das Abfragen von Session Traversal Utilities for NAT (STUN)-Servern [RFC5389] und das Zuweisen von Relay-Kandidaten auf Traversal Using Relay NAT (TURN)-Servern [RFC5766] umfasst. Obwohl viele ICE-Verfahren parallel durchgeführt werden können, müssen die Taktanforderungen (Pacing Requirements) aus [RFC8445] weiterhin befolgt werden.

Dieses Dokument definiert „Trickle ICE", einen ergänzenden Betriebsmodus von ICE, bei dem Kandidaten schrittweise ausgetauscht werden können, sobald sie verfügbar werden (und gleichzeitig mit dem Sammeln anderer Kandidaten). Konnektivitätsprüfungen können auch beginnen, sobald Kandidatenpaare erstellt wurden. Da Trickle ICE das Sammeln von Kandidaten und Konnektivitätsprüfungen parallel ermöglicht, kann die Methode den Prozess des Aufbaus einer Kommunikationssitzung erheblich beschleunigen.

Dieses Dokument definiert auch, wie die Unterstützung für Trickle ICE erkannt wird, wie die Verfahren in [RFC8445] bei Verwendung von Trickle ICE geändert oder ergänzt werden und wie ein Trickle-ICE-Agent mit einem [RFC8445]-konformen ICE-Agent interoperieren kann.

Dieses Dokument definiert keine protokollspezifische Verwendung von Trickle ICE. Stattdessen werden protokollspezifische Details für Trickle ICE in separaten Verwendungsdokumenten definiert. Beispiele für solche Dokumente sind [RFC8840] (das die Verwendung mit dem Session Initiation Protocol (SIP) [RFC3261] und dem Session Description Protocol (SDP) [RFC4566] definiert) und [XEP-0176] (das die Verwendung mit dem Extensible Messaging and Presence Protocol (XMPP) [RFC6120] definiert). Einige der Beispiele im Dokument verwenden jedoch SDP und das Angebot/Antwort-Modell (Offer/Answer Model) [RFC3264], um die zugrunde liegenden Konzepte zu erklären.

Das folgende Diagramm veranschaulicht einen erfolgreichen Trickle-ICE-Austausch mit einem verwendenden Protokoll, das dem Angebot/Antwort-Modell folgt:

     Alice                                            Bob
       |                     Angebot                   |
       |---------------------------------------------->|
       |           Zusätzliche Kandidaten              |
       |---------------------------------------------->|
       |                     Antwort                   |
       |<----------------------------------------------|
       |           Zusätzliche Kandidaten              |
       |<----------------------------------------------|
       |  Zusätzliche Kandidaten und Konnektivitätsprüfungen  |
       |<--------------------------------------------->|
       |<========== VERBINDUNG HERGESTELLT ============>|

Abbildung 1: Ablauf (Flow)

Der Hauptteil dieses Dokuments ist so strukturiert, dass das Verhalten von Trickle-ICE-Agents in ungefähr der Reihenfolge der Operationen und Interaktionen während einer ICE-Sitzung beschrieben wird:

  1. Bestimmung der Unterstützung für Trickle ICE
  2. Generierung der anfänglichen ICE-Beschreibung
  3. Verarbeitung der anfänglichen ICE-Beschreibung und Generierung der anfänglichen ICE-Antwort
  4. Verarbeitung der anfänglichen ICE-Antwort
  5. Bildung von Checklisten, Beschneiden von Kandidaten, Durchführung von Konnektivitätsprüfungen usw.
  6. Sammeln und Übermitteln von Kandidaten nach der anfänglichen ICE-Beschreibung und -Antwort
  7. Verarbeitung eingehender Trickle-Kandidaten
  8. Generierung und Verarbeitung der End-of-Candidates-Anzeige
  9. Verarbeitung von ICE-Neustarts

Es gibt beträchtliche Betriebserfahrung mit der Technik hinter Trickle ICE, die bis ins Jahr 2005 zurückreicht (als die XMPP-Jingle-Erweiterung einen „dribble mode" definierte, wie in [XEP-0176] spezifiziert); dieses Dokument enthält Feedback von denen, die die Technik über die Jahre hinweg implementiert und eingesetzt haben.

2. Terminology (Terminologie)​

Die Schlüsselwörter „muss (MUST)", „darf nicht (MUST NOT)", „erforderlich (REQUIRED)", „soll (SHALL)", „soll nicht (SHALL NOT)", „sollte (SHOULD)", „sollte nicht (SHOULD NOT)", „empfohlen (RECOMMENDED)", „nicht empfohlen (NOT RECOMMENDED)", „kann (MAY)" und „optional (OPTIONAL)" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Diese Spezifikation verwendet alle Terminologie, die für Interactive Connectivity Establishment in [RFC8445] definiert ist. Darüber hinaus definiert sie die folgenden Begriffe:

Leere Checkliste (Empty Checklist): Eine Checkliste, die anfänglich keine Kandidatenpaare enthält, da diese schrittweise hinzugefügt werden, wenn sie getricklet werden. (Dieses Szenario tritt bei einem regulären ICE-Agent nicht auf, da alle Kandidatenpaare bekannt sind, wenn der Agent den Checklistensatz erstellt.)

Vollständiges Trickle (Full Trickle): Der typische Betriebsmodus für Trickle-ICE-Agents, bei dem die anfängliche ICE-Beschreibung eine beliebige Anzahl von Kandidaten (sogar null Kandidaten) enthalten kann und keine vollständige Kandidatengeneration wie beim Half Trickle enthalten muss.

Generation: Alle Kandidaten, die innerhalb einer ICE-Sitzung übermittelt werden (korreliert mit einer bestimmten Kombination aus Benutzername-Fragment (Username Fragment) und Passwort (Password)).

Half Trickle: Ein Trickle-ICE-Betriebsmodus, bei dem der Initiator streng vor dem Erstellen und Übermitteln der anfänglichen ICE-Beschreibung eine vollständige Kandidatengeneration sammelt. Einmal übermittelt, können diese Kandidateninformationen von regulären ICE-Agents verarbeitet werden, die keine Unterstützung für Trickle ICE benötigen. Es ermöglicht auch Trickle-ICE-fähigen Respondern, weiterhin Kandidaten zu sammeln und Konnektivitätsprüfungen auf nicht blockierende Weise durchzuführen, wodurch etwa „die Hälfte" der Vorteile von Trickle ICE geboten werden. Der Half-Trickle-Mechanismus ist hauptsächlich für Fälle gedacht, in denen die Unterstützung von Trickle ICE durch den Responder nicht vor der Übermittlung der anfänglichen ICE-Beschreibung bestätigt werden kann.

ICE-Beschreibung (ICE Description): Alle Attribute, die sich auf die ICE-Sitzung beziehen (außer Kandidaten) und zum Konfigurieren eines ICE-Agents erforderlich sind. Dazu gehören unter anderem das Benutzername-Fragment (Username Fragment), das Passwort (Password) und andere Attribute.

Getricklete Kandidaten (Trickled Candidates): Kandidaten, die ein Trickle-ICE-Agent nach dem Übermitteln oder Beantworten der anfänglichen ICE-Beschreibung übermittelt, aber innerhalb derselben ICE-Sitzung. Getricklete Kandidaten können parallel zur Kandidatensammlung und zu Konnektivitätsprüfungen übermittelt werden.

Trickling: Der Akt des schrittweisen Übermittelns von getrickleten Kandidaten.

3. Determining Support for Trickle ICE (Bestimmung der Unterstützung für Trickle ICE)​

Um Trickle ICE vollständig zu unterstützen, sollten (SHOULD) verwendende Protokolle einen der folgenden Mechanismen integrieren, damit Implementierungen bestimmen können, ob Trickle ICE unterstützt wird:

  1. Eine Fähigkeitsentdeckungsmethode bereitstellen, damit Agents die Unterstützung von Trickle ICE vor dem Initiieren einer Sitzung überprüfen können (XMPPs Service Discovery [XEP-0030] ist ein solcher Mechanismus).

  2. Die Unterstützung für Trickle ICE obligatorisch machen, damit User Agents Unterstützung annehmen können.

Wenn ein verwendendes Protokoll keine Methode bereitstellt, um im Voraus zu bestimmen, ob Trickle ICE unterstützt wird, können Agents die in Abschnitt 16 beschriebene Half-Trickle-Prozedur verwenden.

Vor der Übermittlung der anfänglichen ICE-Beschreibung können Agents, die verwendende Protokolle implementieren, die Fähigkeitsentdeckung unterstützen, versuchen zu überprüfen, ob die entfernte Partei Trickle ICE unterstützt oder nicht. Wenn ein Agent feststellt, dass die entfernte Partei Trickle ICE nicht unterstützt, muss (MUST) er auf die Verwendung von regulärem ICE zurückgreifen oder die gesamte Sitzung abbrechen.

Auch wenn ein verwendendes Protokoll keine Fähigkeitsentdeckungsmethode enthält, kann ein User Agent innerhalb der ICE-Beschreibung angeben, dass er Trickle ICE unterstützt, indem er eine ICE-Option von 'trickle' kommuniziert. Dieses Token muss (MUST) entweder auf Sitzungsebene oder, wenn auf Datenstromebene, für jeden Datenstrom bereitgestellt werden (ein Agent darf nicht (MUST NOT) Trickle-ICE-Unterstützung für einige Datenströme angeben, aber nicht für andere). Hinweis: Die Codierung der 'trickle'-ICE-Option und die Nachricht(en), die verwendet werden, um sie an den Peer zu übermitteln, sind protokollspezifisch; zum Beispiel ist die Codierung für SDP [RFC4566] in [RFC8840] definiert.

Dedizierte Entdeckungssemantik und Half Trickle werden nur vor der Initiierung einer ICE-Sitzung benötigt. Nachdem eine ICE-Sitzung hergestellt und Trickle-ICE-Unterstützung für beide Parteien bestätigt wurde, kann jeder Agent für nachfolgende Austausche vollständiges Trickle verwenden (siehe auch Abschnitt 15).

4. Generating the Initial ICE Description (Generierung der anfänglichen ICE-Beschreibung)​

Ein ICE-Agent kann mit dem Sammeln von Kandidaten beginnen, sobald er eine Anzeige hat, dass Kommunikation bevorsteht (z. B. ein Benutzeroberflächenhinweis oder eine explizite Anforderung zum Initiieren einer Kommunikationssitzung). Im Gegensatz zu regulärem ICE müssen Trickle-ICE-Implementierungen Kandidaten nicht blockierend sammeln. Daher wird, sofern nicht Half Trickle verwendet wird, die Benutzererfahrung verbessert, wenn der initiierende Agent seine anfängliche ICE-Beschreibung so früh wie möglich generiert und überträgt (wodurch die entfernte Partei mit dem Sammeln und Tricklen von Kandidaten beginnen kann).

Ein Initiator kann (MAY) beim Übermitteln der anfänglichen ICE-Beschreibung eine beliebige Mischung von Kandidaten einbeziehen. Dies umfasst die Möglichkeit, alle Kandidaten zu übermitteln, die der Initiator zu verwenden plant (wie beim Half Trickle), nur eine öffentlich erreichbare IP-Adresse zu übermitteln (z. B. einen Kandidaten an einem Datenrelais, von dem bekannt ist, dass es sich nicht hinter einer Firewall befindet), oder überhaupt keine Kandidaten zu übermitteln (in diesem Fall kann der Initiator die anfängliche Kandidatenliste des Responders früher erhalten, und der Responder kann schneller mit dem Sammeln von Kandidaten beginnen).

Für Kandidaten, die in der anfänglichen ICE-Beschreibung enthalten sind, funktionieren die Methoden zur Berechnung von Prioritäten und Foundations, zur Bestimmung der Redundanz von Kandidaten und dergleichen genauso wie bei regulärem ICE [RFC8445].

5. Handling the Initial ICE Description and Generating the Initial ICE Response (Verarbeitung der anfänglichen ICE-Beschreibung und Generierung der anfänglichen ICE-Antwort)​

Wenn ein Responder die anfängliche ICE-Beschreibung erhält, überprüft er zunächst, ob die ICE-Beschreibung oder der Initiator die Unterstützung für Trickle ICE anzeigt, wie in Abschnitt 3 erläutert. Wenn nicht, muss (MUST) der Responder die anfängliche ICE-Beschreibung gemäß den regulären ICE-Verfahren [RFC8445] verarbeiten (oder, wenn überhaupt keine ICE-Unterstützung erkannt wird, gemäß relevanten Verarbeitungsregeln für das verwendende Protokoll, wie z. B. Angebot/Antwort-Verarbeitungsregeln [RFC3264]). Wenn jedoch die Unterstützung für Trickle ICE bestätigt wird, geht ein Responder automatisch auch von der Unterstützung für reguläres ICE aus.

Wenn die anfängliche ICE-Beschreibung die Unterstützung für Trickle ICE anzeigt, bestimmt der Responder seine Rolle und beginnt mit dem Sammeln und Priorisieren von Kandidaten; dabei antwortet er auch, indem er eine anfängliche ICE-Antwort übermittelt, sodass sowohl der Initiator als auch der Responder Checklisten bilden und Konnektivitätsprüfungen beginnen können.

Ein Responder kann zu jedem Zeitpunkt während des Sammelns von Kandidaten auf die anfängliche ICE-Beschreibung antworten. Die anfängliche ICE-Antwort kann (MAY) eine beliebige Menge von Kandidaten enthalten, einschließlich aller Kandidaten oder keiner Kandidaten. (Der Vorteil, keine Kandidaten einzuschließen, besteht darin, die anfängliche ICE-Antwort so schnell wie möglich zu übermitteln, sodass beide Parteien die ICE-Sitzung so früh wie möglich als aktiv verhandelt betrachten können.)

Wie in Abschnitt 3 erwähnt, kann in Protokollen, die SDP verwenden, die anfängliche ICE-Antwort die Unterstützung für Trickle ICE anzeigen, indem sie ein 'trickle'-Token im ice-options-Attribut enthält.

8. Performing Connectivity Checks (Durchführung von Konnektivitätsprüfungen)​

Wie in [RFC8445] spezifiziert, werden jedes Mal, wenn Timer Ta ausgelöst wird, nur Checklisten im Zustand Laufend (Running) ausgewählt, wenn Konnektivitätsprüfungen für Kandidatenpaare geplant werden. Daher muss (MUST) ein Trickle-ICE-Agent jede Checkliste im Zustand Laufend halten, solange erwartet wird, dass Kandidatenpaare schrittweise zur Checkliste hinzugefügt werden. Danach wird der Checklistenstatus gemäß den Verfahren in [RFC8445] festgelegt.

Jedes Mal, wenn Timer Ta ausgelöst wird und eine leere Checkliste ausgewählt wird, wird für diese Liste keine Aktion durchgeführt. Ohne darauf zu warten, dass Timer Ta erneut abläuft, wählt der Agent die nächste Checkliste im Zustand Laufend gemäß Abschnitt 6.1.4.2 von [RFC8445] aus.

Abschnitt 7.2.5.4 von [RFC8445] verlangt, dass Agents Checklisten und Timer-Zustände nach Abschluss einer Konnektivitätsprüfungstransaktion aktualisieren. Während einer solchen Aktualisierung würden reguläre ICE-Agents den Zustand einer Checkliste auf Fehlgeschlagen (Failed) setzen, wenn beide der folgenden zwei Bedingungen erfüllt sind:

  • alle Paare in der Checkliste befinden sich entweder im Zustand Fehlgeschlagen (Failed) oder im Zustand Erfolgreich (Succeeded); und

  • es gibt kein Paar in der gültigen Liste für jede Komponente des Datenstroms.

Bei Trickle ICE würde die oben genannte Situation häufig auftreten, wenn das Sammeln von Kandidaten und das Tricklen noch im Gange sind, obwohl es durchaus möglich ist, dass zukünftige Prüfungen erfolgreich sein werden. Aus diesem Grund fügen Trickle-ICE-Agents der obigen Liste die folgenden Bedingungen hinzu:

  • das gesamte Sammeln von Kandidaten ist abgeschlossen, und der Agent erwartet nicht, neue lokale Kandidaten zu entdecken; und

  • der entfernte Agent hat eine End-of-Candidates-Anzeige für diese Checkliste übermittelt, wie in Abschnitt 13 beschrieben.

9. Gathering and Conveying Newly Gathered Local Candidates (Sammeln und Übermitteln neu gesammelter lokaler Kandidaten)​

Nachdem Trickle-ICE-Agents anfängliche ICE-Beschreibungen und anfängliche ICE-Antworten übermittelt haben, werden sie höchstwahrscheinlich weiterhin neue lokale Kandidaten sammeln, da STUN-, TURN- und andere Nicht-Host-Kandidatensammelmechanismen Ergebnisse zu liefern beginnen. Immer wenn ein Agent einen solchen neuen Kandidaten entdeckt, berechnet er seine Priorität, seinen Typ, seine Foundation und seine Komponenten-ID gemäß den regulären ICE-Verfahren.

Der neue Kandidat wird dann auf Redundanz gegenüber der vorhandenen Liste lokaler Kandidaten überprüft. Wenn seine Transportadresse und Basis mit denen eines vorhandenen Kandidaten übereinstimmen, wird er als redundant betrachtet und ignoriert. Dies würde häufig bei serverreflexiven Kandidaten vorkommen, die mit den Hostadressen übereinstimmen, von denen sie erhalten wurden (z. B. wenn letztere öffentliche IPv4-Adressen sind). Im Gegensatz zu regulärem ICE werden Trickle-ICE-Agents den neuen Kandidaten unabhängig von seiner Priorität als redundant betrachten.

Als Nächstes „tricklet" der Agent den/die neu entdeckten Kandidaten zum entfernten Agent. Die tatsächliche Zustellung der neuen Kandidaten wird von einem verwendenden Protokoll wie SIP oder XMPP gehandhabt. Trickle ICE legt keine Einschränkungen fest, wie dies geschieht (z. B. könnten sich einige verwendende Protokolle dafür entscheiden, keine Updates für serverreflexive Kandidaten zu tricklen, sondern sich stattdessen auf die Entdeckung von peer-reflexiven Kandidaten zu verlassen).

Wenn Kandidaten getricklet werden, muss (MUST) das verwendende Protokoll jeden Kandidaten (und jede End-of-Candidates-Anzeige, wie in Abschnitt 13 beschrieben) der empfangenden Trickle-ICE-Implementierung genau einmal und in derselben Reihenfolge zustellen, in der er übermittelt wurde. Wenn das verwendende Protokoll Kandidatenretransmissionen bereitstellt, müssen diese vor der ICE-Implementierung verborgen werden.

Außerdem muss das Kandidaten-Trickling mit einer bestimmten ICE-Sitzung korreliert werden, damit im Falle eines ICE-Neustarts verzögerte Updates für eine vorherige Sitzung als solche erkannt und von der empfangenden Partei ignoriert werden können. Zum Beispiel könnten verwendende Protokolle, die Kandidaten über SDP signalisieren, einen Username-Fragment-Wert in der entsprechenden a=candidate-Zeile enthalten, wie z. B.:

a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY

Oder, als ein weiteres Beispiel, könnten WebRTC-Implementierungen ein Username-Fragment in die JavaScript-Objekte aufnehmen, die Kandidaten darstellen.

Hinweis: Das verwendende Protokoll muss einen Mechanismus bereitstellen, mit dem beide Parteien die gültige ICE-Sitzung (identifiziert durch die Kombination aus Username-Fragment und Passwort) angeben und darüber einig werden können, damit sie eine konsistente Ansicht darüber haben, welche Kandidaten gepaart werden sollen. Dies ist besonders wichtig im Falle von ICE-Neustarts (siehe Abschnitt 15).

Hinweis: Ein verwendendes Protokoll könnte es vorziehen, serverreflexive Kandidaten nicht an Entitäten zu tricklen, von denen bekannt ist, dass sie öffentlich zugänglich sind und bei denen das Senden einer direkten STUN-Binding-Anfrage das Ziel wahrscheinlich schneller erreicht als das Trickle-Update, das über den Signalisierungspfad läuft.

10. Pairing Newly Gathered Local Candidates (Pairing neu gesammelter lokaler Kandidaten)​

Wenn ein Trickle-ICE-Agent lokale Kandidaten sammelt, muss er Kandidatenpaare bilden; dies funktioniert wie in der ICE-Spezifikation [RFC8445] beschrieben, mit den folgenden Bedingungen:

  1. Ein Trickle-ICE-Agent darf nicht (MUST NOT) einen lokalen Kandidaten paaren, bis er zur entfernten Partei getricklet wurde.

  2. Sobald der Agent den lokalen Kandidaten zur entfernten Partei übermittelt hat, überprüft der Agent, ob derzeit entfernte Kandidaten für denselben Stream und dieselbe Komponente bekannt sind. Wenn nicht, fügt der Agent den neuen Kandidaten lediglich zur Liste der lokalen Kandidaten hinzu (ohne ihn zu paaren).

  3. Andernfalls, wenn der Agent bereits von einem oder mehreren entfernten Kandidaten für diesen Stream und diese Komponente erfahren hat, versucht er, den neuen lokalen Kandidaten zu paaren, wie in der ICE-Spezifikation [RFC8445] beschrieben.

  4. Wenn ein neu gebildetes Paar einen lokalen Kandidaten hat, dessen Typ serverreflexiv (server-reflexive) ist, muss (MUST) der Agent den lokalen Kandidaten durch seine Basis ersetzen, bevor er die relevanten Redundanztests abschließt.

  5. Der Agent beschneidet redundante Paare, indem er den Regeln in Abschnitt 6.1.2.4 von [RFC8445] folgt, überprüft jedoch vorhandene Paare nur, wenn sie einen Zustand Wartend (Waiting) oder Eingefroren (Frozen) haben; dies vermeidet das Entfernen von Paaren, für die Konnektivitätsprüfungen laufen (ein Zustand In Bearbeitung (In-Progress)) oder für die Konnektivitätsprüfungen bereits ein eindeutiges Ergebnis erbracht haben (ein Zustand Erfolgreich (Succeeded) oder Fehlgeschlagen (Failed)).

  6. Wenn nach Abschluss der relevanten Redundanztests die Checkliste, zu der das Paar hinzugefügt werden soll, bereits die maximale Anzahl von Kandidatenpaaren enthält (standardmäßig 100 gemäß [RFC8445]), sollte (SHOULD) der Agent alle Paare im Zustand Fehlgeschlagen verwerfen, um Platz für das neue Paar zu schaffen. Wenn es keine solchen Paare gibt, sollte (SHOULD) der Agent ein Paar mit niedrigerer Priorität als das neue Paar verwerfen, um Platz für das neue Paar zu schaffen, bis die Anzahl der Paare gleich der maximalen Anzahl von Paaren ist. Diese Verarbeitung ist konsistent mit Abschnitt 6.1.2.5 von [RFC8445].

11. Receiving Trickled Candidates (Empfangen getrickleter Kandidaten)​

Zu jedem Zeitpunkt während einer ICE-Sitzung kann ein Trickle-ICE-Agent neue Kandidaten vom entfernten Agent empfangen, aus denen er versuchen wird, ein Kandidatenpaar zu bilden; dies funktioniert wie in der ICE-Spezifikation [RFC8445] beschrieben, mit den folgenden Bedingungen:

  1. Der Agent überprüft, ob derzeit lokale Kandidaten für denselben Stream und dieselbe Komponente bekannt sind. Wenn nicht, fügt der Agent den neuen Kandidaten lediglich zur Liste der entfernten Kandidaten hinzu (ohne ihn zu paaren).

  2. Andernfalls, wenn der Agent bereits einen oder mehrere lokale Kandidaten für diesen Stream und diese Komponente gesammelt hat, versucht er, den neuen entfernten Kandidaten zu paaren, wie in der ICE-Spezifikation [RFC8445] beschrieben.

  3. Wenn ein neu gebildetes Paar einen lokalen Kandidaten hat, dessen Typ serverreflexiv (server-reflexive) ist, muss (MUST) der Agent den lokalen Kandidaten durch seine Basis ersetzen, bevor er die Redundanzprüfung im nächsten Schritt abschließt.

  4. Der Agent beschneidet redundante Paare wie unten beschrieben, überprüft jedoch vorhandene Paare nur, wenn sie einen Zustand Wartend (Waiting) oder Eingefroren (Frozen) haben; dies vermeidet das Entfernen von Paaren, für die Konnektivitätsprüfungen laufen (ein Zustand In Bearbeitung (In-Progress)) oder für die Konnektivitätsprüfungen bereits ein eindeutiges Ergebnis erbracht haben (ein Zustand Erfolgreich (Succeeded) oder Fehlgeschlagen (Failed)).

    A. Wenn der Agent eine Redundanz zwischen zwei Paaren findet und eines dieser Paare einen neu empfangenen entfernten Kandidaten enthält, dessen Typ peer-reflexiv ist, sollte (SHOULD) der Agent das Paar verwerfen, das diesen Kandidaten enthält, die Priorität des vorhandenen Paares auf die Priorität des verworfenen Paares setzen und die Checkliste neu sortieren. (Diese Richtlinie hilft, Probleme mit entfernten peer-reflexiven Kandidaten zu beseitigen, für die eine STUN-Binding-Anfrage empfangen wird, bevor die Signalisierung des Kandidaten zum empfangenden Agent getricklet wird, wie z. B. eine unterschiedliche Ansicht der Paar-Prioritäten zwischen dem lokalen Agent und dem entfernten Agent, da derselbe Kandidat von einem Agent als peer-reflexiv und vom anderen Agent als serverreflexiv wahrgenommen werden könnte.)

    B. Der Agent wendet dann die in Abschnitt 6.1.2.4 von [RFC8445] definierten Regeln an.

  5. Wenn nach Abschluss der relevanten Redundanztests die Checkliste, zu der das Paar hinzugefügt werden soll, bereits die maximale Anzahl von Kandidatenpaaren enthält (standardmäßig 100 gemäß [RFC8445]), sollte (SHOULD) der Agent alle Paare im Zustand Fehlgeschlagen verwerfen, um Platz für das neue Paar zu schaffen. Wenn es keine solchen Paare gibt, sollte (SHOULD) der Agent ein Paar mit niedrigerer Priorität als das neue Paar verwerfen, um Platz für das neue Paar zu schaffen, bis die Anzahl der Paare gleich der maximalen Anzahl von Paaren ist. Diese Verarbeitung ist konsistent mit Abschnitt 6.1.2.5 von [RFC8445].

12. Inserting Trickled Candidate Pairs into a Checklist (Einfügen getrickleter Kandidatenpaare in eine Checkliste)​

Nachdem der lokale Agent einen Kandidaten getricklet und aus diesem lokalen Kandidaten ein Kandidatenpaar gebildet hat (Abschnitt 9), oder nachdem der entfernte Agent einen getrickleten Kandidaten empfangen und aus diesem entfernten Kandidaten ein Kandidatenpaar gebildet hat (Abschnitt 11), fügt der Trickle-ICE-Agent das neue Kandidatenpaar der Checkliste wie in diesem Abschnitt definiert hinzu.

Um das Verständnis der in diesem Abschnitt definierten Verfahren zu erleichtern, betrachten Sie die folgende tabellarische Darstellung aller Checklisten in einem Agent (beachten Sie, dass anfänglich für eine der Foundations, nämlich f5, keine Kandidatenpaare vorhanden sind):

+=================+====+====+====+====+====+
|                 | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
|| s1 (Audio.RTP)  | F  | F  | F  |    |    |
+-----------------+----+----+----+----+----+
|| s2 (Audio.RTCP) | F  | F  | F  | F  |    |
+-----------------+----+----+----+----+----+
|| s3 (Video.RTP)  | F  |    |    |    |    |
+-----------------+----+----+----+----+----+
|| s4 (Video.RTCP) | F  |    |    |    |    |
+-----------------+----+----+----+----+----+

Tabelle 1: Beispiel-Checklistenstatus

Jede Zeile in der Tabelle repräsentiert eine Komponente eines bestimmten Datenstroms (z. B. könnten s1 und s2 die RTP- und RTP-Kontrollprotokoll (RTCP)-Komponenten von Audio sein) und ist daher eine einzelne Checkliste im Checklistensatz. Jede Spalte repräsentiert eine Foundation. Jede Zelle repräsentiert ein Kandidatenpaar. In den in diesem Abschnitt gezeigten Tabellen steht "F" für "Eingefroren (frozen)", "W" für "Wartend (waiting)", "S" für "Erfolgreich (succeeded)"; außerdem wird "^^" verwendet, um neu hinzugefügte Kandidatenpaare zu kennzeichnen.

Wenn der Agent die ICE-Verarbeitung gemäß Abschnitt 6.1.2.6 von [RFC8445] startet, taut er für jede Foundation das Kandidatenpaar mit der niedrigsten Komponenten-ID oder, wenn die Komponenten-IDs gleich sind, das Kandidatenpaar mit der höchsten Priorität auf (dies ist das oberste Kandidatenpaar in jeder Spalte). Dieser anfängliche Zustand ist in der folgenden Tabelle dargestellt.

+=================+====+====+====+====+====+
|                 | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
|| s1 (Audio.RTP)  | W  | W  | W  |    |    |
+-----------------+----+----+----+----+----+
|| s2 (Audio.RTCP) | F  | F  | F  | W  |    |
+-----------------+----+----+----+----+----+
|| s3 (Video.RTP)  | F  |    |    |    |    |
+-----------------+----+----+----+----+----+
|| s4 (Video.RTCP) | F  |    |    |    |    |
+-----------------+----+----+----+----+----+

Tabelle 2: Anfänglicher Checklistenstatus

Dann, während die Prüfungen ablaufen (siehe Abschnitt 7.2.5.4 von [RFC8445]), taut der Agent für jedes Kandidatenpaar, das in den Zustand Erfolgreich (hier mit "S" bezeichnet) übergeht, alle Kandidatenpaare aller Datenströme mit derselben Foundation auf (z. B. wenn das Kandidatenpaar in Spalte 1, Zeile 1 erfolgreich ist, taut der Agent die Kandidatenpaare in Spalte 1, Zeilen 2, 3 und 4 auf).

+=================+====+====+====+====+====+
|                 | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
|| s1 (Audio.RTP)  | S  | W  | W  |    |    |
+-----------------+----+----+----+----+----+
|| s2 (Audio.RTCP) | W  | F  | F  | W  |    |
+-----------------+----+----+----+----+----+
|| s3 (Video.RTP)  | W  |    |    |    |    |
+-----------------+----+----+----+----+----+
|| s4 (Video.RTCP) | W  |    |    |    |    |
+-----------------+----+----+----+----+----+

Tabelle 3: Checklistenstatus mit erfolgreichem Kandidatenpaar

Trickle ICE behält alle diese Regeln bei, wie sie auf den „statischen" Checklistensatz angewendet werden. Dies bedeutet, dass, wenn ein Trickle-ICE-Agent Konnektivitätsprüfungen startet, während alle Kandidatenpaare bereits vorhanden sind, die Art und Weise, wie sich die Kandidatenpaarzustände ändern, nicht von einem regulären ICE-Agent unterscheidbar ist.

Natürlich besteht der Hauptunterschied bei Trickle ICE darin, dass der Checklistensatz dynamisch aktualisiert werden kann, da Kandidaten nach dem Start der Konnektivitätsprüfungen eintreffen können. Wenn dies geschieht, setzt der Agent den Zustand des neu gebildeten Kandidatenpaares wie unten beschrieben.

Regel 1: Setzen Sie den Zustand auf Wartend (Waiting), wenn das neu gebildete Kandidatenpaar die niedrigste Komponenten-ID aller Kandidatenpaare für diese Foundation oder, wenn die Komponenten-IDs gleich sind, die höchste Priorität hat (d. h. wenn es das oberste Kandidatenpaar in der Spalte ist). Dies wäre der Fall, wenn das neu gebildete Kandidatenpaar z. B. in Spalte 5, Zeile 1 platziert wird. Diese Regel ist konsistent mit Abschnitt 6.1.2.6 von [RFC8445].

+=================+====+====+====+====+=====+
|                 | f1 | f2 | f3 | f4 | f5  |
+=================+====+====+====+====+=====+
|| s1 (Audio.RTP)  | S  | W  | W  |    | ^W^ |
+-----------------+----+----+----+----+-----+
|| s2 (Audio.RTCP) | W  | F  | F  | W  |     |
+-----------------+----+----+----+----+-----+
|| s3 (Video.RTP)  | W  |    |    |    |     |
+-----------------+----+----+----+----+-----+
|| s4 (Video.RTCP) | W  |    |    |    |     |
+-----------------+----+----+----+----+-----+

Tabelle 4: Checklistenstatus mit neu gebildetem Kandidatenpaar, Regel 1

Regel 2: Setzen Sie den Zustand auf Wartend (Waiting), wenn es für diese Foundation mindestens ein Kandidatenpaar im Zustand Erfolgreich gibt. Dies wäre der Fall, wenn z. B. das Kandidatenpaar in Spalte 5, Zeile 1 erfolgreich ist und das neu gebildete Kandidatenpaar in Spalte 5, Zeile 2 platziert wird. Diese Regel ist konsistent mit Abschnitt 7.2.5.3.3 von [RFC8445].

+=================+====+====+====+====+=====+
|                 | f1 | f2 | f3 | f4 | f5  |
+=================+====+====+====+====+=====+
|| s1 (Audio.RTP)  | S  | W  | W  |    | S   |
+-----------------+----+----+----+----+-----+
|| s2 (Audio.RTCP) | W  | F  | F  | W  | ^W^ |
+-----------------+----+----+----+----+-----+
|| s3 (Video.RTP)  | W  |    |    |    | ^W^ |
+-----------------+----+----+----+----+-----+
|| s4 (Video.RTCP) | W  |    |    |    | ^W^ |
+-----------------+----+----+----+----+-----+

Tabelle 5: Checklistenstatus mit neu gebildetem Kandidatenpaar, Regel 2

Regel 3: Setzen Sie den Zustand auf Eingefroren (Frozen), wenn keine der vorherigen Regeln zutrifft.

Beachten Sie, dass selbst wenn ein Kandidatenpaar in den Zustand Wartend versetzt wird, die Regeln von [RFC8445] immer noch gelten, sodass Konnektivitätsprüfungen nur von Checklisten im Zustand Laufend ausgeführt werden. Daher ist es möglich, dass ein Kandidatenpaar mehrmals den Zustand zwischen Wartend und Eingefroren ändert, bis eine Konnektivitätsprüfung tatsächlich für dieses Paar durchgeführt wird.

13. Generating an End-of-Candidates Indication (Generierung einer End-of-Candidates-Anzeige)​

Sobald das gesamte Sammeln von Kandidaten für eine ICE-Sitzung, die mit einem bestimmten Datenstrom verbunden ist, abgeschlossen ist oder abläuft, generiert der Agent eine „End-of-Candidates"-Anzeige für diese Sitzung und übermittelt sie über den Signalisierungskanal an den entfernten Agent. Obwohl die genaue Form der Anzeige vom verwendenden Protokoll abhängt, MUSS (MUST) die Anzeige die Generation (Kombination aus Username-Fragment und Passwort) angeben, damit ein Agent die End-of-Candidates-Anzeige mit einer bestimmten ICE-Sitzung korrelieren kann. Die Anzeige kann auf folgende Weise übermittelt werden:

  • Als Teil einer Initiierungsanfrage (was typischerweise bei der anfänglichen ICE-Beschreibung für Half Trickle der Fall wäre)
  • Zusammen mit dem letzten Kandidaten, den ein Agent für einen Stream senden kann
  • Als eigenständige Benachrichtigung (z. B. nachdem STUN-Binding-Anfragen oder TURN-Allocate-Anfragen an einen Server eine Zeitüberschreitung aufweisen und der Agent keine Kandidaten mehr aktiv sammelt)

Die rechtzeitige Übermittlung einer End-of-Candidates-Anzeige ist wichtig, um Unklarheiten zu vermeiden und den Abschluss der ICE-Verarbeitung zu beschleunigen. Insbesondere:

  • Ein kontrollierter Trickle-ICE-Agent SOLLTE (SHOULD) eine End-of-Candidates-Anzeige übermitteln, nachdem er das Sammeln für einen Datenstrom abgeschlossen hat, es sei denn, die ICE-Verarbeitung wird beendet, bevor der Agent die Gelegenheit hatte, das Sammeln abzuschließen.
  • Ein kontrollierender Agent KANN (MAY) die ICE-Verarbeitung vor der Übermittlung von End-of-Candidates-Anzeigen für alle Streams abschließen. Es wird jedoch EMPFOHLEN (RECOMMENDED), dass ein kontrollierender Agent End-of-Candidates-Anzeigen wann immer möglich übermittelt, um der Konsistenz willen und um Middleboxen und kontrollierte Agents über den Status der ICE-Verarbeitung auf dem Laufenden zu halten.

Bei der Übermittlung einer End-of-Candidates-Anzeige während des Tricklens (und nicht als Teil der anfänglichen ICE-Beschreibung oder einer Antwort darauf) liegt es in der Verantwortung des verwendenden Protokolls, Methoden zur Zuordnung der Anzeige zu einem oder mehreren bestimmten Datenströmen zu definieren.

Ein Agent KANN (MAY) auch wählen, eine End-of-Candidates-Anzeige zu generieren, bevor das Sammeln von Kandidaten tatsächlich abgeschlossen ist, wenn der Agent feststellt, dass das Sammeln länger als einen akzeptablen Zeitraum fortgesetzt wurde. Ein Agent DARF (MUST NOT) jedoch keine weiteren Kandidaten übermitteln, nachdem er eine End-of-Candidates-Anzeige übermittelt hat.

Beim Ausführen von Half Trickle SOLLTE (SHOULD) ein Agent eine End-of-Candidates-Anzeige zusammen mit seiner anfänglichen ICE-Beschreibung übermitteln, es sei denn, er plant möglicherweise zusätzliche Kandidaten zu tricklen (z. B. falls die entfernte Partei Trickle ICE unterstützt).

Nachdem ein Agent die End-of-Candidates-Anzeige übermittelt hat, aktualisiert er den Zustand der entsprechenden Checkliste wie in Abschnitt 8 erläutert. Von diesem Punkt an DARF (MUST NOT) ein Agent keine neuen Kandidaten innerhalb dieser ICE-Sitzung mehr tricklen. Daher ist das Hinzufügen neuer Kandidaten zur Verhandlung nur durch einen ICE-Neustart möglich (siehe Abschnitt 15).

Diese Spezifikation überschreibt nicht die reguläre ICE-Semantik für den Abschluss der ICE-Verarbeitung. Daher muss ein Agent auch dann noch die Paar-Nominierung durchlaufen, wenn End-of-Candidates-Anzeigen übermittelt wurden. Auch wenn Paare für Komponenten und Datenströme nominiert wurden, KANN (MAY) die ICE-Verarbeitung noch abgeschlossen werden, selbst wenn End-of-Candidates-Anzeigen nicht für alle Streams empfangen wurden. In allen Fällen DARF (MUST NOT) ein Agent keine neuen Kandidaten innerhalb einer ICE-Sitzung nach der Nominierung eines Kandidatenpaares gemäß Abschnitt 8.1.1 von [RFC8445] trickeln.

14. Receiving an End-of-Candidates Indication (Empfangen einer End-of-Candidates-Anzeige)​

Der Empfang einer End-of-Candidates-Anzeige ermöglicht es einem Agent, Checklistenzustände zu aktualisieren und, falls keine gültigen Paare für jede Komponente in jedem Datenstrom existieren, festzustellen, dass die ICE-Verarbeitung fehlgeschlagen ist. Es ermöglicht einem Agent auch, den Abschluss der ICE-Verarbeitung zu beschleunigen, wenn ein Kandidatenpaar validiert wurde, aber einen Transport mit niedrigerer Präferenz wie TURN verwendet. In solchen Situationen KANN (MAY) eine Implementierung wählen, zu warten und zu sehen, ob Kandidaten mit höherer Priorität empfangen werden; in diesem Fall liefert die End-of-Candidates-Anzeige eine Benachrichtigung, dass solche Kandidaten nicht kommen werden.

Wenn ein Agent eine End-of-Candidates-Anzeige für einen bestimmten Datenstrom empfängt, aktualisiert er den Zustand der relevanten Checkliste gemäß Abschnitt 8 (was dazu führen könnte, dass einige Checklisten als Fehlgeschlagen markiert werden). Wenn sich die Checkliste nach der Aktualisierung noch im Zustand Laufend (Running) befindet, wird der Agent vermerken, dass eine End-of-Candidates-Anzeige empfangen wurde, und dies bei zukünftigen Aktualisierungen der Checkliste berücksichtigen.

Nachdem ein Agent eine End-of-Candidates-Anzeige empfangen hat, MUSS (MUST) er alle neu empfangenen Kandidaten für diesen Datenstrom oder diese Datensitzung ignorieren.

15. Subsequent Exchanges and ICE Restarts (Nachfolgende Austausche und ICE-Neustarts)​

Vor der Übermittlung einer End-of-Candidates-Anzeige KANN (MAY) jeder Agent nachfolgende Kandidateninformationen zu jedem vom verwendenden Protokoll erlaubten Zeitpunkt übermitteln. Wenn dies geschieht, verwenden die Agenten Semantiken aus [RFC8445] (z. B. Überprüfung der Kombination aus Benutzername-Fragment und Passwort), um festzustellen, ob die neuen Kandidateninformationen einen ICE-Neustart erfordern oder nicht.

Wenn ein ICE-Neustart auftritt, können die Agenten davon ausgehen, dass Trickle ICE weiterhin unterstützt wird, wenn die Unterstützung zuvor festgestellt wurde; daher können sie sich auf Trickle-ICE-Verhalten einlassen, wie sie es bei einem anfänglichen Austausch von ICE-Beschreibungen tun würden, bei denen die Unterstützung durch eine Fähigkeitsentdeckungsmethode festgestellt wurde.

16. Half Trickle (Half Trickle)​

Bei Half Trickle übermittelt der Initiator die anfängliche ICE-Beschreibung mit einer verwendbaren, aber nicht unbedingt vollständigen Generation von Kandidaten. Dies stellt sicher, dass die ICE-Beschreibung von einem regulären ICE-Responder verarbeitet werden kann und ist hauptsächlich für Fälle gedacht, in denen die Unterstützung für Trickle ICE nicht bestätigt werden kann, bevor die anfängliche ICE-Beschreibung übermittelt wird. Die anfängliche ICE-Beschreibung zeigt Unterstützung für Trickle ICE an, sodass der Responder mit weniger als einer vollständigen Generation von Kandidaten antworten und dann den Rest tricklen kann. Die anfängliche ICE-Beschreibung für Half Trickle kann eine Ende-der-Kandidaten-Anzeige enthalten, obwohl dies nicht zwingend erforderlich ist, da der Initiator, wenn Trickle-Unterstützung bestätigt wird, wählen kann, zusätzliche Kandidaten zu tricklen, bevor er eine Ende-der-Kandidaten-Anzeige übermittelt.

Der Half-Trickle-Mechanismus kann in Fällen verwendet werden, in denen ein Agent keine Möglichkeit hat, im Voraus zu überprüfen, ob eine entfernte Partei Trickle ICE unterstützt. Da die anfängliche ICE-Beschreibung eine vollständige Generation von Kandidaten enthält, kann sie von einem regulären ICE-Agent behandelt werden, während einem Trickle-ICE-Agent weiterhin die in dieser Spezifikation definierte Optimierung ermöglicht wird. Dies verhindert, dass die Verhandlung im ersteren Fall fehlschlägt, während im letzteren Fall immer noch etwa die Hälfte der Trickle-ICE-Vorteile gewährt wird.

Die Verwendung von Half Trickle ist nur während eines anfänglichen Austauschs von ICE-Beschreibungen erforderlich. Nachdem beide Parteien eine ICE-Beschreibung von ihrem Peer erhalten haben, können sie jeweils zuverlässig die Trickle-ICE-Unterstützung bestimmen und sie für alle nachfolgenden Austausche verwenden (siehe Abschnitt 15).

In einigen Fällen kann die Verwendung von Half Trickle mehr als nur die Hälfte der Verbesserung in Bezug auf die Benutzererfahrung bringen. Dies kann passieren, wenn ein Agent beginnt, Kandidaten aufgrund von Benutzeroberflächenhinweisen zu sammeln, dass der Benutzer bald eine Interaktion initiieren wird, wie z. B. Aktivität auf einer Tastatur oder das Abnehmen des Telefons. Dies würde bedeuten, dass ein Teil oder die gesamte Kandidatensammlung abgeschlossen werden könnte, bevor der Agent die Kandidateninformationen tatsächlich übermitteln muss. Da der Responder Kandidaten tricklen kann, können beide Agenten Konnektivitätsprüfungen früher starten und die ICE-Verarbeitung früher als mit regulärem ICE abschließen und möglicherweise sogar so früh wie mit vollständigem Trickle.

Eine solche Antizipation ist jedoch nicht immer möglich. Zum Beispiel hätte ein Mehrzweck-User-Agent oder eine WebRTC-Webseite, bei der Kommunikation eine nicht zentrale Funktion ist (z. B. Anrufen einer Support-Hotline bei einem Problem mit den Hauptfunktionen), nicht unbedingt eine Möglichkeit, zwischen Anrufabsichten und anderen Benutzeraktivitäten zu unterscheiden. In solchen Fällen führt die Verwendung von vollständigem Trickle am ehesten zu einer idealen Benutzererfahrung. Dennoch wäre die Verwendung von Half Trickle eine Verbesserung gegenüber regulärem ICE, da sie zu einer besseren Erfahrung für Responder führen würde.

18. Requirements for Using Protocols (Anforderungen für die Verwendung von Protokollen)​

Um die Verwendung von Trickle ICE vollständig zu ermöglichen, definiert diese Spezifikation die folgenden Anforderungen für verwendende Protokolle.

  • Ein verwendendes Protokoll SOLLTE (SHOULD) eine Möglichkeit bieten, dass Parteien die Unterstützung für Trickle ICE ankündigen und entdecken können, bevor eine ICE-Sitzung beginnt (siehe Abschnitt 3).

  • Ein verwendendes Protokoll MUSS (MUST) Methoden bereitstellen, um nach der Übermittlung der anfänglichen ICE-Beschreibung zusätzliche Kandidaten inkrementell zu übermitteln (d. h. zu „trickeln") (siehe Abschnitt 9).

  • Ein verwendendes Protokoll MUSS (MUST) jeden getrickelten Kandidaten oder jede Ende-der-Kandidaten-Anzeige genau einmal und in derselben Reihenfolge liefern, in der sie übermittelt wurde (siehe Abschnitt 9).

  • Ein verwendendes Protokoll MUSS (MUST) einen Mechanismus bereitstellen, mit dem beide Parteien die geltende ICE-Sitzung angeben und vereinbaren können (siehe Abschnitt 9).

  • Ein verwendendes Protokoll MUSS (MUST) eine Möglichkeit bieten, dass Parteien die Ende-der-Kandidaten-Anzeige kommunizieren können, die die bestimmte ICE-Sitzung angeben MUSS (MUST), für die die Anzeige gilt (siehe Abschnitt 13).

19. IANA Considerations (IANA-Überlegungen)​

IANA hat die folgende ICE-Option im Unterregister "ICE Options" des "Interactive Connectivity Establishment (ICE) registry" gemäß den in [RFC6336] definierten Verfahren registriert.

ICE-Option: trickle

Kontakt: IESG <[email protected]>

Änderungsverantwortlicher: IESG

Beschreibung: Eine ICE-Option von 'trickle' zeigt Unterstützung für die inkrementelle Kommunikation von ICE-Kandidaten an.

Referenz: RFC 8838

20. Security Considerations (Sicherheitsüberlegungen)​

Diese Spezifikation erbt den größten Teil ihrer Semantik von [RFC8445], und infolgedessen gelten alle dort beschriebenen Sicherheitsüberlegungen für Trickle ICE.

Wenn die Datenschutzauswirkungen der Offenlegung von Host-Adressen auf einem Endgerät ein Problem darstellen (siehe beispielsweise die Diskussion in [RFC8828] und in Abschnitt 19 von [RFC8445]), können Agenten ICE-Beschreibungen generieren, die keine Kandidaten enthalten, und dann nur Kandidaten trickeln, die keine Host-Adressen offenlegen (z. B. Relay-Kandidaten).

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.