EtherNet/IP, like PROFINET IO and some other industrial protocols, uses both acyclic and cyclic communications. Acyclic communications are used for moving information between Scanners (controller side devices) and Adapter devices (I/O type devices). Cyclic communications are used for moving I/O data between Scanners and Adapters. Acyclic messages send configuration and information like ramp up time on an intermittent schedule while Cyclic communications are repeated on a continuous basis.
The underlying communication layers are different for both communication types. Acyclic communications use TCP messaging to move messages. TCP communication is reliable: packets are sent (and received) in sequence, and the sender gets an acknowledgment that each packet arrived on time. Cyclic communications use UDP (Unigram Data Protocol). UDP is a “fire and forget” protocol without any confirmation that the packets arrived at all or in what order.
Because of the underlying differences between these transport layers, CIP Secure Communications (the mechanism used to secure EtherNet/IP) uses two different security mechanisms. Acyclic communications (TCP transport) uses TLS (Transport Layer Security). TLS is a well-known internet security standard designed to ensure message integrity, to authenticate endpoints and to keep the contents of messages private. You’re using TLS whenever you see that little lock and the “https:” at the beginning of a URL.
The key to TLS is the communication handshake where a client and server use asymmetric cryptography to agree on a key. Once that key is known, both sides use it to encrypt messages that are private and free from modification by a third party.
Unfortunately, the nature of UDP makes TLS unsuitable for EtherNet/IP Cyclic communications. Specifically, the TLS handshake, where a client and server privately negotiate encryption algorithms and keys, is unsuitable with a protocol that doesn’t provide message acknowledgment and properly ordered messages. Additionally, the handshake messages used by TLS are potentially larger than the maximum datagram size of UDP, leading to fragmentation issues.
DTLS (Datagram Transport Layer Security) is a variant of TLS that is designed to overcome these problems while also being as similar as possible to TLS. Specifically, it implements:
A Retransmission Timer: Since a client device doesn’t receive any acknowledgment from the UDP transport layer that a message arrived, the DTLS protocol implements a retransmission timer. If the server does not respond to the Hello message within a set time, a client assumes that the Hello never arrived and retransmits it.
Message Reordering: To provide a mechanism for a device to order messages properly, DTLS adds a message sequence number to each message. A message arriving out of order can be queued until any prior messages are processed.
Message Size: TLS messages can often be quite large, exceeding the ~1500 bytes available in a UDP datagram. DTLS accounts for this and compensates for this limitation by fragmenting the handshake messages over several UDP records, allowing the receiver to properly rebuild the original record.
Replay Detection: DTLS implements a mechanism where messages that are old or previously received can be silently discarded.
EtherNet/IP Cyclic messaging relies on DTLS to ensure privacy, authentication and data integrity for the I/O messages that are so important to a properly functioning automation system.