IEC TS 60839-7-8:2019

Alarm systems - Part 7-8: Message formats and protocols for serial data interfaces in alarm transmission systems - Requirements for common protocol for alarm transmission using the Internet protocol

IEC 60839-7-8:2019 specifies a protocol for point-to-point transmission of alarms and faults, as well as communications monitoring, between a supervised premises transceiver and a receiving centre transceiver using the Internet protocol (IP).
The protocol is intended for use over any network that supports the transmission of IP data. These include Ethernet, xDSL, GPRS, WiFi, UMTS and WIMAX.
The system performance characteristics for alarm transmission are specified in IEC 60839‑5‑1.
The performance characteristics of the supervised premises equipment comply with the requirements of its associated alarm system standard and apply for transmission of all types of alarms including, but not limited to, fire, intrusion, access control and social alarms.

General Information

• Status: Published
• Publication Date: 23-May-2019
• ICS: 13.320 - Alarm and warning systems
• Technical Committee: TC 79 - Alarm and electronic security systems
• Current Stage: PPUB - Publication issued
• Start Date: 24-May-2019
• Completion Date: 14-May-2019

Standards Content (Sample)

IEC TS 60839-7-8 ®
Edition 1.0 2019-05
TECHNICAL
SPECIFICATION
Alarm systems –
Part 7-8: Message formats and protocols for serial data interfaces in alarm
transmission systems – Requirements for common protocol for alarm
transmission using the Internet protocol

All rights reserved. Unless otherw ise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, w ithout permission in w riting from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: [phone]
3, rue de Varembé [e-mail]
CH-1211 Geneva 20 w ww.iec.ch
Sw itzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform Electropedia - www.electropedia.org
The advanced search enables to find IEC publications by a The world's leading online dictionary on electrotechnology,
variety of criteria (reference number, text, technical containing more than 22 000 terminological entries in English
committee,…). It also gives information on projects, replaced and French, w ith equivalent terms in 16 additional languages.
and w ithdraw n publications. Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Glossary - std.iec.ch/glossary
details all new publications released. Available online and 67 000 electrotechnical terminology entries in English and
once a month by email. French extracted from the Terms and Definitions clause of
IEC publications issued since 2002. Some entries have been
IEC Customer Service Centre - webstore.iec.ch/csc collected from earlier publications of IEC TC 37, 77, 86 and
If you wish to give us your feedback on this publication or CISPR.

need further assistance, please contact the Customer Service

Centre: [e-mail].
IEC TS 60839-7-8 ®
Edition 1.0 2019-05
TECHNICAL
SPECIFICATION
Alarm systems –
Part 7-8: Message formats and protocols for serial data interfaces in alarm

transmission systems – Requirements for common protocol for alarm

transmission using the Internet protocol

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 13.320 ISBN 978-2-8322-6813-1

– 2 – IEC TS 60839-7-8:2019 © IEC 2019
CONTENTS
FOREWORD . 6
1 Scope . 8
2 Normative references . 8
3 Terms, definitions and abbreviations . 8
3.1 Terms and definitions . 8
3.2 Abbreviations . 9
4 Objective . 9
5 Messaging . 10
5.1 General . 10
5.2 Message format overview . 10
5.2.1 General . 10
5.2.2 Identifiers . 10
5.2.3 Message format . 11
5.2.4 Connection handle. 12
5.2.5 Device ID . 12
5.2.6 Message ID . 13
5.2.7 Message length . 14
5.2.8 Sequence numbers . 14
5.2.9 Flags. 14
5.3 Padding and message length . 14
5.3.1 Padding . 14
5.3.2 Message length . 15
5.4 Hashing . 15
5.5 Encryption . 15
5.5.1 General . 15
5.5.2 Key exchange . 16
5.6 Timeouts and retries . 16
5.7 Version number . 17
5.8 Reverse commands . 17
5.9 Initial values . 18
6 Message types . 18
6.1 General . 18
6.2 Path supervision . 18
6.2.1 General . 18
6.2.2 Poll message . 18
6.2.3 Poll response . 19
6.3 Event reporting . 19
6.3.1 Event message format . 19
6.3.2 Event response format. 22
6.4 Configuration messages . 23
6.4.1 General . 23
6.4.2 Connection handle request . 23
6.4.3 Connection handle response . 24
6.4.4 Device ID request. 24
6.4.5 Device ID response . 25
6.4.6 Encryption selection request . 25

