Experts,
what is the general opinion of using ipp 7 'network control' for
management traffic like: telnet ssh snmp .....
The idea is that ipp 0 1 2 3 4 5 are used for user traffic
ipp = 6 is used by default by routing protocols like BGP, OSPF, LDP ...
this leaves out only ipp 7 for management traffic, on the premise that
routing and management should not share the same queue and
resources.....
Thanks,
Luca.
Management-plane traffic should be sent/received via your DCN/OOB network, so that it's not competing with customer traffic nor subject to network partitions or other disruptive events. It should not be co-mingled with traffic on the production network.
Agreed, it's very important to have a management network that is reachable while you are under ddos or some kind of mess you or someone else've created. Often having something like an ADSL like connection will save trips to colo and will give you nice abilities to work on stuff when combined with serial management tools.
Mehmet
One note on this :-)..
Some time ago, a friend of mine worked in a carrier that had dialup modems for out-of-band access ('lights-out, end-of-world' recovery)
They kept the practice in a new NGN Class4/5 replacement..
Detail, the dial-up line went over the NGN..............
Totally out of the box, but here goes: why don't we run the entire Internet management plane "out of band" so that customers have minimal ability to interact with routing updates, layer 3/4 protocols, DNS, etc.? I don't mean 100% exclusion for all customers, but for the average Joe-customer (residential, business, etc., not the researcher, network operator, or clueful content provider) do they really need to have full access to the Internet mechanisms (routing, naming, numbering, etc.)?
We already provide lots of proxy services for end users, so why not finish the job and move all of the management mechanisms out of plain sight?
Marc
I hope you're joking. If not, I have two questions: how can this be done, and what will the side-effects be?
Take BGP, for example. The average residential consumer doesn't need BGP, doesn't speak it, and has no real ability to interfere with it, so there's no problem. But a multihomed customer *must* speak it. Perhaps you could assert that their ISPs should announce it -- but why trust random ISPs? Is that ISP 12 hops away from you trustworthy, or a front for the Elbonian Business Network?
As for side-effects -- how can you proxy everything? Do you know every application your customers are running? Must someone who invents a new app first develop a proxy and persuade every ISP that it's safe, secure, high-enough performance, and worth their while to run? It's worth remembering that most of the innovative applications have come from folks whom no one had ever heard of.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Totally out of the box, but here goes: why don't we run the entire Internet management plane "out of band" so that customers have minimal ability to interact with routing updates, layer 3/4 protocols, DNS, etc.? I don't mean 100% exclusion for all customers, but for the average Joe-customer (residential, business, etc., not the researcher, network operator, or clueful content provider) do they really need to have full access to the Internet mechanisms (routing, naming, numbering, etc.)?
We already provide lots of proxy services for end users, so why not finish the job and move all of the management mechanisms out of plain sight?
I hope you're joking. If not, I have two questions: how can this be done, and what will the side-effects be?
Take BGP, for example. The average residential consumer doesn't need BGP, doesn't speak it, and has no real ability to interfere with it, so there's no problem. But a multihomed customer *must* speak it. Perhaps you could assert that their ISPs should announce it -- but why trust random ISPs? Is that ISP 12 hops away from you trustworthy, or a front for the Elbonian Business Network?
I was going to mute the thread, but.... So for just routing protocols
(assume we've already turned off snmp/ssh/telnet/sftp/tftp/etc
'management traffic' to a device) for BGP one 'easy' solution is to
have your router only listen on configured addresses, implement the
existing bgp security features (GTSH, filtering, iACLs, etc). Arguably
this is doable today, it's not 100% OOB, but you COULD model it a
little more closely to the TDM world and steal some bw from each eBGP
link for just eBGP (say a frame dlci with CAR, or perhaps a sonet/tdm
channel, or an atm PVC with a CAR). Of course, we can't seem to do
simple bgp filtering, so...
For your IGP things get more 'complex', there is some faith that a
link's behaviour and health is judged by what the IGP itself sees on
the link. If you remove that link from the IGP's view how can the IGP
accurately judge health and add/remove that link from it's database?
There was some decent thought put into this proposal in ~2001/2002 ...
a lot of the time (then) it was simpler to say: "Why not do something
like SS7 for the internet?" (not the best analogy, and I'd rather not
fixate on that particular thing anyway)
-Chris
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!)
Marc
I actually proposed this (bounced it off Paul Mockapetris and Dave
Roberts at the time), and we did it for our internal routing in the
co-lo/hosted apps, when I was CTO at American Digital Network
(1996-1998). Basically, SNMP and our IGPs as well as IBGP rode a totally
private RFC 1918 network that had higher priority at layer 2 if it was
on the same physical (always a different VC) circuit. For Ethernet, we
used a separate layer 2 network for this internally. If we exposed any
IGPs to clients, it was on a per link basis. We also had a hosted
firewall service that was provisioned on a per-Radius profile for ISDN
clients where the "routing" was handled by some layer 2 tricks in ATM
before the arrival of MPLS. We were working on some tests with peers and
subscribers when the FirstWorld merger came along, and the rest is
history.
To answer Steve's questions:
1: Where you can have a different circuit (physical or virtual ) for the
mgt/routing traffic, you provision the traffic ONLY on those links (and
filter it on all others), and only to peers who speak that particular
protocol. Give those VCs highest priority.
2: Where 1 is not possible, use a local-only network, preferably IPV6,
for the mgt/routing, and set priority to highest for that source/dest
net.
This could be provisioned even for those end users who DO need to
sprecken BGP, and who do not have separate (virtual) circuits for
management.
From: Sachs, Marcus Hans (Marc) [mailto:marcus.sachs@verizon.com]
Sent: Tuesday, December 29, 2009 7:22 AM
To: Steven Bellovin
Cc: NANOG list
Subject: RE: ip-precedence for management trafficNope, 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!)Marc
From: Steven Bellovin [mailto:smb@cs.columbia.edu]
Sent: Tuesday, December 29, 2009 10:09 AM
To: Sachs, Marcus Hans (Marc)
Cc: NANOG list
Subject: Re: ip-precedence for management traffic> Totally out of the box, but here goes: why don't we run the entire
Internet management plane "out of band" so that customers have minimal
ability to interact with routing updates, layer 3/4 protocols, DNS,
etc.? I don't mean 100% exclusion for all customers, but for the
average Joe-customer (residential, business, etc., not the researcher,
network operator, or clueful content provider) do they really need to
have full access to the Internet mechanisms (routing, naming,
numbering, etc.)?
>
> We already provide lots of proxy services for end users, so why not
finish the job and move all of the management mechanisms out of plain
sight?I hope you're joking. If not, I have two questions: how can this be
done, and what will the side-effects be?Take BGP, for example. The average residential consumer doesn't need
BGP, doesn't speak it, and has no real ability to interfere with it,
so
there's no problem. But a multihomed customer *must* speak it.
Perhaps you could assert that their ISPs should announce it -- but why
trust random ISPs? Is that ISP 12 hops away from you trustworthy, or
a
front for the Elbonian Business Network?
As for side-effects -- how can you proxy everything? Do you know
every
application your customers are running? Must someone who invents a
new
Experts,
my inquiry was very specific and bounded to the following assumptions:
- in-band management
- not possible to filter customer traffic, certainly not for somebody
else's customer.
- IP
In this case diffserv can help prioritize management plane traffic over
user traffic. To do that only ipp6 and ipp7 values are available for non
user traffic.
IPP6 is used by default for routing protocols, that is control plane; so
probably it is better not to mess around with it.
This leaves to IPP7 for management plane traffic, value that I can not
recall of having seen used by any application/protocol.
What is the general opinion about this?
Thanks.
Sorry, your original query got lost behind the smoke of my out-of-the-box musings.
My biggest quarrel with any type of IP precedence is that anybody along the chain can set or reset these bits. There is no assurance that a packet's priority will remain at the level set by the originator unless you have some very well disciplined netadmins between sender and receiver who do not fiddle with header bits. If I knew that I could reliably set ToS bits in the IP header and they would remain unchanged then I would add a shim to my local stack that sets all of my flows at the highest priority thereby making my Internet experience a wee bit faster than somebody who leaves those three bits set to 000.
I'm sure others will have widely different opinions.
Marc
Marc,
I don't think that's entirely true.
I have in previously run networks that remarked all precedence on inbound
traffic at the borders to particular values (mostly zero except where policy
dictated other) and then accepted the precedence values internally for
priority control.
Customers were allowed to send contracted amounts of higher precedence
traffic, but anything over was marked down (or dropped). So most traffic
got best effort, but marked traffic got a relatively guaranteed QOS.
This was quite some time ago (2000-2001), so I'm thinking it ought to still
be doable today. You have to be diligent in remarking inbound traffic at
all boundaries, but it's not rocket science.
Regards,
-Dorn
Totally out of the box, but here goes: why don't we run the entire Internet management plane "out of band" so that customers have minimal ability to interact with routing updates, layer 3/4 protocols, DNS, etc.?
I hope you're joking. If not, I have two questions: how can this be done, and what will the side-effects be?
Actually...
Some of the models proposed in the IRTF Routing Research Group separate the "access network" from the "transport network". That is, end devices would be numbered from a different "namespace" than the nodes in the transport network. This would allow for the separation of identity from network topology allowing much greater scalability of the routing system (at the cost of requiring a mapping system that maps end point identifiers to/from network topology locators). Think of it as an automated ubiquitous end-to-end tunneling system that tunnels traffic to/from identifiers. A side effect of this approach would be along the lines what Marc is suggesting.
Take BGP, for example. The average residential consumer doesn't need BGP, doesn't speak it, and has no real ability to interfere with it, so there's no problem. But a multihomed customer *must* speak it.
Multihoming in the above model would simply mean the output of the mapping service of an identifier would result in two (or more) locators. Changing ISPs means simply changing the identifier to locator mapping. Ah, the joys of indirection...
Of course, I'm a bit doubtful any of the models discussed in RRG or even LISP will gain much traction.
As for side-effects -- how can you proxy everything? Do you know every application your customers are running? Must someone who invents a new app first develop a proxy and persuade every ISP that it's safe, secure, high-enough performance, and worth their while to run? It's worth remembering that most of the innovative applications have come from folks whom no one had ever heard of.
I dunno. Seems the vast majority of Internet users are happy with this model, given they are sitting behind a NAT box....
Regards,
-drc
Totally out of the box, but here goes: why don't we run the entire
Internet management plane "out of band"
tread caefully. we have experienced (and some continue to experience)
non-linear expansion of management, control, and stability problems when
layers are non-congruent.
randy
Randy Bush wrote:
Totally out of the box, but here goes: why don't we run the entire
Internet management plane "out of band"
tread caefully. we have experienced (and some continue to experience)
non-linear expansion of management, control, and stability problems when
layers are non-congruent.
Isn't this just a suggestion to more or less faithfully reproduce the control and
bearer planes of the TDM network also? I'd think that this fate sharing aspect of the
internet model is a feature rather than a bug. That is, putting everything on the same
wire forces you to deal with QoS or get the predictable results. That and building out
separate and unequal networks pretty much sucks?
Mike
It does create job preservation in old-school telcos, like T.
- Jared
RFC 4594 would suggest using DSCP CS2 (010000xx in the TOS byte; xx is the ECN flags). Section 3.1 discusses the issues with CS7, which is the DSCP counterpart to the deprecated IP Precedence 7. RFCs 2474/2475 discuss the Differentiated Services Architecture and its implementation.
http://www.ietf.org/rfc/rfc4594.txt
4594 Configuration Guidelines for DiffServ Service Classes. J.
Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT=144044 bytes)
(Status: INFORMATIONAL)
http://www.ietf.org/rfc/rfc2474.txt
2474 Definition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black.
December 1998. (Format: TXT=50576 bytes) (Obsoletes RFC1455, RFC1349)
(Updated by RFC3168, RFC3260) (Status: PROPOSED STANDARD)
http://www.ietf.org/rfc/rfc2475.txt
2475 An Architecture for Differentiated Service. S. Blake, D. Black,
M. Carlson, E. Davies, Z. Wang, W. Weiss. December 1998. (Format:
TXT=94786 bytes) (Updated by RFC3260) (Status: INFORMATIONAL)
I feel compelled to say that once a packet leaves you administrative
control, all bets are off, of course.
IP Precedence flagging is not an honored "bit" in The Internet.
Of course, if you own the end-to-end path, anything is possible.
- - ferg