Appendix B. Design Motivations (Design-Motivationen)

ICE enthält eine Reihe normativer Verhaltensweisen, die selbst einfach sein mögen, aber aus komplizierten oder nicht offensichtlichen Überlegungen oder Anwendungsfällen stammen, die eine weitere Diskussion verdienen. Da diese Designmotivationen für Implementierungszwecke nicht verstanden werden müssen, werden sie hier in einem Anhang zur Spezifikation diskutiert. Dieser Abschnitt ist nicht normativ.

B.1. Pacing of STUN Transactions (Taktung von STUN-Transaktionen)

STUN-Transaktionen, die zum Sammeln von Kandidaten und zum Überprüfen der Konnektivität verwendet werden, werden mit einer ungefähren Rate von einer neuen Transaktion alle Ta Millisekunden getaktet. Jede Transaktion hat wiederum einen Neuübertragungstimer RTO, der ebenfalls eine Funktion von Ta ist. Warum werden diese Transaktionen getaktet und warum werden diese Formeln verwendet?

Das Senden dieser STUN-Anforderungen hat oft den Effekt, dass Bindungen auf NAT-Geräten zwischen dem Client und den STUN-Servern erstellt werden. Die Erfahrung hat gezeigt, dass viele NAT-Geräte Obergrenzen für die Rate haben, mit der sie neue Bindungen erstellen. Experimente haben gezeigt, dass einmal alle 20 ms gut unterstützt wird, aber nicht viel weniger als das. Deshalb hat Ta eine Untergrenze von 20 ms. Darüber hinaus nutzt die Übertragung dieser Pakete im Netzwerk Bandbreite und muss vom Agenten ratenbegrenzt werden. Bereitstellungen, die auf früheren Entwurfsversionen dieses Dokuments basierten, neigten dazu, ratenbeschränkte Zugangsleitungen zu überlasten und insgesamt schlecht abzuschneiden, zusätzlich zu negativen Auswirkungen auf das Netzwerk. Infolgedessen stellt die Taktung sicher, dass das NAT-Gerät nicht überlastet wird und der Verkehr auf einer angemessenen Rate gehalten wird.

B.2. Candidates with Multiple Bases (Kandidaten mit mehreren Basen)

Abschnitt 4.1.3 spricht über das Eliminieren von Kandidaten, die dieselbe Transportadresse und Basis haben. Kandidaten mit denselben Transportadressen, aber unterschiedlichen Basen sind jedoch nicht redundant. Wann kann ein Agent zwei Kandidaten haben, die dieselbe IP-Adresse und denselben Port, aber unterschiedliche Basen haben?

Betrachten Sie einen Fall, in dem ein Anbieter multihomed ist. Er hat eine IP-Adresse in einem privaten Netzwerk C und eine andere im Netzwerk A, das zu Netzwerk B genattet wird. Der Anbieter erhält einen Hostkandidaten auf C und einen Hostkandidaten auf A. Er führt eine STUN-Abfrage von A aus, die das NAT passiert und einer Bindung zugewiesen wird, die zufällig mit IP:Port auf C übereinstimmt. Jetzt hat der Anbieter einen serverreflexiven Kandidaten mit einer Transportadresse erhalten, die mit einem Hostkandidaten identisch ist. Der serverreflexive Kandidat hat jedoch eine andere Basis als der Hostkandidat.

B.3. Purpose of the <rel-addr> and <rel-port> Attributes (Zweck der <rel-addr>- und <rel-port>-Attribute)

Das candidate-Attribut enthält zwei Werte, die von ICE selbst überhaupt nicht verwendet werden -- <rel-addr> und <rel-port>. Warum ist es vorhanden?

Es gibt zwei Motivationen für seine Aufnahme. Die erste ist diagnostisch. Es ist sehr nützlich, die Beziehung zwischen den verschiedenen Arten von Kandidaten zu kennen. Durch die Aufnahme kann ein Agent wissen, welcher weitergeleitete Kandidat welchem reflexiven Kandidaten zugeordnet ist, der wiederum einem bestimmten Hostkandidaten zugeordnet ist. Wenn Prüfungen für einen Kandidaten erfolgreich sind und für andere nicht, liefert dies nützliche Diagnosen darüber, was im Netzwerk vor sich geht.

Der zweite Grund hat mit Off-Path-Quality-of-Service (QoS)-Mechanismen zu tun. Wenn ICE in Umgebungen wie PacketCable 2.0 verwendet wird, inspizieren Proxys das SDP und extrahieren die IP-Adresse und den Port für den Medienverkehr, um eine garantierte QoS herzustellen. Wenn ein weitergeleiteter Kandidat ausgewählt wird, benötigt der Proxy den serverreflexiven Kandidaten zum TURN-Server, um QoS vom Zugangsrouter anzufordern. Durch das Mitführen der Übersetzung im SDP kann der Proxy diese Transportadresse verwenden.

B.4. Importance of the STUN Username (Wichtigkeit des STUN-Benutzernamens)

ICE erfordert die Verwendung der Nachrichtenintegrität mit STUN unter Verwendung seiner Kurzzeit-Anmeldeinformationsfunktionalität. Die tatsächlichen Kurzzeit-Anmeldeinformationen werden durch den Austausch von Benutzernamenfragmenten im SDP-Angebots-/Antwortaustausch gebildet. Die Notwendigkeit dieses Mechanismus geht über die bloße Sicherheit hinaus; er ist tatsächlich für den korrekten Betrieb von ICE in erster Linie erforderlich.

Betrachten Sie die Agenten L, R und Z in überlappenden privaten Netzwerken. L sendet ein Angebot an Z. Z stellt Hostkandidaten bereit. R verwendet zufällig dieselbe IP:Port wie Z. L sendet eine STUN-Anforderung, die an R statt an Z geht. Wenn R einfach antworten würde, würde L glauben, dass er eine Verbindung zu Z hat. Um dies zu beheben, werden die STUN-Kurzzeit-Anmeldeinformationsmechanismen verwendet. Die Benutzernamenfragmente sind ausreichend zufällig, dass es höchst unwahrscheinlich ist, dass R dieselben Werte wie Z verwendet. Folglich würde R die STUN-Anforderung ablehnen, da die Anmeldeinformationen ungültig waren.

B.5. The Candidate Pair Priority Formula (Die Kandidatenpaar-Prioritätsformel)

Die Priorität für ein Kandidatenpaar hat eine seltsame Form. Sie ist:

pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

Warum ist das so? Wenn die Kandidatenpaare basierend auf diesem Wert sortiert werden, hat die resultierende Sortierung die MAX/MIN-Eigenschaft. Dies bedeutet, dass die Paare zuerst basierend auf dem abnehmenden Wert des Minimums der beiden Prioritäten sortiert werden. Für Paare, die denselben Wert der minimalen Priorität haben, wird die maximale Priorität verwendet, um zwischen ihnen zu sortieren. Wenn die maximale und die minimale Priorität gleich sind, wird die Priorität des kontrollierenden Agenten als Tie-Breaker verwendet. Dies erstellt die MAX/MIN-Sortierung. MAX/MIN stellt sicher, dass für einen bestimmten Agenten ein Kandidat mit niedrigerer Priorität niemals verwendet wird, bis alle Kandidaten mit höherer Priorität ausprobiert wurden.

B.6. The remote-candidates Attribute (Das remote-candidates-Attribut)

Das a=remote-candidates-Attribut dient dazu, eine Race Condition zwischen dem aktualisierten Angebot und der Antwort auf die STUN-Binding-Anforderung zu beseitigen, die einen Kandidaten in die Gültig-Liste verschoben hat. Um diesen Zustand zu beseitigen, werden die tatsächlichen Kandidaten bei R, die vom Anbieter ausgewählt wurden (die Remote-Kandidaten), in das Angebot selbst aufgenommen, und der Antwortende verzögert seine Antwort, bis diese Paare validiert sind.

B.7. Why Are Keepalives Needed? (Warum werden Keepalives benötigt?)

