Juniper's artificial feature blocking (was legacy /8)

Sun Apr 4 21:07:17 UTC 2010

On Sun, Apr 4, 2010 at 2:33 PM, Michael Sokolov
<msokolov at ivan.harhan.org> wrote:
> feature blocking seems to negate that.  I mean, how could their
> disabled-until-you-pay blocking of "premium features" be effective if a
> user can get to the underlying Unix OS, shell, file system, processes,

Probably signed binaries, veriexec with a signature list of allowed
executables,  proprietary system daemons, hardware drivers, and
read-only filesystems.  Protections may be in hardware, and you do not
have source code.   You can in  JunOS  "start shell user root"  as
much as you like and get a root shell on various platforms,  but some
functions are limited.

Using a 'key' is  slightly less of a network operator nightmare than
having  100  featuresets, and thousands of  mystery meat  images  for
the same software version.   At least you don't need to go buy a new
software image, and do a full upgrade procedure to gain feature
access.

Applying a key seems less risky and less likely that downtime is
needed,  when you decide that you now need this feature.

> etc?  Wouldn't such access allow smart users to unblock whatever feature
[snip]
Perhaps,  but that would be tedious and probably waste a lot of user
time, which can have higher cost than buying a key. The warranty might
be voided, and the installation wouldn't be supported anymore, new
bugs can be discovered. Upgrades can be required.

Even CPU manufacturers are noted for artificially restricting features
in software (such as VT or hyper-threading,  even artificially
disabling cores).  Not all buyers of L3 switches need or want to pay
for that, and there is more $$$ to be made from those that do.

The manufacturer can either segment their market by not offering
OSPFv3 on the device, release a new higher-end hardware model for V3
support at 10x the cost,  or offer an add-on license,  as an
incremental upgrade to a larger number of users  (including the
installed base).

--
-J