ip-precedence for management traffic

Joe Greco jgreco at ns.sol.net
Tue Dec 29 16:00:57 UTC 2009


> Nope, not joking.  Quite serious about this.
> 
> Glad we agree about the residential customers.  Perhaps that's the first place to start and could generate some interesting lessons.
> 
> Properly dual-homed customers are what I'd lump into the "clueful" category so they are not the ones I'm talking about.  Just the basic customers who have no Earthly idea how all of this magic comes together, and who really don't care or have a need to know.
> 
> New applications, by the way, should not be a problem if they are allowed to adapt to a new networking model.  Innovation flourishes when the status quo changes.
> 
> (I see that Chris Morrow just posted some supportive comments.  Thanks Chris!)

I'm going to skip the "proxy" angle - already addressed by others -
and just think about actual OOB management for a second...

There's nothing that requires you to make management of most of these
services in-band, or in a manner that's accessible to the average user.
On the other hand, IP is a least-common denominator and there is no
guarantee that a protocol has been made easy to proxy.

I realize that the OP was talking about the "Internet management plane"
but the problem may be more general than that.  There are all sorts of
devices that can be managed out of band but shouldn't be accessible to
end users.

As an example, I was disappointed to discover that HP's iLO2 lights out
management implementation is lacking in a variety of ways; for example,
it does not appear to be easy to put all your iLO2 devices behind a
web proxy (Squid, etc) on a private network.  Having the ability to do
that, rather than setting up a VPN gateway, would be nice for allowing
strict access controls to the management of those devices.  To heap on
some more unhappiness, HP apparently didn't actually try their own web
management interface with SSL; it's impossible to generate a proper cert
without mucking around with turning JavaScript on and off to defeat their
poorly-coded input sanity checking...  sigh

But the point is, on one hand, we already have ways to separate the
management of networks from the in-band stuff, and at the same time, IP
is such an enabling thing, it's useful for management as well.  It's
great to be able to use a browser to chat with devices, for example.

If we really envision separating management out, do we use the same
IP protocol for it, to be able to take advantage of existing tools and
technologies like SSL for encryption, etc?

If so, I'd note that we largely have the ability to separate management
into out-of-band networks today, and have had this for many years.

If not, I think the proposal's a non-starter, because then you're
talking about significant re-engineering of lots of things.

Getting back to the OP's message, I keep having these visions of the
castrated "Internet" access some hotels provide.  You know the ones.
The ones where everything goes through a Web proxy and you're forced
to have IE6 as a browser.  For some people, who just want to log on 
to Yahoo or Hotmail or whatever to check their e-mail, that's fine.
However, some of us might want to be able to VNC somewhere, or do
VoIP, or run a VPN connection...  these are all well-known Internet
capabilities, and yet some providers of so-called "Internet" access
at hotels haven't allowed for them.

Do we really want to spread that sort of model to the rest of the
Internet?  All it really encourages is for more and more things to
be ported to HTTP, including, amusingly, management of devices...
at which point we have not really solved the problem but we have
succeeded at doing damage to the potential of the Internet.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.




More information about the NANOG mailing list