DASP/UDP (Protocol Version 0) #
EtherTunnel implements the Distributed Authenticated Service Protocol (DASP) over UDP. The assigned port number for DASP is 439.
The DASP Header #
Each DASP packet starts with a common 48 byte long header, this header definition is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 | |
+ +
| |
+ +
| |
+ +
| |
+ 32 bytes HMAC +
| |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | |
+ 8 bytes timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | 4 bytes packet counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | packet type |version|encrypt| 2 bytes data length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
48 | data, zero-padded to 16 byte boundary ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- The starting 32 bytes HMAC is the result of hashing a shared secret together with the packet contents starting at offset 32 until the end of the packet including a 16 byte zero padding.
- The 8 byte timestamp is 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.
- For encryption an 8 byte nonce starts at offset 36.
- The byte at offset 44 indicates the packet type (the valid range is 1 to 5).
- The byte at offset 45 contains the protocol version in the first 4 bits (0x0 for EtherTunnel) and indicates the encryption status in the least significant 4 bits (0x0 for unencrypted and 0x1 for encrypted).
- The two bytes at offset 46 contain the data length without padding.
- The actual data is packet type dependent, starts at offset 48 and is padded with zeroes to a 16 byte boundary before encryption (if present).
DASP Packet Types #
DASP distinguishes several packet types:
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 PACKET_TYPE_DATA data part looks as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
48 | sender NodeID | InterfaceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 | Ethernet frame data, zero-padded to 16 byte boundary ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 if required.
Packet Type 2: PACKET_TYPE_KEEPALIVE #
This packet type is sent to the peer 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 PACKET_TYPE_KEEPALIVE data part looks as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
48 | local NodeID bytes 0-3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
52 | local NodeID bytes 4-5 | peer NodeID bytes 0-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 | peer NodeID bytes 2-5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NodeID is defined as the factory default Ethernet address of the NIC (Network Interface Card) which is connected to the Ethernet LAN being bridged through the tunnel to the other side.
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 no established tunnel, a NodeID change of the sender is accepted.
- 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 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 tunnel that both peers want to establish is identified by a 32 byte long connection identifier (being a SHA256 hash of the tunnel name shared by both 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 local NodeID is sent
The PACKET_TYPE_REGISTRY_REQUEST data part looks as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
48 | |
+ +
| |
+ +
| |
+ +
| |
+ 32 bytes connection identifier +
| |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
80 | local NodeID bytes 0-3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
84 | local NodeID bytes 4-5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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 4) is sent to each 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 readable text format with a trailing 0).
The PACKET_TYPE_REGISTRY_REPLY data part looks as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
48 | |
+ +
| |
+ +
| |
+ +
| |
+ 32 bytes connection identifier +
| |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
80 | peer NodeID bytes 0-3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
84 | peer NodeID bytes 4-5 | peer parameters ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet Type 5: PACKET_TYPE_LDATA #
This packet type transfers the left part (or left fragment) of an Ethernet packet to a known peer.
- 6 bytes at offset 48 contain the NodeID of the sender.
- The 8 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 64.
The PACKET_TYPE_LDATA data part looks as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
48 | sender NodeID | InterfaceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 | Ethernet packet identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
64 | Ethernet fragment data, zero-padded to 16 byte boundary ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics on the receiver side are as follows:
- The left fragment part is stored and the receiver accepts an associated right part within a certain time range.
- If there’s an associated right part already available, the complete packet is reassembled and further processed.
Packet Type 6: PACKET_TYPE_RDATA #
This packet type transfers the right part (or right fragment) of an Ethernet packet to a known peer.
- 6 bytes at offset 48 contain the NodeID of the sender.
- The 8 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 64.
The PACKET_TYPE_RDATA data part looks as follows (identical to PACKET_TYPE_LDATA):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
48 | sender NodeID | InterfaceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 | Ethernet packet identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
64 | Ethernet fragment data, zero-padded to 16 byte boundary ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics on the receiver side are as follows:
- The right fragment part is stored and the receiver accepts an associated left part within a certain time range.
- If there’s an associated left part already available, the complete packet is reassembled and further processed.