How ISE Profiling Works?

• ISE Profiling is the service used to identify the type of endpoints connected to the network
• ISE Profiling service should be enabled to probe for endpoint attributes
• The attributes requested are depending on the type of probes enabled (for example dhcp probe will request for dhcp-class-identifier, http probe will request for user-agent, etc)
• Attributes gathered from probes are matched against profiling policies
• Profiling policy is made of set of rules
• Each rule matches a condition and assign certainty factor (CF)
• Certainty Factor (CF) is a weight defines how relevant this condition to decide the final endpoint profile
• The SUM of matched CFs should be greater than or equal to minimum CF configured in the Profiling Policy to profile the endpoint
• In case the endpoint matches more than one profiling policy, the highest CF_SUM decides the final endpoint profile
• Once Profiling Policy is matched , it can trigger exception or execute NMAP scan
• This kicks in ONLY after matching the profiling policy
• Profiling policies can be nested using Parent/Child structure
• Child Profiling Policy won't be matched unless Parent Policy is matched
• Nested Policies are used to granular profiling
• Endpoint will be profiled based on the deepest profile matched in the structure
• Common practice to trigger NMAP scan on Parent Policy to get more attributes for Child policy matching
• Each Profiling Policy can be configured to create Endpoint Identity Group and assign matched endpoints to it.
• You can group Profiles in Logical profiles
• Logical Profiles are containers where you add different profiled devices to provide them one treatment (for example same authorization policies)
• Authorization policies can call Logical Profiles or Endpoint Identity Groups to grant access
• Profiling isn't supported for VPN endpoints due to lack of endpoint MAC address information from VPN Gateway

Change of Authorization

• Radius Change of Authorization (CoA) Access-Request was introduced in order for ISE to issue new authorization policy to the endpoint based CoA triggers
• Endpoint authenticated
• Initial Authorization Policy pushed to the switch (endpoint not yet profiled)
• Profiling data received and endpoint profile selected
• ISE triggers CoA for endpoint to reauthenticate (this is subject to configured CoA Type)
• Final Authorization Policy pushed to the switch based the endpoint profile (during reauthentication process)
• The following scenarios trigger CoA
• Endpoint profiling for 1st time
• Endpoint statically assigned to device identity group
• Endpoint removed from ISE database
• Endpoint dynamically change identity group membership
• Manual CoA  from Context Visibility > Endpoints > Change Authorization

Enable ISE SSH Access

If you missed enabling SSH access during the initial setup of ISE, you can enable it using console by pasting the command  service sshd enable

How to find Unassigned Media Resource (No MRG)

To look at media resources and the allocated MRGs, use the sql query

run sql select mrg.name as mrg,d.name as resource from mediaresourcegroup mrg inner join mediaresourcegroupmember mgm on mgm.fkmediaresourcegroup=mrg.pkid   inner join device d on mgm.fkdevice=d.pkid

To filter specific site

run sql select mrg.name as mrg,d.name as resource from mediaresourcegroup mrg inner join mediaresourcegroupmember mgm on mgm.fkmediaresourcegroup=mrg.pkid   inner join device d on mgm.fkdevice=d.pkid where d.name like '%AD1%' or mrg.name like '%A01%'

Use this CLI command to find media resources in the default MRG (no assigned to any created MRG).

admin:run sql select d.name as resource from device as d full outer join mediaresourcegroupmember as mgm on mgm.fkdevice=d.pkid where and mgm.pkid is NULL

resource   

===========

AD1MTP-G711 

AD1XCODER

 

You look for specific device type such as MTP

admin:run sql select d.name as resource from device as d full outer join mediaresourcegroupmember as mgm on mgm.fkdevice=d.pkid where d.name like '%MTP%' and mgm.pkid is NULL

resource   

===========

AD1MTP-G711

Bandwidth and Storage Requirements for Voice and Screen Recording in a Contact Center

We have recently been asked by a contact center to calculate the local network bandwidth and the HDD storage needed for implementing the PhoneUP Voice and Screen Recording solution for 300 agent seats.

Imagine 300 simultaneous audio/video streams recorded 18 hours a day (the agent utilization rate is 75%) 7 days a week and then stored for 1 year. Let’s neglect the voice part as the major load on both the LAN and the HDD storage is produced by the video (screen) recording.

Well... the most used screen resolution is 1366x768 (by w3schools) which is (roughly) corresponds to 720p movie format. And as we all know the file size per hour of 720p movie is about 2Gb. With this in mind thinking about 300 video streams recorded 18x7 could make your hair stand on end. But it’s not that bad.

Let’s examine parameters which influence the size of a screen recording video and how they can be optimized in the case of agent screen recording.

1.       The codec.

