Figure 2.2: Encapsulating Security Payload (ESP) frame

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Protokoll-/PDU-Layout (Paket- und Kapselungsformat gemäß IETF RFC 4303 im AUTOSAR-Kontext).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_IPsecImplementationGuidelines). Spezifiziert die Kapselungsstrukturen sowie die kryptografischen Schutzgrenzen (Vertraulichkeit vs. Authentizität/Integrität) des Encapsulating Security Payload (ESP) Protokolls für die abgesicherte fahrzeuginterne und fahrzeugexterne IP-Kommunikation (z. B. SOME/IP, DoIP, HTTP/REST).
• Technischer Zweck: Gegenüberstellung der Frame-Struktur und der Wirkbereiche von Verschlüsselung und Signierung/Integritätsprüfung für:
  • Transport Mode: End-to-End-Absicherung zwischen zwei kommunizierenden Endknoten (Host-to-Host).
  • Tunnel Mode: Kapselung vollständiger IP-Pakete (Security Gateway / Host-to-Gateway / Gateway-to-Gateway).

2. Komponenten, Entitäten & Schnittstellen

• Strukturelemente (Felder & Layer-Segmente):
  • IP Header (blau):
    • Transport Mode: Originaler IPv4- (RFC 791) bzw. IPv6-Header (RFC 8200). Feld Protocol (IPv4) bzw. Next Header (IPv6) wird auf 50 (ESP) gesetzt.
    • Tunnel Mode: Neuer äußerer IP-Header (Outer Header), adressiert die Tunnelendpunkte (z. B. Telematics-Gateway).
  • ESP Header (gelb/orange): Enthält Security Parameters Index (SPI, 32 Bit) zur Zuordnung der Security Association (SA) sowie die Sequence Number (32 Bit, Replay-Schutz).
  • IP Header (dunkelgrün, nur Tunnel Mode): Ursprünglicher innerer IP-Header (Inner Header) mit den Original-Endpunkt-Adressen der Applikation.
  • IP Payload (hellgrün): Nutzdaten der Transportschicht (TCP-Segmente, UDP-Datagramme inkl. SOME/IP-Payloads, ICMP-Nachrichten).
  • ESP Trailer (gelb/orange): Beinhaltet Padding (Auffüllbytes zur Erfüllung von Cipher-Blockgrößen/4-Byte-Alignment), Pad Length (1 Byte) und Next Header (1 Byte, identifiziert das gekapselte Protokoll, z. B. 6 für TCP, 17 für UDP, 4 für IPv4-in-IPv4, 41 für IPv6-in-IPv4).
  • ESP Auth Trailer (rotbraun): Enthält den Integrity Check Value (ICV), d. h. den kryptografischen MAC (z. B. HMAC-SHA-256) oder das Authentication-Tag bei AEAD-Verfahren.
• Schutzbereich-Beziehungen (Kryptografische Grenzen):
  • Encrypted by ESP header (Vertraulichkeit):
    • Transport Mode: Erstreckt sich ab Beginn der IP payload über den gesamten ESP trailer.
    • Tunnel Mode: Erstreckt sich ab Beginn des inneren IP header (gesamtes inneres IP-Paket) über die IP payload bis zum Ende des ESP trailer.
  • Signed by ESP trailer (Integrität & Origin Authentication):
    • In beiden Modi identisch definiert: Erstreckt sich vom Beginn des ESP header über die verschlüsselte Payload bis zum Ende des ESP trailer.
    • Abgrenzung: Der äußere IP-Header bleibt unauthentifiziert (Unterschied zum Authentication Header / AH, RFC 4302). Der ESP Auth trailer (ICV) selbst ist nicht Teil der HMAC-Berechnung, sondern trägt das Ergebnis.

3. Dynamisches Verhalten & Sequenzablauf

