DNSMON visualisation delay
Dear DNS Working Group, At RIPE68 we were asked to "send an email to the mailing-list about advantages and disadvantages of delayed and non-delayed versions of DNSMON [visualisation], specifically related to the management of the software and the ongoing maintenance of the legacy systems that you want to retire". As many of you know, the old DNSMON service had an artificial delay of a couple of hours for visualising the incoming data, for everyone except a specific "DNSMON customers" group. With the changes to the service model as of 2013 there is no good definition of "DNSMON customers" any more. Also, the current DNSMON implementation does not apply any artificial delays, which in practice means all data points show up in the graphs within 10-15 minutes. As Daniel projected a few days ago, we see some realistic options regarding this visualisation delay: === 1. No changes to what the service offers now; ie. graphs will show results with minimum delay Development effort: none Pro: simplest solution Con: this is perceived by some to be "helping potential attackers" by making it easy to observe the effects of an attack on the DNS infrastructure === 2. Introduction of an artificial delay to *all* users, regardless of NCC member/non-member, or login status (known an anonymous users) Development effort: minimal (est. couple of developer days) Pro: not helping potential bad guys monitoring the zones/servers in real time Con: not helping the good guys monitoring the zones/servers in real time either === 3. Introduction of an artificial delay to users in general, except for RIPE NCC members. Authentication is done by RIPE NCC Access (Single Sign-On), authorization is controlled by the existing LIR portal mechanism. Development effort: minimal (est. couple of developer days) Pro: RIPE NCC members have early access to visualisations, others don't Note: the current number of SSO account belonging to RIPE NCC members is ~24000 Note: we may or may not help the attacker, depending on whether (s)he is a member of the RIPE NCC or not === 4. Introduction of an artificial delay to users in general, except for a specially designated DNSMON customers (zone operators) group. Authentication is done by RIPE NCC Access (Single Sign-On), authorization is controlled by a vetting process managed by the RIPE NCC. Development effort: moderate (est. more than a couple of developer days) Con: administration overhead is non-trivial -- we'll have to establish and keep tracking who is in the privileged group and who isn't; with people joining/leaving organisations this could be tricky and diverge from reality. Pro: members of the special group have early access to visualisations, others don't Note: people in this special group can come from organisations which may or may not be RIPE NCC members. Note: we may or may not help the attacker, depending on whether (s)he is a member of this group or not Please give us guidance about your your preferred solution by replying to this mail to the list. Regards, Robert Kisteleki RIPE NCC
[With no hat on my personal head] I prefer option 1. I could live with option 3 if a large number of people consider it necessary. Option 2 should not be chosen because it makes the dnsmon visualisations much less useful in dealing with incidents. Option 4 has obviously been invented by the "complications department". It will do nothing but waste considerable effort by both the RIPE NCC and the community. Daniel
My Preference is for option 1. I think option 2 would do more damage then good. Option 3 and 4 both seem like a waste of time and effort. The perceived threat is from a technical audience, as the underlining measurement data would still be available, in real time, it would be trivial for such an audience to make use of it. Furthermore as the visualization is all client side they could mirror the web page and run it locally with more recent data (something i would consider doing if option 2 was implemented) John
Robert, Replying to an old mail, but I suppose that's okay. :-P On Tue, 10 Jun 2014 22:11:54 +0200 Robert Kisteleki <robert@ripe.net> wrote:
=== 1. No changes to what the service offers now; ie. graphs will show results with minimum delay
Development effort: none
Pro: simplest solution
Con: this is perceived by some to be "helping potential attackers" by making it easy to observe the effects of an attack on the DNS infrastructure
Yes please. As far as using DNSMON as a tool to measure the effectiveness of attack, anyone able to create a DDoS can use their attack hosts to measure the success of their attack as well, in real time, so that doesn't make much sense to me. (I admit that other types of DoS might benefit from this telemetry - for example someone probing the effectiveness of a newly-minted 0-day exploit.) Operationally any kind of sign-on requirement is a hassle. It means that half the people that get an internal e-mail with a link to a DNSMON graph aren't going to be able to see it, and many of the others are going to have to dig around in wiki's and old e-mail to find credentials. It means I can't paste a link into a chat with someone who doesn't have DNSMON access but could help me with the problem. Bah, humbug. Cheers, -- Shane
participants (4)
-
Daniel Karrenberg -
John -
Robert Kisteleki -
Shane Kerr