On Sun, Jul 10, 2011 at 6:42 PM, Dino Farinacci <[email protected]>
wrote:
or people are too busy to respond. But we, the LISP authors take
input very
seriously. I can speak for myself, we do not want to ignore the
mailing
I suggest you read my post, linked below, discussing cache management
vulnerabilities, and a way to improve upon them. Darrel Lewis is the
only person who has showed any interest in this at all, and there has
Oh so you did get a response. You gave the impression you were ignored.
been essentially zero public discussion of it. I have also swapped
email with the authors of the lisp-threats draft, who believe this
problem warrants precisely one vague sentence.
Have you looked at the latest draft. We have added more in this area.
http://www.ietf.org/mail-archive/web/lisp/current/msg02949.html
You can imagine how my view of LISP as a pet project, consuming vendor
personnel / resources on something which may have, at best, VPN
application, came about. This is a very obvious problem with a great
deal of history -- many of the people I see working on LISP have been
around since flow-cache routing was popular, and unpopular, certainly
including yourself. Some have not been and have yet to learn some of
the lessons from the 90s.
An ITR does not maintain a flow-cache.
A LISP cache can get as large as a BGP cache if the site is sending to
every destination in the Internet. Probabilistically that won't
happen. But routers do have finite memory so even today the BGP cache
can exceed the physical capacity of the device.
The problems of the 90s are much different that what is going on
there. I was there.
With a on-demand cache you can limit who you talk to. With a BGP
cache, you could do the same thing. There really is no different. Any
implementor experienced in the art, will tell you the same resources
are used and the same table management techniques would have to be used.
The size of the LISP cache will usually be less than or equal to a BGP
cache. When comparing apples to apples it is the same. If you think
the LISP will have more granular prefixes, say you put host routes in
it, it will be as large as BGP with host routes. The reason I am
going this way is to indicate that any data structure can be abused.
Many researchers have looked at ITR caching and there are papers
published
that discuss pros and cons.
An academic paper examining 20k macro-flows toward ETRs is far from
Internet-scale, and is in my opinion not useful. Perhaps I have not
Okay, so put 350K in it. What is your point. Give me a technical point
and not that we didn't make the test large enough.
read some more recent work on this topic; but all the LISP-specific
"research" I've seen in this area is nothing more than C.V. padding.
It can easily be shown that an ITR must have a huge FIB, compared to
FIB sizes today, in order to operate normally under a DDoS designed to
It can be easily shown that it doesn't. And this week it will be
publicly presented that the FIB cache can be over-subscribed when LISP
is used.
exploit the vulnerable negative mapping cache, which must be able to
install same mappings into FIB to guard the control-plane against
excessive punts, or avoid simply dropping punts which would cause
resolution of mappings for positive/good destination mappings. Again,
see my mailing list post.
Punting will always be a problem until data-planes can create state.
But it is not a show-stopper.
We are all wrong and we are all right. Let's start the technical
discussion.
I welcome such discussion. LISP is very much designed from an
"eyeball" perspective, with the intent of delivering increased traffic
engineering capabilities, and multi-homed connectivity, to SOHO-type
networks with less expensive hardware. The impact of this is, quite
simply, a shift of cost to the datacenter / content network, or a
shift of complexity to the actual content server, which may, and
probably should, become an ITR itself to avoid scaling problems with
ITRs in mixed-use datacenters.
Right. It is time to experiment with state in a few places rather than
everywhere.
Making it cheaper and easier to multi-home a SOHO network must
ultimately have the affect of dramatically increasing the number of
such networks which are multi-homed. Not only is current LISP work
viewing the number of destination networks as substantially fewer than
those which already exist today -- it does not even attempt to account
for this growth.
Yes, but that growth will not affect the core capacity.
It certainly does not account for the possibility of DoS designed to
exploit cache churn. Even without any significant increase in the
With the mapping database, we can push back attacks to the source.
That has only been tried with source-quench for congestion control.
number of destination networks today, and if you assumed each ASN had
only one ETR (obviously that will not be true), if LISP were really
deployed widely across the Internet, an ITR would need about 500k FIB
slots to manage just 50k destination networks, given current IPv6
I don't know what you mean, but if your definition of a 'destination
network' is either a single or multi-homed site, then the FIB would
hold 50K entries.
addressing strategy. An ETR intending to check the origin of traffic
before admitting it to the network will encounter a similar problem.
Should a router today check origin before admitting traffic? If not,
why not? Why does LISP require it where a CPE router today not? And by
the way those routers as well as routers running LISP to run with uRPF
configured.
These problems are obvious. Improvements can be made, but this has
They are problems but not the end of the world. Why you think they are
serious I am not sure.
not been done, and as far as I can tell, it has not been seriously
discussed. A test network is certainly useful to discover emergent
Have you been to the LISP working group meetings? This has been
discussed many times.
problems and implementation issues, but from my perspective, feeling a
little proud about having a pilot network deployed while gaping
protocol design problems are not being addressed is a deeply misguided
waste of time and resources. Scaling problems with ITR caches can be
shown with simple arithmetic -- they do not even require a working
router to discover.
Then show me the simple arithmetic.
Dino
--
Jeff S Wheeler <[email protected]>
Sr Network Operator / Innovative Network Concepts
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
