zeek-plugin-bacnet
zeek-plugin-bacnet copied to clipboard
amzn
BVLC Layer 6 thru 8 messages should be implemented
In the bvlc_function layer atop UDP which your work identified and which zeek-plugin-bacnet has handled: switch(bvlc_function) { case 0x00: ##! BVLC_RESULT case 0x05: ##! REGISTER_FOREIGN_DEVICE case 0x01, ##! WRITE_BROADCAST_DISTRIBUTION_TABLE 0x02, ##! READ_BROADCAST_DISTRIBUTION_TABLE 0x03: ##! READ_BROADCAST_DISTRIBUTION_TABLE_ACK case 0x04, ##! FORWARDED_NPDU 0x09, ##! DISTRIBUTE_BROADCAST_TO_NETWORK 0x0a, ##! ORIGINAL_UNICAST_NPDU 0x0b: ##! ORIGINAL_BROADCAST_NPDU
You have a comment there in the consts.zeek: [5] = "Register Foreign Device", ##! 6-8 is not assigned for IPv4? [9] = "Distribute Broadcast To Network", but they are assigned, as follows:
BVLC Function: 1-octet X'06' Read-Foreign-Device-Table BVLC Length: 2-octets X'0004' Length, in octets, of the BVLL message
BVLC Function: 1-octet X'07' Read-Foreign-Device-Table-Ack BVLC Length: 2-octets L Length L, in octets, of the BVLL message List of FDT Entries: N*10-octets
BVLC Function: 1-octet X'08' Delete-Foreign-Device-Table-Entry BVLC Length: 2-octets X'000A' Length, in octets, of the BVLL message FDT Entry: 6-octets
The standard in 135-2016 edition, starting advocating a new and different methodology to achieve those functions, but most of the installed base are older. These designate themselves using a network-visible Protocol_Revision and if that is 16 or less, then they are still implementations which will use the older method.
@duffy-corelight, thank you for providing this insight! I'll start by updating the enumeration. Do you also know the data structure of messages 6-8? I found this on the BACNet website, so maybe we could use it as reference: http://www.bacnet.org/Tutorial/BACnetIP/sld016.html
The data structure of BVLC messages 6-8 is there above, in the three sections which each start with a BLVC Function: line. One addl clarification that might not be self-evident, where N as indicate, is the number of entries in the FDT whose contents are being returned. N can be calculated by (L-4)/10. Each returned entry consists of the 6-octet B/IP address (an IPv4 then a port as uint16_t) of the registrant; the 2-octet (as uint16_t) Time-to-Live value supplied at the time of registration; and a 2-octet (as uint16_t) value representing the number of seconds remaining before the BBMD will purge the registrant's FDT entry if no re-registration occurs. The time remaining includes the mandated 30-second grace period.
So many parts of BACnet are not represented in the present state of zeek-plugin-bacnet, that to productively prioritize and proceed, when we evaluate the options for "what next?" I hope we do so against a criterion selected with a larger perspective than just "what's missing?"
One crucible by which I would like us to prioritize, is to pursue things that would qualify to be captured in a probe.log. By that term, I mean things that indicate a networked exploration that would not be expected nor encountered during ordinary production traffic.
Over time, I'm sure we'll settle upon our preferred mechanism and arrangement of enhancement-priority discussions. I didn't want to be the one to start a proliferation of places that we need to look to follow the discussion, so for now, I am somewhat overloading this issue's comment history with a kitchen-sink of ideas, until we pick a different direction or mechanism.
RFDT.pcap.zip The reason for pkt#6 being different from pkt#8 is because after time-to-live expires, the BBMD holding the Foreign Device subscription auto-purges it from its table.