First, the good news: so far, the NANOG conference has been very valuable and
content-rich, covering a lot of issues that need to be discussed. For that, I am grateful.
But now, the bad news(?): Maybe it's just me & my paranoia, but do I detect
an inkling of "murk spam" going on with some presentations?
I fully agree with you -- some talks are thinly (or not so thinly) veiled attempts to convince you to buy a vendor's shiny, new solution. There are a large number of reasons for this, and the Program Committee works hard (and I think is doing a great job) to limit the amount of sales pitch but A: there are a limited number of talks and B: many vendors are unable to resist trying to spin their product. I suggest that if you have a topic that you would like to present (and will keep it sales free) you resent it to the PC.
I *do* however disagree with you that this happened in the talks to which you are referring...
Because there seems to be a fundamental misunderstanding, either on my part,
or the part of certain vendors: I'm hear to discuss ideas & freely share
them, and they are here to discuss (it would seem) their products.
Once again, great -- please submit a talk to the PC and they will review it. The PC is always looking for good talks...
Sometimes
both goals coincide, and that is fine...but...
When a vendor at the security BOF starts showing documents that are "company
confidential", and trying to whip up a climate of fear, that we should all
deploy their product in front of our recursive name servers, i get this
funny feeling that I am being "murk spammed".
Hmmm... The vendor that you are referring to provides authoritative DNS for many domains (and, at least some of them I view as "important", meaning that I would prefer a correct response!). Yes, I am sure that he would be happy to have you as a customer and, yes, this is feature that differentiates his company, but I did not get the impression AT ALL that he was trying to sell his service, but rather provide better service to his existing customers, even going so far as to provide free devices to people who run large recursive resolvers. This helps both his existing customers (who, yes, will be more likely to continue using him), but, more importantly helps me as an end user feel a little comfortable that the page that I am getting is the correct page...
Perhaps that is my own perspective (& paranoia?), but I found the CERT
gentleman's call to monitor icmp backscatter on our authoritative
nameservers far more informative -- and open.
But I was disappointed with two vendors and their presentations: the first
had the tactic of saying "DNSSEC is the actual solution" when asked about
why their product would be necessary...completely ignoring the fact that
their proprietary "interim solution" was by no means the only way to prevent
cache poisoning attacks.
I may be mistaken, but I didn't get the impression that he believed that his solution was the only one -- he repeatedly pointed out that DNSSEC is the correct solution and this his solution does not solve all of the problems that DNSSEC would -- however, DNSSEC is FAR from being fully deployed.
Indeed, I would daresay it isn't the best, either
by a BCP perspective, or a cost analysis perspective.
To put a finer point on this, i should say that i found myself discomforted
by a presentation suggesting that I should put their proprietary appliances
between my recursive name servers & the Net, and I am grateful that Mr.
Vixie stood up and said that there are other ways of dealing with the
problem.
Hmmm.. We must have VERY different recollections -- I don't remember him mentioning how much this would cost, other than that he would be give away some to the biggest wins first. Without knowing how much these widgets will be, it is not possibly to do a cost comparison, but don't discount just how expensive engineering time is, and just how hard it is to find competent DNS folks able to deploy something else.
I have chatted with many people about the state of their DNS infrastructure -- many people don't care, many people DO care but just don't have the cycles to properly maintain it, many have weird internal politics around them, and many just don't have the knowledge. Some of these are hard to solve, the lack of knowledge is probably the easiest, so I would welcome any how0-to, etc guides that would feel like writing....
Then there was the gentleman with the DDOS detection/mitigation appliance,
who flipped through several graphs, which were intended to show the number
of each type of attack. It's unfortunate that there wasn't more time for
questions, because I really wanted to ask why "http GET" and "spidering"
attacks weren't listen on their graphs...more on that in a second.
Hmmm, probably some of this is my fault, I am largely responsible for the agenda -- this was my first tie doing this an I suspect that I tried to fit too many talks into too little time. If there had been more time Danny might have covered their collection methodology (but, I need to warn you that that would probably have involved some information that *could* be construed as "This is what differentiates us" and would have been construed as sales, but whatever...). The information that was presented is part of a very well know report that gets published (but in a more executive format) and he (apparently incorrectly) assumed that the BOF audience would already be aware of how the information is collected and some of the benefits and short comings of their collection methodology. Once agin, probably my fault that he didn't have enough time to go though how the data is collected, but if he had, most of the audience would have bored out of their minds and they already know this and the rest would have felt like they were being sold to...
Fortunately, said vendor had a table at "beer and gear", so I was able to
talk with one of their representatives -- and learned that they have just as
much trouble with automatic detection of attacks designed to look like a
"slashdotting"...which cleared up the mystery as to why it wasn't on the
graphs.
Because this is a real problem: anybody, with sufficient knowledge &
preparation can vandalize _anybody's_ network. Showing me a graph that ping
floods happen all the time doesn't impress me -- what would impress me is
going over the actual methods, algorithms (and heuristics?) used in these
attack mitigation appliances.
Ok, now I am confused --- you would like the vendor to stand up (in a NANOG presentation) and say: "Here is our widget, look how shiny it is.. Our device is better than $COMPETITOR because we do X, Y, Z, etc. We use the following heuristics <cough> and other vendors don't </
"? To me this sound WAY more like a sales ploy (and, some of the
other talks were much closer to this....).
Because, the "best" attack mitigation appliance vendor would seem to have
100% of their market, and thus, charge exhorbant prices for their
product(s). When I brought this up with Mr. Vendor, his first reaction was
to point out that the cost was less than a home-grown solution.
Yup... Said vendor does have a large market share -- by explaining how they collect the information they would have had to explain just how much of the Internet they instrument, which to me would have felt very salesey...
When I
raised the question of open source software to do the same thing, his
reaction was to ask: "oh? who's going to write it?"
And that right there would seem to be a bit of bravado, perhaps fueled by a
misunderstanding of the role that FOSS has played on the Net.
Yes, you can build your own attack mitigation solution (either based on OSS and / or from scratch), but there are limitations. Just saying "use OSS" doesn't make a fully formed solution spring into being, there are *large* investments needed in terms of time, effort, resource, scaling, training, lack of support, etc. While you *can* build a router using just OSS tools[0] there is a reason that most don't...
Fortunately -- and again, I am grateful for this -- the ISC was represented
in the security BOF, presenting the SIE concept...as well as what
applications _already exist_ to detect and mitigate various attacks. One
demonstration that blew me away: detecting a botnet being set up for a
phishing attack...and preventing the attack before it even started.
Great, I'm glad you liked that...
So in conclusion, I'll say this: the last NANOG I attended was NANOG 9 --
and i remember that being a more challenging environment for vendors.
Probably the biggest problem discussed back then was head-of-line blocking
on a vendor's switches. _That_ is the kind of content that i have found
valuable, both on this list, and at a conference.
Hmmm, I remember some of these -- and I remember the "Our box does this way better than $OTHER_VENDOR" spin that was always put on this...
And so: If I weren't so knock-kneed in public venues,
I would probably be doing what i would like to call on conference
participants to do: if someone gives a presentation that includes their own
proprietary black-box "solution", I think the best benefit for NANOG would
be to point out alternatives.
Next time, please try and overcome your fear (although, I will happily point out that I haven't -- even saying "sorry, only time for 1 more question" gives me sweaty palms, makes me feel queasy, etc. What helps is to remember just how badly most of the other people here speak and that no-one cares) -- other (sane and realistic) solutions are always welcomed...
-Scott
p.s. sorry for the long post.
W
[0]: OMG, have I just kicked off the "Liinux / BSD as your core router" discussion again?!