PhoneUP uses H.264 and here’s the first major saving. The movie we mentioned above is whole dynamic – every part of it constantly changes throughout the film. But contact center agents usually don’t watch Youtube when talking to customers. They work with CRM instead and that means that 95% of the screen is static, the only part that changes is where the agent, say, types the customer complaint (or selects an item from the drop-down list, or pushes a button etc). So, when compressed with H.264, such “static” nature of the video makes the file size 3-4 times less.

2.       The quality.

The agent screen recording is hardly the type of video you need to be of the highest quality. If you can read what agent typed when on phone – that’s enough. In our projects the quality setting of H.264 codec is usually 0,5-0,7.

3.       The FPS (frame per second) rate.

Most movies are shot at 24 FPS, but then again, this is not the case for screen recording in a contact center. You don’t need a smooth movie of the agent screen to understand what text is entered and which button is clicked. FPS 5-7 could be enough for recording the screen with CRM.

AnyConnect VPN DTLS vs TLS

Difference

DTLS is used for delay sensitive applications (voice and video) as its UDP based while TLS is TCP based

DTLS is supported for AnyConnect VPN not in IKEv2

How it works?

• SSL−Tunnel is the TCP tunnel that is first created to the ASA
• When it is fully established, the client will then try to negotiate a UDP DTLS−Tunnel
• During DTLS negotiation, traffic will be passing over TLS tunnel
• When the DTLS−Tunnel is fully established, all data now moves to the DTLS−tunnel and the SSL−tunnel is only used for occasional control channel traffic
• In case of failures in establishing DTLS Tunnel, traffic will continue passing over TLS tunnel
• After establishing DTLS, in the event of failure in DTLS Tunnel, traffic will pass over TLS tunnel until DTLS tunnel is reestablished

How Data is Forwarded?

• For each packet there is a part in AnyConnect client code which decides whether to send the packet over TLS or DTLS
• If the DTLS tunnel is established, the code will decide to forward the packet over DTLS and start encryption
• If the DTLS is dead, the code will decide to forward the packet over TLS and start encryption

• The key point is the performance of DTLS tunnel
• Since DTLS is based on UDP, it is unreliable and there is no flow control to decide its performance
• Performance can be determined using DPD packets
• When DPD is triggered and no response received, AnyConnect client will start forwarding packets over TLS (assuming TLS is up and DTLS is unhealthy)
• Therefore, there is a packet drop period between DTLS failing and DPD triggering/detection. During this time, AnyConnect client will be forwarding packets over DTLS but they will be lost because DTLS is unhealthy
• In case DTLS is established again, AnyConncect client will forward packets over DTLS
• For receiving ASA with healthy DTLS and TLS, it will reply based on the receiving tunnel, i.e. if packets received over TLS, the response will be over TLS even if DTLS is healthy

What about Idle timeout?

• When a DTLS−Tunnel is active, that is the only tunnel where idle timeout matters. Because very little control channel traffic passes over the SSL−Tunnel, it is almost always idle so it is exempt while there is an active DTLS−Tunnel. If something happened to UDP and the DTLS−Tunnel was torn down, then idle timeout would apply to the SSL−Tunnel

Configuration

DTLS is enabled by default but you can enable it or distable using CLI.

It can be enabled/disable per interface terminating AnyConnect VPN

webvpn

 enable if-name tls-only

Also, you can enable/disable DTLS at Group Policy level

webvpn

 dtls port 443

!

group-policy custom_group_policy attributes

 wins-server none

 dns-server value 10.170.7.99 10.170.7.100

 vpn-tunnel-protocol ssl-client ssl-clientless

 split-tunnel-policy tunnelspecified

 split-tunnel-network-list value sslvpn_split_tunnel

 default-domain value shelfdrilling.com

 split-dns none

 split-tunnel-all-dns enable

 webvpn

  anyconnect ssl dtls enable

  anyconnect mtu 1420

  anyconnect profiles value sslvpnfromrdpprofile type user

  customization value ShelfDrilling-Customization

  always-on-vpn profile-setting

The Importance of Understanding MTU value in AnyConnect VPN

Why do we need it?

During encryption, additional overhead will be added to the packets made by new headers and features. This means that the actual size of the unencrypted TCP segment or UDP datagram which holds the application will be reduced because the MTU of the adapter is still same.

For example with Ethernet and MTU of 1500-bytes, the unencrypted TCP segment can't be more than 1460-bytes. With encryption, for Ethernet and MTU of 1500, the unencrypted TCP segment can't be more 1380 (can be different value). The 80-bytes difference are utilized by encryption overhead.

Now the value of unencrypted TCP segment can be more which leads to MTU more than 1500-bytes but this will cause the networking devices to fragment the packet which is bad and should be avoided.

