12. Security Considerations (Sicherheitsüberlegungen)
12. Security Considerations (Sicherheitsüberlegungen)
Solange Flow Specifications darauf beschränkt sind, den entsprechenden Unicast-Routing-Pfaden für die betreffenden Präfixe zu entsprechen (Abschnitt 6), sind die Sicherheitseigenschaften dieses Vorschlags gleichwertig mit den bestehenden Sicherheitseigenschaften von BGP-Unicast-Routing. Jede Lockerung des in Abschnitt 6 beschriebenen Validierungsprozesses kann die Verbreitung unerwünschter Flow Specifications und möglicherweise die Anwendung unerwünschter Traffic Filtering Actions auf Verkehrsflüsse ermöglichen.
Wenn die oben genannten Mechanismen nicht vorhanden sind, kann dies die Tür für weitere Denial-of-Service-Angriffe öffnen, z. B. unerwünschte Verkehrsfilterung, erneutes Markieren oder Umleiten.
Die Bereitstellung spezifischer Lockerungen der Validierung innerhalb der administrativen Grenzen eines Netzes kann für einige Netze nützlich sein, um Filter schnell zur Abwehr von Denial-of-Service-Angriffen zu verteilen. Damit ein Netz eine solche Lockerung nutzen kann, MUSS die BGP-Richtlinie zusätzliche Filterung unterstützen, da das Quell-AS-Feld leer ist. Spezifikationen, die Validierungseinschränkungen lockern, MÜSSEN Sicherheitsüberlegungen enthalten, die die erforderliche zusätzliche Filterung im Detail angeben. Beispielsweise kann Quellvalidierung innerhalb eines AS-Bündnisses verstärkte Filterung ermöglichen.
Interdomain-Routing basiert auf einem Netz aus Vertrauen. Benachbarte autonome Systeme werden als vertrauenswürdig angesehen, gültige Erreichbarkeitsinformationen anzukündigen. Wenn dieses Vertrauensmodell verletzt wird, kann ein benachbartes autonomes System einen Denial-of-Service-Angriff verursachen, indem es Erreichbarkeitsinformationen für ein gegebenes Präfix ankündigt, für das es keinen Dienst erbringt (ungefilterter Adressraum-Diebstahl). Da die Validierung von Flow Specifications mit der Ankündigung des besten Unicast-Routings verknüpft ist, kann ein Fehler bei der Validierung des besten Pfads den lokalen Router daran hindern, die Flow Specification zu verwenden. Mögliche Milderungen sind [RFC6811] und [RFC8205].
An Internet Exchange Points (IXP) wird Routing häufig über Route Server ausgetauscht, die AS_PATH nicht erweitern. In diesem Fall kann nicht erzwungen werden, dass das linke AS in AS_PATH das Nachbar-AS ist (das AS des Route Servers). Da die Validierung von Flow Specifications (Abschnitt 6) darauf basiert, ist besondere Vorsicht geboten. In solchen Szenarien wird empfohlen, eine strenge eingehende Routing-Richtlinie zu verwenden.
Die Aktivierung firewallähnlicher Funktionen in Routern ohne zentrale Verwaltung kann bestimmte Fehler schwerer diagnostizierbar machen. Beispielsweise können TCP-Pakete zwischen einem Adresspaar durchgelassen werden, ICMP-Pakete jedoch nicht. Pakete kleiner als 900 oder größer als 1000 Oktette können zwischen einem Adresspaar erlaubt sein, nicht jedoch solche mit Längen zwischen 900 und 1000. Ein solches Verhalten kann verwirrend sein; ob durch manuelle Konfiguration oder koordiniert über die in diesem Dokument beschriebenen Protokollerweiterungen, diese Funktionen SOLLTEN mit Vorsicht verwendet werden.
Ein BGP-Flow-Specification-Sprecher (z. B. ein automatisierter DDoS-Controller), wenn er schlecht programmiert ist, der Algorithmus sich nicht wie erwartet verhält oder es sich schlicht um ein bösartiges System handelt, kann unerwartete Flow Specifications ankündigen, Updates mit hoher Rate senden oder eine große Anzahl von Flow Specifications erzeugen. Dies kann empfangende Systeme über ihre Kapazität hinaus belasten oder zur Anwendung unerwünschter Traffic Filtering Actions auf Verkehrsflüsse führen.
Ein System kann möglicherweise nicht alle Headerwerte lokalisieren, die zur Identifizierung eines Pakets erforderlich sind. Dies ist besonders problematisch bei fragmentierten Paketen, die nicht das erste Fragment sind und daher keinen Header eines höheren Protokolls oder ESP-NULL-Verschlüsselung (Encapsulating Security Payload) [RFC4303] aufweisen.
Obwohl die allgemeine Validierung des Flow-Specification-NLRI in diesem Dokument spezifiziert ist (Abschnitt 6), kann der Empfang von Traffic Filtering Actions von Dritten benutzerdefinierte Validierung oder Filterung erfordern. Insbesondere können alle anderen als Traffic-Rate-Aktionen es Dritten ermöglichen, Paketweiterleitungsattribute zu ändern und möglicherweise Zugriff auf andere Routing-Tabellen/VPNs oder unerwünschte Warteschlangen zu erhalten. Dies kann vermieden werden, indem Traffic-Filtering-Action-Communities an Netzgrenzen ordnungsgemäß gefiltert werden und Dritten nur eine vordefinierte Teilmenge von Traffic Filtering Actions offengelegt wird (siehe Abschnitt 7). Eine Methode dazu ist, benutzerdefinierte Communities, die von Dritten gesetzt werden können, auf Traffic Filtering Actions abzubilden und von Dritten stammende Traffic-Filtering-Action-Extended-Communities nicht zu akzeptieren.
Diese Erweiterung fügt Internet-Routern zusätzliche Informationen hinzu. Diese sind begrenzt hinsichtlich der maximalen Datenmenge, die sie aufnehmen können, und der Anzahl der Ereignisse, die sie pro Zeiteinheit verarbeiten können. Dienstanbieter MÜSSEN die maximale Kapazität ihrer Geräte berücksichtigen und müssen möglicherweise die Anzahl der akzeptierten und verarbeiteten Flow Specifications begrenzen.