On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci <[email protected]> wrote:

> (1) At the ITR
>

I think this presumes that a malicious end-user in the Locator address space
can't simply forge packets and pretend to be an ITR.  It would also rely on
most/all operators of ITRs to configure uRPF or BCP-38 at their site, which
historically has been impossible to achieve for a large enough portion of
the Internet to prevent large spoofed source attacks.


> (2) At the PE router connecting the site's ITR to the service provider PE
>

The PE router may not have routing tables for the given address-family.
 Even if the PE did, to do uRPF on the inner-payload, it would encounter the
same scaling limitations as xTRs.


> (3) At the ETR
>

How can the ETR do uRPF without also being subject to the same mapping churn
problem as an ITR?  It must have access to enough state information to check
all the packets flowing through it, so if under attack, it must have enough
FIB to install many entries from the MS.

Also another, different, problem is that if an ETR doing uRPF has routinely
20k flow cache entries, because around 20k sites are accessing the
downstream hosts, but suddenly a DoS begins at a high rate, it will take
some time for the FIB to become populated with enough of the address space
for the uRPF checks to be successful on most legitimate traffic arriving
from "new sites."  The reason is, for example, if there are 500k total
mappings possible and the FIB can punt and update at 20k/second, for around
25 seconds an initially high, and then decreasing toward zero, portion of
new flows will be dropped because the limit of punts has been reached.  TCP
will simply retransmit but performance of the downstream hosts will appear
to be affected temporarily.  As more negative entries can be installed to do
the uRPF failures without punting, the rate of successful punts, and mapping
FIB installs, for "good" sources will increase.  This assumes there is
enough FIB.

(4) At a firewall router anywhere in the path.
>

IMO this has the same scaling limitation as the ETR.

-- 
Jeff S Wheeler <[email protected]>
Sr Network Operator  /  Innovative Network Concepts
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to