securitytechnician.wiki
Reference About 6 min read

Discovery and multicast

Check the scope of discovery and multicast traffic. Verify the identity and advertised services of a device before using the returned addresses.

Sources and scopeChecked 29 September 2026

OPC UA discovery reference section only

Source check record

Architecture and standards defined assignments only; routed multicast, product discovery behaviour, response limits, and inventory identity require deployment specific environment validation.

Verification and testing

On this page

Overview#

Discovery answers what claims to be present. It doesn't answer whether the claimant is approved, authentic, correctly located, safe to query, or authorised for control. Bind discovery to commissioned identity and inventory before using any returned endpoint.

Discovery families#

Mechanism Scope and role Standards defined orientation Trust and operations boundary
DHCP / DHCPv6 Supplies address and configuration through client/server and relay paths RFC 2131 / RFC 8415 An offered address, gateway, DNS server, or option is configuration input; protect the server/relay path
DNS Resolves controlled names and service data RFC 1034 / RFC 1035 A record is not device authorisation; govern dynamic updates, split views, TTL, and DNSSEC policy where used
mDNS Link local multicast name resolution UDP 5353; IPv4 224.0.0.251; IPv6 FF02::FB MDNS Local advertisements are untrusted and can reveal device/service metadata
DNS SD Discovers service instances using DNS records RFC 6763; can use unicast DNS or mDNS TXT and instance data are display/capability hints, not a trusted schema or identity
WS Discovery Probe, resolve, hello, and bye for web services Ad hoc UDP 3702 to IPv4 239.255.255.250 or IPv6 FF02::C; managed mode can use a discovery proxy WSD SOAP/XML and endpoint references are untrusted; response storms and stale announcements require bounds
ONVIF discovery Uses WS Discovery to locate candidate ONVIF devices/services ONVIF Core plus WS Discovery Validate scopes, types, and XAddrs; then establish authenticated product/service identity
SSDP / UPnP discovery Search and advertisement for UPnP devices/services UDP 1900 and scoped multicast assignments in the UPnP Device Architecture LOCATION is an untrusted URL; UPnP presence does not establish physical security product trust
LLDP Adjacent link chassis, port, and capability information IEEE 802.1AB Switch neighbour evidence is valuable but is not cryptographic device identity by default
BACnet Who Is / I Am Discovers BACnet device instances and routes BACnet service over the configured data link; BACnet/IP often uses broadcasts Device instance/address advertisements are untrusted until bound to PICS, project inventory, and identity
KNXnet/IP search Locates KNXnet/IP endpoints KNXnet/IP project/profile assignments Device/project identity, supported service families, secure mode, and ETS record remain authoritative
OPC UA discovery Finds server applications and endpoint descriptions Local discovery/server mechanisms defined by OPC UA Discovery is deliberately separate from application certificate trust and user authorisation
Static inventory No active discovery; provisioned endpoint set Site configuration and asset records Prefer for stable high consequence paths, but continuously reconcile drift and replacement

See infrastructure discovery and addressing, multicast, discovery, and NAT, and ports, transports, and protection.

WS Discovery and ONVIF handling#

In WS Discovery ad hoc mode, probes go to a multicast group and matching targets reply directly. The standard also defines managed mode through a discovery proxy and multicast suppression behaviour. WSD

A safe consumer should:

  1. send only an owner approved, narrowly scoped probe on an intended interface/VLAN;
  2. randomize and rate limit according to the selected specification/profile;
  3. cap datagram, SOAP envelope, XML depth, response count, types, scopes, endpoint reference count, and address count;
  4. correlate message identifiers and ignore unrelated, replayed, or late responses under an explicit window;
  5. parse XAddrs as untrusted URIs and reject unexpected schemes, user info, fragments, link local zone confusion, and disallowed destinations;
  6. prevent redirect or address substitution from crossing the approved network/tenant boundary;
  7. fetch only the minimal read only service metadata required after a separate authorisation decision;
  8. bind the candidate to an approved serial/product/firmware record and authenticated certificate or commissioned secret;
  9. preserve the raw bounded advertisement or hash as evidence without treating it as authoritative state.

An ONVIF scope or device type is self asserted. Conformance requires the exact registered product and firmware/profile evidence described in ONVIF.

Multicast is delivery scope, not access control#

