Dans cet article
dropdown icon
Exigences relatives aux points de terminaison
    IPv4 contre IPv6
dropdown icon
Exigences relatives au SIP et aux médias
    Exigences pour un SIP sécurisé avec mTLS (TLS mutuel)
Exigences de sécurité pour Webex Calling
list-menuDans cet article
list-menuUn commentaire ?

Cet article est destiné aux administrateurs réseau, en particulier aux administrateurs de pare-feu et de sécurité des proxys qui souhaitent utiliser Webex Calling au sein de leur organisation.

Exigences relatives aux points de terminaison

Webex CallingEdge

Pour effectuer un enregistrement SIP ou un appel, procédez comme suit :

  • Découvrez l'adresse hôte d'un point de terminaison SIP pour les nœuds Edge actifs.

  • Remplissez toutes les conditions préalables relatives à la configuration de l'utilisateur et de l'appareil.

  • Assurez-vous que le terminal est connecté au réseau public pour commencer à découvrir les services.

  • Remplissez les conditions préalables au démarrage du terminal avec une configuration d'approvisionnement spécifique à une région ou à un centre de données. Cette configuration permet d'obtenir le suffixe de nom de domaine approprié pour la découverte de services.

IPv4 contre IPv6

Les appareils peuvent fonctionner en version unique ou en mode double pile. C'est la configuration qui détermine les modifications à apporter au protocole préféré et ces modifications ne font pas partie de la découverte des services.

  • Mode pile unique : active un seul protocole IP (par exemple, IPv4) et ignore les autres adresses de protocole.

  • Mode Dual-Stack : sélectionne la version IP préférée par le biais de la configuration.

Le client considère que la priorité de toutes les adresses préférées est inférieure (c'est-à-dire préférée) à celle de toutes les adresses IP. Si IPv4 est préférée, toutes les adresses IPv4 sont essayées avant d'essayer d'obtenir une adresse IPv6. Si toutes les adresses échouent, le cycle recommence avec l'adresse de protocole préférée la moins prioritaire.

Un client mobile qui s'enregistre à la réception d'une notification push peut décider d'optimiser le mode en fonction des inscriptions précédentes.

Résolution de l'adresse de l'hôte à partir de l'DNS SRVadresse

Dans le fichier de configuration des terminaux obtenu lors de l'approvisionnement, l'indicateur de domaine indique le nom de domaine utilisé pour découvrir le service Access Edge. Voici un exemple de nom de domaine :

wxc.edge.bcld.webex.com

D'après l'exemple, le point de terminaison qui effectue une DNS SRV recherche pour ce domaine peut obtenir une réponse similaire à la suivante :


# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com
_sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com.
_sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.

Dans ce cas, le record SRV indique 3 records A.


sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com

Dans l'exemple, tous les hôtes sont invités à contacter le port 5061 avec un poids et une priorité différents.

Tenez compte de ces exigences pour les terminaux.

  • Un point de terminaison doit utiliser _sips._tcp(combinaison de services et de protocoles) comme préfixe pour effectuer une DNS SRV recherche afin d'obtenir l'adresse de l'hôte afin d'initier une communication par TLS.

  • Un terminal doit rechercher les conditions expliquées dans la section Résolution de l'adresse de l'DNS SRVhôte. DNS SRV

  • Un point de terminaison doit respecter l'hôte, le port, le poids et la priorité tels qu'ils sont annoncés pour chacune des adresses de l'hôte. De plus, cela doit créer une affinité entre l'hôte et le port lors de la création d'une connexion socket lors de l'enregistrement SIP.

  • En ce qui concerne l'utilisation du DNS SRV record, les critères de sélection des hôtes en fonction de la priorité et du poids sont expliqués dans la RFC 2782.

Exigences relatives au SIP et aux médias

Exigence

Description

Un certificat de confiance est requis pour le cryptage par clé publique

Reportez-vous à l'article pour en savoir plus sur le pouvoir de signature des certificats Webex et sur la nécessité de Root CA sur les appareils

Version TLS prise en charge pour le SIP sécurisé

TLS 1.2 et TLS 1.3

Chiffrements TLS pris en charge pour un SIP sécurisé

TLS_AES_256_GCM_SHA384

TLS_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

Clés SRTP prises en charge pour sécuriser les médias

AES_CM_128_HMAC_SHA1_80

Exigences pour un SIP sécurisé avec mTLS (TLS mutuel)

Les exigences sont expliquées en détail ici.

Un certificat signé est requis pour autoriser et authentifier avec succès les appels depuis le tronc. Le certificat doit répondre aux exigences suivantes :

  • Le certificat doit toujours être valide :

    • Les certificats signés doivent toujours avoir une date d'expiration valide.

    • Les certificats racine ou intermédiaires doivent avoir une date d'expiration valide et ne doivent pas être révoqués.

    • Les certificats contenant uniquement l'utilisation étendue des clés d'authentification par serveur (EKU) sont pris en charge. Webex Callingne valide ni n'impose la présence de l' EKU d'authentification client lors de l'établissement de la poignée de main TLS.

      Certains contrôleurs de session (SBC) tiers peuvent appliquer une validation EKU stricte et rejeter les certificats qui n' incluent pas l'authentification client EKU. Dans ce cas, assurez-vous que le SBC est configuré pour accepter les certificats avec authentification du serveur EKU uniquement ou pour désactiver la validation EKU stricte (si elle est prise en charge).

    • Les certificats doivent contenir le nom de domaine complet (FQDN) comme nom courant ou nom alternatif du sujet sur le certificat, le nom de domaine complet ayant été choisi dans le Control Hub. Par exemple :

      • Un tronc configuré depuis le Control Hub de votre organisation avec london.lgw.cisco.com:5061 comme nom de domaine complet doit contenir london.lgw.cisco.com dans le certificat CN ou SAN.

      • Un tronc configuré depuis le Control Hub de votre organisation avec london.lgw.cisco.com était que le SRV devait contenir london.lgw.cisco.com dans le certificat CN ou SAN. Les enregistrements vers lesquels l'adresse SRV est renvoyée (enregistrement CNAME/A/adresse IP) sont facultatifs dans le SAN.

    • Vous pouvez partager des certificats avec plusieurs passerelles locales, mais assurez-vous que les exigences du FQDN sont respectées.

Hors de portée

Cet article ne contient pas les informations suivantes relatives à la sécurité du réseau :

  • Exigences F5 pour CA et Ciphers

  • Une API basée sur HTTP pour télécharger les règles de pare-feu pour Webex.

  • API pour un pack de confiance

  • Pare-feu obligatoire et désactivation de l'ALG

Cet article était-il utile ?
Cet article était-il utile ?