6.4.7 Encryption selection response . 26
6.4.8 Encryption key exchange request . 26
6.4.9 Encryption key exchange response. 27
6.4.10 Hash selection request . 27
6.4.11 Hash selection response . 28
6.4.12 Path supervision request. 28
6.4.13 Path supervision response . 29
6.4.14 Set time command. 29
6.4.15 Set time response . 29
6.4.16 Protocol version request . 30
6.4.17 Protocol version response . 30
6.4.18 Transparent message. 30
6.4.19 Transparent response . 30
6.4.20 DTLS completed request . 31
6.4.21 DTLS completed response. 31
6.4.22 RCT IP parameter request . 31
6.4.23 RCT IP parameter response. 32
7 Commissioning and connection setup . 32
7.1 Commissioning . 32
7.1.1 General . 32
7.1.2 Procedures . 33
7.1.3 Commissioning message sequence . 33
7.1.4 Commissioning using shared secret . 34
7.1.5 Commissioning using X.509 certificates and DTLS . 35
7.2 Connection setup . 36
Annex A (normative) Result codes . 38
Annex B (normative) Protocol identifiers. 39
Annex C (normative) Shared secret. 40
C.1 Formatting of the shared secret . 40
C.2 Checksum for shared secret formatting. 40
C.3 Example of secret encoding and formatting. 40
Annex D (informative) Examples of messaging sequences . 42
D.1 Commissioning . 42
D.2 Connection setup . 45
Annex E (informative) Examples of application protocols . 48
E.1 SIA . 48
E.2 Ademco contact ID . 48
E.3 Scancom fast format . 49
E.4 VdS 2465 . 49
Annex F (informative) Design principles . 51
F.1 General . 51
F.2 Information security . 51
F.3 Use of UDP signalling . 51
Bibliography . 52

Table 1 – Identifiers . 10
Table 2 – Basic unencrypted format of messages . 11

– 4 – IEC TS 60839-7-8:2019 © IEC 2019
Table 3 – Basic encrypted format of messages . 11
Table 4 – Message ID overview . 13
Table 5 – Flags . 14
Table 6 – Hashing IDs . 15
Table 7 – Encryption IDs . 16
Table 8 – Reverse commands . 17
Table 9 – Initial values. 18
Table 10 – Poll message SPT   RCT . 18
Table 11 – Poll response RCT   SPT. 19
Table 12 – Event message format – SPT  RCT . 20
Table 13 – Event message format – Fields . 20
Table 14 – Event field. 21
Table 15 – Time event field . 21
Table 16 – Time message field . 21
Table 17 – Link field – IP address. 22
Table 18 – Link field – IP port number . 22
Table 19 – Link field – URL . 22
Table 20 – Link field – Filename. 22
Table 21 – Event response message format . 23
Table 22 – Connection handle request message format . 24
Table 23 – Connection handle response message format . 24
Table 24 – Device ID request message format . 24
Table 25 – Device ID request flags . 25
Table 26 – Device ID response message format. 25
Table 27 – Encryption selection request message format . 25
Table 28 – ‘Master encryption selection request’ flag . 26
Table 29 – Encryption selection response message format . 26
Table 30 – Encryption key exchange request message format . 26
Table 31 – ‘Master key request’ flag. 27
Table 32 – Encryption key exchange response message format . 27
Table 33 – Hash selection request message format . 28
Table 34 – Hash selection response message format . 28
Table 35 – Path supervision request message format . 28
Table 36 – Path supervision response message format. 29
Table 37 – Set time command message format . 29
Table 38 – Set time response message format . 29
Table 39 – Protocol version request message format . 30
Table 40 – Protocol version response message format . 30
Table 41 – Transparent message format . 30
Table 42 – Transparent response format . 31
Table 43 – DTLS completed request message format . 31
Table 44 – DTLS completed response message format . 31
Table 45 – RCT IP parameter request message format . 32

Table 46 – RCT IP parameter response message format . 32
Table 47 – Message flow during the commissioning of a new SPT . 33
Table 48 – Message flow during connection setup . 36
Table A.1 – Result codes . 38
Table B.1 – Protocol identifiers . 39
Table D.1 – Commissioning messaging sequence . 42
Table D.2 – Messaging sequence during connection setup . 45

– 6 – IEC TS 60839-7-8:2019 © IEC 2019
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
ALARM SYSTEMS –
Part 7-8: Message formats and protocols for serial data interfaces in alarm
transmission systems – Requirements for common
protocol for alarm transmission using the Internet protocol

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Techni ca l S pe cif i cat i ons,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee intereste d
in the subject dealt with may participate in this preparat ory w ork. In t ern at i on al , go vern me nt al a n d n on -
governmental organizations liaising with the IEC also participate in this preparation. IEC collabo rat es cl o sel y
w ith the International Organization for Standardization (ISO) in accordance w i t h co nd i ti o ns d et ermi n e d b y
agreement between the tw o organizations.
2) The f ormal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committ ee h as r ep resen ta ti o n f ro m a l l
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accep te d b y IEC Na t i o n a l
Committees in that sense. While all reasonable efforts are made to ensure that the tech ni cal c on te nt of IEC
Publications is accurate, IEC cannot be held responsi b l e f o r t he w a y i n w h i ch t h ey a re u se d o r f o r a ny
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake t o a pp l y IEC Pu b l i c a ti o ns
transparently to the maximum extent possible in their national and r eg io na l p ub l ica ti o ns. A ny d i verg en ce
betw een any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies pro vid e c onf o rmi ty
assessment services and, in some areas, access to IEC marks of conformity. IEC is not r esponsible for any
services carried out by independent certification bodies.
6) A ll users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage o r
other damage of any nature whatsoever, whether direct or indirect, or for c osts ( i ncl ud i ng l e ga l f ees) a n d
expenses arising out of the publication, use of, or rel i a nce u p on , t h is IEC Pu b l i c a t i on o r a ny o t he r IEC
Publications.
8) A ttention is drawn to the Normative references cited in this publication. Use of the referenced p ub l i cat i ons i s
indispensable for the correct application of this publication.
9) A ttention is drawn to the possibility that some of the elements of this IEC Publicatio n ma y be t he su bj ect of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. In
exceptional circumstances, a technical committee may propose the publication of a te c h n i c a l
specification when
• the required support cannot be obtained for the publication of an Internatio n a l S t andard,
despite repeated efforts, or
• the subject is still under technical development or where, for any other reason, there is the
future but no immediate possibility of an agreement on an International Standard.
Technical specifications are subject to review within three years of publication to decide
whether they can be transformed into International Standards.
IEC 60839-7-8, which is a technical specification, has been prepared by IEC technical
committee 79: Alarm and electronic security systems.

The text of this technical specification is based on the following documents:
Enquiry draft Report on voting
79/419/DTS 79/453A/RVDTS
Full information on the voting for the approval of this technical specificatio n c a n b e fo u n d i n
the report on voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts in the IEC 60839 series, published under the gener a l t i t l e A l arm s ys tem s,
can be found on the IEC website.
The committee has dec ided that the contents of this publication will remain u n c h a n g e d u n t i l
the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication will be
• transformed into an International Standard,
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

– 8 – IEC TS 60839-7-8:2019 © IEC 2019
ALARM SYSTEMS –
Part 7-8: Message formats and protocols for serial data interfaces in alarm
transmission systems – Requirements for common
protocol for alarm transmission using the Internet protocol

1 Scope
This Part of IEC 60839 specifies a protocol for point-to-point transmission of alarms and
faults, as well as communications monitoring, between a supervised premises transceiver and
a receiving centre transceiver using the Internet protocol (IP).
The protocol is intended for use over any network that supports the transmissi o n o f IP d a t a .
These include Ethernet, xDSL, GPRS, W iFi, UMTS and WIMAX.
The system performance characteristics for alarm transmission are specified in
IEC 60839-5-1.
The performance characteristics of the supervised premises equipment comply with the
requirements of its associated alarm system standard and apply for transmission of al l t y pes
of alarms including, but not limited to, fire, intrusion, access control and social alarms.
Compliance with this document is voluntary.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited app l i e s. F o r
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 60839-5-1:2014, Alarm and electronic security systems – Part 5-1: A l arm t rans m i ssi on
systems – General requirements
RFC 793:1981, Internet standard – Transmission control protocol, DARPA Intern e t p r o g r a m ,
protocol specification
NIST 800-38A:2001, Recommendation for block cipher modes of operation: methods and
techniques
3 T e rms, de finitions and abbreviations
3.1 Te rms a nd de finitions
For the purposes of this document, the terms and definitions given in IEC 60839-5-1 apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp

