Figure 7.1: Pattern matching mechanism

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Entscheidungs- und Regelauswertungsmodell (First-Match-Prinzipschema).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Firewall (AUTOSAR_AP_SWS_Firewall, Kap. 7).
• Technischer Zweck: Spezifikation des deterministischen Filter- und Evaluierungsmechanismus für Netzwerkpakete (L2/L3/L4 sowie Payload-Header) zur Durchsetzung von Kommunikationsrichtlinien, Netzwerksegmentierung und Security-Policies im POSIX-/IP-Stack des Adaptive Core.

2. Komponenten, Entitäten & Schnittstellen

• Network packet: Eingehendes oder ausgehendes Netzwerkdatum (Ethernet-Frame, IPv4/IPv6-Paket, TCP/UDP-Datagramm), das der Filter-Engine zugeführt wird.
• Network packet pattern (#1, #2, #3, ...): Geordnete Menge von Filterregeln (Rule Set). Jedes Pattern kapselt Matching-Kriterien (z. B. Quell-/Ziel-IP, Subnetz, Port-Ranges, Transportprotokoll, Schnittstelle, Richtung und ggf. Stateful-Attribute). Die Indexierung (#n) definiert die strikte Priorität.
• Firewall action: Diskrete Folgeoperation, die bei Regelübereinstimmung ausgeführt wird (z. B. PASS/ACCEPT, DROP, REJECT, optionales Logging / Security-Event-Trigger via ara::ids). Jedes Pattern besitzt eine 1:1-Assoziation zu einer Aktion.
• Default Firewall action: Fallback-Aktion des Regelsatzes, die bei vollständigem Ausbleiben eines Regel-Matches angewendet wird (1:1-Zuordnung pro Regeltabelle/Interface).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: Empfang eines Netzwerkpakets am Stack (Ingress) oder Bereitstellung zur Transition über das Netzwerk (Egress).
2. Sequenzielle Evaluierung (First-Match-Verfahren):
   • Das Paket wird mit der am höchsten priorisierten Regel (#1) verglichen.
   • Match-Pfad (Pattern match): Führt der Vergleich zu einem Treffer, wird unmittelbar die zugehörige Firewall action ausgeführt. Die Auswertung terminiert sofort (Short-Circuit-Evaluation); nachfolgende Regeln (#2, #3, ...) werden ignoriert.
   • No-Match-Pfad: Schlägt der Vergleich fehl, wird das Paket an die nachfolgende Regel (#2) weitergereicht. Dieser Zyklus wiederholt sich bis zur letzten konfigurierten Regel (#n).
3. Fallback-Terminierung (Pattern no-match):
   • Ergibt keine der Regeln #1 bis #n einen Treffer, wird zwingend die Default Firewall action ausgeführt.

4. Normative Relevanz & Entwickler-Hinweise

• Regel-Shadowing (Konfigurationsrisiko): Da die Regelauswertung beim ersten Match terminiert, führt eine vorangestellte generische Regel (z. B. weites Subnetz) zur Unwirksamkeit (Shadowing) nachgelagerter, spezifischerer Regeln. Regelketten im Execution Manifest müssen strikt von spezifisch zu generisch modelliert werden.
• Performance & Latenz-Optimierung:
  • Die Worst-Case-Laufzeit ist linear O(n) bezogen auf die Regellänge.
  • Hochfrequenter, latenzkritischer Datenverkehr (z. B. zyklische SOME/IP-Events oder PTP/gPTP-Frames) muss auf den vordersten Positionen (#1, #2) abgebildet werden, um CPU-Overhead und Jitter im Packet-Processing-Pfad zu minimieren.
• Default-Deny-Prinzip: Die Default Firewall action ist normativ und sicherheitskritisch standardmäßig auf DROP bzw. REJECT zu konfigurieren (Whitelisting-Architektur / Zero Trust).
• Security-Telemetrie: Verwerfende Aktionen (DROP im Match- oder Default-Pfad) sollten über die standardisierten Security-Schnittstellen (IdsM / ara::ids) meldbare Security Events (SEv) erzeugen, um Denial-of-Service- oder Spoofing-Muster im Fahrzeugnetz frühzeitig zu detektieren.