RE: Proper authentication model

From: []On Behalf Of
Iljitsch van Beijnum
Sent: Wednesday, January 12, 2005 6:25 AM
To: Gernot W. Schmied
Cc: NANOG list
Subject: Re: Proper authentication model

>> True out of band management networks are very hard to
build and very
>> hard to use, and you run the risk that you can't get at your stuff
>> because the management network is down.

> IS-IS can be highly recommended for true out of band
management, it is
> reachable when IP goes down the drain entirely.

To me, true "out of band management" means that the
management traffic
doesn't flow over production links. You are right that IS-IS can
continue to function when IP is confused (although with integrated
IS-IS OSI will probably be just as confused as IP). But IS-IS isn't a
management protocol, of course. :slight_smile:

Out of band management isn't telnetting from your desktop to
the serial port.

Mgmt and surveillance is the Bellcore standard for out of band.
It means your M/S is not riding your customer or public networks, and
it's physically seperate. Yes, this is the cadillac method, but the
only way to support five nines IMHO.

If you have 3 sites and they're interconnected via an OC3
and the internet, you would also have 2 frame or ppp circuits
seperately connecting the terminal server network. You'd do the
different path, different provider, etc. on these circuits.

The ts' would be connected to the hub. If that failed, or the machine
was DOA, serial port. A TS may have a modem at each site for the
hail mary connection.

IPv6 is also very useful in providing non-IPv4 management.

I always knew you could get deer meat from a deer.

You mean you'd *request* a different path from different providers.

That's not the same thing as getting paths with no points of failure in common. How many times have you seen an OC3 service bought from one provider share the same conduit, or the same piece of fibre as a DS1 frame-relay service bought from a different provider? Often enough to post paranoid rantings to NANOG, in my case.

In the past I have been attracted the idea of console servers with GPRS modems in order to eliminate local-loop shared fate (since there is an argument that the amount of shared infrastructure in two apparently separate services will reduce dramatically the further you get away from the service delivery point). However, the colocation centres where GPRS coverage is good enough to use in any serious way are probably the ones with microcells installed within them, which presumably use the same fibre and the same conduits as everybody else to haul packets out of the building.


Recently I've been doing this by tunneling over ADSL circuits from the
local telco. At around $60 per month per location with static IP
addresses it's cheap. Since the tunnels go between two ADSL lines,
they're limited to circuits' 128Kb/s upload speeds, but that's generally
ok for management traffic.

I've also been connecting bastion hosts to the DSL lines. This way, all
that's required to get into the OOB network is Internet connectivity
through some other network, rather than having to hunt around for a POTS
phone line to plug a modem into in an emergency.

Obviously, if you are the local telco this isn't really out of band, but
works well for others who aren't sharing the local telco's infrastructure.

Is it as secure as having your own diverse-path management network of
private point to point circuits? Probably not, but with sufficient
firewalling and encryption on the tunnels, it's good enough, and cheap
enough that it's possible to talk ISP owners into paying for it.