3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
AES Advanced Encryption Standard
ARC Alarm Receiving Centre
ATS Alarm Transmission System
CA X.509 Certificate Authority
CBC Cipher Block Chaining
CRC Cyclic Redundancy Check
DNS Domain Name System
DTLS Datagram Transport Layer Security
HL Header Length
IP Internet Protocol
IV Initialization Vector
MAC Media Access Control
MTU Maximum Transmission Unit
NAT Network Address Translation
NIST National Institute of Standards and Technology
NTP Network Time Protocol
NVM Non-Volatile Memory
P-MTU Path Maximum Transmission Unit
RCT Receiver Centre Transceiver
RX Receive
SCTP Stream Control Transmission Protocol
SNTP Simple Network Time Protocol
SPT Supervised Premises Transceiver
TFTP Trivial File Transfer Protocol
TX Transmit
UDP User Datagram Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTC Coordinated Universal Time
WS W indow Size
4 Objective
The object of this document is to specify the protocol details (transport and application layers)
for alarm transmission systems using Internet Protocol (IP), to ensure interoperability between
SPTs and RCTs supplied by different manufacturers. Mechanism s t o c o m m i ssi o n S P T a n d
RCT and build mutual trust between the communicating parties are also described.
As compliance with this document is voluntary, any other alarm transmission protocol or
equipment not covered by this document may be used, provided that the requirements of
IEC 62642-1 are met.
This protocol is designed to run on top of UDP and is des igned to support both IPv4 and IPv6.

– 10 – IEC TS 60839-7-8:2019 © IEC 2019
NOTE For f urther discussion of IP and UDP in alarm transmission, please see F.3.
5 Messaging
5.1 General
This clause defines the messaging layer, on top of which the alarm event data is tr a n s m i t te d
using the existing reporting formats like for example Sia and Contact ID. Clause 7 defines t he
initial commissioning of an SPT, as well as how SPTs connect to the RCT.
The functionality of the alarm messaging and polling protocol includes:
– exchanging master and session parameters;
– (alarm) event reporting (including linking to out-of-band additional data related t o e ve n t s ,
like audio/video);
– line monitoring;
– transparent message transmission, e.g. vendor specific messages that, for ex a m p l e , c a n
be used for remote commands from RCT to SPT.
It fulfils the following requirements:
– encryption, fulfilling requirements for most demanding category of EN 50136-1;
– authentication, fulfilling requirements for most demanding category of EN 50136-1;
– SPT: allows a broad range of hardware (limited demands on memory footpri n t a s w e l l a s
CPU power);
– RCT: allows support for at least 10 000 SPTs in compliance with any category in
EN 50136-1, using modern general purpose server hardware;
– allow Dynamic IP addresses of the SPTs;
– allow one or more SPTs to be placed behind a NAT firewall.
5.2 Message format overview
5.2.1 General
This subclause describes the basic outline of all messages.
Each message shall be explicitly acknowledged, including line supervision messages.
Backwards compatibility is achieved by the implementation of the
RESP_CMD_NOT_SUPPORTED result value, which the receiving party can sen d a s a n s w e r
to unsupported messages.
Multi-byte values will be transmitted using network byte order (big-endian).
5.2.2 Identifiers
The identifiers given in Table 1 below exist.
Table 1 – Identifiers
Description Pur pose Pr esent in Encr ypted Se e
Look up the current symmetric A ll messages No 5.2.4
Connection handle
encryption key
Contributing to N / A 5.2.5
Device ID Uniquely identify the hardware hashes in all
messages
The connection handle is unencrypted. It is a unique number, initialized d u r i n g t h e s e t u p o f
the connection. Its sole purpose is to be able to look up the encryption key. It is valid for the
communication session only.
The Device ID uniquely identifies the hardware once the connection has been established.
The Device ID is used when computing the hash value for each message. In combination with
the encryption of the hash this is used for substitution detection.
NOTE Device ID is not equivalent to any account code or similar ID specified by application protocol.
The Device ID shall be stored in non-volatile memory within the SPT.
The IP address is not used for identification purposes, in order to allow for the use of dynamic
or translated IP addresses.
5.2.3 Message format
The basic unencrypted format of all messages is as follows. Message in this fo r m a t i s n e ve r
transmitted. It is described in Table 2 below only to clarify the hash value calculation.
Table 2 – Ba sic une ncrypted format of me ssa ges
Byte index Byte s Description Se e Gr oup
0 4 Connection handle 5.2.4 Header
4 16 Device ID 5.2.5
20 2 Tx Sequence number 5.2.8
22 2 Rx Sequence number 5.2.8
24 2 Flags 5.2.9
26 1 Protocol version number 5.7
27 1 Message ID 5.2.6 Message
28 2 Message length 5.2.7
30 n Message data Clause 6
The basic encrypted, transmitted format of all messages is as shown in Table 3. Note that t h e
Device ID field is not included in the encrypted message, but its value is used to compute t h e
message hash value i.e. the hash is calculated from the unencrypted version of the m e s s a g e
described above.
Table 3 – Basic encrypted format of messages
Byte index Byte s Description Se e Encr ypted Gr oup
0 4 Connection handle 5.2.4 No Header
4 2 Tx Sequence number 5.2.8 Y es
6 2 Rx Sequence number 5.2.8 Y es
8 2 Flags 5.2.9 Y es
10 1 Protocol version number 5.7 Y es
11 1 Message ID 5.2.6 Y es Message
12 2 Message length 5.2.7 Y es
14 n Message data Clause 6 Y es
Padding 5.3.1 Y es Tail
14 + n
32 Hash – SHA -256, or 5.4 Y es

