In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden die verschiedenen Optionen zur Aktivierung des ActiveControl-Protokolls für Mobile and Remote Access (MRA)-Clients und für Anrufe von Endgeräten vor Ort bei WebEx Meetings über Expressway beschrieben. MRA ist eine Bereitstellungslösung für Jabber und Endgeräte ohne Virtual Private Network (VPN). Mit dieser Lösung können Endbenutzer von einem beliebigen Standort weltweit auf interne Unternehmensressourcen zugreifen. Das ActiveControl-Protokoll ist ein proprietäres Protokoll von Cisco, das eine verbesserte Konferenzerfahrung mit Laufzeitfunktionen wie Meeting-Listen, Änderungen des Video-Layouts, Stummschaltung und Aufzeichnungsoptionen ermöglicht.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.
In diesem Dokument liegt der Schwerpunkt auf der MRA-Client-Verbindung zu einem Cisco Meeting Server (CMS). Das Gleiche gilt jedoch für andere Plattformen oder Verbindungen, z. B. bei der Verbindung mit WebEx Meetings. Dieselbe Logik kann für die folgenden Arten von Anrufflüssen angewendet werden:
Hinweis: Die von WebEx Meetings unterstützten Funktionen von ActiveControl unterscheiden sich derzeit von denen von CMS und stellen nur eine begrenzte Teilmenge dar.
Die Cisco Meeting Server-Plattform bietet Meeting-Teilnehmern die Möglichkeit, ihre Meeting-Umgebung direkt vom Konferenzendpunkt aus über ActiveControl zu steuern, ohne dass externe Anwendungen oder Operatoren erforderlich sind. ActiveControl verwendet das iX-Medienprotokoll in Cisco Geräten und wird als Teil des SIP-Messaging eines Anrufs ausgehandelt. Ab CMS-Version 2.5 stehen die folgenden Hauptfunktionen zur Verfügung (diese können jedoch vom verwendeten Endgerätetyp und der verwendeten Softwareversion abhängen):
Auf dem ersten Bild sehen Sie eine Benutzeransicht von einem Jabber-Client, der einen Anruf in einen CMS-Raum ohne ActiveControl getätigt hat, während das zweite Bild die funktionsreichere Benutzeransicht zeigt, in der Jabber ActiveControl mit dem CMS-Server aushandeln konnte.
ActiveControl ist ein XML-basiertes Protokoll, das unter Verwendung des iX-Protokolls übertragen wird, das im Session Description Protocol (SDP) der SIP-Anrufe (Session Initiation Protocol) ausgehandelt wird. Es handelt sich um ein Protokoll von Cisco (eXtensible Conference Control Protocol (XCCP)), das nur in SIP ausgehandelt wird (sodass interworking calls nicht über ActiveControl verfügen) und UDP/UDT (UDP-based Data Transfer Protocol) für die Datenübertragung nutzt. Die sichere Aushandlung erfolgt über Datagram TLS (DTLS), das als TLS-over-UDP-Verbindung betrachtet werden kann. Einige Beispiele für die Unterschiede in der Verhandlung sind hier aufgeführt.
Unverschlüsselt
m=application xxxxx UDP/UDT/IX *
a=ixmap:11 xccp
Verschlüsselt (bestmögliche Leistung - Verschlüsselung versuchen, aber Fallback auf unverschlüsselte Verbindung zulassen)
m=Anwendung xxxx UDP/UDT/IX *
a=ixmap:2 xccp
a=Fingerabdruck:sha-1 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
Verschlüsselung (Verschlüsselung erzwingen - Fallback auf unverschlüsselte Verbindung nicht zulassen)
m=application xxxx UDP/DTLS/UDT/IX *
a=ixmap:2 xccp
a=Fingerabdruck:sha-1 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
Es gibt einige Mindestsoftwareversionen, die für eine vollständige ActiveControl-Unterstützung erforderlich sind:
Es gibt einige Konfigurationsoptionen, die berücksichtigt werden müssen:
ActiveControl wird sicher anders als andere Medienkanäle ausgehandelt. Für andere Medienkanäle wie Audio und Video wird dem SDP eine Verschlüsselungsleitung angefügt, die dem Remote-Teilnehmer mitteilt, welcher Verschlüsselungsschlüssel für diesen Kanal verwendet werden soll. Der RTP-Kanal (Real-time Transport Protocol) kann daher als sicherer RTP-Kanal (Secure RTP) eingestuft werden. Für den iX-Kanal wird das DTLS-Protokoll verwendet, um den XCCP-Medien-Stream zu verschlüsseln, sodass ein anderer Mechanismus verwendet wird.
Die Expressway-Software terminiert das DTLS-Protokoll nicht. Dies wird im Abschnitt Einschränkungen unter Nicht unterstützte Funktionen der Expressway-Versionshinweise angegeben.
Wenn eine Expressway-Version vor X12.5 ausgeführt wird und eine eingehende Verbindung mit einem verschlüsselten iX-Kanal besteht, der entlang einer unsicheren TCP-Zone weitergeleitet wird, entfernt der Expressway sowohl die Krypto-Leitungen der normalen Medienkanäle als auch den gesamten iX-Kanal. Dies wird visuell für einen MRA-Client dargestellt, der sich mit einem CMS-Bereich verbindet, in dem Sie sehen, dass die Verbindung vom MRA-Client zum Expressway-C sicher ist. Je nach dem auf dem CUCM für das Gerät eingerichteten Telefonsicherheitsprofil ist sie jedoch entweder unverschlüsselt (und über die CEtcp-Zone gesendet) oder verschlüsselt (und über die CEtls-Zone gesendet). Wenn es unverschlüsselt ist, wie auf dem Bild gezeigt, sehen Sie, dass der Expressway-C die Kryptozeilen für alle Medienkanäle abzieht und sogar den gesamten iX-Medienkanal abzieht, da er das DTLS-Protokoll nicht beenden kann. Dies geschieht über den Back-To-Back User Agent (B2BUA), da die Zonenkonfiguration für die CEtcp-Zone mit Medienverschlüsselung 'Force unencrypted' eingerichtet ist. In die entgegengesetzte Richtung (über die UC-Überbrückungszone mit "Force encrypted" Medienverschlüsselung), wenn die SDP-Antwort empfangen wird, werden die Krypto-Leitungen für die normalen Medienleitungen hinzugefügt, und der Port für den iX-Kanal wird auf Null gesetzt, was zu keiner ActiveControl-Aushandlung führt. Intern, wenn die Clients direkt beim CUCM registriert sind, ermöglicht dies sowohl verschlüsselte als auch unverschlüsselte iX-Medienkanäle, da sich der CUCM nicht selbst im Medienpfad befindet.
Die gleiche Logik gilt für die Anrufverbindungen über Expressway zu WebEx Meetings. Es erfordert, dass der vollständige Pfad durchgehend sicher ist, da die Expressway-Server (vor X12.5) nur die DTLS-Verbindungsinformationen weiterleiten, aber nicht selbst daran enden, um eine neue Sitzung zu starten oder den Medienkanal auf den verschiedenen Anrufabschnitten zu verschlüsseln/zu entschlüsseln.
Wenn eine Expressway-Version von X12.5 oder höher ausgeführt wird, hat sich das Verhalten geändert, da es jetzt als erzwungene Verschlüsselung (UDP/DTLS/UDT/IX) über den iX-Kanal über die TCP-Zonenverbindung weitergeleitet wird, damit der iX-Kanal weiterhin ausgehandelt werden kann, allerdings nur, wenn das Remote-Ende ebenfalls Verschlüsselung verwendet. Sie erzwingt die Verschlüsselung, da der Expressway die DTLS-Sitzung nicht beendet und somit nur auf Pass-Through reagiert, sodass die DTLS-Sitzung dann vom Remote-Ende gestartet/beendet wird. Die Krypto-Leitungen werden jedoch aus Sicherheitsgründen über die TCP-Verbindung entfernt. Diese Verhaltensänderung wird in den Versionshinweisen im Abschnitt 'MRA: Unterstützung für verschlüsseltes iX (für ActiveControl)' behandelt. Was danach passiert, hängt von der CUCM-Version ab, da sich dieses Verhalten in 12.5(1)SU1 geändert hat. Dort kann es auch bei unsicheren eingehenden Verbindungen über den iX-Kanal übertragen. Selbst wenn ein sicherer TLS-SIP-Trunk zu CMS vorhanden wäre, würde der iX-Kanal bei Ausführung der CUCM-Version unter 12.5(1)SU1 entfernt, bevor er an das CMS weitergeleitet wird, was letztendlich zu einem ausgeschalteten Nullopport von CUCM an Expressway-C führen würde.
Mit einem durchgängigen sicheren Signalisierungs- und Medienpfad für Anrufe kann der iX-Kanal direkt (über verschiedene Hops von Expressway-Servern) zwischen dem MRA-Client und der Konferenzlösung (CMS oder WebEx Meeting) ausgehandelt werden. Das Bild zeigt den gleichen Anrufverlauf für einen MRA-Client, der sich mit einem CMS-Bereich verbindet, jetzt jedoch mit einem auf CUCM konfigurierten sicheren Telefonsicherheitsprofil und einem sicheren TLS SIP-Trunk zu CMS. Sie können sehen, dass der Pfad durchgängig sicher ist und dass der DTLS-Fingerabdruckparameter einfach über den gesamten Pfad übertragen wird.
Um ein sicheres Gerätesicherheitsprofil einzurichten, müssen Sie sicherstellen, dass der CUCM in einem gemischten Modus eingerichtet ist. Dies kann ein mühsamer Prozess sein (auch wenn er betriebsbereit ist, da er CAPF (Certificate Authority Proxy Function) für eine sichere standortbasierte Kommunikation erfordert). Aus diesem Grund können hier weitere praktische Lösungen angeboten werden, um die Verfügbarkeit von ActiveControl über MRA und Expressway im Allgemeinen zu unterstützen, wie in diesem Dokument beschrieben.
Sichere TLS-SIP-Trunks zu den CMS-Servern sind nicht erforderlich, da der CUCM (vorausgesetzt, für den SIP-Trunk ist die Option "SRTP erlaubt" aktiviert) immer noch von einer eingehenden sicheren SIP-Verbindung den iX-Kanal sowie die Verschlüsselungsleitungen weiterleitet, aber CMS antwortet nur mit Verschlüsselung auf den iX-Kanal (ermöglicht ActiveControl) (vorausgesetzt, SIP-Medienverschlüsselung wirdvorausgesetzt) ist auf CMS unter "Einstellungen" > "Anrufeinstellungen" (erlaubt oder erzwungen) eingestellt, hat aber keine Verschlüsselung auf den anderen Medienkanälen, da die Krypto-Leitungen von diesen gemäß Bild entfernt werden. Die Expressway-Server können die Krypto-Leitungen erneut hinzufügen, um den Teil der Verbindung noch zu sichern (und iX wird direkt zwischen den Endkunden noch über DTLS ausgehandelt). Dies ist jedoch aus Sicherheitssicht nicht ideal, und daher wird empfohlen, einen sicheren SIP-Trunk zur Konferenzbrücke einzurichten. Wenn SRTP zulässig auf dem SIP-Trunk nicht aktiviert ist, entfernt der CUCM die Krypto-Leitungen, und die sichere iX-Aushandlung schlägt ebenfalls fehl.
Es gibt eine Reihe von verschiedenen Optionen mit verschiedenen Anforderungen und verschiedenen Vor-und Nachteile. Jede davon wird in einem detaillierteren Abschnitt vorgestellt. Folgende Optionen stehen zur Verfügung:
Voraussetzungen:
Vorteile:
Nachteile:
Dies ist die Methode, die im Abschnitt "Problem" sowie am Ende beschrieben wird. Hier stellen Sie sicher, dass Sie über einen verschlüsselten End-to-End-Signalisierungs- und Medienpfad für Anrufe verfügen. Hierfür muss der CUCM gemäß dem folgenden Dokument im gemischten Modus eingerichtet werden.
Für MRA-Clients ist kein CAPF-Vorgang erforderlich. Führen Sie jedoch die zusätzlichen Konfigurationsschritte mit dem sicheren Telefonsicherheitsprofil mit einem Namen aus, der mit einem der alternativen Antragstellernamen des Expressway-C-Serverzertifikats übereinstimmt, wie im Collaboration Edge TC-basierten Endgeräte-Konfigurationsbeispiel (das auch für CE-basierte Endgeräte und Jabber-Clients gilt) hervorgehoben wird.
Wenn Sie eine Verbindung von einem lokalen Endpunkt oder einem Jabber-Client zu einem WebEx Meeting herstellen, müssen Sie den CAPF-Vorgang durchführen, um den Client sicher beim CUCM zu registrieren. Dies ist erforderlich, um einen sicheren End-to-End-Anruffluss sicherzustellen, bei dem der Expressway die DTLS-Aushandlung einfach weiterleiten kann und nicht selbst verarbeiten muss.
Um den Anruf durchgängig sicher zu machen, müssen alle relevanten SIP-Trunks (an Expressway-C bei Anrufen an Webex Meeting und an CMS bei Anrufen an CMS-Konferenz) ebenfalls sichere SIP-Trunks mit TLS mit sicherem SIP-Trunk-Sicherheitsprofil sind.
Voraussetzungen:
Vorteile:
Nachteile:
Im SIP-OAuth-Modus können Sie OAuth-Aktualisierungstoken für die Cisco Jabber-Authentifizierung in sicheren Umgebungen verwenden. Sie ermöglicht eine sichere Signalisierung und sichere Medien ohne die CAPF-Anforderungen von Lösung 1. Die Tokenvalidierung während der SIP-Registrierung ist abgeschlossen, wenn die OAuth-basierte Autorisierung auf dem CUCM-Cluster und den Jabber-Endpunkten aktiviert ist.
Die Konfiguration in CUCM wird im Funktionskonfigurationsleitfaden dokumentiert und setzt voraus, dass OAuth mit Refresh Login Flow unter Enterprise Parameters bereits aktiviert ist. Um dies auch über MRA zu aktivieren, müssen Sie die CUCM-Knoten im Expressway-C-Server unter Configuration > Unified Communication > Unified CM Servers aktualisieren, sodass Sie unter Configuration > Zones > Zones nun auch die automatisch erstellten CEOAuth-Zonen sehen müssen. Stellen Sie außerdem sicher, dass unter Configuration > Unified Communication > Configuration das Token Authorize by OAuth mit Aktualisierung ebenfalls aktiviert ist.
Mit dieser Konfiguration können Sie eine ähnliche sichere End-to-End-Anrufverbindung sowohl für die Signalisierung als auch für die Medien herstellen. Daher wird der Expressway nur über die DTLS-Verhandlung geleitet, da er diesen Datenverkehr nicht selbst terminiert. Dies ist auf dem Bild zu sehen, wo der einzige Unterschied im Vergleich zur vorherigen Lösung ist, dass es die CEOAuth-Zone auf dem Expressway-C zum CUCM im Gegensatz zur CEtls-Zone verwendet, weil es SIP OAuth anstelle der sicheren Geräteregistrierung über TLS verwendet, wenn CUCM in einem gemischten Modus mit einem sicheren Telefon-Sicherheitsprofil arbeitet, aber abgesehen davon, bleibt alles gleich.
Voraussetzungen:
Vorteile:
Nachteile:
Ab CUCM 12.5(1)SU1 unterstützt es die iX-Verschlüsselungsaushandlung für jedes SIP-Leitungsgerät, sodass es die DTLS-Informationen in sicheren ActiveControl-Nachrichten für nicht sichere Endgeräte oder Softphones aushandeln kann. Es sendet über bestmögliche iX-Verschlüsselung über TCP, sodass Telefone trotz einer unsicheren TCP-Verbindung (nicht TLS) zum CUCM einen verschlüsselten iX-Kanal durchlaufen können.
Im Sicherheitsleitfaden von CUCM 12.5(1)SU1 im Abschnitt "Verschlüsselter iX-Kanal" wird gezeigt, dass für nicht verschlüsselte Modi mit unsicheren Geräten Best Effort und erzwungene iX-Verschlüsselung ausgehandelt werden können, vorausgesetzt, dass das System die Exportbestimmungen einhält und der SIP-Trunk zu Ihrer Konferenzbrücke sicher ist.
Auf CUCM:
Auf CMS:
Im Bild können Sie sehen, dass die Verbindung sicher ist, bis der Expressway-C und dann C über das SDP an CUCM ohne die Krypto-Leitungen sendet, aber der iX-Medienkanal bleibt erhalten. Das normale Medium für Audio/Video/... ist also nicht mit Krypto-Leitungen gesichert, aber es hat jetzt eine sichere Verbindung für den iX-Medienkanal, sodass der Expressway die DTLS-Verbindung nicht beenden muss. Daher kann ActiveControl direkt zwischen dem Client und der Konferenz-Bridge ausgehandelt werden, selbst wenn das Sicherheitsprofil eines Telefons nicht sicher ist. Bei früheren Versionen von CUCM wäre der Fluss anders, und ActiveControl wird nicht ausgehandelt, da es nicht von vornherein über den iX-Kanal an das CMS weitergeleitet wird, da dieser Teil bereits entfernt worden wäre.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
21-Sep-2020 |
Erstveröffentlichung |