[j-nsp] Juniper as a route-server

[Guy Davies]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----Original Message-----
> From: Richard A Steenbergen [mailto:ras@e-gerbil.net]
> Sent: Thursday, December 05, 2002 5:26 PM
> To: Guy Davies
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Juniper as a route-server
> 
> 
> On Thu, Dec 05, 2002 at 05:00:53PM -0000, Guy Davies wrote:
> > 
> > This is kind of using the Juniper as a server rather than a 
> router.  That's
> > not really what it was designed for.  It certainly doesn't 
> do BGP the way
> > Route servers do (e.g. hiding its AS, setting next-hop to 
> someone else,
> > creating views of the routing table based on routing 
> policy).  Route servers
> > are a somewhat specialised function which isn't really 
> appropriate for a
> > router.
> 
> Sorry if I was unclear, I meant a route-server as in a diagnostic box
> which has a full iBGP mesh, where anyone can connect to look at your
> routing policies and test connectivity (e.g. route-server.exodus.net,
> route-server.ip.att.net, route-server.cerf.net, route-server.gblx.net,
> etc etc etc).

Ah, you mean like a collector.  That function can be performed.  However,
the statement regarding passwords for accounts still remains.  In general,
it's a good thing to have individual accounts for those wishing to access
the box but it's perfectly feasible to create a group account to which lots
of people know the password.

> However, you are right that it is indeed a server and not a 
> router. Yet 
> another function which could be better served if Juniper 
> would legitimize 
> that little fruit you put in your martini. :)
> 
> > How can I put this?  No, no, no, no, no!  There is no way 
> to log into
> > the box without an account and this is, without any doubt, 
> a *very* good
> > thing. Even if you have an account, if it has no password, then you
> > can't get in (unless you've configured an SSH key in which case, the
> > relevant user can login with no prompt using ssh).  If 
> you're using a
> > script, then you just need to make sure that you force the 
> script to use
> > the required user in SSH.
> 
> Nonsense, there is nothing wrong with intelligent operators 
> having the 
> power to elect a direct login to a specific account without a user or 
> password. Crisco can do it, why Juniper would choose to 
> under-power their 
> authentication policies is beyond me.

That's fine, if you give them enough rope to hang themselves....  IMHO, that
is a gross security risk.  As I say, that's just my opinion.  I think
describing it as nonsense is unfair.  You just hold a different opinion
which I think exposes you to unacceptable risk.  We clearly have a different
opinion of what is an acceptable risk so let's leave it at that :-)

> > There's no concept of "enable" in JUNOS.  An account either has
> > administrative privileges, or it doesn't.  It's a feature 
> of each account
> > based on the class.
> 
> Precisely, this creates a lack-of-feature, in that since you 
> can't change 
> users or privileges while connected to the CLI (short of 
> going to a shell 
> and su'ing, which isn't something I'm prepared to let the world have 
> access to), it is much more difficult to run public services box.

Why would you want to change a users privileges while they're connected to
the CLI?  You either want the user to have access to particular functions or
you don't!  You have a great deal of flexibility in setting classes to which
you can assign users, each of those classes having different subsets of the
total functionality.  It's certainly more flexible than the fixed number of
"levels" available with other vendors' software ;-)

> > I suspect that quit or exit are default commands that 
> cannot be turned on or
> > off.  Since you're kind of screwed if you can logon but 
> can't disconnect or
> > can go down the config tree but can't get back up it to the root ;-)
> 
> Well, apparently you can turn it off at any rate. It's there 
> if I don't 
> deny anything. The documentation covers permissions for 
> "quit" from config 
> mode and "quit" from the shell, but not "quit" from the box. 
> I'm guessing 
> its an oversight in that noone ever ran it with an explicit 
> allow, deny 
> the rest configuration, but if there is something I'm doing 
> wrong feel 
> free to point it out. :)

Not sure...

Guy

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0 (Build 349) Beta

iQA/AwUBPe+OqY3dwu/Ss2PCEQJDBgCeKyTa9loa2mLnr74fVJ64yUuo2qMAoLFX
EqwTfFarpVTJCYs1jgEMCzRo
=bhby
-----END PGP SIGNATURE-----


This e-mail is private and may be confidential and is for the intended
recipient only.  If misdirected, please notify us by telephone and confirm
that it has been deleted from your system and any copies destroyed.  If you
are not the intended recipient you are strictly prohibited from using,
printing, copying, distributing or disseminating this e-mail or any
information contained in it.  We use reasonable endeavors to virus scan all
e-mails leaving the Company but no warranty is given that this e-mail and
any attachments are virus free.  You should undertake your own virus
checking.  The right to monitor e-mail communications through our network is
reserved by us.