Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

From: [email-masked] (Noel Chiappa)
Date: Wed, 20 Jul 2011 10:14:41 -0400 (EDT)

> From: Patrick Frejborg <[email-masked]>

    > So when the botnet clients are sending their SYN traffic through the ETR,
    > the server replies with an ACK and then the ACK will hit the ITR.
    > ...
    > I'm not an expert in LISP, thus do I miss something here?

Err, I think this is the same 'thrash ITRs with reflected traffic' problem
we've been discussing for a while now? (And that is a real issue - I've gotten
several private email messages of the form 'yeah, that's a real issue - we're
glad someone brought it up so we can think about it'.)

    > if LISP deployment is successful the probability that botnet clients
    > resides at prefix dispersed EIDs increases.

Actually, I don't think it matters whether the source address is an EID or a
'legacy' address - the ITR will still always have to talk to the MR to see if
it's an EID. (The ITR can't rely on simply finding the destination in its local
routing table, and assuming that means it's not an EID, since PITRs will be
injecting routes to EIDs to make LISPed nodes accessible to legacy nodes.)

	Noel

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 21 Jul 2011 10:03:13 +0300

On Wed, Jul 20, 2011 at 5:14 PM, Noel Chiappa <[email-masked]> wrote:
>    > From: Patrick Frejborg <[email-masked]>
>
>    > So when the botnet clients are sending their SYN traffic through the ETR,
>    > the server replies with an ACK and then the ACK will hit the ITR.
>    > ...
>    > I'm not an expert in LISP, thus do I miss something here?
>

Yes, right - but I think there are two use cases in our discussions;
external attack and internal attack scenarios.

In the external attack scenario the botnet clients ACKs might
overwhelm the ITR and this one is hard to mitigate.

The internal attack is coming from an infected endpoint inside the EID
space, it might use different source addresses to avoid a rate limiter
at the ITR. Jeff suggested a L2 adjacency mechanism but I feel that
approach is not suitable for most of the enterprises. These usually
have a security architecture with several security zones and with a
"defense in depth" principle in place, thus there will a bunch of
security nodes/middleboxes between the ITR and endpoints. To mitigate
this risk, the enterprise should install IDS/IDP devices at the L2
segments where there is a risk for infected endpoints.

>
>    > if LISP deployment is successful the probability that botnet clients
>    > resides at prefix dispersed EIDs increases.
>
I believe your statement is correct for the punting issue - I didn't
realize this situation until Jeff brought it up and you spelled out
the details above.

But for the cache trash issue you need to take into account how many
botnet clients might be located at dispersed EID prefixes and how many
entries (positive and negative) they create. An example, after five
years from today, LISP has been deployed and there is a botnet with 2
million clients - 10% is located at dispersed EID prefixes and each
client generates 1-10 entries in the mapping system. To sustain an
attack the ITR should have a FIB of somewhere between 200k - 2 million
entries.

On the other hand, in the current system we have about 350 entries
today - how many entries will there be in that system after 5 years...

Thanks for the clarification and I hope I'm on the same page now

Patrick

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 21 Jul 2011 03:52:07 -0400

> segments where there is a risk for infected endpoints.

Also troubling is that IDS implies a whack-a-mole strategy which is not
practical in a mixed-use data-center environment, where compromised machines
are more common, IDS is not practical, and detection does not happen until
there are actionable abuse reports or serious DoS originated by the
machines.  As you mention, the L2ADJ-based policer will not work for these
networks if the ITR is a more centralized device with layer-3 devices
between the ITR and untrustworthy downstream hosts.

In most of my networks, we would not be able to push ITRs further toward the
hosts.  It is simply not cost-effective for us to have many boxes with large
L3 FIB.  Our typical L3 aggregation box is a Cisco 3750G or Juniper EX4200
-- these are 1RU switches with <= 16k IPv4 FIB and considerably smaller
IPv6.  These boxes can't be a good ITR for us because, especially after
using a lot of FIB for customer routes, they would not even have enough FIB
for a routine working set, let alone survive DoS churn.

Our DFZ routers would work fine as an ITR in a "cache-less implementation"
with today's Internet basically projected onto LISP, but with scaling up
SOHO multi-homed networks that would not be true.  Also, with expected IPv6
growth plus caching (and negative cache entry problem) even *without*
scaling up SOHO multi-homing, they would not work as ITRs.  And the
L2ADJ-based punt/churn mitigation mechanism would not work for this design
since the DFZ router is distant, by L3, from the untrustworthy downstream
hosts.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts