Eliot, On 14 Jul 2011, at 07:41, Eliot Lear wrote: > Ross, > > On 7/14/11 4:55 AM, Ross Callon wrote: >> I have read a couple of papers on this issue, which I believe are probably >> the ones that you are referring to. The papers that I read both assume that >> the granularity of the EID-to-RLOC tables will be the same as the >> granularity of the current top level BGP routing table. If this assumption >> is wrong, then the results will be correspondingly inaccurate. >> >> To me it seems highly unlikely that this assumption is within an order of >> magnitude of being correct. > > There are now two discussions intermixed in this thread: > > 1. What is the projected cache growth rate based on legitimate use? > > 2. What are the security considerations regarding cache attacks. > > In the first instance, let me suggest that the whole point of LISP is to > disentangle memory consumption from number of reachable points on the > Internet, but rather bound it to the number of sites actually being > reached. That is what induces the concern that Jeff has raised with the > 2nd discussion. What Jeff has described is a variation of the classic > reflection attack. This is, IMHO, probably worth noting more > explicitly, as an area for future work. > > I do not agree with Jeff that the only approach to solving this problem > is to allow for overlapping negative / positive responses. That itself > can cause other problems. For instance, it causes confusion as to when > in fact a query must be sent if a negative entry is already cached, but > there exists a positive entry somewhere in the world. In any case, I > suggest we add a line that states the risk but not attempt to solve it > in this round of the experiment.
You are right but I think this problem can be solved with the ACT bit with the value 0x02 and overlapping mappings. Indeed, the assigned prefixes are known for sure and the "holes" do not change too frequently. So the result of a request in a hole could be the large "holed" prefix with a TTL that corresponds to the time before which no hole will be assigned (depends on the policy of prefix assignments but I think it should be not less than one day), this is a negative reply with the ACT bits = 0x0. And all the aggregated prefixes that have been assigned in this prefix in a negative reply form with the ACT bit = 0x2 meaning that the ITR must send a map-request before trying to encapsulate the packets in such sub-prefixes. For example, if you have 192.0.2.0/24 and only 192.0.2.0/30 and 192.0.2.128/30 that are assigned, the reply for let say 192.0.2.13 could be 192.0.2.0/24, negative, ACT=0x0, TTL= 1day 192.0.2.0/30, negative, ACT=0x2, TTL=min lease time 192.0.2.128/30, negative, ACT=0x2, TTL=min lease time where min lease time is the minimum time a prefix in the aggregate of sub-prefix is assigned to the company. For example, if the prefix 192.0.2.0/30 is assigned on a year basis, its TTL can safely be 1 year as it has the ACT=0x2 meaning that the ITR will request for mappings corresponding to addresses in this prefix on demand. Damien Saucez > > Eliot _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
