Figure 20.1: Firewall pattern matching algorithm

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Logik- und Flussdiagramm (Algorithmus-Schema zur Regelauswertung).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Firewall (FC) innerhalb der Systemarchitektur (Security-Subsystem in Co-Existenz mit IAM und IdsM).
• Technischer Zweck: Spezifikation des sequenziellen First-Match-Verfahrens zur Inspektion und Filterung von Netzwerkpaketen (Network packet) auf Ethernet-, IP-, Transport- und Service-Ebene (z. B. SOME/IP) anhand einer geordneten Regeltabelle mit Fallback auf eine Default-Aktion.

2. Komponenten, Entitäten & Schnittstellen

• Dargestellte Entitäten & Datenstrukturen:
  • Network packet: Das zur Laufzeit am Ingress oder Egress eintreffende Datenpaket (L2/L3/L4/L7-Header und Payload).
  • Network packet pattern (#1, #2, #3, ...): Geordnete Liste von Filterkriterien (FirewallRule), modelliert im AUTOSAR-Metamodell (Machine Manifest). Enthält Felddefinitionen wie Source-/Destination-MAC/IP, VLAN-ID, Transportprotokoll (TCP/UDP), Portnummern oder Higher-Layer-Protokoll-IDs (z. B. SOME/IP Service-ID, Method-ID, Client-ID).
  • Firewall action: Assoziierte Operation bei positivem Musterabgleich (Pattern match). Typische Aktionen laut AP-Spezifikation:
    • ALLOW / FORWARD: Weiterleiten des Pakets.
    • DROP / BLOCK: Stummes Verwerfen.
    • REJECT: Verwerfen mit Fehlerantwort (z. B. ICMP Unreachable / TCP RST).
    • RATE_LIMIT: Begrenzung via Token-/Leaky-Bucket-Algorithmus.
    • SECURITY_EVENT: Auslösen eines Sicherheitsereignisses an den IdsM (Intrusion Detection System Manager).
  • Default Firewall action: Konfigurierbare Rückfall-Aktion bei vollständigem Ausbleiben eines Treffers (Pattern no-match).
• Beziehungen & Kardinalitäten:
  • Eingehendes Paket zu Regelsatz: 1 : N (Prüfung gegen N konfigurierte Patterns).
  • Pattern zu Firewall Action: 1 : 1 (Jedes Pattern referenziert exakt eine deterministische Primäraktion, ggf. kombiniert mit IDS-Reporting).
  • Regeltreffer zu Ausführung: 0..1 : 1 (Sobald ein Treffer auftritt, terminiert die Kette; trifft kein Pattern zu, greift genau die Default-Aktion).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: Eintreffen eines Frames/Pakets an der Firewall-Schnittstelle (Kernel-Netzwerkstack, Socket-Schicht, eBPF/XDP-Hook oder Hardware-Switch-Pipeline).
2. Parsing & Extraktion: Relevante Header- und Metadaten des Network packet werden extrahiert.
3. Sequenzielle Pattern-Evaluation (First-Match-Prinzip):
   • Das Paket wird beginnend bei Regel #1 sukzessive gegen die Pattern verglichen.
   • Zweig Pattern match (grüner Vektorpfeil): Stimmen alle Attribute des Patterns überein, wird die zugehörige Firewall action unmittelbar ausgelöst. Die Regelauswertung bricht für dieses Paket instantan ab (Short-Circuit-Evaluation).
   • Zweig Nicht-Übereinstimmung: Evaluation wechselt zur nächsthöheren Regelnummer (#2, #3, ...).
4. Zweig Pattern no-match (roter Vektorpfeil):
   • Schlagen alle N Pattern-Vergleiche fehl, wird zwingend die Default Firewall action ausgeführt.
5. Synchronizität & Nebenläufigkeit:
   • Paketbehandlung (Datapath): Streng synchron im Datapath (ALLOW/DROP), um Framing und Latenzen einzuhalten.
   • IDS-Meldungen: Asynchrones Absetzen von Security-Events via IdsM-Ports, um Denial-of-Service-Zustände im Filterkern bei hohem Paketaufkommen zu verhindern.

4. Normative Relevanz & Entwickler-Hinweise

• Konfiguration via ARXML: Regeln, Pattern-Tupel und Default-Aktionen werden über das MachineManifest bzw. die Systembeschreibung konfiguriert und zur Deploy-Zeit in die Zielplattform (z. B. Linux nftables, tc, POSIX-Firewall-Dämon oder Switch-TCAM) generiert.
• Regel-Reihenfolge & Shadowing: Da es sich um ein striktes Top-to-Bottom-Matching handelt, führen allgemein gehaltene Patterns in niedrigen Index-Positionen (#1, #2) zum Maskieren (Shadowing) spezifischerer, nachgelagerter Regeln (#3). Integratoren müssen Regelsätze formell auf Widerspruchsfreiheit und Priorisierung prüfen.
• Laufzeit-Performance im Embedded-Stack: Bei softwarebasiertem Matching skaliert die Latenz im Worst Case linear mit $\mathcal{O}(N)$ bis zur Default-Aktion. Zeitkritische, hochfrequente Kommunikationspfade (z. B. zyklische Ethernet-Sensorströme) müssen auf die obersten Regel-Indizes gemappt oder durch optimierte Datenstrukturen (z. B. Decision Trees, Hash-Tabellen oder Hardware-Offloading) verarbeitet werden.
• Security-Policy (Default Deny): Im Automobilumfeld erfordert UN R155 / ISO/SAE 21434 in der Regel DROP als Default Firewall action (Zero-Trust-Prinzip).
• Zustandsabhängigkeit (Firewall States): Adaptive Platform Firewalls unterstützen dynamische Zustände (z. B. Driving, Charging, Diagnostic/Flashing). Entwickler müssen beachten, dass ein State-Wechsel die aktive Regeltabelle austauscht oder adaptiert, wodurch sich Auswertungsreihenfolge und Default-Verhalten kontextabhängig ändern.

Die im System-Katalog verzeichneten Metadaten aus AUTOSAR_EXP_PlatformDesign (Kapitel 20 Firewall, S. 90/91) bestätigen die vorliegende Analyse vollinhaltlich:

• Spezifikatorische Verankerung: Figure 20.1 (Firewall pattern matching algorithm) definiert die operative Auswertungslogik für das in Figure 20.2 gezeigte Gesamtsystem des Functional Clusters FC Firewall.
• Zusammenspiel mit Nachbarkomponenten:
  • Die Parametrierung der Patterns (#1 bis #n) und Aktionen speist sich originär aus dem Machine Manifest zur Konfiguration der plattformspezifischen Firewall Engine.
  • Die Verzweigung bei Pattern match umfasst neben Paketfilterung (ALLOW/DROP) explizit das Triggern von Security Events (Raise SEvs) an den IdsM (Intrusion Detection System Manager).
  • Kontextuelle Anpassungen erfolgen dynamisch über den Firewall State (angesteuert u. a. durch OEM-Applikationen / State Management).

Zur Ergänzung der normativen Implementierungsbasis (AUTOSAR Adaptive Platform SWS Firewall):

• Zustandsumschaltung & API-Schnittstelle: Die zustandsabhängige Aktivierung der Regelsätze erfolgt über das C++-Interface ara::fw::FirewallStateSwitchInterface mittels:

  ara::core::Future<void> SwitchFirewallState(EnumT firewallState) noexcept; // [AP_SWS_Fw_82008]

• Fehlerbehandlung: Mögliche Fehlerzustände bei der Aktivierung zustandsabhängiger Regelsätze werden normativ über ara::fw::FwErrc typisiert ([AP_SWS_Fw_83001]):
  • FwErrc::kServiceNotAvailable
  • FwErrc::kInvalidStateDependentFirewall
• Zustandsraum: Die Definition der Firewall-Zustände (FirewallState) ist spezifiziert unter [AP_SWS_Fw_81001].

Die Katalogisierung der Figur ist konsistent über alle Ziel-Releases verifiziert:

• Figure ID: FIG-744532f540235970
• Vorkommen & Paginierung:
  • R22-11: AUTOSAR_EXP_PlatformDesign.pdf, Seite 90
  • R23-11: AUTOSAR_AP_EXP_PlatformDesign.pdf, Seite 91
  • R24-11: AUTOSAR_AP_EXP_PlatformDesign.pdf, Seite 93
  • R25-11: AUTOSAR_AP_EXP_PlatformDesign.pdf, Seite 96
• Status: Invariante Kernspezifikation ohne Release-Delta (is_delta: false).