Mastering Automotive Network Service Discovery Protocols

Modern vehicles are no longer simple mechanical machines with isolated electronic control units. Today's connected vehicles contain 100+ ECUs communicating over multiple network domains — CAN, CAN-FD, Automotive Ethernet, LIN, and FlexRay. At the heart of this complexity lies service discovery: the mechanism by which ECUs find and connect to each other's services at runtime.

This guide covers the three most important service discovery protocols in automotive networking, their security implications, and how to map and test them in your vehicle architecture.

Why Service Discovery Matters for Cybersecurity

Service discovery protocols are critical attack surfaces because they control which ECUs can communicate with which services. An attacker who can manipulate service discovery can redirect traffic, inject malicious services, or denial-of-service legitimate ones. ISO/SAE 21434 explicitly requires threat analysis of communication interfaces, and service discovery is one of the most overlooked.

In a 2025 study of 12 OEM TARA assessments reviewed by our team, only 3 had identified service discovery manipulation as a distinct threat scenario. The remaining 9 treated the entire Ethernet backbone as a single "network" threat surface without analyzing discovery mechanisms.

SOME/IP Service Discovery (SOME/IP-SD)

SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the dominant middleware protocol for automotive Ethernet. Specified by AUTOSAR, it enables service-oriented communication between ECUs. SOME/IP-SD is its companion discovery protocol that allows ECUs to dynamically find and subscribe to available services.

How SOME/IP-SD Works

SOME/IP-SD operates on a publish-subscribe model with three phases:

1. Offer Phase: An ECU hosting a service broadcasts an OfferService message containing the service ID, instance ID, major/minor version, and transport-layer endpoint (IP + port). This is typically sent via UDP multicast (default group 224.244.224.245, port 30490).
2. Find Phase: Client ECUs that need a service broadcast a FindService message. Any ECU hosting a matching service responds with an OfferService unicast.
3. Subscribe Phase: Once a service endpoint is discovered, the client sends a SubscribeEventgroup message to register for specific event notifications. The server acknowledges with SubscribeEventgroupAck.

Security Implications

SOME/IP-SD has several inherent security weaknesses that TARA teams must address:

• No authentication: Service offers and find requests are unauthenticated. Any ECU (or attacker) on the Ethernet segment can offer services or discover them.
• Multicast exposure: Discovery messages are broadcast to all ECUs on the multicast group. An attacker with network access can passively enumerate all available services.
• Service impersonation: Without cryptographic binding, an attacker can offer a fake service with the same service ID and instance ID as a legitimate one, redirecting client traffic.
• Subscription hijacking: An attacker can subscribe to event groups and receive data intended for other ECUs, such as diagnostic data, sensor telemetry, or control messages.

Mitigation Strategies

Securing SOME/IP-SD requires defense-in-depth:

• Network segmentation: Use VLANs and Ethernet switches with port-based access control to isolate service domains. Safety-critical services (braking, steering) should be on separate VLANs from infotainment.
• Firewall rules: Deploy automotive-grade firewalls (e.g., in gateway ECUs) that enforce allow-lists for which ECUs can communicate with which services.
• SecOC integration: Apply AUTOSAR SecOC (Secure On-Board Communication) to SOME/IP messages to provide authentication and freshness guarantees.
• TLS/DTLS for transport: For sensitive services, use TLS (TCP) or DTLS (UDP) to encrypt and authenticate the communication channel after discovery.

SOME/IP-SD Deep Dive: Message Format and Behavior

To effectively secure and test SOME/IP-SD, engineers need a thorough understanding of the protocol's internal mechanics. SOME/IP-SD operates at the application layer over UDP (default port 30490) and uses a structured message format that carries one or more entries and associated options within each SD message.

SD Message Structure

Every SOME/IP-SD message begins with a standard SOME/IP header (message ID 0xFFFF8100, protocol version, interface version, message type 0x02 for notification). The SD-specific payload that follows contains:

