6.1.5. EID-to-RLOC UDP Map-Reply Message

6.1.5. EID-to-RLOC UDP Map-Reply Message (EID-zu-RLOC UDP Map-Reply Nachricht)

Das in der Map-Reply zurückgegebene EID-Prefix und seine Präfixlänge sind kleiner oder gleich der angeforderten EID. Die angeforderte EID stammt aus dem Ziel-Feld des IP-Headers der Data-Probe oder dem EID-Datensatz der Map-Request. Die RLOC in der Map-Reply ist die global routbare IP-Adresse aller ETRs der LISP-Site. Jede RLOC übermittelt die Statuserreichbarkeit, übermittelt jedoch nicht die Pfaderreichbarkeit aus der Sicht des Anforderers; die Pfaderreichbarkeit muss separat getestet werden (siehe Abschnitt 6.3).

Die Granularität des in der Map-Reply enthaltenen EID-Prefix (Präfix + Länge) kann sich von der Map-Request unterscheiden, die sie ausgelöst hat. Wenn beispielsweise die Map-Request für das von einer vorherigen Map-Reply zurückgegebene Präfix ist, aktualisiert der Anforderer den Cache mit den neuen Präfixinformationen und der Granularität. Wenn beispielsweise der Anforderer zwei EID-Prefix im Cache hat, die von einem gröberen Präfix in der Map-Reply abgedeckt werden, ersetzt er die Einträge durch das gröbere EID-Prefix. Umgekehrt kann auch ein gröberes Präfix durch mehrere feinere Präfixe ersetzt werden, wobei nicht der gröbere Eintrag gelöscht wird, sondern feinere Präfixe hinzugefügt werden, und bei der Suche decken die feineren Einträge die gröberen Einträge ab.

Wenn ein ETR mit überlappenden EID-Prefix konfiguriert ist, MUSS (MUST) die Map-Request für eine EID, die am besten zu einem der EID-Prefix passt, nur in einer einzigen Map-Reply-Nachricht zurückgegeben werden. Wenn beispielsweise die Mapping-Einträge der ETR-Datenbank sind:

10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24

Hat die Map-Reply für die EID 10.1.1.1 eine Datensatzanzahl von 1, mit dem EID-Prefix des Mapping-Datensatzes 10.1.1.0/24.

Die Map-Reply für die EID 10.1.5.5 hat eine Datensatzanzahl von 3, mit den Mapping-Datensätzen 10.1.0.0/16, 10.1.1.0/24 und 10.1.2.0/24.

Nicht alle überlappenden EID-Prefix müssen zurückgegeben werden; es werden nur feinere Einträge relativ zum EID-Prefix zurückgegeben, der der angeforderten EID entspricht (im zweiten Beispiel wird 10.0.0.0/8 nicht zurückgegeben, wenn 10.1.5.5 angefordert wird). Beim Zurückgeben mehrerer EID-Prefix SOLLTEN (SHOULD) alle dieselbe Time to Live verwenden, damit sie gleichzeitig ablaufen. Wenn später ein feineres EID-Prefix empfangen wird, kann die TTL des Map-Reply-Datensatzes auch dann gespeichert werden, wenn ein gröberer Eintrag existiert. Wenn später ein gröberes EID-Prefix empfangen wird, SOLLTE (SHOULD) dessen map-cache-Ablaufzeit auf die minimale Ablaufzeit aller feineren EID-Prefix im map-cache gesetzt werden, um die Integrität des EID-Prefix-Satzes aufrechtzuerhalten und zu vermeiden, dass feinere Einträge gelöscht werden, während gröbere Einträge beibehalten werden.

Für dasselbe EID-Prefix SOLLTE (SHOULD NOT) die Map-Reply nicht öfter als einmal pro Sekunde an denselben anfordernden Router gesendet werden. Für Skalierbarkeit wird erwartet, dass EID-Adressen zu EID-Prefix aggregiert werden, sodass eine Map-Reply das Mapping mehrerer EID im Präfixbereich erfüllen kann, wodurch Map-Request reduziert werden.

Map-Reply-Datensätze können ein leeres Locator-Set haben. Eine Negative Map-Reply ist eine Map-Reply mit einem leeren Locator-Set, die eine spezielle Aktion des Absenders an den ITR oder PITR übermittelt, der die Map-Reply anfordert. Hauptverwendungszweck: Der Map-Resolver gibt an, ob das Ziel zu einer LISP-Site oder einer Nicht-LISP-Site gehört, und führt Quellunterdrückung für Map-Request für nicht zugewiesene EID durch.

In jedem Map-Reply-Datensatz MUSS (MUST) die Reihenfolge der Locator-Liste im Locator-Set für jeden ETR, der die Map-Reply initiiert, gleich sein. Das Locator-Set MUSS (MUST) in aufsteigender Reihenfolge der IP-Adressen sortiert werden, wobei IPv4-Locator-Adressen numerisch "kleiner" sind als IPv6-Locator-Adressen.

Beim Senden einer Map-Reply wird die Zieladresse aus einem der ITR-RLOC-Felder der Map-Request kopiert. Der ETR KANN (MAY) eine Locator-Adresse aus den von ihm unterstützten Adressfamilien auswählen. Bei einer Data-Probe wird die Zieladresse der Map-Reply aus der Quelladresse der Data-Probe-Nachricht kopiert, die die Antwort ausgelöst hat. Die Quelladresse der Map-Reply ist eine der ausgewählten lokalen IP-Adressen, sodass die Unicast Reverse Path Forwarding (uRPF)-Prüfung des vorgelagerten Dienstanbieters erfolgreich ist. Der Zielport der Map-Reply wird aus dem Quellport der Map-Request oder Data-Probe kopiert, und der Quellport wird auf den bekannten UDP-Port 4342 gesetzt.

6.1.5.1. Traffic Redirection with Coarse EID-Prefixes (Verkehrsumleitung mit groben EID-Präfixen)

Wenn ein ETR falsch konfiguriert ist oder kompromittiert wurde, kann er in der Map-Reply ein grobes EID-Prefix zurückgeben, das Präfixe abdeckt, die anderen Sites zugewiesen sind, und dadurch deren Verkehr zum Locator der kompromittierten Site umleitet.

Es gibt hauptsächlich zwei Lösungsansätze. Einer besteht darin, den Map-Server anstelle des ETR die Map-Reply beantworten zu lassen, sodass das registrierte EID-Prefix zurückgegeben wird; die Kommunikation zwischen ETR und Map-Server ist durch einen gemeinsamen Schlüssel geschützt, und der ETR kann Anomalien leichter erkennen. Der zweite besteht darin, ITR und PITR nur EID-Prefix mit einer Maskenlänge größer oder gleich einer konfigurierten Präfixlänge cachen zu lassen, wodurch der Schaden durch beliebige beworbene Präfixbreiten auf einen bestimmten Bereich begrenzt wird, was jedoch eine Koordination mit der Präfixzuweisung der Site erfordert. Beide Ansätze können unabhängig voneinander oder gleichzeitig verwendet werden.

Zum Zeitpunkt der Erstellung dieses Dokuments werden andere Ansätze noch erforscht und in Betracht gezogen.