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

From: [email-masked] (Noel Chiappa)
Date: Mon, 18 Jul 2011 15:21:45 -0400 (EDT)

> From: Jeff Wheeler <[email-masked]>

    >> the assertion that for most sites (even things like very large
    >> universities, etc), their 'working set' (of nodes they communicate
    >> [with]) .. will be much smaller than the network as a whole?

    > Why would you assume this to be true if LISP also promises to make
    > multi-homing end-sites cheaper and easier, and independent of the ISP's
    > willingness to provide BGP without extra cost? 

Please read carefully what I wrote.

To start with, why will multi-homing of more sites elsewhere on the network
increase the number of nodes the _average_ site communicates with
(i.e. increase the sites of that site's 'working set')?  The former is purely
a technical issue of how things are wired underneath (where the users cannot
see them); the latter is driven by users access patterns. There is no
connection between the two that I can see?

Having answered that, where is the problem with my statement? Actual packet
traces from several large sites show it to be true in those traces. Do you
have any data which shows otherwise (for many/most sites)?

    > You see, if every SOHO network and "power user" can suddenly become
    > multi-homed without spending a great deal of money on a powerful router
    > and ISP services which support BGP, many of these networks will do so.

Yes. And?

    > unless you wish to ignore DoS (which you seem to want to do very badly.)

Where did I say that? Please don't put words I not only never said, but have
no intention of saying, in my mouth. 

	Noel

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 18 Jul 2011 17:13:27 -0400

> increase the number of nodes the _average_ site communicates with

Because you will benefit less from aggregation of many users into a
single unit of state information -- a CIDR route entry in the DFZ --
the average working set increases.

>    > You see, if every SOHO network and "power user" can suddenly become
>    > multi-homed without spending a great deal of money on a powerful router
>    > and ISP services which support BGP, many of these networks will do so.
>
> Yes. And?

That is what causes the increase in number of end-sites, and as a
result, the larger working set.

>    > unless you wish to ignore DoS (which you seem to want to do very badly.)
>

If you don't want to ignore DoS, then you should concern yourself more
with ensuring that it is practical for an xTR to carry all of the
possible mappings and not rely on a cache at all.  That is what is
needed for a targeted xTR to be "DoS proof" to the same degree that
common BGP routers are today -- or at least, the xTR must be able to
churn its cache at a high enough rate that an attack would saturate
the available Internet connection.  SOHO CPE, for example, is more
appropriately designed this way.

On Mon, Jul 18, 2011 at 4:07 PM, Noel Chiappa <[email-masked]> wrote:
> I definitely agree with this, and I've been pondering it a bit over the
> last couple of days. (BTW, do you forsee this being an issue for IPv4 and
> IPv6, or 'mostly' an IPv6 issue, because of the very large address space?)

The problem is worse with IPv6 because of the holes in the address
space between active allocations.  The larger address space is not, in
itself, the cause of the negative cache problem; but the way holes are
handled by the MS protocol.

For IPv4, the holes are fewer and more easily represented, so it is
not conceivable that LISP will require substantially more FIB than the
BGP DFZ, even for a worst-case scenario such as a DoS specifically
exploiting the negative mappings.  You can calculate this if you wish,
by building a Trie of the current DFZ and counting all empty node
pointers as negative mappings.  You'll get a number that is bigger
than zero (as if the router did not need a cache) but it won't be 10x
bigger like for IPv6.

> At another level, one can take advantage of the fact that one has to 'bounce'
> traffic off a machine inside the site to attack the ITR mapping mechanisms; if
> one can 'harden' the host against such attacks, then you can kill the problem
> that way.

If you could do this, certainly it would help the ITR for the case of
inbound attacks.  However, the same problem exists for ETRs if they
are going to do any kind of source address validation.  I do not know
how the LISP community envisions this working, but I am fairly sure it
will be affected by the same scaling limitations -- the ETR must be
able to look-up entries from the mapping system to validate the source
address of packets (even loosely) and thus it will have a churn
problem.

> I dunno, I'm not sure that this is an insoluble problem - _if_ one puts ones
> mind to solving it. I agree that it is an important issue, though.

It might not be unsolvable.  I think the efforts of LISP developers
should be focused on this issue, as it is really the only huge,
show-stopping issue I see that makes it impractical for Internet-scale
use.  If this problem can be overcome, LISP has a great potential.  I
like the concept of LISP more than is apparent from my postings -- but
I also live in the practical world where I see > 10Mpps DoS attacks
every day.

On Mon, Jul 18, 2011 at 4:21 PM, Joel M. Halpern <[email-masked]> wrote:
> Fundamentally, if a subscriber DoS' himself, and denies himself service,
> then he hurts himself.  So?

Of course this is true, but imagine that a malicious program is
installed on one subscriber's PC behind an ITR that serves ten
thousand subscribers (nominal.)  You don't want service for all those
subscribers to be disrupted because of one infected machine.

The same problem is present in mixed-use data-center networks, where
there are commonly thousands (at least) of servers self-managed by
thousands of different customers.

> Now, there do need to be ways that this is prevented from hurting the rest
> of the system.  But there are already specified rate limits.

I think scaling up the mapping service infrastructure should be very
easy.  I am truly not worried about that in the least.

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

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 19 Jul 2011 10:16:19 +0200

On Jul 18, 2011, at 23:13 , Jeff Wheeler wrote:

[snip]
> like the concept of LISP more than is apparent from my postings

Happy to hear that you changed your mind from 
"I personally believe LISP is a horrible idea that will have trouble scaling up,..."
in http://mailman.nanog.org/pipermail/nanog/2011-April/035131.html

Luigi

> -- but

---

From: [email-masked]
Date: Tue, 19 Jul 2011 07:30:28 -0400

DoS attackers  will discontinue doing DoS attacks, provided that a DoS attack fails to overload the attacked user.

Cascade Tree Routing would limit the number of service requests to the pre-assigned degree of cascading.

Cascade Tree Routing would do so in case of multiple download requests within a particular time window, no matter whether these are honest or malicious and would BTW work like state-less Multicast.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Luigi Iannone <[email-masked]>
An: Jeff Wheeler <[email-masked]>; [email-masked]
Verschickt: Di., 19. Jul. 2011, 10:16
Betreff: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

[snip]

Luigi

 -- but

=
 
_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp