>>> the time of the reply from the mapping system must be shorter than it >>> takes for the SYN packet to become an ACK packet. If not, then the xTR >>> needs to store the packet in memory (which is expensive at higher >>> speeds) or drop it but we have to assume that valid traffic have >>> already been dropped or delayed at the ingress ITR. So doing that a >> >> Right, so you have some hard decisions to make. The ETR can do lookup in its >> cache to figure out if the (source-RLOC, source-EID) is in its cache and if >> not, drop the packet, then do a lookup so subsequent packets can have the >> cache populated so the check can pass. >> >> I would prefer to not propose this solution. I'd rather try to solve on the >> ITR and make the solution closer to the source. >> > > Me either, no cache and mapping functionality at the ETR but instead > have a quick look at the incoming packets so that ITR doesn't have to > fetch the information from a very slow memory (e.g. hard disk). > Assumption here is that there is a local database at the ITR - but > that is not the case in current I-Ds, this is an option but it has > other problems…
It is described or else the ITR does not know how to set locator-status-bits. >>> second time is not helpful. Also the mapping system must always >>> respond promptly to an ITR, if there are several ITRs using the same >>> server how to ensure that an ITR under attack gets priority so that >>> the mapping requests are further delayed (apart from the light of >>> speed issue). >> >> Agree, but these issues are no different than what we see in the DNS today. >> It is too hard and won't scale to differentiate and if anyone tries to >> figure a solution to this bit, it probably can't work. >> > > There is a huge difference between a DNS and a MS lookup, DNS is not > in the forwarding plane at all but to build forwarding plane in LISP > you need to ask the MS on how to build it - the forwarding plane is There is not a huge difference, the rate of incoming requests is what is the difference. And if data-plane induced Map-Requests are rate-limited to the same rate a control-plane protocol, like DNS, is being used, it is exactly the same. > not prepared in advance. And if the MS system is fair away or can't > reply to the requests at the same pace as the bogus ITR sends packets The draft talks about how to pace. And if a DNS server can't reply because of the 1,000,000 requests coming to it from 1,000,000 places, you won't get your TCP connection established too. >> >>> Then if LISP gets widely deployed there is the botnet issue with >>> clients at dispersed EID prefixes, these will not be caught by a uRPF >>> filter but they could generate a lot of cache entries depending on how >>> many +/- mappings each EID prefix provides. >> >> That is why you solve it at the encapsulator end of this so you don't have >> to query the mapping database *for your own EID-prefixes*. The ITR has all >> the information it needs locally to determine to pass a packet from a source >> or not. > > For the first case, i.e. an attacker using a fake ITR - the attacker > owning the fake ITR(s) will not do that :-) And you can't stop me bombarding your home router with packets. There are some solutions that can help some situations but you are not going to find a silver bullet. > The second case is far in the future, LISP has been deployed and well > established. Imagine if you have 200 000 botnet clients, each client > is attached to their dedicated EID prefix and each client generates > 1-10 +/- mappings per EID prefix. Now the botnet admin decides that a What does that mean? Each EID-prefix is one mapping so what are you saying "10 per EID-prefix". > EID site will be attacked, he triggers a timestamped HTTP request to > that EID site, a SYN goes out at the very same seconds from 200 000 > botnet clients. No fake source/destination are used, all EIDs are What makes you think 200,000 requests will hit the same map-server and ETR at the same time? If you frame a problem to your advantage, all my answer is going to be is "packets will get dropped". And that is goodness. If we rate-limite, 200 botnets will get map-replies and 10% of good clients will get service. It is not LISP that causes this problem, it is the rate the ETR can receive and process packets. > legal and they don't get caught by uRPF. But the ITR (handling the > ACKs from the attacked EID site) has to create somewhere between 200 > 000 to 2 millions cache entries at a pace that depends on how powerful So the xTR can handle 200,000 incoming requests but can't cache 2 million entries? How does that exactly work? > server/servers are used to generate the 200 000 ACKs. And if there is > no local database at the ITR (that is handling the ACKs) it has to I am not following, you logic is not making any sense. > consult the MS, resolve each entry and that will take some time. And > if the cache size is limited, you need adjust the timers and flush the > cache more often, but then the attacker can do this trick more often. Who says you should flush the cache. > After a while, when there is analyzed data, you could create a > blacklist at the ITR (that is handling the returning ACKs). The > numbers used here are taken from nowhere, I had to use some numbers to > explain the possible scenario that could happen in the future. No, no, no. I don't know where to start to reply to this. I can't actually because I don't understand the sequence and believe it contradicts itself. Dino > > Patrick _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
