Subject: [lisp] AD review of draft-ietf-lisp: summary

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Oct 2011 14:28:21 +0300

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