Zusammenfassung

  • Revision 08 von draft-nir-ipsecme-big-payload erschien am 10. September 2026. Gegenüber Revision 07 wurden Daten, Ablaufdatum, ein Wort und ein Classic-McEliece-Verweis gepflegt; der Mechanismus wurde nicht neu entworfen.
  • Ein reserviertes Bit wird zu L. Nach der booleschen Meldung LARGE_PAYLOAD_SUPPORTED in IKE_SA_INIT kann die Payload-Länge statt 16 nun 32 Bit belegen.
  • Die Meldung nennt weder Höchstgröße noch Austausch- oder Payload-Typ, Speicher, Rechenbudget oder Parallelität. Der Entwurf erlaubt ausdrücklich Plausibilitätsgrenzen einer Implementierung.
  • Datatracker führt das Dokument weiter als aktiven IPSECME-Kandidaten mit „Call For Adoption By WG Issued“, ohne Shepherd und ohne IESG-Genehmigung. Der beantragte Wert fehlt im aktuellen IANA-Register.

Eine Meldung ohne Maßeinheit

RFC 7296 stattet die gesamte IKE-Nachricht mit einem vier Oktett langen Length-Feld aus. Im Generic Payload Header stehen für Payload Length dagegen nur zwei Oktette bereit. Die äußere Nachricht kann also eine größere Gesamtlänge beschreiben, während eine einzelne Payload unter 65.536 Oktetten bleiben muss.

Der Entwurf nutzt dafür ein bislang reserviertes Bit. Ist L gesetzt, wird die Payload-Länge in vier Oktetten gelesen. Vorher muss die empfangende Seite in IKE_SA_INIT mit der datenlosen Statusmeldung LARGE_PAYLOAD_SUPPORTED erkennen lassen, dass sie dieses Layout versteht. So wird die Parserwahl eindeutig.

Die Meldung besitzt aber keine Maßeinheit. Sie nennt keine Obergrenze in Bytes, keinen Geltungsbereich nach Austausch oder Payload, keinen Speicher für Zusammensetzung, keine zulässige CPU-Arbeit und keine Zahl gleichzeitig offener Großobjekte. „Unterstützt“ als „jede in 32 Bit darstellbare Länge wird angenommen“ zu deuten, würde eine nicht gesendete Verpflichtung ergänzen.

Das Format gewinnt Reichweite. Die knappen Mittel bleiben unter lokaler Kontrolle.

Aushandlung pro Richtung

Große Payloads selbst dürfen laut Entwurf nicht in IKE_SA_INIT stehen, obwohl dort die Fähigkeit angekündigt wird. Für großes Material beim anfänglichen Schlüsselaustausch verweist der Text auf den IKE Intermediate Exchange aus RFC 9242.

Die Fähigkeit darf asymmetrisch sein. Wer die Meldung sendet, kann das erweiterte Format empfangen und verarbeiten. Ohne dieselbe Meldung der Gegenseite darf er es nicht zurücksenden. Ausgehandelt wird somit ein zulässiges Headerlayout je Richtung, kein gleicher oder gemeinsamer Ressourcentopf.

Beim Eingang prüft die Implementierung, ob die versprochene Länge in die noch verbleibenden Oktette der IKE-Nachricht passt. Fehlen Daten, sieht der Entwurf INVALID_SYNTAX vor. Sind sie vorhanden, soll die Payload normal verarbeitet werden. Nur weil die konkrete Länge auch im kurzen Format Platz gehabt hätte, darf die erweiterte Kodierung nicht abgewiesen werden.

Damit wird Syntaxwillkür verhindert. Eine anschließende, dokumentierte Ressourcenentscheidung über ein korrekt kodiertes, aber zu teures Objekt bleibt davon unberührt.

65.535 SPIs und zwei verschiedene Grenzen

Als anschaulichen Fall verwendet der Text eine DELETE-Payload. Sie kann IPsec-SPIs zu je vier Oktetten auflisten; der Zähler reicht bis 65.535. Das kurze Längenfeld kann die vollständige Liste nicht in einer Payload abbilden. Mit dem langen Header beträgt sie nach der Rechnung des Entwurfs 262.150 Oktette.

Die Zahl belegt eine Lücke im bisherigen Kodierraum. Sie verpflichtet jedoch nicht jedes Gerät, diese Maximalgröße zu verarbeiten. Der Entwurf sagt ausdrücklich, dass Implementierungen eine sinnvolle Obergrenze für die Zahl der SPIs in einem DELETE setzen dürfen. Headerverständnis und Ressourcenannahme bleiben zwei Konformitätsfragen.

Bleibt die zweite Grenze unsichtbar, muss ein Sender sie über Timeouts, unspezifische Fehler oder Leistungsverlust ertasten. Ein vorsichtiger Schutz kann wie fehlende Formatunterstützung aussehen; ein echter Parserfehler wie Ressourcenknappheit. Aus einem Bit, das Eindeutigkeit schaffen soll, würde eine Quelle betrieblicher Unklarheit.

Fragmentierung und TCP verschieben keine Verfügungsgewalt

RFC 7383 zerlegt verschlüsselte IKE-Nachrichten, damit sie Pfade mit kleineren Paketgrenzen passieren. RFC 9329 beschreibt IKEv2 und IPsec über TCP für Umgebungen, in denen UDP blockiert oder beeinträchtigt ist. Beide verändern die Beförderung, nicht die zugesagte Verarbeitungskapazität des Empfängers.

Fragmente müssen gespeichert, zusammengesetzt, geprüft und bearbeitet werden. Ein zuverlässiger TCP-Strom kann mehr Arbeit zustellen, als ein begrenztes System gleichzeitig annehmen will. Längenformat, Transporthilfe und lokale Zulassung sind daher getrennte Steuerungen.

Revision und Verfahrensstand präzise auseinanderhalten

Der offizielle Vergleich von Revision 07 und 08 zeigt aktualisierte Daten und Ablaufzeiten, die Korrektur von than zu that sowie einen erneuerten Classic-McEliece-Verweis. Es kam kein numerischer Grenzwert und keine Ressourcenverhandlung hinzu. Die Veröffentlichung vom 10. September ist Pflege, kein neues Design.

Beim Verfahrensstand stehen mehrere Signale nebeneinander. Datatracker ordnet das Dokument IPSECME zu und nennt „Call For Adoption By WG Issued“. Die Historie verzeichnet am 22. Juli die Zuordnung zu Working Group und IETF Stream sowie den Adoptionsaufruf. Die Mailingliste setzte den 15. August als Frist für Kommentare. Die automatische I-D-Ankündigung von Revision 08 bezeichnet es als „work item“ von IPSECME.

Gleichzeitig steht auf der aktuellen Seite weiterhin Candidate. Es gibt keinen Shepherd, der IESG-Status lautet „I-D Exists“, und weder verantwortlicher Area Director noch Telechat sind eingetragen. Der Dateiname draft-nir passt zu einem individuellen Namen, ist aber kein Beschluss. Eine belastbare Meldung muss beide Seiten des Datensatzes nennen, statt daraus eigenmächtig eine Annahmeentscheidung zu machen.

Im Text wird Standards Track angestrebt und eine Aktualisierung von RFC 7296 für den Fall der Genehmigung angekündigt. Datatracker zeigt beim intended status derzeit „(None)“. Das ist eine Metadatendifferenz, keine Genehmigung. Auch im IANA-Register der IKEv2 Notify Message Status Types fehlt LARGE_PAYLOAD_SUPPORTED: Beantragung und Zuteilung sind nicht dasselbe. Belege für IETF-Konsens, IESG-Zustimmung, RFC-Veröffentlichung, Implementierung, Interoperabilitätstest, Einsatz oder Vorfall liegen in den geprüften Quellen nicht vor.

Quellen