You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered: