8. Sicherheitsüberlegungen
Die Sicherheitsüberlegungen für UDP und SCTP werden in den referenzierten RFCs bereitgestellt.
8.1. Steuerung der Sondierungsfrequenz
Um übermäßige Last zu vermeiden, MUSS das Intervall zwischen einzelnen Sondierungspaketen mindestens eine RTT betragen, und das Intervall zwischen Sondierungsrunden wird durch den PMTU_RAISE_TIMER bestimmt.
8.2. Schutz der Sondierungspaketbestätigung
Der PL-Sender muss sicherstellen, dass die zur Bestätigung des Empfangs von Sondierungspaketen verwendete Methode vor Off-Path-Angreifern schützen kann, die Pakete in den Pfad einschleusen. Dieser Schutz wird in IETF-definierten Protokollen (z.B. TCP, SCTP) unter Verwendung einer zufällig initialisierten Sequenznummer bereitgestellt. Abschnitt 5.1 von [BCP145] beschreibt eine Möglichkeit, dies bei Verwendung von UDP zu tun.
8.3. Validierung von PTB-Nachrichten
Es gibt Fälle, in denen Packet Too Big (PTB)-Nachrichten aufgrund von Richtlinien, Konfiguration oder Gerätedesign nicht zugestellt werden (siehe Abschnitt 1.1). Diese Methode stützt sich daher nicht auf den Empfang von PTB-Nachrichten, kann diese jedoch nutzen, wenn sie von einem Sender empfangen werden.
Schutz vor PTB-Nachrichtenangriffen
PTB-Nachrichten könnten verwendet werden, um einen Knoten dazu zu bringen, die PLPMTU unangemessen zu reduzieren. Ein Knoten, der DPLPMTUD unterstützt, MUSS die Nutzdaten von PTB-Nachrichten angemessen validieren, um sicherzustellen, dass diese als Antwort auf Datagramme empfangen werden, die tatsächlich von der PL-Schicht gesendet wurden (d.h. einer Fehlerbedingung entsprechen, die für ein tatsächlich gesendetes Datagramm aufgetreten ist, siehe Abschnitt 4.6.1).
Abschwächung von On-Path-Angriffen
Ein On-Path-Angreifer, der PTB-Nachrichten erstellen kann, könnte PTB-Nachrichten fälschen, die ein gültiges zitiertes IP-Paket enthalten. Ein solcher Angriff könnte verwendet werden, um die PLPMTU zu reduzieren. Ein On-Path-Gerät könnte in ähnlicher Weise eine Reduzierung der PLPMTU erzwingen, indem es eine Richtlinie implementiert, um Pakete zu verwerfen, die größer als eine konfigurierte Größe sind.
Abschwächungsmethoden:
-
Basis-Schutz: Sicherstellen, dass ein PL-Sender die PLPMTU niemals unter die Basisgröße reduziert, nur als Reaktion auf den Empfang einer PTB-Nachricht. Dies wird erreicht, indem zuerst der BASE-Zustand betreten wird, wenn eine solche Nachricht empfangen wird.
-
Sondierungs-Validierung: Entwickelt, um die Verarbeitung von PTB-Nachrichten nicht zu erfordern; ein PL-Sender kann die Verarbeitung von PTB-Nachrichten aussetzen (z.B. in einem Robustheitsmodus, nachdem festgestellt wurde, dass nachfolgende Sondierungen tatsächlich bestätigen, dass eine Größe größer als PTB_SIZE vom Pfad unterstützt wird).
8.4. Schutz vor Denial-of-Service
Begrenzung des Verarbeitungsaufwands
Das Parsen des zitierten Pakets in einer PTB-Nachricht kann zusätzliche Verarbeitung pro Paket beim PL-Sender einführen. Diese Verarbeitung SOLLTE begrenzt werden, um einen Denial-of-Service-Angriff zu vermeiden, wenn beliebige Header vorhanden sind. Eine Ratenbegrenzung der Verarbeitung könnte dazu führen, dass der PL keine PTB-Nachrichten empfängt; die DPLPMTUD-Methode ist jedoch robust gegen solche Verluste.
ICMP-Nachrichtenverarbeitung
Eine erfolgreiche Verarbeitung einer ICMP-Nachricht kann eine Sondierung auslösen, wenn die gemeldete PTB-Größe gültig ist, aktualisiert aber nicht direkt die PLPMTU für einen Pfad. Dies verhindert Nachrichten, die versuchen, Daten durch Angabe einer Größe, die größer als vom Pfad unterstützt ist, zu black-holing.
8.5. Instabilität der Pfadinformationen
Informationen über einen Pfad können instabil sein. Dies könnte das Ergebnis einer Weiterleitung über mehrere Pfade mit unterschiedlichen tatsächlichen PMTUs oder eines einzelnen Pfads sein, der eine variierende PMTU aufweist.
Abschwächung: Das Design einer DPLPMTUD-Implementierung SOLLTE berücksichtigen, wie die Auswirkungen variierender Pfadinformationen gemildert werden können. Eine mögliche Abschwächung besteht darin, Robustheit in die Methode einzubauen (siehe Abschnitt 5.4), um Oszillationen im MPS zu vermeiden.
8.6. Sicherheit von Padding-Daten
Die DPLPMTUD-Methode kann Padding-Daten einführen, um die Länge des Datagramms auf die für ein Sondierungspaket erforderliche Gesamtgröße aufzublähen. Die Gesamtgröße eines Sondierungspakets umfasst alle Header und Padding, die den gesendeten Nutzdaten hinzugefügt werden (z.B. einschließlich sicherheitsbezogener Felder wie AEAD-Tags und TLS-Record-Layer-Padding). Der Wert der Padding-Daten beeinflusst den DPLPMTUD-Suchalgorithmus nicht und muss daher in einer Weise festgelegt werden, die mit der Richtlinie des PL konsistent ist.
Anforderungen an den Verschlüsselungsschutz
Wenn der PL einen kryptographischen Vertraulichkeits- oder Datenintegritätsmechanismus verwenden kann, sollte das Design vermeiden, etwas zu DPLPMTUD-Sondierungspaketen hinzuzufügen (z.B. Padding), das nicht auch durch diese kryptographischen Mechanismen geschützt ist.
8.7. Zusammenfassung der Sicherheits-Best-Practices
- Alle PTB-Nachrichten validieren: Ursprung und Inhalt von PTB-Nachrichten vor Verwendung validieren
- Verarbeitungsrate begrenzen: Ressourcenerschöpfung durch PTB-Nachrichtenverarbeitung verhindern
- Sondierungsbestätigung schützen: Schwer zu erratende Kennungen verwenden
- Padding-Daten verschlüsseln: Sicherstellen, dass alle Daten in Sondierungspaketen durch Verschlüsselung geschützt sind
- Pfadstabilität überwachen: Ungewöhnliche Änderungen in Pfadinformationen erkennen und darauf reagieren
- Ratenbegrenzung implementieren: Frequenz des Sendens von Sondierungspaketen kontrollieren
Diese Sicherheitsüberlegungen stellen sicher, dass DPLPMTUD sicher und zuverlässig arbeiten kann, selbst in Gegenwart böswilliger Angreifer.