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. 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). - 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 - 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 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). - make sure that the punting resources are higher than the bandwidth capacity at the xTR. 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. Patrick _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
