Seminar Erik für Relying Parties: Client-Integration, Fetch-Logik, Validierung

Inhaltsverzeichnis

• Abstract
• Zielgruppe
• Voraussetzungen
• Lernziele
• Inhalte (detailliert)
• Praxisübungen Schritt für Schritt
• Ergebnisprofil

Abstract

Dieses Seminar fokussiert die Integration von Erik in Relying-Party-Software und Validated-Caches. Im Zentrum stehen Client-seitige Verarbeitungsschritte: Index-Handling, Partition-Selektion, Manifest-Auswahl per Sequenznummern- und Zeitlogik, objektbasierter Abruf per Hash sowie Ablage- und Garbage-Collection-Strategien. Zusätzlich werden Sicherheits- und Robustheitsmechanismen aus Sicht des Clients behandelt: Scope-Prüfungen, Hash-Verifikation, Relay-Rotation bei Fehlern und der parallele Betrieb mehrerer Transportwege. Das Seminar liefert eine umsetzbare Referenzarchitektur für Client-Implementierungen und Betriebsparameter für zuverlässige Synchronisationsläufe.

Zielgruppe

• Teams, die RPKI-Validatoren/Validated Caches betreiben oder entwickeln
• Plattformteams mit Verantwortung für Verfügbarkeit und Update-Zyklen
• Engineering Leads für Routing-Sicherheitskomponenten

Voraussetzungen

• Seminar Erik Synchronization Protocol: Architektur, Datenstrukturen, Ablauf oder gleichwertiges Erik-Protokollverständnis.
• Erfahrung mit einem Validator oder Cache-Konzept (betrieblich oder entwicklungstechnisch).
• Grundkenntnisse HTTP, Hashing, Filesystem-/Objektspeicherung.

Lernziele

• Client-Fetch-Pipeline für Erik end-to-end entwerfen.
• Relevanzlogik für Manifeste (Sequenznummern, Zeitfelder) korrekt anwenden.
• Scope-Checks und Hash-Verifikation als Sicherheitsgates implementieren.
• Hybridbetrieb (Erik plus weitere Transportwege) robust umsetzen und testen.
• Garbage Collection und Cache-Konsistenz unter Fehlerbedingungen steuern.

Inhalte (detailliert)

• Client-Pipeline: Index-Fetch, Vergleich mit lokalem Zustand, Partition-Fetch, Manifest-Fetch, Objekt-Fetch.
• Local State: Speicherung nach Hash, Metadatenindex, Wiederverwendung bereits geladener Objekte.
• Entscheidungslogik:
  • Partition-Fetch nur bei Bedarf (z. B. unbekannte Partition-Hashes).
  • Manifest-Fetch nach Sequenznummern und Zeitfeldern.
  • Objekt-Fetch aus Manifest-FileLists und Abgleich mit lokalem Cache.
• Sicherheitsgates:
  • Index-Scope vs. angefragter Scope.
  • Locations und SIA-gebundene Pfade: nur scope-konforme Objekte.
  • Hash-Verifikation für jeden Abruf.
• Robustheit:
  • Kein Session-Konzept: Wechsel zwischen Relays im Lauf.
  • Retry-/Backoff-Strategien pro Objekttyp (Index vs. Objekt).
  • Umgang mit byzantinen oder fehlerhaften Relays durch Rotation.
• Hybridbetrieb:
  • Priorisierung von Erik vs. alternative Quellen (z. B. Fallback).
  • Telemetrie zur Entscheidungsfindung (Latenz, Fehlerraten, Hash-Mismatch).
• Cache-Hygiene:
  • Mark-and-sweep-Ansatz: „referenziert vs. nicht referenziert“.
  • Umgang mit veralteten Objekten ohne serverseitige Withdraw-Information.

Praxisübungen Schritt für Schritt

• Client-Pipeline als Checkliste implementieren: Zustandsdiagramm erstellen (Idle → Index → Partition → Manifest → Objekt → Validate).
• Scope-Validierung als Unit-Test-Set: Negativfälle definieren (falscher Scope, fremde Locations).
• Hash-Fetch-Storage: Ablagekonzept entwerfen (Content-Store, Metadaten-DB, dedup).
• Hybrid-Fallback: Regeln definieren, wann alternative Quellen genutzt werden; Tests mit erzwungenen Fehlern.
• Fehlerlabor: Simulierte HTTP-Fehler, Timeouts, Hash-Mismatch, inkonsistente Relays; erwartetes Client-Verhalten.

Ergebnisprofil

• Referenzarchitektur für Erik-fähige Validatoren.
• Testset und Betriebsparameter für zuverlässige Synchronisationsläufe.