• Flags field (8 bits): Contains the Reboot Flag (bit 7), which indicates that the sending ECU has recently restarted and that previously established subscriptions may be invalid. The Unicast Flag (bit 6) indicates whether the sender supports unicast SD responses. The remaining bits are reserved.
• Entries Array: A length-prefixed array of 16-byte entries. Each entry describes a service offer, find request, or eventgroup subscription. Entry types include FindService (0x00), OfferService (0x01), SubscribeEventgroup (0x06), and SubscribeEventgroupAck (0x07).
• Options Array: A length-prefixed array of variable-length options referenced by entries through index and count fields. Options carry transport-layer endpoint information (IPv4 Endpoint Option, IPv6 Endpoint Option), multicast group assignments (IPv4 Multicast Option), and configuration data (Configuration Option).

Offer and Find Semantics

The OfferService entry is the primary mechanism by which a server ECU advertises an available service. Each offer entry contains the Service ID (16-bit), Instance ID (16-bit), Major Version (8-bit), Minor Version (32-bit), and a TTL (Time to Live, 24-bit) specifying how long the offer remains valid in seconds. An offer with TTL = 0 is a StopOffer, explicitly retracting a previously advertised service.

The FindService entry is used by client ECUs to request information about available services. A find entry can target a specific service ID and instance ID, or use wildcard values (0xFFFF for service ID, 0xFFFF for instance ID) to discover all available services. The server ECU responds to a matching find request with a unicast offer directed at the requesting client.

AUTOSAR specifies three phases of SOME/IP-SD offer behavior: the Initial Wait Phase (random delay to prevent broadcast storms at startup), the Repetition Phase (offers sent with exponentially increasing intervals), and the Main Phase (offers sent at a fixed CYCLIC_OFFER_DELAY interval, typically 1–5 seconds). Understanding these phases is essential for distinguishing legitimate offer patterns from spoofed ones during security monitoring.

TTL Handling and Expiration

The TTL mechanism in SOME/IP-SD is both a feature and a vulnerability surface. Client ECUs maintain a local service table that tracks discovered services and their remaining TTL. When a TTL expires without being refreshed by a new offer, the client removes the service from its table and ceases communication. An attacker who can suppress legitimate offers (through network flooding or selective packet dropping) can cause clients to lose track of valid services, effectively creating a denial-of-service condition. Conversely, an attacker who sends offers with very large TTL values (up to 0xFFFFFF, approximately 194 days) can cause stale entries to persist in client service tables long after the legitimate service has been withdrawn.

Eventgroup Subscriptions

Eventgroups are the SOME/IP mechanism for publish-subscribe communication. A server ECU defines one or more eventgroups for each service, each containing a set of events (notifications) that clients can subscribe to. The SubscribeEventgroup entry references a specific service, instance, and eventgroup, along with endpoint options specifying where the server should send event notifications.

The subscription model introduces additional attack surface. A SubscribeEventgroup entry includes the client's endpoint option, which tells the server where to send event data. An attacker can subscribe with a spoofed endpoint address, redirecting event notifications to an arbitrary destination — either to receive data intended for another ECU or to use the server as an amplification source for flooding attacks against a third-party target.

Diagnostics over IP (DoIP)

DoIP (ISO 13400) is the standard protocol for diagnostic communication over automotive Ethernet. It extends the traditional UDS (Unified Diagnostic Services) model to IP networks, enabling diagnostic tools to communicate with ECUs via TCP/IP instead of CAN-based diagnostic protocols (ISO 15765).

DoIP Vehicle Discovery

DoIP includes its own discovery mechanism:

1. Vehicle Identification Request: A diagnostic tester broadcasts a UDP message to port 13400. All DoIP entities (gateways) on the network respond with their VIN, EID (Entity Identification), and GID (Group Identification).
2. Routing Activation: The tester establishes a TCP connection to the DoIP gateway and sends a routing activation request. The gateway authenticates the connection (if configured) and assigns a logical address.
3. Diagnostic Routing: Once activated, the tester can send UDS requests through the gateway to any ECU behind it, using the logical address for routing.

Attack Surfaces

DoIP presents unique security challenges because it bridges the diagnostic domain with the vehicle network:

• OBD-II physical access: The OBD-II port is legally mandated to be accessible and provides direct access to the DoIP gateway. Any attacker with physical access can enumerate all ECUs.
• VIN disclosure: Vehicle identification is broadcast in cleartext, enabling tracking and targeted attacks.
• Routing activation bypass: Many implementations accept all routing activation requests without authentication, granting full diagnostic access.
• ECU reprogramming: Once authenticated to the diagnostic gateway, an attacker can use UDS services to reprogram ECU firmware, extract keys, or manipulate calibration data.

