For some folks, the OSI Reference Model is just something we have read about in standards documents (or memorized the seven layer model for a certification exam or a job interview) but never actually used in the real world. This was true for me until I started looking at ICCP. (To be completely honest, I had heard about OSI Protocols being used in aviation communication networks such as the ATN, but that was the extent of my exposure.)

For the next several blogs, we’ll start at the bottom of the stack and work our way up to illustrate the differences (and the relative complexity) of ICCP compared to other SCADA protocols. If you are a registered SCADA IDS user you will find a half-dozen packet capture files in the ICCP .zip file so you can follow “at home.”

For the lower layer protocols, you can use a recent version of Ethereal, but when we get to MMS and TASE.2/ICCP you will need to get Herbert Falk’s MMS-Ethereal.

One of the aspects of ICCP that surprised us (although in hindsight, it makes a lot of sense) is that many of the messages exchanges between ICCP clients and servers do not actually involve ICCP. This was reflected in our signatures, many which are for lower layer protocols.

But enough intro, here we go:

TCP
By default, ICCP uses the well-known port TCP/102, which depending on your services file may get resolved to “iso-tsap.” Not unlike the TCP sessions used by BGP (the Border Gateway Protocol), ICCP sessions are relatively long lived, perhaps staying active for weeks or months. I have heard this has caused issues with some stateful firewalls and network address translation implementations. Contrast this with most web (HTTP) sessions which may only be active for seconds or minutes. From a vulnerability perspective, why do we care? Some vulnerability research has suggested that long-lived sessions are more susceptible to TCP spoofing attacks. The standard countermeasures that have been around since the late 1990s, should apply as well for ICCP as well as they do for BGP.

TPKT
RFC 1006 (which Ethereal refers to as “TPKT”) is used to encapsulate OSI protocols on top of TCP. This is a simple four byte layer that only includes a version (I only saw 3) and and length field. Pretty straightforward and you can you can see this below. More information is available on the Ethereal Wiki. We included a non-TPKT signtaure to identify attempts to send non-ICCP traffic over port 102.

To close this blog, I’ll included Ethereal output to show where we are headed in the next blog: the Connection Oriented Transport Protocol (COTP), which is the first OSI protocol where communication parameters are exchanged to form an ICCP association.

Stay tuned…

TPKT, Version: 3, Length: 42 Version: 3 Reserved: 0 Length: 42 ISO 8073 COTP Connection-Oriented Transport Protocol Length: 37 PDU Type: CR Connect Request (0x0e) Destination reference: 0x0000 Source reference: 0x0001 Class option: 0x00 Parameter code:   0xc1 (src-tsap) Parameter length: 12 Source TSAP: B_VCC1_for_A Parameter code:   0xc2 (dst-tsap) Parameter length: 12 Destination TSAP: A_VCC1_for_B Parameter code:   0xc0 (tpdu-size) Parameter length: 1 TPDU size: 2048