Properties of ICS Protocols

I want to propose a method or philosophy to study ICS protocols but first I need to define some of their properties.  These properties are not unique, or new, only that with the analysis of the network communication, it's best if the terminology is consistent.

There are many ICS protocols.  Many are called fieldbus protocols, and some are based on the pre-Ethernet days, while some are not.  Some popular Ethernet ones are

ModbusTCP
EtherNet/IP 
Profinet
PowerLink
EtherCAT
sercosIII

and many others.  Some non-Ethernet ones are

CANopen
DeviceNet
Modbus
ASI

and many more...

My focus is on Ethernet mostly, in particular ModbusTCP and EtherNet/IP, which is CIP on Ethernet.

Some particular features of ModbusTCP is that it is usually a polling protocol.  A request is made, and then this request is fulfilled in a response.  This applies to CIP explicit messaging as well (CIP is a suite of protocols, and the explicit messaging type behaves this way).  Based on this behavior, there are several factors to note:

1. No response with updated data is usually available until a request is made.  There are exceptions, but the vast majority of these types of communications is pure polling - there is little to no report-by-exception.  The server issues responses.
2. There is typically a request time - how often a request for new data is made.  This is called many things on many different platforms, but the concept is simple: every period of time, make a request for new data.  The client makes the request.
3. The device that acts as the server has a response time.  How long does it take to answer a request that comes in?  Wireshark is a nice tool to evaluate this, if the number of samples is not too large.
4. There is a concept of data freshness - how long does it take to update data in the client?  This is obviously a function of both the request period and the response time of the server device.

Some different role names used in ICS protocols:

 
and a visual on the request/response aspect of ModbusTCP:

Since we are capturing the traffic in Wireshark now, we can see the Queries going out, and then we can see the responses coming back.  It's straightforward to calculate the time between the two, and we can call that the response time.  The time between queries for a given set of data we can call Query-Query time, or what is called RepRate in the graphic above (it's not really a repetition rate, but rather a repetition period - I didn't name it!)

For CIP (EtherNet/IP) the same concepts exist for explicit messaging.  This is actually what makes it explicit - a request comes in and then it is answered.  It's object based -yada, yada, yada, but fundamentally the communications profile is the same - a request is sent, and it is answered.  Now there are advances here.  There is Implicit messaging as well (often called Class1 or IO messaging), which is very different.  It uses UDP at the transport layer, and the logical connection is set up in advance in which both sides agree to what data will be sent, how often, and with what options (timeouts, etc).  In this case, then, there is no request - each side, independently, just publishes data to the wire (possibly using multicast, other times using unicast at the network layer).  But explicit is different - the specific request comes in, and then is answered, and uses TCP at the transport layer.  There is Class3 messaging which means a CIP connection is set up before hand and then explicit messages are sent and responded to.  There is UCMM, where the message is just sent and it's best effort - this is much like ModbusTCP where there is no concept of an application layer connection like with Class3 messaging.  There are unconnected_sends, which uses UCMM but the actual data request is encapsulated.  I expect to talk more about EtherNet/IP in the future.

For analysis, Class1 messaging has a free tool from NIST available on SourceForge.  It's called IENetP, and is available at http://sourceforge.net/projects/ienetp/.  A method of analysis will be presented here for explicit type messaging, though right now it is for ModbusTCP only.  It could be easily extended to EtherNet/IP, and will be in the future.  Note that this request/response type communication protocol is similar to others: SNMP has a similar structure with gets and get-responses (and has trap type extensions which are nice additions to improve performance with a report-by-exception mechanism).    

Next time we'll introduce the tool and show some of the results.