The Distributed Authenticated Service Protocol (DASP)

The Distributed Authenticated Service Protocol (DASP) is an UDP protocol designed for the following purposes:

• Authenticated and optionally encrypted bidirectional exchange of data packets between two endpoints.
• Establishing a link between two matching peers even when the current locations are unknown by contacting a third party (a registry).
• Providing an optional simple fragmentation and reassembly mechanism for larger data packets as an alternative to standard UDP/IP fragmentation and reassembly.

DASP and its implementation RBridge use the following algorithms and methods:

• SHA-256 for authentication
• ChaCha20 or AES-256 CTR (Counter Mode) for encryption
• Optional true random key material for ChaCha20 and AES-256 CTR
• Replay attack prevention with time stamps

The DASP Protocol Header

All DASP packet types start with a generic 48 byte long header, this header definition is as follows (each [] representing one byte):

offset 0
[][][][][][][][] [][][][][][][][] [][][][][][][][] [][][][][][][][]
32 bytes SHA-256 authentication hash

offset 32
[][][][]
4 bytes reserved (currently all 0)

offset 36
[][][][]
4 bytes timestamp in network byte order

offset 40
[][][][]
4 bytes unsigned packet counter in network byte order

offset 44
[]
1 byte packet type

offset 45
[]
1 byte encryption indicator
0 = not encrypted
1 = encrypted

offset 46
[][]
2 bytes data length (network byte order)

offset 48
[] ..... []
data, zero-padded to 16 byte boundary (before encryption)

• The starting 32 bytes contain the SHA-256 authentication hash. This hash value is the result of hashing a shared secret together with the packet contents starting at offset 32 until the end of the packet including the 16 byte padding.
• The 4 bytes at offset 32 are reserved for future extensions of the Unix “epoch” time value and are defined to contain all zeroes for the time being.
• The 4 bytes at offset 36 contain the result of the time() function in network byte order.
• The 4 bytes at offset 40 contain a packet counter that each sender increments by one with each packet being sent to a peer or a registry.
• These 12 bytes above together (at offsets 32, 36 and 40, respectively) are being used as the the Nonce for AES-256 in CTR (counter) mode (leaving 4 bytes for the counter itself).
• For ChaCha20 encryption the 8 byte nonce starts at offset 36.
• The byte at offset 44 indicates the packet type (the valid range is 1 to 5). The higher order 4 bits are carrying the DASP version (which is 0).
• The byte at offset 45 (the encryption indicator) has the following settings 0 – the packet data area is not encrypted, 1 – the packet data area is encrypted (either with ChaCha20 or with AES-256 CTR) and a shared single key (optionally with true random key material where the counter at offset 40 is used as an index). The two bytes at offset 46 contain the data length without padding. The actual data starts at offset 48 and is padded with zeroes at the end on the sender side (before encryption).

DASP Packet Types

DASP distinguishes several packet types, these are the definitions:

Packet Type 1: PACKET_TYPE_DATA

This packet type transfers an Ethernet packet to a known DASP peer.

• The packet type (offset 44) is 1.
• The data length field (offset 46) contains the length of the original data (which is the length of the Ethernet packet).
• The data starts at offset 48, and may be optionally encrypted (in that case the encryption indicator (offset 45) has to be set to 1 on the sender side).
• 6 bytes at offset 48 contain the nodeid of the sender.
• The original Ethernet packet data starts at offset 54.

The data part looks as follows (each [] representing one byte of information):

offset 48
[][][][][][]
6 bytes sender nodeid

offset 54
[] ...
Ethernet packet data

The semantics on the receiver side are as follows:

• First, the authentication is being checked, the packet must be dropped if that fails.
• The receiver checks is the timestamp at offset 36 is in its accepted range, if not the packet is being dropped.
• Then – if the encryption indicator is 1 – the packet is being decrypted using the shared credentials.
• The receiver checks the validity of the sender nodeid and drops the packet if that fails.
• The forwarding table is being updated with the source MAC address of the original Ethernet packet.
• The Ethernet packet is injected into the local network.

Packet Type 2: PACKET_TYPE_KEEPALIVE

This packet type is sent to the peer DASP node at a configured interval. The packet type definitions are as follows:

• The packet type (offset 44) is 2.
• The data length field (offset 46) contains 12 being the data length.
• The data contains at offset 48 the own nodeid, and at offset 54 the peer nodeid (or 00:00:00:00:00:00 if currently unknown).

The data part looks as follows (each [] representing one byte of information):

