Sunday, October 18, 2020

CUCM Security Tips

CUCM Security Tips

  • Secure Conference Bridge has special requirement.  Though configuration for secure conference bridge (CFB) is pretty much the same as secure transcoder(TRA) and secure media termination point(MTP), secure CFB requires the register name to match the hostname portion of the subject name (in the certificate/trust-point).  For instance,
    • You router's FQDN is
    • Most likely you would enroll a certificate for the router with a subject name "".
    • On the router, you created a trust point R1-Cert to hold the above certificate.
    • You would think you could use R1-Cert for secure SIP-trunk, secure media resource, etc.  Until it comes to the point that you try to register a secure conference bridge.
      • On CUCM, you saw the conference bridge status is "rejected", yet secure transcoder and MTP are registered.  So it's unlikely certificate problem.
      • On CUCM, you named them R1-CFB, R1-TRA, and R1-MTP

The problem is with the name "R1-CFB".  It has to match with the hostname portion in the certificate (which is "R1" in this case).  OK, no big deal, I'll just change the name from "R1-CFB" to "R1".  Well... you cannot do that.  Because IOS won't accept a conference bridge name shorter than 6 characters or longer than 15 characters.  So you either change the router name (make it between 6 and 15 characters), re-enroll the certificate; or keep the router name/keep the router certificate, and enroll another certificate for conference bridge (yes, for conference bridge only).  For instance,

    • Your router certificate is
    • Your conference bridge certificate is

No, you don't need DNS entry created for those names.  You may use IP addresses and TLS handshake will still succeed.

  • On IOS-XE (all ISR G3 / ISR 4000 series), Cisco decided not to support secure transcoding, which means, when you create transcoding profile on the router, there's no "security" option available.  Available options are:
    • Register non-secure transacoder to CUCM (application sccp)
    • Register LTI transcoder to the router (application cube)
    • No transcoding at all.  on IOS-XE, SRTP to RTP internetworking does not require transcoding.
  • Crypto Mismatch in ad-hoc conference (call dropped)