Concern Design question
Scope Is the group link local, administratively scoped, site scoped, or routed? Are IPv4 and IPv6 equivalent?
Membership Which switch ports and receivers may join? Is IGMP/MLD snooping and querier behaviour understood?
Routing Which multicast routing boundary, reflector, proxy, BBMD, or relay intentionally crosses subnets?
Source Is source specific multicast used or can any reachable sender inject?
Capacity What is the peak bitrate/packet rate, group count, receiver count, replication point, and storm limit?
Availability What happens on querier loss, switch reboot, topology change, duplicate sender, or stale membership?
Confidentiality Can an unauthorized device on an allowed segment join and observe? Is application layer media protection required?
Evidence Which group/source/interface actually carried the traffic, and how was loss/reordering measured by the owner?

Joining a video multicast doesn't authorise viewing. Network ACLs and multicast controls constrain reachability; authenticated keying/application authorisation protects the stream where the selected protocol supports it. See media streaming fundamentals and RTSP, RTP, RTCP, and SDP.

Broadcast and proxy boundaries#

BACnet/IP#

BACnet/IP discovery and services can depend on broadcasts. BBMDs and Foreign Device registration intentionally extend broadcast reach. Treat Broadcast Distribution Tables, Foreign Device Tables, network numbers, and routed scopes as security sensitive configuration; avoid circular replication and public exposure. BACNET IP

BACnet/SC changes the secure data link topology but doesn't authenticate an attached classic MS/TP segment or make every object write safe. See BACnet family.

Reflectors and relays#

mDNS reflectors, SSDP relays, WS Discovery proxies, DHCP relays, NAT traversal, and generic UDP forwarding enlarge the trust boundary. For each, record:

  • exact messages and scopes forwarded;
  • source address and hop/TTL behaviour;
  • loop and amplification prevention;
  • rate, response, and payload limits;
  • tenant/site separation;
  • identity binding after discovery;
  • audit, health, restart, and configuration change behaviour.

Don't deploy a generic reflector merely to make discovery “work everywhere.” Prefer controlled DNS/service registries, explicit inventory, or a protocol defined managed proxy when the operational model permits.

Inventory promotion model#

State Minimum evidence Permitted use
Observed candidate Interface, source address, discovery family, claimed type/name, first/last seen Display in a quarantined candidate queue only
Correlated candidate Expected switch port/site plus plausible product/serial/firmware data Owner review and constrained metadata retrieval
Authenticated candidate Validated certificate/application identity or commissioned cryptographic identity Capability interrogation within a read only policy
Approved asset Asset owner, location, product/firmware, profiles, trust material, management path, lifecycle state Explicitly authorised operational flows
Drifted/quarantined asset Identity/address/topology/firmware conflict or expired evidence No automatic overwrite or actuation; investigate

Keep asset ID, protocol identifier, hardware address, IP address, DNS name, certificate identity, product serial, and physical location as separate fields. Replacements legitimately change some fields; cloning/spoofing can duplicate others.

Defensive failure cases#

  • A single query elicits thousands of replies or fragments.
  • A response advertises a loopback, link local, multicast, private cross tenant, metadata service, or public URL.
  • The same logical identity appears from two ports/addresses.
  • A known address changes certificate or product identity.
  • Announcements flap during boot or network loss.
  • IPv6 discovery bypasses an IPv4 only policy.
  • Reflectors form a loop or amplify a service across sites.
  • Multicast succeeds while unicast return paths, MTU, or firewall state fail.
  • A discovery parser consumes unbounded XML, TXT data, URLs, or endpoint lists.
  • An integration automatically enrolls or commands every discovered device.

Safe acceptance checklist#

  • Discovery family, revision, scope, interface, address family, and owner recorded
  • Query and response size/rate/count bounded before parsing or allocation
  • Discovered text, XML, URLs, addresses, and capabilities treated as untrusted input
  • Candidate can't trigger credential use, configuration, subscription, or actuation automatically
  • Authenticated identity plus inventory/location evidence required for promotion
  • Routed multicast, proxy, reflector, BBMD, and NAT boundaries documented
  • IGMP/MLD/switch and IPv4/IPv6 behaviour included in the environment validation plan
  • Absence from discovery not treated as proof of decommissioning
  • Any environment validation has a written target allowlist, bounded query plan, and separate evidence record

Sources#

Section overview · Wiki home

View MarkdownSuggest an editBack to top ↑