32 Hash – RIPEMD-256
– 12 – IEC TS 60839-7-8:2019 © IEC 2019
The connection handle is unencrypted; the remainder of the message is encrypted u s i n g t h e
encryption method as negotiated during the commissioning stage.
Message ID’s are defined in pairs: each message has its matching response. Fo r r e s p o n s e s
the first byte of the Message Data always holds a ‘Result code’ as defined in Annex A.
All fields are described in detail in the following subclauses.
5.2.4 Connection handle
The connection handle is assigned (uniquely for the RCT to which a SPT r e p o r t s ) u s i n g t h e
commissioning protocol. The RCT creates a unique connection handle and l i nk s t hi s t o t he
Device ID of the SPT in its internal database. This translation results in a compact, fixed
length connection handle.
The purpose of the connection handle is to be able to determine the encryption key to be used
to decrypt the received message, independent of the IP address of the message.
The connection handle is not a (by the installer/operator) configurable par a m e t e r , n o r m a d e
visible on user interfaces. It is generated and used internally by the SPT/RCT equipment only.
5.2.5 De vice ID
5.2.5.1 General
The Device ID uniquely identifies the SPT and RCT. It is used (in combination with the
encryption) for substitution detection. Both SPT and RCT can verify the identity of the
connected party using this field, and create a substitution alarm in case it has changed.
W ithin the message header, the Device ID itself is never transmitted. However Devi c e ID i s
used to contribute to the message hash calculation.
Device ID is 16 bytes long.
5.2.5.2 SPT device ID
The device ID of the SPT is an ID that is random to the SPT, but fixed and read-only ove r t h e
lifetime of the SPT, i.e. a hardware serial number. It is unique within the SPT database i n t h e
RCT.
The device ID is created during manufacturing time of the device; in m e s s a g i n g , i t i s n e ve r
transmitted itself in clear text, but is needed to be known in clear text for the ARC to configure
the RCT accordingly.
Thus, it is only transmitted during initial commissioning phase to the RCT.
Uniqueness is assured by the following principles:
– each SPT manufacturer shall use his 24 bits “organizationally unique identifier” as
assigned to him by the IEEE for MAC-address generation;
– each SPT manufacturer not having such a code shall attend for such a code from IEEE;
– if an interface in the SPT makes use of a MAC address, the next 24 bits i n t h e d e vi c e ID
shall be the same as the rest of MAC address specified by the manufac t urer. If s uc h an
interface does not exist, the manufacturer shall use another numbering scheme
documented by the manufacturer;
– the manufacturer shall use non-consecutive, randomly distributed numbers for t h e r e s t o f
the device ID field and guarantee uniqueness for all his delivered SPT devices.