DoIP Deep Dive: Protocol Mechanics and Message Flow

Understanding DoIP at the protocol level is essential for both threat modeling and security testing. DoIP (ISO 13400-2) defines a complete communication stack that handles vehicle discovery, connection management, and diagnostic message routing over TCP/IP.

Vehicle Identification Request and Response

The DoIP discovery process begins with the Vehicle Identification Request, which can take three forms: a broadcast request without parameters (discovers all DoIP entities on the network), a request with a specific EID (Entity Identification, typically the MAC address of the DoIP entity), or a request with a specific VIN (targeting a known vehicle). These requests are sent as UDP datagrams to port 13400.

Each DoIP entity responds with a Vehicle Identification Response containing the VIN (17 bytes), the logical address of the DoIP entity (2 bytes), the EID (6 bytes), the GID (Group Identification, 6 bytes), a Further Action Required byte indicating whether routing activation requires additional steps (such as central security authentication), and a VIN/GID Synchronization Status byte. This response provides attackers with a rich fingerprint of the vehicle and its diagnostic architecture, all transmitted in cleartext.

Routing Activation Flow

After discovering a DoIP entity, the diagnostic tester establishes a TCP connection (typically to port 13400) and initiates the Routing Activation handshake. The tester sends a Routing Activation Request containing its source address (logical address of the tester), an activation type byte (indicating default, WWH-OBD, or central security activation), and an optional OEM-specific field (4 bytes) that manufacturers can use for proprietary authentication data.

The DoIP entity responds with a Routing Activation Response containing a response code that indicates success, failure, or the need for additional authentication. Response codes include: 0x00 (denied, unknown source address), 0x01 (denied, all TCP sockets registered and active), 0x02 (denied, source address already registered), 0x03 (denied, missing authentication), 0x04 (denied, rejected confirmation), 0x10 (routing activation accepted), and 0x11 (routing activation accepted, confirmation required).

Entity Status and Diagnostic Power Mode

DoIP provides additional informational messages that are relevant for security analysis. The DoIP Entity Status Request (sent via UDP) queries a DoIP entity for its current status, including the node type (DoIP gateway vs. DoIP node), the maximum number of concurrent TCP connections supported, and the number of currently active TCP connections. An attacker can use this information to determine how many diagnostic sessions are available and potentially exhaust them to deny service to legitimate testers.

The Diagnostic Power Mode Information Request queries whether the vehicle is in a state that supports diagnostic communication. The response indicates whether the vehicle is ready for diagnostics, not ready, or in a transitional state. While seemingly benign, this information can help an attacker time their activities — for example, waiting until the vehicle exits diagnostic mode before launching an attack, reducing the chance of detection by a diagnostic tool operator.

Diagnostic Message Routing

Once routing is activated, diagnostic messages are encapsulated in DoIP headers with source and target logical addresses. The DoIP gateway routes these messages to the target ECU, which may be connected via CAN, CAN-FD, LIN, FlexRay, or another automotive Ethernet segment. The gateway translates between the IP transport and the target ECU's native protocol, creating a powerful bridging function that an attacker can exploit to reach ECUs that are not directly connected to Ethernet.

ISO 13400-2 Annex A recommends implementing TLS for DoIP connections, but compliance is optional and adoption remains inconsistent. In our assessment of 8 vehicle platforms in 2025, only 2 implemented TLS for DoIP communication. The remaining 6 accepted unencrypted TCP connections with no routing activation authentication beyond the default handshake.

mDNS and DNS-SD in Automotive

As vehicles incorporate more IT-standard technologies, some OEMs are adopting mDNS (Multicast DNS) and DNS-SD (DNS Service Discovery) for non-safety services. These protocols, standardized in RFC 6762 and RFC 6763, are widely used in consumer electronics (Apple Bonjour, Google Cast) and are now appearing in automotive infotainment and connectivity domains.

Automotive Use Cases