• Tx-Pfad (Paketversand / Egress):
  1. Policy-Matching: Socket/Stack leitet Paket an IPsec-Subsystem; Security Policy Database (SPD) triggert Zuordnung zu einer Security Association (SA) in der Security Association Database (SAD).
  2. Kapselung:
     • Bei Tunnel Mode: Ursprüngliches Paket wird als inneres IP-Paket gekapselt.
     • Trailer-Generierung: Padding berechnen (Alignment gemäß Algorithmus, z. B. AES-CBC 128 Bit Blockgröße), Pad Length und Next Header setzen.
  3. Verschlüsselung: Symmetrische Verschlüsselung des Bereichs (IP Payload + ESP Trailer bzw. innerer IP Header + IP Payload + ESP Trailer).
  4. Header-Generierung: ESP-Header voranstellen (SPI aus SA, Sequence Number inkrementieren).
  5. Integritätssicherung: ICV über ESP Header bis ESP Trailer berechnen und als ESP Auth Trailer anhängen (entfällt als separater Schritt bei integrierten AEAD-Ciphers wie AES-GCM).
  6. IP-Framing: Äußerer IP-Header voranstellen; Übergabe an Ethernet-Treiber / Network Interface.
• Rx-Pfad (Paketempfang / Ingress):
  1. Erkennung Protocol/Next Header == 50 im äußeren IP-Header.
  2. SA-Lookup in SAD anhand Ziel-IP und SPI aus dem ESP-Header.
  3. Anti-Replay-Prüfung über Sequence Number gegen das konfigurierte Sliding-Window.
  4. Verifikation des ICV (ESP Auth Trailer) über den signierten Bereich. Bei Mismatch: Verwerfen des Pakets, Fehlereintrag / Security-Event.
  5. Entschlüsselung des Chiffrats.
  6. Padding-Entfernung, Auswertung des Next Header-Felds aus dem ESP-Trailer und Übergabe an L4-Protokollstack (Transport Mode) bzw. Re-Routing des inneren IP-Pakets (Tunnel Mode).

4. Normative Relevanz & Entwickler-Hinweise

• MTU-Budgetierung & Fragmentierungsvermeidung:
  • ESP erzeugt dynamischen Frame-Overhead: ESP Header (8 Byte) + IV (typ. 8–16 Byte) + Padding (0–255 Byte) + Trailer (2 Byte) + ICV (typ. 12–16 Byte).
  • Im Tunnel Mode addieren sich zusätzlich 20 Byte (IPv4) bzw. 40 Byte (IPv6) für den äußeren IP-Header.
  • Konsequenz: Maximal nutzbare TCP-MSS bzw. maximale UDP-Payload-Größe (z. B. SOME/IP TP PDU-Limits) muss zwingend reduziert konfiguriert werden, um IP-Fragmentierung im Automotive-Ethernet (typ. MTU 1500 Byte) zu verhindern.
• Architekturauswahl Transport vs. Tunnel Mode:
  • Transport Mode: Zu wählen für direkte ECU-zu-ECU-Verbindungen (Host-to-Host) auf der Adaptive Platform zur Minimierung von Latenz und 20/40 Byte Header-Overhead.
  • Tunnel Mode: Verbindlich bei Gateway-Knoten, die Subnetze (z. B. Domänen-Controller zu Telematik-Einheit) absichern oder fahrzeugexterne VPN-Tunnel terminieren.
• Hardware-Offloading & Performance:
  • AES-GCM (AEAD) wird in AUTOSAR AP bevorzugt, da Encryption und Authentication in einem Durchlauf erfolgen.
  • Embedded-Entwickler müssen sicherstellen, dass der POSIX-Kernel (Linux/QNX) Crypto-Engines (z. B. per XFRM-Offload auf SoC/Crypto-Beschleunigern wie NXP HSE, TI HSM) nutzt, da Software-ESP den CPU-Budgetrahmen bei hohem SOME/IP-Durchsatz überschreitet.
• Transparenz für Applikationen:
  • Der IPsec-Betrieb erfolgt für Applikationsentwickler (ara::com, POSIX-Sockets) vollständig transparent auf Netzwerkstack-Ebene; Security-Richtlinien werden deklarativ in der Maschinen-/Netzwerkkonfiguration hinterlegt.