AnyConnect client builds Virtual Adapter (VA) during installation on the clients machine. This VA will receive unencrypted traffic and emulates Ethernet to forward traffic after encryption. The actual traffic then goes over the physical adapter.

Therefore, we need to know what is the MTU value of the VA and what is the max allowed size of unencrypted traffic to avoid fragmentation. Later the applications need to make sure that they don't create segments and datagrams larger else they will be fragmented.

How it works?

AnyConnect VA gets its MTU value from SSL Server (ASA or IOS. We will focus more on ASA). The default value is 1406-bytes. It can be configured as follow:

group-policy custom_group_policy attributes

 webvpn

  anyconnect mtu 1420

Now the actual MTU used by the VA will be selected based on the smaller between physical NIC MTU and VA configured MTU. This is to avoid scenarios where the VA has MTU configured more than physical NIC which will trigger fragmentation.

Next we need to find out the max value of unencrypted payload. Two values will be calculated, one for TLS Tunnel and one for DTLS tunnel. This can be viewed in ASA using the command debug webvpn anyconnect 1

……

……

Iphdr=20 base-mtu=1300 def-mtu=1500 conf-mtu=1420

tcp-mss = 1260

path-mtu = 1260(mss)

TLS Block size = 16, version = 0x301

mtu = 1260(path-mtu) - 0(opts) - 5(ssl) = 1255

mod-mtu = 1255(mtu) & 0xfff0(complement) = 1248

tls-mtu = 1248(mod-mtu) - 8(cstp) - 20(mac) - 1(pad) = 1219

DTLS Block size = 16

mtu = 1300(base-mtu) - 20(ip) - 8(udp) - 13(dtlshdr) - 16(dtlsiv) = 1243

mod-mtu = 1243(mtu) & 0xfff0(complement) = 1232

dtls-mtu = 1232(mod-mtu) - 1(cdtp) - 20(mac) - 1(pad) = 1210

computed tls-mtu=1219 dtls-mtu=1210 conf-mtu=1420

DTLS enabled for intf=2 (CORP)

tls-mtu=1219 dtls-mtu=1210

……

……

Let's examine the debugs

Iphdr=20 base-mtu=1300 def-mtu=1500 conf-mtu=1420

!!!... Iphdr is 20 bytes, Physical NIC MTU is 1300, configured MTU value for AnyConnect VA is 1420. Conclusion, Physical NIC MTU is used for VA.

!!!... Now will start TLS Tunnel calculations

tcp-mss = 1260

path-mtu = 1260(mss)

!!!... Since TLS is TCP based, the TLS payload size is MTU - 40. 40-bytes is 20-bytes IP Header + 20-bytes TCP Header

TLS Block size = 16, version = 0x301

mtu = 1260(path-mtu) - 0(opts) - 5(ssl) = 1255

mod-mtu = 1255(mtu) & 0xfff0(complement) = 1248

tls-mtu = 1248(mod-mtu) - 8(cstp) - 20(mac) - 1(pad) = 1219

!!!... Subtracting headers (5-bytes ssl header, 1-byte padding, 8-bytes Cisco SSL Tunneling Protocol (CSTP) header, 20-bytes MAC), we will get the size of unencrypted payload. This will be communicated back from ASA to AnyConnect client so that applications shouldn't cross this value else fragmentation will be triggered

!!!... Note: ANDing MSS value will complement 0xfff0 is to make sure that MSS value is power of 2

!!!... Now will start DTLS MTU calculations

DTLS Block size = 16

mtu = 1300(base-mtu) - 20(ip) - 8(udp) - 13(dtlshdr) - 16(dtlsiv) = 1243

mod-mtu = 1243(mtu) & 0xfff0(complement) = 1232

dtls-mtu = 1232(mod-mtu) - 1(cdtp) - 20(mac) - 1(pad) = 1210

!!!... Subtracting headers (20-bytes IP header, 8-bytes UDP header, 13-bytes DTLS header, 8- or 16- bytes for encryption [depending DES or AES], 1-byte Cisco DTLS Tunneling Protocol [CDTP] header, 20-bytes MAC, 1-byte pad), we will get the size of unencrypted payload. This will be communicated back from ASA to AnyConnect client so that applications shouldn't cross this value else fragmentation will be triggered

computed tls-mtu=1219 dtls-mtu=1210 conf-mtu=1420

DTLS enabled for intf=2 (CORP)

tls-mtu=1219 dtls-mtu=1210

Message Authentication Code (MAC)
A Message Authentication Code is a one-way hash computed from a message and some secret data.  It is difficult to forge without knowing the secret data.  Its purpose is to detect if the message has been altered.