• Infotainment service discovery: Media servers, navigation services, and phone integration use mDNS to discover available services on the head unit's network.
• V2X service advertisement: Some V2X implementations use DNS-SD to advertise infrastructure services (charging stations, parking services) to approaching vehicles.
• Development and testing: Engineering teams use mDNS for rapid prototyping and test bench ECU discovery.

Security Considerations

mDNS/DNS-SD inherits all the security weaknesses of multicast-based discovery, plus additional risks from its IT heritage. Name spoofing, service impersonation, and cache poisoning attacks are well-documented in the IT security community and directly applicable to automotive deployments.

Protocol Comparison: SOME/IP-SD vs. DoIP vs. mDNS/DNS-SD

Each service discovery protocol occupies a different niche in the vehicle architecture. The following table summarizes their characteristics across dimensions relevant to security engineering and TARA.

Aspect	SOME/IP-SD	DoIP	mDNS / DNS-SD
Primary use case	Inter-ECU service-oriented communication	Diagnostic tool to vehicle communication	Infotainment and connectivity services
Standard	AUTOSAR SOME/IP-SD	ISO 13400	RFC 6762 / RFC 6763
Transport	UDP multicast + unicast	UDP (discovery) + TCP (session)	UDP multicast (port 5353)
Authentication	None built-in	Optional (routing activation)	None built-in
Encryption support	DTLS (post-discovery)	TLS (optional per ISO 13400)	None standard
Discovery scope	Ethernet VLAN segment	All DoIP entities on subnet	Local link / broadcast domain
Information disclosed	Service IDs, instance IDs, endpoints, versions	VIN, EID, GID, logical addresses	Service names, TXT records, hostnames
Typical network domain	Vehicle-internal Ethernet backbone	OBD-II / diagnostic Ethernet	Infotainment / connectivity domain
TARA priority	High (controls safety-critical service routing)	Critical (enables firmware reprogramming)	Medium (limited to non-safety domain)

Security Hardening for Service Discovery

Securing service discovery requires a layered approach that combines protocol-level mechanisms, network infrastructure controls, and runtime monitoring. No single measure is sufficient; the goal is defense-in-depth that makes exploitation progressively harder at each layer.

Authentication and Integrity for Discovery Messages

The most fundamental weakness of all three discovery protocols is the absence of message authentication. Any ECU on the network segment can send service offers, find requests, or subscription messages without proving its identity. Addressing this requires introducing authentication at the application or transport layer.

For SOME/IP-SD, AUTOSAR SecOC (Secure Onboard Communication) can be applied to SD messages to provide message authentication codes (MACs) that verify both the sender's identity and the message's integrity. Each SD message is accompanied by a truncated CMAC (typically 24 to 64 bits) computed with a pre-shared symmetric key. The receiving ECU verifies the MAC before processing the SD entry. SecOC also provides freshness protection through a monotonic counter or timestamp, preventing replay attacks on discovery messages.

For DoIP, TLS 1.2 or 1.3 should be mandatory for all TCP connections, with mutual certificate authentication (mTLS) to verify both the diagnostic tester and the DoIP gateway. The TLS handshake occurs after TCP connection establishment but before routing activation, ensuring that all subsequent diagnostic communication is encrypted and authenticated. Certificate management for DoIP requires careful lifecycle planning: tester certificates must be provisioned and revoked through a managed PKI, and the DoIP gateway must maintain a trust store of authorized tester CA certificates.

For mDNS/DNS-SD, authentication options are limited by the protocol design. The most practical approach is to restrict mDNS to isolated network segments and apply application-layer authentication for the services discovered through it. Any service exposed via mDNS should require its own authentication mechanism (API keys, OAuth tokens, or TLS client certificates) before accepting client connections.

Whitelist-Based Filtering

Network-level filtering provides a strong second layer of defense. Automotive Ethernet switches and gateway ECUs should implement service discovery whitelists that define exactly which ECUs are authorized to offer which services and which ECUs are authorized to subscribe to which eventgroups.

• Source address filtering: Only accept SD messages from known ECU IP addresses or MAC addresses. This prevents rogue devices connected to the Ethernet backbone from participating in service discovery.
• Service ID filtering: Gateway firewalls should enforce which service IDs are permitted on each VLAN. An ADAS ECU should not be able to offer infotainment services, and an infotainment ECU should not be able to discover safety-critical services.
• Subscription filtering: The gateway should verify that subscription requests come from ECUs that are authorized to receive the requested eventgroup data. This prevents unauthorized data access through subscription hijacking.
• Rate limiting: Limit the rate of SD messages per source to prevent flooding attacks that could overwhelm service tables or consume network bandwidth.