Sobald Medien auf einem Kandidatenpaar zu fließen beginnen, ist es immer noch notwendig, die Bindungen an zwischengeschalteten NATs für die Dauer der Sitzung am Leben zu erhalten. Normalerweise erfüllen die Medienstrompakete selbst dieses Ziel. Wenn jedoch Medien in die Warteschleife gelegt werden oder wenn Stilleunterdrückung verwendet wird, kann die Medienübertragung lange genug aufhören, damit NAT-Bindungen ablaufen. Aus diesen Gründen kann man sich nicht auf die Medienpakete selbst verlassen. ICE definiert ein einfaches periodisches Keepalive unter Verwendung von STUN-Binding-Indikationen.

B.8. Why Prefer Peer Reflexive Candidates? (Warum Peer-Reflexive-Kandidaten bevorzugen?)

Abschnitt 4.1.2 verlangt, dass die Typpräferenz für Peer-Reflexive-Kandidaten immer höher ist als die für Server-Reflexive. Warum ist das so? Der Grund hat mit den Sicherheitsüberlegungen zu tun. Es ist für einen Angreifer viel einfacher, einen Agenten dazu zu bringen, einen falschen serverreflexiven Kandidaten zu verwenden, als es für einen Angreifer ist, einen Agenten dazu zu bringen, einen falschen Peer-Reflexive-Kandidaten zu verwenden. Folglich werden Angriffe gegen die Adresssammlung mit Binding-Anforderungen durch ICE vereitelt, indem die Peer-Reflexive-Kandidaten bevorzugt werden.

B.9. Why Send an Updated Offer? (Warum ein aktualisiertes Angebot senden?)

Beide Agenten können Medien senden, sobald die ICE-Prüfungen abgeschlossen sind, ohne auf ein aktualisiertes Angebot zu warten. Tatsächlich besteht der einzige Zweck des aktualisierten Angebots darin, das SDP zu "korrigieren", damit das Standardziel für Medien mit dem Ort übereinstimmt, an den Medien basierend auf ICE-Verfahren gesendet werden (dies ist das nominierte Kandidatenpaar mit der höchsten Priorität).

Warum wird der aktualisierte Angebots-/Antwortaustausch überhaupt benötigt? In der Praxis betrachten zahlreiche Komponenten entlang des Signalisierungspfads die SDP-Informationen (z. B. für QoS, NAT-Traversal, Diagnose). Damit diese Tools weiterhin unverändert funktionieren, muss die Kerneigenschaft von SDP -- dass die bestehenden, vor ICE definierten Definitionen der für Medien verwendeten Adressen beibehalten werden müssen -- gewahrt bleiben. Aus diesem Grund muss ein aktualisiertes Angebot gesendet werden.

B.10. Why Are Binding Indications Used for Keepalives? (Warum werden Binding-Indikationen für Keepalives verwendet?)

Der Hauptgrund hat mit Netzwerk-QoS-Mechanismen zu tun. Wenn ein Agent Medienpakete sendet und dann eine Binding-Anforderung empfängt, müsste er ein Antwortpaket zusammen mit seinen Medienpaketen generieren. Dies erhöht die tatsächlichen Bandbreitenanforderungen und führt Jitter ein. Die Verwendung einer Binding-Indikation ermöglicht es, die Integrität zu deaktivieren, was eine bessere Leistung ermöglicht.

B.11. Why Is the Conflict Resolution Mechanism Needed? (Warum wird der Konfliktlösungsmechanismus benötigt?)

Der Zustand, in dem beide Agenten glauben, dass sie kontrolliert werden, tritt in Fällen der Anrufsteuerung durch Dritte auf. Beispielsweise sendet ein Controller eine angebotslose INVITE an Agent A, der mit einem Angebot antwortet. Der Controller sendet dann eine angebotslose INVITE an Agent B, der mit einem Angebot antwortet. Der Controller verwendet die Angebote, um Antworten zu generieren. Wenn dieser Fluss verwendet wird, läuft ICE zwischen den Agenten A und B, aber beide glauben, dass sie sich in der kontrollierenden Rolle befinden. Mit den Verfahren zur Lösung von Rollenkonflikten funktioniert dieser Fluss ordnungsgemäß.