On Mon, Jul 25, 2011 at 4:12 PM, Dino Farinacci <[email protected]> wrote: >> The only way (except from going after the stack) I see to get around >> this is to have the following: >> - have ETR and ITR in the same box (xTR). > > For which case, can you be specific please?
Hope I don't mess up the discussion but here are my inputs and think their aligned with Jeff's. First I'm discussing the case when a fake ITR (or several fake ITRs) sends bogus LISP packets to a selected ETR > >> - ETR is not doing uRPF but it inspect the incoming SYN-packets and >> pre-select mappings for the ITR so that ITR is "warned" when >> ACK-packtes are returned from the server > > Let's be careful how you use the term uRPF in context to LISP. Let's keep the > definition as the current definition. Let's refer to an ETR doing a mapping > database lookup to verify the source locator and the source EID are in sync > to be "binding verification". > > The ETR can do binding verification when it decapsulates packets. It doesn't > matter what type of packet it is and it doesn't have to be an ITR to do this > and it doesn't have to correlate with any other cross packet state. > > I am not suggesting this is the best way. We are just discussing options. Yes, agree - the fake ITR sends bogus packets to the selected ETR and that ETR is not applying "binding verification" but instead it does a preview at the packet so that it can inform the ITR of the forthcoming returning packets from the destination EID. ITR and ETR resides in the same box, this feature suggestion is there to buy some time for ITR so it is prepared for what is going to come. I think you had some ideas in this direction but it could be a misinterpretation... > >> - the mapping database has to be installed locally at the xTR, because >> 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... >> 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 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 to a targeted ETR, then the ITR (that is handling the returning packets on behalf of the targeted ETR) can't establish forwarding plane in time. > I call this the "needle in the haystack" problem. And we have had to deal > with this with hardware packet punting for a number of decades. > >> - make sure that the punting resources are higher than the bandwidth >> capacity at the xTR. > > Yep. > >> 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 :-) 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 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 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 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 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. 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. Patrick _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
