CoAP protocol for the Internet of Things - traffic study

June

2021

CoAP protocol for the Internet of Things - traffic study

безопасность

18 June 2021 11:35

Using WireShark, we were able to capture two packets of the new CoAP network protocol.

Contrained Application Protocol (RFC 7252 standard) is designed for the Internet of Things and operates on the basis of UDP. This simple protocol allows machines to communicate with each other (M2M - machine to machine).

The first packet is a device request to server 188.34.167.226:
Frame 13: 103 bytes on wire (824 bits), 103 bytes captured (824 bits) on interface 0
Ethernet II, Src: Keenetic_0f:40:ef (50:ff:20:0f:40:ef), Dst: router.lan (c4:ad:34:45:6a:fb)
Internet Protocol Version 4, Src: 192.168.0.73 (192.168.0.73), Dst: static.226.167.34.188.clients.your-server.de (188.34.167.226)
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 89
Identification: 0xfaca (64202)
Flags: 0x4000, Don't fragment
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x1ad3 [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.0.73 (192.168.0.73)
Destination: static.226.167.34.188.clients.your-server.de (188.34.167.226)
User Datagram Protocol, Src Port: 56911 (56911), Dst Port: coap (5683)
Source Port: 56911 (56911)
Destination Port: coap (5683)
Length: 69
Checksum: 0x8392 [unverified]
[Checksum Status: Unverified]
[Stream index: 1]
Constrained Application Protocol, Confirmable, POST, MID:41783
01.. .... = Version: 1
..00 .... = Type: Confirmable (0)
.... 1000 = Token Length: 8
Code: POST (2)
Message ID: 41783
Token: 398d7e264ddd9768
Opt Name: #1: Uri-Path: a
Opt Name: #2: Uri-Query: cid=4cef9cfe-af0c-11e8-8f23-df6cd39224ef
Opt Name: #3: Uri-Query: r=ru
[Response In: 59]
[Uri-Path: /a]

The second packet is the server response

Frame 59: 75 bytes on wire (600 bits), 75 bytes captured (600 bits) on interface 0
Ethernet II, Src: router.lan (c4:ad:34:45:6a:fb), Dst: Keenetic_0f:40:ef (50:ff:20:0f:40:ef)
Internet Protocol Version 4, Src: static.226.167.34.188.clients.your-server.de (188.34.167.226), Dst: 192.168.0.73 (192.168.0.73)
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x40 (DSCP: CS2, ECN: Not-ECT)
Total Length: 61
Identification: 0xa920 (43296)
Flags: 0x4000, Don't fragment
Time to live: 52
Protocol: UDP (17)
Header checksum: 0x7859 [validation disabled]
[Header checksum status: Unverified]
Source: static.226.167.34.188.clients.your-server.de (188.34.167.226)
Destination: 192.168.0.73 (192.168.0.73)
User Datagram Protocol, Src Port: coap (5683), Dst Port: 56911 (56911)
Source Port: coap (5683)
Destination Port: 56911 (56911)
Length: 41
Checksum: 0x38a3 [unverified]
[Checksum Status: Unverified]
[Stream index: 1]
Constrained Application Protocol, Acknowledgement, 2.04 Changed, MID:41783
01.. .... = Version: 1
..10 .... = Type: Acknowledgement (2)
.... 1000 = Token Length: 8
Code: 2.04 Changed (68)
Message ID: 41783
Token: 398d7e264ddd9768
End of options marker: 255
[Request In: 13]
[Response Time: 0.049948917 seconds]
[Uri-Path: /a]
Payload: Payload Content-Format: application/octet-stream (no Content-Format), Length: 2
Data (20 bytes)
Data: 3138382e3133342e38362e3232363a3536393131
[Length: 20]

CoAP packet analysis:
Destination port -5683, protocol UDP.
The first one passes a pointer (Uri-Query: cid=) in the second the value is returned (Data).
Server static.226.167.34.188.clients.your-server.de(188.34.167.226)
Request Packet Length 89 byte, the response consists of 41 byte.

As you can see, in this case the response contains a string in the form of a set of hexadecimal numbers without spaces:
31 38 38 2e 31 33 34 2e 38 36 2e 32 32 36 3a 35 36 39 31 31
(This digital data may contain, for example, control commands for the end device or, conversely, telemetry for the server - bit fields about on/off device buttons, information about temperature, voltage, toner level, number of printed pages).

What is the Internet of Things protocol CoAP

The CoAP protocol is a simplified HTTP protocol running over UDP.
Unlike the HTTP protocol, which is strictly text-based, CoAP can also transmit binary data in the request and response.

Since UDP does not guarantee delivery, reception control is implemented.

In order to save transmission channel resources, the CoAP protocol very often uses "Piggy-backed" answer. (In logistics in the field of cargo transportation, this term "piggyback" means passing cargo delivery). Here, along with the receipt, the result of processing the request is immediately sent.

ДляWhen transmitting text in requests and responses, UTF-8 encoding is used. If a string is used as a request or payload, its length does not exceed 270 bytes. What is done for low-power devices (with a small amount of RAM). But some tags may be repeated several times to convey all the necessary information.

Security: The response must match the request ("Request/Response Matching").
In a piggy-backed response, the response token must match the request token.

Request:
request

Answer:
response

I note that the time between request and response is short - only 50 milliseconds.

Description of the request and response fields

Options are divided into two groups: “critical” and “optional”. The difference is how unrecognized parameters are processed by the endpoint:

optional parameters, if their value is not recognized by the endpoint, MUST be silently ignored.
unrecognized parameters of the "critical" class in a correctly composed request MUST cause a "Bad Option" error. This response must include a human-readable error message.
all unrecognized "critical" messages in the response MUST be rejected with a restart message
optional parameters in the server response not recognized by the client MUST be silently ignored.

Critical and optional messages should be distinguished from “mandatory” messages. No option in CoAP is mandatory. All these rules are designed to handle unrecognized (or unrealized) requests and responses.

No.	Critical	Name	Format	Length, bytes	Description
1	YES	Content-Type	uint	0-2	Message format type 0 - text/plain; charset=utf-8 40 - application/link-format 41 - application/xml 42 - application/octet-stream 47 - application/exi 50 = application/json
2	no	Max-Age	uint	0-4	60 seconds by default - maximum response time in seconds from 0 to 2^32-1
3	YES	Proxy-Uri	string	1-270	The request is to the proxy, not to the server. Contains a URI for a request to a proxy; Proxy-Uri can be thought of as a request to a cache.
4	no	ETag	hidden	1-8	Additional "shortcut" for security verification. The response will only be returned if the Etag check by the server is successful. If the verification is successful, the server is obliged to send a response.
5	YES	Uri-Host	string	1-270	Internet host - a server serving requests.
6		Location-Path	string	1-270	Similar to Uri-Path, but can be specified multiple times in a request
7	YES	Uri-Port	uint	0-2	Internet port on the server
8		Location-Query	string	1-270	Similar to Uri-Query, but can be specified multiple times in a query
9	YES	Uri-Path	string	1-270	Internet - absolute path on the server to the resource
11	YES	Token	hidden	1-8	Security token (Token in response and request must match)
12	no	Accept	uint	0-2	For data types accepted by the client, see Content-Type
13	YES	If-Match	hidden	0-8	Prerequisites. The response will only be received if the condition is met (together with the ETag tag) - used for concurrent requests to update data from several clients to avoid data overwriting
15	YES	Uri-Query	string	1-270	The name of the destination resource on the destination server. Can contain any characters except "." And "..". Encoding of (Russian) letters using % is not used. Only UTF-8 characters are implied.
21	YES	If-None-Match	no	0	Reverse If-Match condition. The response will only come if the condition not completed. See If-Match - the operating logic is reversed.

Conclusions:

Studying Internet of Things packets using WireShark reveals only the external part of the protocol (you can find out the IP address of the server, the requested URI resource and the response - data in encoded or otherwise unreadable form for humans).
Although the request and data were decoded, it is impossible to understand the internal logic of the application: to find out what the device is intended for, and who is the owner of the domain where the data was sent.
The packets I intercepted are very short - approximately 40-89 bytes long. Packets come in groups: request-response.
The time period between transmissions (packets and groups) in the CoAP standard can be quite significant - from several minutes to many months and even years.

Protecting CoAP with DTLS

If increased security is needed and protection of content from being read and modified during transmission, CoAP can be used together DTLS- implementation of TLS over UDP. When using DTLS, connections and protocols are protected, as well as the data itself.

Sources:

Blog about Radio and Linux