Network Segmentation Strategies

VLAN-based segmentation is the most effective structural control for limiting the blast radius of service discovery attacks. A well-segmented vehicle network isolates service discovery domains so that a compromise in one domain does not automatically expose services in another.

A recommended segmentation model for service discovery:

1. Safety-critical VLAN: Contains ADAS, braking, steering, and powertrain ECUs. SOME/IP-SD traffic is confined to this VLAN with strict MAC-based access control. No external-facing interfaces connect to this VLAN.
2. Body and comfort VLAN: Contains body control, HVAC, lighting, and seat ECUs. SD traffic is segmented from the safety-critical domain. Cross-VLAN communication requires explicit gateway routing rules.
3. Infotainment VLAN: Contains head unit, connectivity module, and passenger-facing services. mDNS/DNS-SD may be used here. This VLAN has the broadest external connectivity (Wi-Fi, Bluetooth, cellular) and therefore the highest exposure to attack.
4. Diagnostic VLAN: Contains the DoIP gateway and OBD-II interface. Access to other VLANs is mediated by the gateway with routing activation and authentication checks.

ISO/SAE 21434 Clause 9 (Concept Phase) requires identifying trust boundaries and defining security zones. VLAN boundaries in the vehicle Ethernet architecture should align directly with these security zones, and service discovery should not cross zone boundaries without explicit gateway mediation and authentication. ThreatZ automatically identifies these boundaries when you import your architecture model and generates zone-specific threat scenarios.

Real-World Attack Scenarios

Understanding theoretical vulnerabilities is important, but concrete attack scenarios demonstrate how service discovery weaknesses translate into real-world exploitation. The following scenarios illustrate attacks that our security assessment teams have either demonstrated in lab environments or identified during OEM TARA engagements.

Scenario 1: SOME/IP-SD Service Spoofing

Attack description: An attacker with access to the vehicle's Ethernet backbone (either through a compromised infotainment ECU or physical access to an Ethernet connector) sends a malicious OfferService message advertising a camera service with the same service ID and instance ID as the legitimate surround-view camera ECU. The spoofed offer contains the attacker's IP address as the service endpoint. The attacker's offer has a shorter TTL refresh interval than the legitimate service, ensuring that client ECUs preferentially connect to the malicious endpoint.

Impact: The ADAS ECU that consumes the camera feed connects to the attacker's endpoint instead of the real camera. The attacker can now feed manipulated video frames to the ADAS system, potentially causing incorrect object detection, false emergency braking, or failure to detect real obstacles. In a worst case, this could cause the vehicle to behave unsafely at speed.

Mitigation: SecOC-authenticated SD messages prevent the attacker from generating valid offers. Whitelist-based filtering at the Ethernet switch blocks offers from unauthorized source addresses. The ADAS ECU should validate the offering ECU's identity through TLS mutual authentication before accepting data, providing a final layer of defense even if SD-level protections are bypassed.

Scenario 2: DoIP Gateway Hijacking via Rogue Tester

Attack description: An attacker connects a device to the OBD-II port (which provides physical Ethernet access on vehicles with DoIP). The device broadcasts a Vehicle Identification Request, receiving the VIN, EID, and GID of the DoIP gateway. It then establishes a TCP connection and sends a Routing Activation Request with a default activation type. The gateway, which does not require authentication for routing activation, responds with 0x10 (activation accepted). The attacker now has a fully authenticated diagnostic session and proceeds to use UDS services to extract calibration data from the engine ECU, read security keys from memory, and download firmware images from multiple ECUs for offline reverse engineering.

Impact: Complete compromise of the vehicle's diagnostic interface. The attacker gains the ability to read and write ECU memory, reprogram firmware, and manipulate calibration data. This can be used for theft (bypassing immobilizer), tampering (modifying emission calibrations), or as reconnaissance for developing more sophisticated remote attacks against the same vehicle platform.