5.2.5.3 RCT device ID
The device ID of the RCT is an ID that is unique within the receiver and never changes wit hi n
the lifetime of a receiver. It represents the unique identity of the RCT.
The RCT device ID is made available to the SPT during the commissioning phase.
5.2.6 Message ID
The message IDs as used are listed in the following Table 4.
Table 4 – Message ID overview
Dir e ction V e rsion M essage
ID
M essage name Description
SPT 
RCT
POLL_MSG Poll message  1 0x11
EV ENT_MSG Event message  1 0x30
CONN_HA NDLE_REQ Connection handle request  1 0x40
DEV ICE_ID_REQ Device ID request  1 0x41
ENCRY PT_SELECT_REQ Encryption selection request  1 0x42
ENCRY PT_KEY _REQ Encryption key exchange   1 0x43
HA SH_SELECT_REQ Hash selection request 1 0x44

PA TH_SUPERV ISION_REQ Path supervision request 1 0x45
 
SET_TIME_CMD Set time command 1 0x47

V ERSION_REQ Protocol version request  1 0x48
PMTU_REQ P-MTU  1 0x60
PMTU_PROBE P-MTU probe  1 0x61
DTLS_COMPLETE_REQ DTLS completed request  1 0x62
TRA NSPA RENT_MSG Transparent message   1 0x70
POLL_RESP Poll response  1 0x91
EV ENT_RESP Event response  1 0xB0
CONN_HA NDLE_RESP Connection handle response  1 0xC0
DEV ICE_ID_RESP Device ID response  1 0xC1
ENCRY PT_SELECT_RESP Encryption selection response  1 0xC2
Encryption key exchange 1 0xC3
ENCRY PT_KEY _RESP  
response
HA SH_SELECT_RESP Hash selection response  1 0xC4
PA TH_SUPERV ISION_RESP Path supervision response   1 0xC5
SET_TIME_RESP Set time response  1 0xC7
V ERSION_RESP Protocol version response  1 0xC8
PMTU_RESP P-MTU response 1 0xE0

PMTU_PROBE_RESP P-MTU probe response 1 0xE1

DTLS_COMPLETE_RESP DTLS completed response 1 0xE2

TRA NSPA RENT_RESP Transparent response 1 0xF0
 
The message ID of any response is the same as the message ID of the corresponding
command, but with bit 7 set.
– 14 – IEC TS 60839-7-8:2019 © IEC 2019
5.2.7 Message length
This is the length of the message data (excluding message ID and message length). This field
is used:
– in variable length messages (see for example 6.3.1 and 6.4.18) to check for the end of
data;
– to be able to determine the start of an embedded reverse command (see 5.8).
Possible padding is never considered when calculating the value of the message length field.
5.2.8 Se que nce numbers
The sequence number is used to determine if a message is missing or duplicated. Bo t h e n d s
have a transmit sequence number and a receive sequence number.
These two counters exist at both ends (e.g. we are speaking about 4 counters in total),
whereas the RX_Sequence counters are used to realize a “state-full machine”
implementation.
These counters are used to fulfil three simultaneous functions:
a) Both SPT and RCT choose their TX_seqs to be a random number which is used as a
datagram counter, incrementing them for each sent datagram. The RX_seqs are the
expected next TX_seqs from the other communication end-point. If one did see “42” as the
last TX_seq coming in from the other communication end-point, one would s end out “ 43”
as next RX_seq. As the other end-point does this in the same style, the TX_seq and
RX_seq operate as a mutual sequence control mechanism.
b) Second, they can simultaneously operate as a resend-mechanism: If it is det ec t ed t hat a
datagram is missing (because for example, the incoming TX_seq is “44”, but TX_seq = 43
was expected) or the received datagram is corrupted (by checking the hash), t h e c orrec t
old previously s ent last datagram is resent by one communication end-point and the o t h e r
communication end-point will see by the old TX_seq that a re-transmission is requested.
c) Being chosen randomly and being part of the encrypted data block, t h e y r u l e o u t r e p l a y
attacks.
For each connection, every message has to be acknowledged before the next new (not
retransmission) message may be transmitted.
5.2.9 Flags
The flags given in Table 5 are defined.
Table 5 – Flags
Byte Bit De finition
Reverse command included in response:
0 0 – value 0 = no reverse command included,
– value 1 = reverse command included
0 1…7 Reserved
1 0…7 Reserved
5.3 Pa dding a nd messa ge length
5.3.1 Padding
Padding is required for the following two reasons:

