[ipv6-wg] Follow-Up on Niall's talk: Ramond (RA Monitoring Daemon)

Hi Enno and list,

I'll skip my comments on the contexts where ramond is useful or not, as
Tim has already pointed that out, but there are a couple more aspects in
your posting I consider very important (and unsuitable for a quick reply
from a conference auditorium):

Enno Rey <erey at ernw.de> writes:

> It would help against accidentally brought-in/fired-up systems
> emitting rogue RAs (which, admittedly, in quite some networks
> constitute a bigger risk than said attacker)

That's the point: It is a tool for dealing with BYOD style ("guest" or
whatever) networks where you have rather limited control over the
devices being connected and your main concern are broken configurations
on guest devices rather than malicious attackers.

> but that threat/risk can easily be addressed with stuff like
> "router-preference high" (or its equivalents) on the infrastructure
> side. and this type of stuff/mitigation is available to _most_
> networks in the interim.

That approach has the drawback that it doesn't let you prioritize your
default routers.  That's not an issue if you run a first hop redundancy
protocol like VRRP/HSRP/CARP/..., but not everybody does that.

Additionally, it doesn't provide two features I consider rather useful:

If you hook up the ramond logging output to your monitoring, then you
can keep an eye on the relevance of this issue in your particular
networks.

And if you actually use a proper response script so that offending
devices are disabled, by shutting down the switch port in question or by
locking the matching entry in your WiFi's Radius DB, you can actually
make people contact your first level support/conference NOC/whatever so
their misconfiguration can be fixed by people who know---which is of
course For the Good of the Internet in General[TM].

> more importantly I'd like to ask you another question: how many
> environments do you know which have a "mature network incident
> response process" which would have to be followed once ramond "alerts
> $ADMIN of $VIOLATION"? unfortunately there's usually a strong
> correlation between "lack of appropriate tools" and "lack of process
> maturity" so those environments where ramond could make sense will not
> be able to make reasonable use of it anyway.

There's a third aspect in here that you make assumptions about: What
degree of authority does $ADMIN have to deal with $USER, or more
specifically, with $DEVICE?  

If you run an 802.1x managed network with devices that you control
through some sort of orchestration tool (puppet, cfengine, or whatever),
that's a completely different situation than a $COFFEESHOP WiFi where
people show up, turn on their own misconfigured devices, expect to get
half an hour's worth of work done before they leave again, and your job
is to keep them happy without.

In a coffeeshop style environment you can define all the processes you
like, but if the business case is not to step on any customer's toes
(unless they intentionally did something seriously malicious and you can
produce legal grade evidence and whatnot), your options are extremely
limited.

> In general, the "detection/reaction type of tools" (as opposed to a
> "prevention-oriented" security approach) haven't proven their
> usefullness too much in the past.

If you have RA guard or similar available, by all means use it.  But
some people don't have that option.

And beyond that, I think you still remember that I strongly promote to
segment networks wherever feasible (and actually that's one of the
reasons why I do that multicast routing presentation at the
IPv6-Kongress in Frankfurt next week).  But sometimes that's not an
option either, and that's where the ramond becomes rather useful.

Which brings us back to the beginning of the thread: I don't know
Niall's setup itself, but from similar ones I've seen elsewhere, he
might well run an environment where ramond is extremely useful.


Cheers,

    Benedikt

-- 
Benedikt Stockebrand,                   Stepladder IT Training+Consulting
Dipl.-Inform.                           http://www.stepladder-it.com/

          Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/