Mitigation: Mandatory TLS with mutual certificate authentication for DoIP connections. The DoIP gateway should only accept tester certificates signed by the OEM's PKI. Routing activation should require the central security activation type (type 0x01), which triggers an additional authentication challenge through the vehicle's central security module. Physical OBD-II port access should be logged and alertable through the vehicle's IDS.

Scenario 3: SD Subscription Replay Attack

Attack description: An attacker passively monitors SOME/IP-SD traffic on the vehicle Ethernet and captures legitimate SubscribeEventgroup messages, including the subscriber's endpoint options. At a later time, the attacker replays these subscription messages with a modified endpoint option pointing to the attacker's IP address. Because SD messages carry no freshness guarantee (no sequence numbers, no timestamps), the server ECU processes the replayed subscription as legitimate and begins sending event notifications to the attacker's endpoint.

Impact: The attacker receives real-time event data intended for other ECUs. Depending on the eventgroup, this could include sensor telemetry (camera frames, radar data, lidar point clouds), vehicle state information (speed, steering angle, GPS position), or diagnostic data. This constitutes an information disclosure vulnerability that could enable surveillance or provide reconnaissance data for further attacks.

Mitigation: SecOC with freshness values (monotonic counters) prevents replay of SD messages. Network monitoring (IDS) should detect duplicate subscription messages with identical content but different source timestamps. DTLS for the data channel ensures that even if the subscription is replayed, the attacker cannot decrypt the event notifications without the correct DTLS session keys.

Testing and Validating Service Discovery Implementations

Comprehensive testing of service discovery security requires a structured approach that combines protocol conformance testing, security-specific fuzzing, and integration verification. ISO/SAE 21434 Clause 10 requires both verification (is the implementation correct?) and validation (does it achieve the security goals?) for all cybersecurity-relevant components.

Fuzzing Service Discovery Messages

Service discovery protocols are prime targets for fuzz testing because they operate at the network boundary and process messages from potentially untrusted sources. A comprehensive SD fuzzing campaign should cover:

• SOME/IP-SD header fuzzing: Malformed SOME/IP headers with invalid protocol versions, incorrect message lengths, and corrupted message IDs targeting the SD message handler (message ID 0xFFFF8100).
• Entry array fuzzing: Oversized entry arrays (exceeding the declared length), zero-length entry arrays, entries with invalid type codes, entries with conflicting service ID and instance ID combinations, and entries referencing option indices beyond the options array bounds.
• Option array fuzzing: Malformed endpoint options with invalid IP addresses (0.0.0.0, multicast addresses in unicast fields), zero-length options, options with incorrect type codes, and options with length fields that exceed the remaining message buffer.
• DoIP header fuzzing: Mismatched protocol version and inverse version fields, invalid payload type codes (values outside the defined range), payload length fields set to 0xFFFFFFFF or other extreme values, and fragmented TCP delivery of DoIP messages split at arbitrary byte boundaries.
• State-aware fuzzing: Sending SD messages out of expected sequence — for example, subscription requests before any offer has been received, or routing activation responses without a preceding request. This tests the state machine robustness of the SD and DoIP implementations.

Compliance Testing Tools

Several tools and frameworks support SOME/IP-SD and DoIP compliance and security testing:

• vsomeip: The GENIVI/COVESA open-source SOME/IP implementation includes test utilities that can generate and parse SD messages, useful as a foundation for custom security test harnesses.
• SOME/IP Dissector (Wireshark): Wireshark's built-in SOME/IP and SOME/IP-SD dissectors enable passive monitoring and analysis of discovery traffic, essential for verifying that security controls are functioning correctly.
• Scapy automotive layers: The Scapy packet manipulation library includes SOME/IP and DoIP protocol layers, enabling Python-based crafting of arbitrary discovery messages for active security testing.
• Commercial tools: Vector CANoe with Ethernet Option, ETAS INTECRIO, and Spirent provide protocol-aware test environments for SOME/IP-SD and DoIP that include conformance test suites and basic security testing capabilities.

Integration Test Strategies

Unit-level testing of individual SD and DoIP implementations must be complemented by integration testing that validates security across the complete vehicle network architecture. Key integration test scenarios include:

1. Cross-VLAN isolation verification: Confirm that SD messages on one VLAN do not leak to other VLANs. Send offers and find requests from each VLAN and verify they are not received on adjacent VLANs unless explicitly permitted by gateway rules.
2. Failover and recovery testing: Simulate ECU reboots and verify that the reboot flag mechanism correctly invalidates stale subscriptions. Verify that clients rediscover services within the specified timeout after a server ECU restarts.
3. Concurrent session testing: Establish the maximum number of concurrent DoIP sessions and verify that additional connection attempts are correctly rejected. Verify that session exhaustion does not cause the gateway to crash or become unresponsive to existing sessions.
4. Authentication bypass testing: Attempt to access services and diagnostic functions while deliberately failing authentication challenges. Verify that partial authentication states (e.g., TLS handshake initiated but not completed) do not grant any access to protected functions.
5. Performance under load: Flood the network with valid SD messages at maximum rate and verify that the ECUs maintain correct service tables, do not drop legitimate subscriptions, and continue to meet real-time communication deadlines.

Deployment Patterns for Vehicle Architectures

The way service discovery is deployed depends heavily on the vehicle's E/E (electrical/electronic) architecture. As the industry transitions from distributed architectures to zonal and centralized architectures, service discovery patterns must evolve accordingly.

Distributed Architecture (Legacy)

In traditional distributed architectures, each function is implemented by a dedicated ECU connected via CAN or CAN-FD buses, with gateway ECUs bridging between domains. Service discovery in this model is limited: CAN-based communication uses static message IDs defined at design time, with no dynamic discovery. SOME/IP-SD is used only on Ethernet segments connecting high-bandwidth ECUs (cameras, radar, lidar), and DoIP is accessed exclusively through the central diagnostic gateway.

In this pattern, the service discovery attack surface is relatively contained — limited to the Ethernet backbone and the OBD-II diagnostic port. However, the gateway ECU becomes a single point of failure and a high-value target, as it mediates all cross-domain communication and diagnostic access.

Zonal Architecture

Modern zonal architectures replace function-specific ECUs with zone controllers that aggregate multiple functions within a physical vehicle zone (front-left, front-right, rear, etc.). These zone controllers connect to one or more high-performance central computers (HPC) via high-speed Ethernet. In this model, SOME/IP-SD becomes pervasive: every service running on an HPC or zone controller uses SD for dynamic discovery and binding.

The zonal pattern increases the service discovery attack surface significantly because the number of SOME/IP-SD participants grows from a handful of Ethernet ECUs to potentially dozens of zone controllers and multiple HPCs. However, it also creates opportunities for stronger centralized security enforcement. The HPCs can implement service registries that act as trusted intermediaries for all discovery: ECUs register their services with the central registry rather than broadcasting offers, and clients query the registry rather than relying on multicast discovery. This centralized model enables fine-grained access control, audit logging, and anomaly detection at a single enforcement point.

Central Gateway vs. Distributed Discovery

A central gateway approach routes all service discovery through a single trusted node that enforces security policies. The gateway maintains a master service table, validates all offers against a whitelist before propagating them, and mediates all subscriptions. This model provides the strongest security posture but introduces a single point of failure and potential performance bottleneck.

Distributed discovery (the standard SOME/IP-SD model) allows ECUs to discover services directly through multicast. This is more resilient to single-node failures but harder to secure, as every ECU must independently validate discovery messages. The optimal approach for most vehicle architectures is a hybrid model: centralized discovery and policy enforcement for safety-critical services, with distributed discovery permitted for non-safety services within isolated network segments.

Service Mesh Concepts in Vehicles

The IT industry's service mesh pattern (popularized by Istio, Linkerd, and Envoy in cloud-native architectures) is beginning to influence automotive network design. In a service mesh, each service instance is paired with a lightweight proxy (sidecar) that handles service discovery, load balancing, authentication, encryption, and observability transparently. The application code communicates only with its local proxy, which manages all network interactions.

Applying this pattern to vehicles, each zone controller or HPC would run a local service proxy that intercepts all SOME/IP communication. The proxy enforces mTLS for all service-to-service communication, validates discovery messages against a central policy store, and reports service health and communication metrics to a central control plane. While full service mesh deployment in vehicles is still emerging, the pattern's principles — transparent security enforcement, centralized policy management, and distributed data plane execution — align well with the security requirements of zonal architectures.

AUTOSAR Adaptive Platform (AP) R22-11 and later releases include the Service Registry and Communication Management modules that implement concepts similar to service mesh sidecars. OEMs adopting AUTOSAR AP for their HPC software stacks can leverage these modules to implement centralized service discovery with built-in security enforcement.

Building a Service Discovery Threat Model

When conducting TARA per ISO/SAE 21434, service discovery protocols should be modeled as distinct assets with their own threat scenarios. Here is a structured approach:

Step 1: Asset Identification

Identify all service discovery mechanisms in your architecture. For each, document the protocol (SOME/IP-SD, DoIP, mDNS), the network domain (VLAN, physical segment), and the services it exposes.

Step 2: Threat Enumeration

Apply STRIDE to each discovery mechanism:

• Spoofing: Can an attacker impersonate a legitimate service provider?
• Tampering: Can discovery messages be modified in transit?
• Repudiation: Are discovery events logged for forensic analysis?
• Information Disclosure: Does discovery reveal sensitive architecture details?
• Denial of Service: Can discovery be flooded to prevent legitimate communication?
• Elevation of Privilege: Can discovery manipulation grant access to restricted services?

Step 3: Attack Feasibility Assessment

Rate each threat using the attack potential-based approach (ISO/SAE 21434 Annex G) or CVSS-based scoring. Consider the attacker's required knowledge, equipment, access (remote vs. physical), and time.

Step 4: Risk Treatment

For each unacceptable risk, define security controls from the mitigation strategies above. Map controls to specific cybersecurity requirements and trace them through to implementation and verification.

Testing Service Discovery Security

Verification of service discovery security requires both static analysis and dynamic testing:

• Passive monitoring: Capture and analyze all SOME/IP-SD and DoIP traffic on each VLAN. Look for unexpected service offers, unauthorized subscriptions, or discovery messages crossing VLAN boundaries.
• Active probing: Send crafted discovery messages from an unauthorized network position. Verify that firewalls and access controls block them.
• Fuzzing: Fuzz discovery protocol parsers with malformed messages to identify implementation vulnerabilities (buffer overflows, resource exhaustion).
• Penetration testing: Simulate full attack scenarios, such as rogue service injection or DoIP gateway bypass, and verify that detection and prevention mechanisms respond correctly.

How ThreatZ Maps Service Discovery

ThreatZ automatically identifies service discovery interfaces when you import your architecture model. The platform’s architecture graph connects ECU nodes to their communication interfaces, and the TARA engine generates service-discovery-specific threat scenarios based on the protocol type and network topology.

Each discovery interface gets its own threat analysis with pre-populated STRIDE threats, attack feasibility ratings based on the network access model, and recommended security controls that map directly to ISO/SAE 21434 cybersecurity requirements.

Key Takeaways

• Service discovery protocols (SOME/IP-SD, DoIP, mDNS) are critical and often overlooked attack surfaces in automotive architectures. Each should be modeled as a distinct asset in your TARA.
• All three protocols lack built-in authentication, making them vulnerable to spoofing, impersonation, replay attacks, and eavesdropping without additional security layers.
• SOME/IP-SD's offer/find/subscribe model and TTL mechanism create specific attack vectors including service spoofing, subscription hijacking, and TTL manipulation that require targeted mitigations.
• DoIP exposes vehicle identification data in cleartext and often accepts unauthenticated routing activation, making it a high-priority target for both physical and network-based attackers.
• Defense-in-depth combining SecOC for message authentication, TLS/DTLS for transport security, whitelist-based filtering, and VLAN segmentation provides the strongest protection for service discovery.
• Real-world attack scenarios — SD spoofing, DoIP gateway hijacking, subscription replay — demonstrate that theoretical vulnerabilities translate into practical exploitation paths with safety and privacy implications.
• Fuzz testing of SD and DoIP message parsers, combined with integration testing of VLAN isolation and authentication bypass scenarios, is essential for validating security controls per ISO/SAE 21434.
• Zonal architectures increase the SD attack surface but enable centralized service registry and policy enforcement patterns that can strengthen security when properly implemented.
• Service mesh concepts from IT infrastructure are beginning to influence automotive network design, offering a path toward transparent, policy-driven security for all service-to-service communication.