Since Ekr has cycled off the IESG, I'll try to take over any remaining points here. It seems like there may just be the one left, hooray! The authors very helpfully put together a spreadsheet with all the comments, discussion about them, and pointers to what changed (if anything) in the document as a result; thank you for that!
On Thu, Sep 27, 2018 at 05:16:00AM -0700, Eric Rescorla wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- [trimming heavily] > > S 6.1. > > receives an SMR-based Map-Request and the source is not in the > > Locator-Set for the stored Map-Cache entry, then the responding Map- > > Request MUST be sent with an EID destination to the mapping database > > system. Since the mapping database system is a more secure way to > > reach an authoritative ETR, it will deliver the Map-Request to the > > authoritative source of the mapping data. > > If I'm understanding this correctly, this allows an ETR to prevent an > ITR from learning that it is no longer the appropriate ETR for a > prefix. The way this attack works is that before the topology shift, I > send SMRs, thus causing Map-Requests, which, because my entry is > cached, refresh the cache on the ITR past the topology shift. I can > keep doing this indefinitely. Am I missing something If I can perhaps try to refine the questionable scenario, suppose there's an ITR "A" that's trying to direct traffic to EID "B", and "B" is currently behind an evil ETR "C" but will shortly move behind a different ETR "D". For simplicity, suppose further that C is the only ETR at that site, so there is only one RLOC in the legitimate mapping data. The claim here is that, if C knows what timeout/configuration A has stored for the mapping information for B, then C can periodically send SMR to A, and the procedures in this section cause A to send the solicited Map-Reply not through the mapping system, but directly to C, since C's RLOC is already in the Map-Cache entry that A has stored for mapping B's EID. Since C is evil and wants to keep looking at B's traffic, C will then reply with a (now-false, after B has moved away) Map-Reply that "confirms" that C is the right RLOC for reaching B, and A continues to route traffic for B through C. Thus, C is able to "hold on to" traffic to B even after B has moved away. If A bothered to send a Map-Request to the mapping system, it would discover the truth, but I didn't find anything that required that to happen. In this simple example, there's only the one ETR, and since D has never seen traffic from A it may not know to send an SMR to A that would trigger a request to the mapping system. I do see in numbered point (2) that "If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request", but (a) that's only a SHOULD, and (b) while this is true in my simplified example above, it would not be hard to construct more complicated scenarios where it failed to apply. I also consider the case that if B is sending return traffic towards [something behind] A, and that traffic goes through D where D acts as an ITR, then D will know to send its own SMR to A. But, (c) nothing requires D to be an xTR as opposed to just an ETR, and (d) unidirectional flows would still be affected. -Ben _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
