Die Brigham Young University schickt gerade Empfehlungsschreiben an Internet Provider aus, in denen darauf hingewiesen wird, dass es bei
diesen möglich ist, eingehende IP Pakete mit Source-Adressen aus dem Netz des Internet Providers zu empfangen.

Das mag jetzt auf den ersten Blick nicht wie ein großes Problem aussehen - schließlich können Antwort-Pakete nur ins eigene Netz gesendet werden, und werden dort wohl einfach verworfen.

In manchen Umgebungen ist es aber möglich, durch einzelne Pakete eine neue Verbindung anderswohin aufbauen zu lassen
- die ForscherInnen nehmen hier als Beispiel DNS:

Nehmen wir an, der betroffene ISP nutzt 192.0.2.0/24 als IPv4-Adressen. Er bekommt nun ein Paket mit folgender DNS-Anfrage an seinen Resolver:

Quelle: 192.0.2.253
Ziel: 192.0.2.1
Frage: IP-Adresse von Ziel.example?

Der Resolver ist für die KundInnen da, die natürlich IP-Adressen aus dem Bereich des ISPs verwenden. Der Resolver sieht eine passende Adresse
als Anfrage-Quelle (192.0.2.253) und wird versuchen die Frage zu beantworten.
Dazu sieht er nun nach, welcher Nameserver für Ziel.example zuständig sind - nehmen wir hier an, das wäre  198.51.100.1 - und schickt nun seinerseits eine neue Frage dorthin.:

Quelle: 192.0.2.1
Ziel: 198.51.100.1
Frage: IP-Adresse von Ziel.example?

Auch das wird in einzelnen Fällen wohl kein großes Problem darstellen. Werden allerdings große Mengen solcher gefälschten Anfragen geschickt, kann das zu einer Überlastung des eigentlichen Ziels (im Beispiel 198.51.100.1) führen. Es ist ebenso denkbar, dass die Details der DNS-Frage und die gefälschte Quell-Adresse bei jeder Anfrage verschieden sind, und so bestehende Sicherungsmaßnahmen wie Rate Limits fehlschlagen.
Genauso ist es vorstellbar, dass AngreiferInnen gezielt Anfragen stellen, die große Antwortpakete auslösen, um damit ihr Ziel zu überlasten. Im Beispiel könnten das 192.0.2.1 oder das ihn umgebende Netzwerk sein.

Kurz gesagt: ISPs sollten nicht nur ihre eigenen KundInnen daran hindern, Pakete mit gefälschten Absender-Adressen zu schicken (vgl. BCP38),
sondern auch an den Übergabepunkten zu ihren Upstreams/Peers dafür sorgen, dass keine Pakete mit Source-Adressen aus dem eigenen Netz
herein können.
Das ist technisch oft eine gewisse Herausforderung: einfache Filterlisten (ACLs) werden aufgrund der Ressourcen-Anforderungen meist
ausscheiden. Reverse-Path-Filter (RPF/uRPF) sind aber in den meisten Routern implementiert und deutlich "sparsamer" zu betreiben.
Auch manche Netzwerk-Topologien, zB in Umgebungen mit Multi-Homing oder Anycast-Setups, können hier ein gewisses Kopfzerbrechen auslösen.
RFC8704 behandelt das Thema ausführlich, und in den meisten Fällen sollte sich eine praktikable Lösung finden lassen.