– create a message length which is a multiple of the block length of the encryption algorithm
as used;
– make poll and alarm messages look alike.
Padding is done using random or pseudo-random data. Random bytes a r e a p p e n d e d t o t h e
actual messages data until the total message length is one of those as speci fi ed i n t he nex t
clause.
5.3.2 Message length
The message lengths as used fulfil the requirements as mentioned in 5.3.1 (using a 16
or 32 byte block length), and are a compromise between obfuscation of alarm events and
bandwidth usage.
This results message lengths that are a multiple of 128 + 4 bytes for the connection handle:
– 132 bytes (4 bytes connection handle + 8 × 16 bytes);
– 260 bytes (4 bytes connection handle + 16 × 16 bytes);
– etc.
5.4 Hashing
The methods of message validation given in Table 6 are supported.
Table 6 – Ha shing IDs
Has h ID Description Has h size in bytes
0 SHA -256 32
1 RIPEMD-256 32
RCTs have to implement all methods. However, it is permissible to configure a RCT not to
accept all hash methods.
SPTs shall at least implement the default method, but can implement all methods.
The default method is 0 (SHA-256) until explicitly updated using the messages as defined
in 6.4.10 and 6.4.11.
The hashing method to be used is negotiated during session initialization, using the messages
as defined in 6.4.10 and 6.4.11.
The selectable hashing method allows for an upgrade of security in the future while
maintaining backwards compatibility.
The hash is included in the encrypted part of the message.
5.5 Encryption
5.5.1 General
Except for the connection handle, the entire message is encrypted. The encryption method t o
be used has been negotiated during commissioning. The methods given in Table 7 are
supported.
– 16 – IEC TS 60839-7-8:2019 © IEC 2019
Table 7 – Encryption IDs
Encr yption ID Description
Unencrypted
May only be used for debugging purposes or in test environments.
1 A ES-128
2 A ES-256
RCTs have to implement all methods. SPTs shall at least implement the default m e t h o d , b u t
can implement all methods. The default method is 2 (AES-256) until explicitly up d a t e d u s i n g
the messages as defined in 6.4.6 and 6.4.7.
The encryption key is valid only for one connection between an SP T a n d t h e R C T, e . g . t h e
RCT shall keep track of all different keys as used by the SPTs connected to it.
The operation mode to be used with AES is CBC (Cipher Block Chaining) as specified in NIST
Special Publication 800-38A (2001 edition). The IV (Initialization Vector) is all zeros.
The selectable encryption method allows for an upgrade of security in the future while
maintaining backwards compatibility.
The sole purpose of the non-encrypted mode is for implementation ease (the messaging layer
can be implemented without encryption in place, and only once this is ready one ca n a d d t h e
encryption).
5.5.2 Key exchange
The lifetime of a key is determined by the number of transmitted packets. To ensure secur i t y ,
key updates are triggered regularly by the RCT every n successfully transmitted packets
(using the RCT’s sequence counter as reference), with n being a value which is sent fro m t h e
RCT to the SPT during the initial commissioning phase.
To enforce security, a key exchange is to be triggered by the RCT at least once a w e e k o r a t
least every 2 = 65 536 successful packets (whichever comes first).
In addition to that regular pattern, both RCT and SPT can invoke additional key exchanges.
To avoid RCT and SPT getting out of synchronisation when an alarm message is triggered
exactly in between an on-going session key exchange action, the RCT shall mainta i n t h e o l d
session key until the first successful transmission of a packet wi t h t he new s es s i on k ey i s
acknowledged.
5.6 Time outs a nd re tries
The timeouts (after which a message will be retried) will increase with each retry as defined in
RFC 793.
In addition to RFC 793, the resulting time-out value is upper-bound by t h e report i ng t i m e of
the ATP plus/minus an evenly randomly distributed time offset of 10 %.
NOTE RFC 793 def ines a learning algorithm, which
...