Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Network Layer Message Types X'12': What-Is-Network-Number and X'13': Network-Number-Is #18

Open
duffy-ocraven opened this issue Sep 10, 2020 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@duffy-ocraven
Copy link

duffy-ocraven commented Sep 10, 2020

Clause 6.2.4 Network Layer Message Types X'12' and X'13' are seeing adoption. What seeing them should tell a protocol parser to do, is a subject worthy of its own ticket.

X'12': What-Is-Network-Number
X'13': Network-Number-Is

These two message types were invented during a transient period of BACnet history. In 2011, the original 1995 approach to cryptographic obfuscation of on-the-wire traffic which no one implemented, was "discarded" (in terms beyond even the typical BACnet renunciation of past mistakes, which are merely termed: "deprecated"), and a second transient period of BACnet history tried to specify another different cryptographic approach to obfuscation of on-the-wire traffic, which again no one implemented, and which too was then in 2019 "discarded".

But the two message types which had been invented during that transient 2011-2019 period were actually mandated in some devices, so a resigned capitulation to adding them as needless work became the path of least resistance. Every device which implements them is mandated to local broadcast emit one or the other on startup. Typically no one answers, and typically nodes do nothing with the payloads even if they do execute one or both messages. Sometimes an answer is indistinguishable from the mandated initial unilateral broadcast which occurs contemporaneously. They aren't important, as long as they appear in traffic only in this vestigial situation.

But they are either the most information-laden or very-close-to the most information-laden messages which a nefarious outsider could exploit. If they ever appear outside of the mandated initial unilateral broadcast, they are probably notice-worthy.

@NothinRandom NothinRandom self-assigned this Sep 10, 2020
@NothinRandom NothinRandom added the enhancement New feature or request label Sep 10, 2020
@duffy-ocraven
Copy link
Author

I will upload for you a .pcap of these later today.

@duffy-ocraven
Copy link
Author

@duffy-ocraven
Copy link
Author

Network-Number-Is message is indicated by a Message Type of X'13' followed by a 2-octet network number (most significant octet first), followed by a 1-octet flag, where a value of 1 indicates that the network number was "configured", and a value of 0 "learned" indicates that the network number was learned by receipt of a previous Network-Number-Is message.

It shall be transmitted with a local broadcast address. It shall never be routed. Devices shall ignore Network-Number-Is messages that contain SNET/SADR or DNET/DADR information in the NPCI or that are sent with any unicast address. Protocol decoders are advised to highlight if these encodings are observed.

@duffy-ocraven
Copy link
Author

What-Is-Network-Number message is indicated by a Message Type of X’12'. This message may be transmitted with a local broadcast or a local unicast address. This message shall never be routed. Devices shall ignore What-Is-Network-Number messages that contain SNET/SADR or DNET/DADR information in the NPCI. Protocol decoders are advised to highlight if these encodings are observed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants