Zusammenfassung
- RFC 2385 prüfte jedes geschützte TCP-Segment mit einem gemeinsamen Geheimnis und verwarf fehlgeschlagene Prüfungen ohne Antwort.
- Um knappen TCP-Optionsraum zu sparen, enthielt das Format weder Algorithmus- noch Schlüsselkennung; ein gültiger Digest belegte ein Segment unter lokaler Konfiguration, nicht Schlüsselalter, Gegenstellenrecht oder Routenwahrheit.
Eine kleine Fälschung mit großer Wirkung
BGP erhielt von TCP geordnete, zuverlässige Übertragung und wurde dadurch von dessen Verbindungszustand abhängig. Konnte ein Angreifer Endpunkte und Sequenzraum ausreichend erraten, konnte ein gefälschtes RST die Verbindung schließen. Der Routingprozess musste neu verbinden und konnte erlernte Routen vorübergehend entfernen.
Option Kind 19 bestand aus Typ, Länge und 16 Byte MD5. In die Berechnung gingen IPv4-Pseudoheader, TCP-Header ohne Optionen und mit genullter Prüfsumme, Nutzdaten und ein beiden Endpunkten bekanntes Geheimnis ein. Bei Abweichung musste der Empfänger schweigend verwerfen.
Das schützte den Übergang in die TCP-Zustandsmaschine. Es identifizierte nicht den Betreiber, berechtigte kein AS zu einem Präfix und bewies weder Policy-Annahme noch RIB, FIB oder Zustellung. Ein Digest war ein enger Beleg über Segmentbytes und konfiguriertes Geheimnis.
Kein Aushandeln, keine sichtbare Epoche
Ob die Option verlangt wurde, handelte TCP nicht aus. Standortpolitik und Anwendung entschieden. Fehlte sie im SYN/ACK, durfte der geschützte Sender nicht herunterstufen; die Antwort wurde ignoriert, die Verbindung kam nicht zustande. Ein unbeglaubigter Peer erhielt keine Macht über die lokale Pflicht.
Die Einigung über Geheimnis und Aktivierungszeit lag damit außerhalb des Pakets. RFC 2385 trug keine KeyID. Ein Passwortwechsel während der Sitzung war möglich, wenn beide Seiten ihn synchronisierten, doch Retransmits konnten unter dem alten Geheimnis erzeugt und erst nach dem Wechsel empfangen werden. Das Segment konnte seine Prüfebene nicht benennen.
Emission, Optionspräsenz, Schlüsselwahl, Digestprüfung, TCP-Annahme, BGP-Fortbestand, UPDATE-Policy, Routeninstallation und Paketlieferung bleiben deshalb getrennte Belege.
Der fehlende Platzhalter
Der vollständige TCP-Header ist auf 60 Byte begrenzt. Nach 20 festen Byte bleiben 40 für sämtliche Optionen. Die MD5-Option nahm 18. Im RFC-Beispiel füllten MSS, Window Scale, Timestamp, MD5 und Padding den SYN-Optionsraum vollständig.
Zweifel an MD5 waren bekannt. Das bereits eingesetzte Format hatte trotzdem kein Algorithmusfeld. Ein zusätzliches Byte hätte 19 Byte ergeben und wäre praktisch oft auf 20 aufgefüllt worden. Zwei wirksame Byte erschienen in einem 40-Byte-Budget teuer.
Die Einsparung erleichterte die sofortige Einführung, entfernte aber die Auswahl des Nachfolgers. Ein anderer Algorithmus brauchte eine andere Option. Errata 4432 korrigierte „32-byte words“ zu „32-bit words“. RFC 6691 korrigierte die MSS-Regel: Der Sender verkürzt seine Daten um die tatsächlichen Optionen. Beides änderte weder die Grenze noch die fehlende Algorithmuskennung.
Verdrängte Schlüsselarbeit
RFC 3562 empfahl 12 bis 24 Byte lange Schlüssel, begrenzte Wiederverwendung und einen Wechsel spätestens nach 90 Tagen. So wurde sichtbar, was das Drahtformat nicht ausdrückte. Kurze Geheimnisse konnten erraten werden, Wiederverwendung vergrößerte Lecks, asynchrone Wechsel trennten legitime Peers.
RFC 5925 ersetzte TCP MD5 durch TCP-AO. Es brachte erweiterbare Algorithmen, KeyID, eine Kennung für den nächsten Empfangsschlüssel, verbindungsspezifische Ableitung und Replay-Schutz. Es verteilte dennoch keine Master Keys und autorisierte keine BGP-Route.
Ein anderer BTW-Beitrag behandelt bereits TCP-AO-Schlüsselepochen. Dieser Artikel bleibt bei der älteren Grenze: RFC 2385 konnte „passt zu unserem gemeinsamen Zustand“ sagen, aber nicht, welcher austauschbare Zustand gemeint war.
Die richtige historische Bewertung
RFC 2385 war kein vollständiges BGP-Sicherheitssystem und gab sich nicht als eines aus. Es löste ein konkretes Problem mit dem Platz und der Hardware seiner Zeit. Der lokale Verzicht auf Downgrade war eine belastbare Entscheidung.
Die dauerhafte Lehre betrifft minimale Spezifikation. Eine gemeinsame Schicht sollte klein bleiben. Sie muss aber genug expliziten Zustand enthalten, damit unabhängige Implementierungen dieselbe Gegenwart prüfen und eine andere Zukunft wählen können. Ein grüner TCP-Status ist keine Routenberechtigung; eine ausgewählte Route ist keine Lieferquittung.
RFC 2385 schützte das Segment. Weil sein Selektor fehlte, musste der Algorithmuswechsel später eine neue Protokolloberfläche schaffen.
Quellen
- IETF-Datatracker-Historie zu RFC 2385
- RFC-Editor-Eintrag zu RFC 2385
- RFC 2385 — Schutz von BGP-Sitzungen
- Errata zu RFC 2385
- RFC 793 — TCP
- RFC 1321 — MD5
- RFC 4271 — BGP-4
- RFC 3562 — TCP-MD5-Schlüsselverwaltung
- RFC 4953 — Schutz von TCP gegen Spoofing
- RFC 5925 — TCP-AO
- RFC 6691 — TCP-Optionen und MSS
- RFC 6952 — KARP-Analyse
- RFC 7454 — BGP-Betrieb und Sicherheit
- Heng Lu — Vorrang laufenden Codes
- Heng Lu — Minimale Spezifikation und freiwillige Übernahme
- Heng Lu — Realitätsebenen und Klarheit
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

