Community.cisco.com



DATAGRAM TRANSPORT LAYER SERVICE (DTLS) OVERVIEW AND CONFIGURATION TCP is used in SSL/TLS because of the need to support message reordering, retransmission and reliable delivery. TLS cannot be used to secure datagram. Also, UDP traffic can have poor performance (due to packet loss, congestion and packet received out-of-order) when TLS is used. When packet loss exists between SSL VPN client and SSL VPN gateway, the inner TCP connection will suffer and this might lead to latency in the communication. DTLS was invented by Eric Rescorla and Nagendra Modadugu and defined in RFC 4347, 5238 and 5764. The use of DTLS (UDP based protocol) helps mitigate the problem described in TLS. DTLS uses UDP transport to avoid latency and bandwidth problems. No retransmission of lost packet exists at the TLS layer, only application retransmission exists. DTLS is still based on the original implementation of TLS but instead it operates using UDP transport protocol for faster packet delivery. DTLS was implemented by adding additional lines of code to open SSL, of which about 60% were cut and pasted from OpenSSL. Similar to TLS, all DTLS data are carried in records. Additional parameters, fields and functions allow it to provide reliable message delivery, message reordering, fragmentation and anti-replay. DTLS record protocol adds two new fields (Sequence number and Epoch) to the original TLS record layer. The sequence number is used to mitigate packet loss out-of-order. The sequence number increment for each packet sent between client and server and windowing systems is used for anti-replay purpose. Only a single packet (with a unique sequence number) is allowed within the replay window. If a packet with the same sequence number is received within the replay window, the packet will be dropped. Sequence numbers used in DTLS are explicitly defined unlike TCP. To allow reuse of sequence numbers when an SSL client or SSL server is engaging in multiple conversations, Epoch field is used. This field is used to differentiate different conversations occurring at the same time. The Epoch begins with a value of zero during the handshake process and the field increments each time a ChangeCipherSpec packet is sent by the client. This field is rest to zero again when the handshake process occurs again between the SSL client and the SSL gateway. DTLS handshake is similar to TLS except these major changes:Stateless cookie exchange to prevent denial of service (DOS). Since DTLS handshake takes place over datagram transport, it is vulnerable to DOS attacks.Message fragmentation and re-assembly used to reassemble records into a coherent stream of complete handshake messages.Retransmission timer used by SSL client and SSL gateway to handle message losses.DTLS helps to eliminate the latency involved when using voice, video, real-time and multimedia applications across SSL VPN tunnels. This process is defined in RFC 4347. When DTLS is enabled, TLS is still used to negotiate and establish DTLS connections (control message and key exchange). Two tunnels are used between the client and the server: one uses SSL with TCP port 443 and the other uses DTLS with UDP port 443 by default. If a DTLS connection becomes unhealthy and unreliable, communication data will be lost over the DTLS connection during that short period of time. Once Dead Peer Detection (DPD) occurs, data will be immediately set via the SSL connection using TLS. SSL VPN client will send data over the last connection it received data on. Therefore, if the client has determined that the DTLS connection is not healthy, it will start sending data over the TLS connection then the gateway will reply on the TLS connection. In order to make DTLS connection successful, both TCP and UDP ports need to be open on the SSL VPN gateway and paths along the gateway (these include any physical or logical firewall, router with IOS firewall or inbound Access Control List (ACL).) Also, it is important to check with the ISP side to ensure UDP 443 is opened. Also, between this device and the remote pair it is important to ensure that no ACL exists on local and remote routers and also that no firewall or network device is blocking UDP port 443. DTLS works through NAT gateways as long as they do not perform inspection and/or validation of the packets (such as is done by an application-aware proxy or load balancer). DTLS tunnel is not successful if a TCP proxy exists between SSL client and SSL gateway. On the CISCO ASA, DTLS is not possible when running AnyConnect Secure Mobility client with Internet Key Exchange Version 2 (IKEV2)DTLS AND WEAK SECURITY SUITE (RC4 MD5 ALGORITHM)RC4 (also known as ARC4 or ARCFOUR meaning Alleged RC4 ) , usually uses 40 bit or 128 bit encryption key length. It is the most popular stream based cipher due to its computational efficiency and simplicity. For similar reasons, it was used as a preferred cipher for many applications, including SSL protocol method in (TLS 1.0 ) and Wired Equivalent Privacy (WEP). The RC4 cipher suite is not easily applied to lossy datagram traffic: random access implies that the key stream needs to be buffered. Also RC4 is known to be vulnerable when non-random or related keys are used. Due to this limitation, RC4 is considered an unsuitable cipher suite for DTLS. Message Digest 5 (MD5) is a cryptographic hash function that produces a 128-bit (16-byte) hash value. MD5 is not collision resistant. A group of researchers described how a pair of files can have the same MD5 checksum. Due to this weakness, it is not suitable for securing applications.If the Cisco ASA is set to use RC4-MD5 encryption, AnyConnect fails to initiate DTLS.TLS AND WEAK SECURITY SUITE (DES and MD5 ALGORITHM)Data Encryption Standard (DES) is a block based cipher which uses shared secret encryption. DES is considered insecure due to its small key size (56 bit key size); this can be cracked in less than 24 hours. Message Digest 5 (MD5) is cryptographic hash function that produces a 128-bit (16-byte) hash value. MD5 is not collision resistant. A group of researchers described how a pair of files can have the same MD5 checksum. Due to this weakness, it is not suitable for securing applications.A “show run all ssl” command displays the current cipher suite being used by ASA while the “show version” command displays the license capability on an ASA. Out of the box, the Cisco ASA comes with VPN-DES license only and this license supports only DES encryption and MD5 hashing algorithm. In order to use more secure cipher suite, one needs to have the VPN-3DES-AES?license. If the ASA does not have this license or when the license is not enabled, it will become impossible to configure the more secure cipher suite. Due to inherent weakness in older versions of SSL versions (SSL 1.0 and SSL 2.0), they are no longer supported in modern operating systems and browsers. When using the default license(VPN-DES), due to the weakness of the ciphers suite and hashing algorithm, modern version of Firefox and internet browser do not negotiate the weak cipher suite and hashing algorithm during the SSL hand shake (client hello). This makes it impossible to complete the SSL handshake. Since the handshake can never be completed, it becomes impossible to make SSL VPN or ASDM work. In this situation, the SSL VPN logon page is never displayed. A Wireshark capture on the client PC will indicate the SSL handshake is never completed , a “show asp drop” on the ASA indicates SSL handshake failure and the logs on the ASA show port 443 is being reset.NOTE: Besides the above described scenario, the same problem can also been seen in the following situations:When the ASA is reset to factory default with the (restore factory-default) commandWhen the VPN-3DES-AES?license exists on the ASA and SSL is not configured correctly. To configure SSL correctly ,use the commands below: GoryASA (config ) ssl server-version any GoryASA (config ) ssl client-version any GoryASA (config ) ssl encryption rc4-md5 rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1WORKAROUND: If one is using a Firefox browser, one can configure the browser to negotiate the weak cipher suite and hashing algorithm by typing “about:config” in the address bar. This will open a page that allows modification of the SSL supported cipher suite and hashing algorithm.DTLS AND FIREWALL CONNECTIONWhen DTLS is enabled, two tunnels are used between the client and the server: one uses TLS with TCP port 443 and the other uses DTLS with UDP with port 443. Since DTLS uses UDP, intermediate firewalls or address translation devices can create problems by timing out idle DTLS connections before they are done. Increasing the UDP idle timeout on the firewall and address translation devices can be used to mitigate this problem. Dead Peer Detection (DPD) can be used to send keepalives across the DTLS connection to ensure this does not happen. For DTLS to fall back to TLS during failure of DTLS session, DPD needs to be enabled. The DPD interval should be set two times higher than the firewall’s idle threshold. The keepalive interval should be set to a time value less than the firewall’s idle timer. For example, if the firewall has an idle timer of 30 seconds, the DPD interval should be set to 60 seconds and the keepalive interval to 20 or 25 seconds.SAMPLE CONFIGURATION OF DTLS ON CISCO ASA 8.4Webvpn enable outsidedtls port 443 group-policy sales attributes webvpn anyconnect ssl keepalive 25 anyconnect dpd-interval client 60 anyconnect ssl dtls enable exit Verifying DTLS on ASAShow vpn-sessiondb svcShow conn port 443 allSAMPLE CONFIGURATION OF DTLS ON CISCO ROUTERDTLS on Cisco IOS feature was introduced on IOS 15.1(2)T and above. The example below shows how DTLS can be configured GORYROUTER(config)#webvpn context GoryConGORYROUTER(config-webvpn-context)#policy group salespolGORYROUTER(config-webvpn-group)#svc dtlsGORYROUTER(config-webvpn-group)#svc dpd-interval client 60GORYROUTER(config-webvpn-group)#svc keepalive 25DTLS DEBUG COMMANDS ON IOSdebug webvpn dtls errorsdebug webvpn dtls packetsdebug webvpn dtls eventsThe output below is taken from CISCO ASA after a DTLS connection was initiated and established between the ASA and AnyConnect Client PC. The output indicated that, for a single connection from the Anyconnect client (IP address of 192.168.100.1). Two tunnels were created on the ASA, (TLS and DTLS tunnel)GoryASA# sh vpn-sessiondb detail svcSession Type: SVC DetailedUsername : cisco Index : 8Assigned IP : 192.168.100.1 Public IP : 171.69.89.86Protocol : Clientless SSL-Tunnel DTLS-TunnelLicense : SSL VPNEncryption : DES Hashing : SHA1Bytes Tx : 46232 Bytes Rx : 11307Pkts Tx : 47 Pkts Rx : 12Pkts Tx Drop : 0 Pkts Rx Drop : 0Group Policy : connect Tunnel Group : connectLogin Time : 21:13:16 PST Wed Nov 30 2011Duration : 0h:02m:21sInactivity : 0h:00m:00sNAC Result : UnknownVLAN Mapping : N/A VLAN : noneClientless Tunnels: 1SSL-Tunnel Tunnels: 1DTLS-Tunnel Tunnels: 1Clientless: Tunnel ID : 8.1 Public IP : 171.69.89.86 Encryption : DES Hashing : SHA1 Encapsulation: TLSv1.0 TCP Dst Port : 443 Auth Mode : userPassword Idle Time Out: 30 Minutes Idle TO Left : 27 Minutes Client Type : Web Browser Client Ver : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; GTB7.2; .NET CLR Bytes Tx : 45440 Bytes Rx : 11307SSL-Tunnel: Tunnel ID : 8.2 Assigned IP : 192.168.100.1 Public IP : 171.69.89.86 Encryption : DES Hashing : SHA1 Encapsulation: TLSv1.0 TCP Src Port : 2314 TCP Dst Port : 443 Auth Mode : userPassword Idle Time Out: 30 Minutes Idle TO Left : 27 Minutes Client Type : SSL VPN Client Client Ver : Cisco AnyConnect VPN Agent for Windows 3.0.4235 Bytes Tx : 792 Bytes Rx : 0 Pkts Tx : 1 Pkts Rx : 0 Pkts Tx Drop : 0 Pkts Rx Drop : 0 Filter Name : denyconnectDTLS-Tunnel: Tunnel ID : 8.3 Assigned IP : 192.168.100.1 Public IP : 171.69.89.86 Encryption : DES Hashing : SHA1 Encapsulation: DTLSv1.0 UDP Src Port : 2317 UDP Dst Port : 443 Auth Mode : userPassword Idle Time Out: 30 Minutes Idle TO Left : 27 Minutes Client Type : DTLS VPN Client Client Ver : Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; GTB7.2; .NET CLR Bytes Tx : 0 Bytes Rx : 0 Pkts Tx : 0 Pkts Rx : 0 Pkts Tx Drop : 0 Pkts Rx Drop : 0 Filter Name : denyconnectGoryASA# sh conn port 443 allUDP outside 171.69.89.86:2317 NP Identity Ifc 171.69.89.142:443, idle 0:00:06, bytes 5875, flags -TCP outside 171.69.89.86:2314 NP Identity Ifc 171.69.89.142:443, idle 0:00:12, bytes 1986, flags UOBFURTHER READING REQUEST FOR COMMENTS: 4347 REQUEST FOR COMMENTS: 5238 REQUEST FOR COMMENTS: 5764 HOW TO CRACK MD5 HASHS WITH CAIN NEWS KEY RECOVERY ATTACKS ON RC4/WEP (EN) RC4 BASICS SYMMETRIC KEY CRYPTO --- STREAM CIPHERS, RC4 BACK TRACK SSLSTRIP TOOL "DES CRACKER" MACHINEGORI DAWODUCisco TAC VPN (San Jose) ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download