31948894.000 |11:19:34.039 |SdlSig   |MXErrorReport                          |interfacesEstablished          |MediaExchange(3,100,114,571)     |AgenaInterface(3,100,11,249)     |3,100,247,81913.201^^*      |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] error=0 CallMediaFailureCause=block unencrypted  media Reason=prepareAndSendOLC - Serv Param 'Block Unencrypted Calls' is true and the call is unencrypted. Hence blocking the call.
31948895.000 |11:19:34.039 |SdlSig   |MXErrorReport                          |waitStopped                    |MediaExchange(3,100,114,571)     |AgenaInterface(3,100,11,249)     |3,100,247,81913.201^^*      |[R:N-H:0,N:4,L:0,V:0,Z:0,D:0] error=0 CallMediaFailureCause=block unencrypted  media Reason=openOutgoingAudioChannel - Serv Param 'Block Unencrypted Calls' is true and sRTP keys not generated successfully. Hence blocking the call.

    The above messages indicate there's a crypto mismatch between the conference resource and the intended call leg.  Use "show sccp" command to see support crypto on conference resource.  e.g.:

    Router#show sccp
    Conferencing Oper State: ACTIVE - Cause Code: NONE
    Active Call Manager:, Port Number: 2443
    TCP Link Status: CONNECTED, Profile Identifier: 1
    Signaling Security: ENCRYPTED TLS
    Media Security: SRTP
    Supported crypto suites: AES_CM_128_HMAC_SHA1_32, AES_CM_128_HMAC_SHA1_80

    On CUBE, create a voice class for crypto and apply it to the dial-peer:

    voice class srtp-crypto 1
     crypto 1 AES_CM_128_HMAC_SHA1_32
     crypto 2 AES_CM_128_HMAC_SHA1_80
    dial-peer voice 50 voip
     voice-class sip srtp-crypto 1

    Reference #1: 

    Reference #2: (For SCCP-based signalling, only TLS_RSA_WITH_AES_128_CBC_SHA cipher suite is supported)

    Use IOS router as CA (Certificate Authority) Server

    If you have a router handy (especially with GNS3), IOS CA is probably the most convenient way to sign certificates.  Though you may set up IOS CA for online enrollment, I strong recommend you practice terminal method.  In most cases, terminal is the quickest (and probably the only) way to get your job done.

    To set up CA server on IOS, you just need a couple commands:

    conf t
    crypto key generate rsa general-keys exportable label myCA modulus 2048
    crypto key export rsa myCA pem url nvram: des myCAkey
    ip http server
    crypto pki server myDB
     database level minimum
     database url nvram:
     issuer-name cn=myCA, l=Dallas, c=US
     lifetime certificate 7305
     grant auto

     no shut

    From a router (say, R1) you want to enroll certificate, do the following:

    crypto key generate rsa label MyRSAkey exportable modulus 2048
    crypto pki trustpoint R1-Cert
     serial-number none
     fqdn none
     ip-address none
     revocation-check none
     rsakeypair MyRSAkey
     enrollment terminal
    crypto pki enroll R1-Cert

    R1 will generate CSR and print it on the terminal.  You're going to copy/paste the CSR to the CA server we created above.  An example output is like below:

    R1(config)#crypto pki enroll R1-cert
    % Start certificate enrollment .. 
    % The subject name in the certificate will include:
    % The fully-qualified domain name will not be included in the certificate
    Display Certificate Request to terminal? [yes/no]: yes
    Certificate Request follows: 
    ---End - This line not part of the certificate request--- 
    Redisplay enrollment request? [yes/no]: no

    On CA server, use global command "crypto pki server myDB request PKCS10 terminal" to sign a CSR.  An example output is like below:

    CA#crypto pki server myDB request PKCS10 terminal
    PKCS10 request in base64 or pem 
    % Enter Base64 encoded or PEM formatted PKCS10 enrollment request.
    % End with a blank line or "quit" on a line by itself.
    % Granted certificate:

    The yellow portion above is our input.  The green portion the the signed certificate (for R1).  We're going to copy/paste it to R1.  This is called "import" a signed certificate into R1.  But before importing a signed certificate, we need to import the signer (CA) certificate first.  On CA, use config command "crypto pki export myDB pem terminal" to export CA certificate.  An example is as below:

    CA(config)#crypto pki export myDB pem terminal
    % The specified trustpoint is not enrolled (myDB).
    % Only export the CA certificate in PEM format.
    % CA certificate:
    -----END CERTIFICATE----- 

    Now on router R1, do the following:

    1. Import CA certificate with config command "crypto pki authenticate R1-Cert".  R1-Cert is the trust point name, which is just a placeholder for a cert and its signer.  Paste the CA cert (the 2nd green block above).
    2. Import R1 cert with config command "crypto pki import R1-Cert cert".  Paste the signed R1 cert (the 1st green block above).

    Now you have successfully installed certificate on R1.

    Wednesday, October 14, 2020

    Revisit "Urgent Priority"

    Cisco CUCM (CallManager) has "urgent priority" option for translation patterns and route patterns.  At the first glance, it is pretty straight forward.  It is usually used with emergency patterns like "911".  The purpose is to eliminate potential inter-digit timeout.  For instance, when user dialed 911, CUCM will route the call immediately, even if there are potential matches (like 911XXX).

    But what happens if we use urgent priority on variable length pattern (like "!")?  Since wildcard ! means "one or more digits", shouldn't the system wait for more digit anyway?  Would interdigit timeout happen or not?

    The short answer is "No".  If you have urgent priority on pattern "!", and you are dialing digit by digit, the system will start routing the call after the first digit is pressed.  Because that matches the definition "one or more digits".  That seems pretty useless.  Why would people do that?

    It is not totally useless.  You may still dial multiple digits with the following options:

    Option 1: Bloc-Dial

    Keep the phone on hook (do not get a dial tone), enter all the digits you want, then hit the "Dial" button.  This is called bloc-dial.  You may pass all digits to ! pattern with urgent priority with bloc-dial.

    Option 2: From previous hop

    In large-scale dial plan design, we usually expose translation patterns(TPs) to phones, but not route patterns(RPs).  The intend is to use TPs to do all kinds of digit manipulation and class of control.  Then pass the manipulated digits to RPs.  In this case, TP has no problem passing all digits to RP (even if the RP has urgent priority).

    Let say, you have a two-tier dial plan design (TP/RP).  You have emergency TPs with urgent priority.  When those TPs pass digits to RPs, it may or may not experience interdigit timeout depending on your RP setup.  Interdigit timeout is evaluated at each hop.  If you use RP ! to catch all digits passed by TPs, you might want to enable urgent priority on that ! pattern.  Or as an alternative, you may enable "Do Not Wait for Interdigit Timeout On Subsequent Hops" on the TP.

    Another interesting topic is the interaction of urgent priority and "longest match".  Take a look at the following patterns:

    • 7XXX
    • 700XX

    When you dial 7, 0, 0, 1, 2 digit-by-digit, which one will be matched?  At the first glance, 700XX seems to be the best candidate because it matches more digits.  Enable urgent priority on 7XXX seems harmless for this dialing string, right?  Actually not.  When urgent priority is enabled on 7XXX, you won't be able to enter the fifth digit.  Once you entered the 4th digit, system immediately routes the calls.  The only way to work around that is to use bloc-dialing.

    In summary:

    1. Interdigit timeout applies to digit-by-digit dialing.  It does not apply to bloc-dialing.
    2. Digits passed by previous hop does NOT equal to bloc-dialing.  For instance, urgent priority on TP level does not necessarily immune to interdigit timeout at RP level.
    3. Be careful of overlapped patterns.  Using urgent priority might have side effects.

    Sunday, May 24, 2020

    cEdge - Single Image Switch to Controller Mode

    cEdge is a Cisco router acting as SD WAN Edge.  Cisco's road map is to replace vEdge products with cEdge.  cEdge can be on ISR, ASR and CSR, as well as their corresponding virtual variants (such as ISR 1000v, CSR 1000v, etc.)

    When the above devices operating in "regular mode", it's called "Autonomous Mode", which is your good old IOS XE command system.  When they operate in "SD WAN mode", it's called "Controller Mode", which is Viptela-like command system.

    In pre-17.2 versions, you'll have to load different software on the router to support different modes.  Since version 17.2.1r, one single image can support two different modes.  Please see

    I put CSR 1000v 17.2.1r in my GNS3 lab.  It boots into autonomous mode by default.  I tried to switch it to controller mode with no luck.  I was referring to  Also

    I did quite a lot research.  However, this version is too new to yield any helpful resource online.  I finally figured it out.  It's a documentation issue.

    First, let's take a look at Cisco documentation below:

    Per above documentation, the cfg file (in router bootflash:) will trigger the mode change.  That is NOT TRUE!  At least not in CRS 1000v 17.2.1r.  The cfg file won't be used UNTIL the router is switched to controller mode.

    To switch from autonomous mode to controller mode, you use CLI command "controller-mode enable".  Router will warn you that all configuration will be lost.  After conformation, router will reboot into controller mode.

    The first sign of controller mode is - you'll be prompted to enter username/password, even if you don't have it set up previously.  Default username/password is admin/admin, which aligns with Viptela defaults.

    After login, you may use the following commands to double confirm it's in controller mode: