[Discuss] Cisco's IOx architecture

[tmetro+blu at gmail.com (Tom Metro)]

Daniel Feenberg wrote:
> Tom Metro wrote:
>> Is running applications on your router really such a good idea?
>
> I don't imagine they expect users to run SQL or Word.

Actually the article I quoted mentions hosting a database on the router
several times, though I chalked that up to speculation by the author.


Jerry Feldman wrote:
> I think that the ability to run applications in a router is not a bad
> thing per se. For instance, running a mail scanner can block some
> content at the router level.

That sounds like something you might want on a border device. The idea
being to stop malware at the network edge. But mail scanners tend to be
heavy-weight, somewhat CPU intensive, and are constantly being updated.

Even though it seems like something appropriate to be on the router,
there's not really any good reason for it to be there. Port forwarding
SMTP connections to your DMZ where a server performs mail scanning is
likely to be low risk with respect to that malware getting onto your
LAN, yet makes your router setup simpler.

Perhaps the thing that is driving this multi-purpose router idea is the
success of "Unified Threat Management" appliances, that combine router,
proxy servers, and mail scanners into one box. Popular with small
businesses without an IT department, but probably not the best security
model.


Peter (peabo) Olson wrote:
> A router should be a router.  Allowing applications to run on it invites
> serious security risks. ... It is a truism that an attacker cannot 
> attack a program/feature which isn't installed on the victim.

Right. The other reason in favor if keeping the router environment
simple is that there is less noise clouding the picture of what is
happening on your router. For example, if you are closely monitoring the
process table, a narrowly focused appliance will show virtually no
change over time, so anomalies will be easy to spot.

Another is that the simpler you can make your router OS, the more
practical it is to run it from a read-only file system, making it less
prone to malicious alteration.


John Abreau wrote:
> ...boot a minimal Linux system, establish the network, routing, and
> firewall rules, then halt the system without powering off and without
> disabling the networking. A vestige of the kernel would remain
> running in memory, with no disk, no I/O other than networking, pretty
> much all kernel modules unloaded except for networking.

I'm sure many of us have experienced a version of this: your Linux box
crashes, won't do anything, but still responds to pings.

A neat idea, but clearly you're not going to get a user friendly web UI
to control it, so not practical for the consumer market. In fact it
isn't clear how you'd control it at all, other than perhaps doing
something like putting the firmware on an SD card and using an
application on a host computer to alter the firewall settings by
manipulating config files in the init file system. So basically any
settings changes require shutting down your router.


> ...halting meant that the cpu was in a tight busy loop...

Well, that would just needlessly generate heat. (Modern CPUs do support
an actual halt instruction where they will sleep until the next
interrupt occurs, but that's not really relevant to this approach to
router design.)

That aside, I don't see why this couldn't be done by simply having a
super minimal execution environment: a custom built kernel stripped of
all unnecessary drivers, a paired down init fs, and no root fs.

 -Tom

-- 
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/