I have now completed my review.
In general, I'm quite happy with the document. There were of course a number of
issues, even some technical ones such as explaining the areas where
experimentation is needed in Section 1, expanding the security considerations
section, when you do return routability checks, pointing to normal ECN
functionality, advice for ICMP treatment, the scope of the mobility section,
better acknowledgment of cache management difficulties in the router
performance section, contents of the IANA section, normative/non-normative
reference split, and so on. But on the whole I did not see any showstoppers. We
should be able to make the modifications quickly and last call the document. I
can see that Dino has already done a lot of that; thanks. In some cases further
discussion is needed. I will respond on the mail thread on each specific mail.
One additional follow-up on my own earlier note:
An ITR that is configured with mapping database information (i.e. it
is also an ETR) may optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request and it does
not have this mapping in the map-cache, it may originate a "verifying
Map-Request", addressed to the map-requesting ITR. If the ETR has a
map-cache entry that matches the "piggybacked" EID and the RLOC is in
the locator-set for the entry, then it may send the "verifying Map-
Request" directly to the originating Map-Request source. If the RLOC
is not in the locator-set, then the ETR MUST send the "verifying Map-
Request" to the "piggybacked" EID. Doing this forces the "verifying
Map-Request" to go through the mapping database system to reach the
authoritative source of information about that EID, guarding against
RLOC-spoofing in in the "piggybacked" mapping data.
I want to understand this better and I guess reading to the end of the document will answer some of my questions. But as a general rule, I think we should not trust other nodes in the network to claim alternative addresses for themselves, unless we can somehow verify (via return routability or via mapping data base) that they appear to really be at that address. So I am wondering if the "may originate" should become "originates". But I'm reading on.
I think the right thing here is already specified in your text for the case when the map-cache
entry exists. But I think you need to change the "may originate" in the to "MUST
originate" when there is no map-cache entry. Otherwise, you are believing a locator claim from
a random packet sent to you. It is too easy to misuse this, and the remedy is simple: just require
the same check as you already do when the cache entry exists but the locator is new.
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
