> On Mon, Jul 25, 2011 at 4:35 AM, Jeff Wheeler <[email protected]> wrote: >> On Sun, Jul 24, 2011 at 2:14 PM, Dino Farinacci <[email protected]> wrote: >>> >>> How about a simpler solution where an ITR at a site does not accept any >>> UDP 4341 packets? So when a host that wants to spoof a source-EID with a >>> valid RLOC in the outer header (so the uRPF check succeeds), can be caught >>> by an non-compromised ITR. >>> >>> Routers today can do this by uRPFing solely on the EIDs and since the RLOC >>> belongs to the ITR itself, anyone at the site originated a packet with that >>> RLOC will uRPF fail. >> >> I do not understand how this is helpful. Perhaps you could give an example >> of how this would work if the Internet were in a transition state, with both >> many LISP sites, and many "legacy" sites? > > Me either.
I was focusing one case at the moment. That was the one that Jeff brought up. It was a compromised host in a LISP site with non-compromised ITRs. This case can be solved. For your reference to "transition state", there isn't this same issue on a PITR because it receives and forwards packets from non-LISP sites, where there is one IP header in the packet, and the source address is subject to uRPF and forwarding rules as it is today. > 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? > - 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. > - 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. > 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. 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. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