offset 48
[][][][][][]
6 bytes own nodeid

offset 54
[][][][][][]
6 bytes peer nodeid
(00:00:00:00:00:00 if unknown)

The semantics on the receiver side are as follows:

• First authentication and the timestamp tolerance is being checked (the packed must be dropped if there’s a failure)
• Then – if the encryption indicator is 1 – the packet is being decrypted using the shared credentials.
• The nodeid of the sender is updated (as the current peer).
• The current UDP connection parameters are updated, if they have changed (packets will be sent to that new address and port from thereon).
• These semantics allow the change of the communication parameters during normal operation (including a change of the IP protocol, from IPv4 to IPv6 or backwards).

Packet Type 3: PACKET_TYPE_REGISTRY_REQUEST

If a DASP node does not know where its peer node is (and a DASP registry is known at the same time), it sends a Registry Request packet to using a separate set of authentication and encryption credentials. The link that both DASP peers want to establish is identified by a 32 byte long connection identifier (being a SHA-256 hash of suitable input shared by both DASP peers that need to find each other).

• The packet type (offset 44) is 4.
• The data length field (offset 46) contains 38 being the data length.
• The data contains at offset 48 the 32 byte connection identifier
• At offset 80 the own nodeid is sent

The data part looks as follows (each [] representing one byte of information):

offset 48
[][][][][][][][] [][][][][][][][] [][][][][][][][] [][][][][][][][]
32 bytes connection identifier

offset 80
[][][][][][]
6 bytes own nodeid

The semantics on the receiver side are as follows:

• First authentication and the timestamp tolerance is being checked (the packed must be dropped if there’s a failure)
• Then – if the encryption indicator is 1 – the packet is being decrypted using the shared credentials.
• If there’s currently no other known DASP node known to the registry, the request is stored together with the requesting nodeid, the connection identifier and its current communication parameters (IP address and port as seen from the registry).
• If a peer matches the same connection identifier, a separate Registry Reply (packet type 5) is sent to each DASP node with the same connection identifier.

Packet Type 4: PACKET_TYPE_REGISTRY_REPLY

• The packet type (offset 44) is 5.
• The data length field (offset 46) contains the data length.
• The data contains at offset 48 the 32 byte connection identifier
• At offset 80 the matching peer nodeid is reported back.
• At offset 86 the textual representation of the communication parameters of the matching peer followed by a final 0x00 byte (the communication parameters consist of the IP address in IPv6 format (mapped to ::ffff: for IPv4 addresses), a comma, and the port number in text format).

The data part looks as follows (each [] representing one byte of information):

offset 48
[][][][][][][][] [][][][][][][][] [][][][][][][][] [][][][][][][][]
32 bytes connection identifier

offset 80
[][][][][][]
6 bytes peer nodeid

offset 86
[] ... []
textual representation of peer communication parameters with a trailing 0x00 byte

Packet Type 5: PACKET_TYPE_LDATA

This packet type transfers the left part (or left fragment) of an Ethernet packet to a known DASP peer.

• 6 bytes at offset 48 contain the nodeid of the sender.
• The 2 bytes at offset 54 identify the Ethernet packet where this left part belongs to in an unspecified way.
• The data of the left part of an Ethernet packet starts at offset 56.

The data part looks as follows (each [] representing one byte of information):

offset 48
[][][][][][]
6 bytes sender nodeid

offset 54
[][]
Ethernet packet identifier

offset 56
[] ...
Ethernet packet data

The semantics on the receiver side are as follows:

• The left fragment part is stored and the receiver starts waiting for the associated right part.
• If there’s an associated right part already available, the complete packet is reassembled and further processed.
• The usual authentication and encryption rules apply.

Packet Type 6: PACKET_TYPE_RDATA

This packet type transfers the right part (or right fragment) of an Ethernet packet to a known DASP peer.

• 6 bytes at offset 48 contain the nodeid of the sender.
• The 2 bytes at offset 54 identify the Ethernet packet where this right part belongs to in an unspecified way.
• The data of the left part of an Ethernet packet starts at offset 56.

The data part looks as follows (each [] representing one byte of information):

offset 48
[][][][][][]
6 bytes sender nodeid

offset 54
[][]
Ethernet packet identifier

offset 56
[] ...
Ethernet packet data

The semantics on the receiver side are as follows:

• The right fragment part is stored and the receiver starts waiting for the associated left part.
• If there’s an associated left part already available, the complete packet is reassembled and further processed.
• The usual authentication and encryption rules apply.