weird things at Network Layer

[duffy-ocraven]

The loop construct in network_layer_message processing, for any observed amount of network_number content, is the proper way to capture what is in the actual packet. After provisioning for the 1-octet in Reject-Message-To-Network X'03' where 1-octet reason precedes network_number, odd-length in the remainder of the packet for many of the network_layer_message_types must indicate a malformed 1-octet network number.

There are some odd exceptions, however, as I-Could-Be-Router-To-Network message X'02' where after network number, there is a 1-octet "Performance Index". Establish-Connection-To-Network message X'08' where after network number, there is a 1-octet "Termination Time Value" in seconds. Network-Number-Is X'13' where after network number, there is a 1-octet flag, where a value of 1 indicates that the network number was "configured", and a value of 0 "learned".

Except for those, an odd-length in the remainder of the packet after the network_layer_message_type octet, is a malformed 1-octet final network number in the network_layer_message_types == X'00', X'01', X'04', X'05', plus X'09' and X'12'. And in the above odd exceptions conversely, even-length in the remainder of the packet after the network_layer_message_type octet, that too must indicate a malformed 1-octet network number, because the one odd 1-octet field is required.

In addition to a 1-octet network number being malformed, violations of the network_number content can occur due to presence/absence/count-limit violations. These should be noted:

if (network_layer_message_type == 0x00), the content can be zero or one network number (both situations are stipulated in the standard) and yet is still properly well-formed. if (network_layer_message_type == 0x01), the content can be one or more than one network number (both situations are stipulated in the standard) and yet is still properly well-formed. if (network_layer_message_type == 0x02) or the (network_layer_message_type == 0x03) or the (network_layer_message_type == 0x08) or the (network_layer_message_type == 0x09) or the (network_layer_message_type == 0x12) or the (network_layer_message_type == 0x13), the content is required to be exactly one network number to be properly well-formed. if (network_layer_message_type == 0x04) or the (network_layer_message_type == 0x05), the content can be any count (zero or more) network numbers (situations are stipulated in the standard) and yet is still properly well-formed.

Also Devices shall ignore Network-Number-Is and What-Is-Network-Number messages that contain any SNET/SADR or DNET/DADR information in the NPCI. Also Devices shall ignore Network-Number-Is that are sent with any unicast address. Protocol decoders are advised to highlight if these encodings are observed.

https://www.researchgate.net/profile/Steffen_Wendzel/publication/261550187_Towards_Suppressing_Attacks_on_and_Improving_Resilience_of_Building_Automation_Systems_-_an_Approach_Exemplified_Using_BACnet/links/00463534929aeb1ce1000000/Towards-Suppressing-Attacks-on-and-Improving-Resilience-of-Building-Automation-Systems-an-Approach-Exemplified-Using-BACnet.pdf?origin=publication_detail also has in its section 5 entitled Traffic Normalization for BACnet, a litany of things that it says it will drop or normalize, which if observed in network traffic are definitely weird.