Figure 2.1: Authentication Header (AH) frame

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Netzwerk-Protokoll- / Frame-Format-Layout (PDU-/Paket-Struktur-Diagramm) gemäß RFC 4302 (IPsec Authentication Header).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP) und Classic Platform (CP) IPsec-Netzwerk-Sicherheitsebene (dokumentiert in AUTOSAR_AP_EXP_IPsecImplementationGuidelines).
• Technischer Zweck: Spezifikation der Integritäts- und Authentifizierungsabdeckung auf Vermittlungsschichtebene (OSI-Layer 3) für die beiden standardisierten IPsec-Modi:
  • Transport Mode: Absicherung der Host-to-Host-Endpunktkommunikation bei Erhalt der ursprünglichen IP-Adressierung.
  • Tunnel Mode: Kapselung kompletter IP-Pakete zur Gateway-to-Gateway- oder Host-to-Gateway-Absicherung (Security Gateway / VLAN-Übergänge).

2. Komponenten, Entitäten & Schnittstellen

• Dargestellte Protokollelemente & PDU-Segmente:
  • IP header (Blau, äußerer Header): Standard-IPv4- oder IPv6-Header; führt im Feld Next Header (IPv6) bzw. Protocol (IPv4) den Protokollwert 51 (AH).
  • Authentication Header (Gelb/Orange): RFC 4302 Datenstruktur bestehend aus:
    • Next Header (8 Bit)
    • Payload Len (8 Bit)
    • Reserved (16 Bit)
    • Security Parameters Index (SPI) (32 Bit)
    • Sequence Number (32 Bit, Replay-Schutz)
    • Integrity Check Value (ICV) (variables MAC-Feld, typisch 96 oder 128 Bit via HMAC-SHA256/AES-GMAC).
  • IP header (Grün, nur Tunnel Mode): Gekapselter Original-IP-Header des inneren Zielnetzwerks / Ziel-Steuergeräts.
  • IP payload (Grün): Transport-Layer-PDU (TCP-Segment, UDP-Datagramm z. B. SOME/IP, DoIP oder ICMP-Nachricht).
• Strukturelle Beziehungen & Integritätsbereich (Signed by Authentication Header):
  • Transport Mode: Der AH wird zwischen dem bestehenden IP-Header und die IP-Payload geschoben. Der Signaturbereich umfasst den modifizierten IP-Header (unter Ausschluss mutierbarer Felder), den AH selbst (mit genulltem ICV bei der Berechnung) sowie die vollständige IP-Payload.
  • Tunnel Mode: Das gesamte originale IP-Paket (IP packet, bestehend aus innerem IP-Header und IP-Payload) wird unverändert als Nutzlast hinter den AH gelegt. Der Signaturbereich erstreckt sich über den äußeren IP-Header (ohne mutierbare Felder), den AH und das vollständige innere IP-Paket.
  • Kryptografische Eigenschaft: Authentizität und Datenintegrität ohne Vertraulichkeit (Payload liegt im Klartext vor; Abgrenzung zu ESP / RFC 4303).

3. Dynamisches Verhalten & Sequenzablauf

• TX-Pfad (Paketversand / Egress):
  1. SPD-Lookup (Security Policy Database): Treffer der Traffic-Selektoren (IP-Adressen, Ports, Protokoll) erfordert IPsec-AH.
  2. SAD-Lookup (Security Association Database): Zuordnung von Schlüsselmaterial, Hash-/MAC-Algorithmus, aktuellem SPI und monoton steigender Sequenznummer.
  3. Header-Generierung:
     • Transport Mode: Einfügen des AH-Headers vor die L4-Payload; IP-Header-Protokoll auf 51 setzen.
     • Tunnel Mode: Kapselung des Originalpakets in ein neues IP-Paket mit äußerem IP-Header und AH.
  4. Zeroing mutierbarer IP-Felder: Vor der MAC-Generierung werden mutable IPv4-Felder (ToS/DSCP/ECN, Flags, Fragment Offset, TTL, Header Checksum) bzw. mutable IPv6-Felder (Traffic Class, Flow Label, Hop Limit) im zu signierenden Bereich temporär genullt.
  5. ICV-Kalkulation: Berechnung des MAC über den gesamten rot markierten Bereich und Schreiben des Werts in das ICV-Feld des AH.
  6. Übergabe an L2: Weiterleitung der PDU an den Ethernet-Controller/Treiber (EthIf / Linux-Netzwerk-Subsystem via XFRM).
• RX-Pfad (Paketempfang / Ingress):
  1. Parser-Trigger: Erkennung von IP-Protokoll 51.
  2. SPI- & Replay-Validierung: Auffinden der SA anhand von SPI und Ziel-IP; Prüfung der Sequenznummer gegen das Sliding Replay Window.
  3. Verifikation: Re-Kalkulation des ICV über den definierten Signaturbereich (unter identischer Nullung mutierbarer Header-Felder).
  4. Abbruch-/Fehlerpfad: Mismatch führt zum sofortigen Verwerfen des Frames (Security Drop), Inkrementieren von Fehlerzählern und Meldung an Sicherheitsüberwachungsinstanzen (z. B. IdsM / Security Event Reporting via Det/Dem).
  5. Forwarding: Bei Erfolg Strippen des AH (und bei Tunnel Mode Entkapseln des inneren IP-Pakets) und Übergabe an den Socket/L4-Stack.

4. Normative Relevanz & Entwickler-Hinweise

• Inkompatibilität mit Network Address Translation (NAT / NAPT): Da der äußere IP-Header Teil des Signaturbereichs ist, bricht jede Adress- oder Port-Translation durch zwischengeschaltete Router/Switches (z. B. Gateway-ECUs) den ICV. AH unterstützt prinzipbedingt kein NAT-Traversal (NAT-T via UDP-Kapselung). Für Strecken mit Adress-Translation muss zwingend ESP (mit Null-Verschlüsselung) projektiert werden.
• MTU- und Fragmentierungs-Management:
  • Der AH vergrößert den IP-Frame um 24 bis 32+ Bytes (abhängig von IPv4/IPv6 und ICV-Länge); Tunnel Mode fügt zusätzlich 20 Bytes (IPv4) bzw. 40 Bytes (IPv6) hinzu.
  • Dies erzwingt MSS-Clamping (TCP Maximum Segment Size) und Path-MTU-Discovery für Applikationsprotokolle (SOME/IP, DoIP), um Laufzeit-Fragmentierung auf dem Automotive-Ethernet-Bus zwingend zu verhindern.
• Hardware-Beschleunigung & CPU-Last:
  • Da die Integritätsprüfung das gesamte Paket abdeckt, entsteht bei hohem Durchsatz signifikante CPU-Last.
  • Integration von Crypto-Hardwaretreibern (Crypto Stack / HSM / vHSS / krypto-beschleunigte NICs) über synchrone/asynchrone CSM- bzw. XFRM-Offload-Schnittstellen ist zwingend einzuplanen.
• Konfigurationsaspekte:
  • Wahl zwischen Transport- und Tunnel-Modus muss konsistent in den AUTOSAR-ARXML-Modellen (IPsecRule, SecurityAssociation) zwischen Kommunikationspartnern parametriert werden.