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.
On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote:
this leaves out only ipp 7 for management traffic, on the premise that routing and management should not share the same queue and resources.....
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
On Dec 29, 2009, at 2:07 AM, Dobbins, Roland wrote:
On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote:
this leaves out only ipp 7 for management traffic, on the premise that routing and management should not share the same queue and resources.....
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.............. On Dec 29, 2009, at 6:03 AM, Mehmet Akcin wrote:
On Dec 29, 2009, at 2:07 AM, Dobbins, Roland wrote:
On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote:
this leaves out only ipp 7 for management traffic, on the premise that routing and management should not share the same queue and resources.....
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
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 -----Original Message----- From: Mehmet Akcin [mailto:mehmet@akcin.net] Sent: Tuesday, December 29, 2009 6:03 AM To: NANOG list Subject: Re: ip-precedence for management traffic On Dec 29, 2009, at 2:07 AM, Dobbins, Roland wrote:
On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote:
this leaves out only ipp 7 for management traffic, on the premise that routing and management should not share the same queue and resources.....
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
On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote:
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 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
On Tue, Dec 29, 2009 at 10:08 AM, Steven Bellovin <smb@cs.columbia.edu> wrote:
On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote:
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
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
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 -----Original Message----- 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 On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote:
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 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
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.
On Tue, 29 Dec 2009 10:00:57 CST, Joe Greco said:
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...
I can remember at one time, some of the same players who argued against IPv6 adoption because the long addresses would increase network overhead were the same ones championing the insane firewalling that started the "everything over HTTP" insanity. Guess which adds more bits to the total packet? :)
Joe wrote:
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.
Yes, taking away the mechanisms will result in a "castrated" Internet experience for the clueful ones which is why I don't think this can be a one-size-fits-all model like the hotels try to do. Imagine a residential ISP that offers castration at a lower price point than what is currently charged for monthly "raw" access. I think that many consumers would opt for that choice, while those who need access to everything would continue to pay the same rate. The price drop would be the incentive to get castrated, and what you give up would be access to things you likely don't use anyway. This castration process would be a big help to spam-blocking, evilware-blocking, ddos-blocking, etc. in addition to mitigating attacks against the mechanisms from hijacked residential computers. Marc
On Tue, 29 Dec 2009 11:43:25 EST, "Sachs, Marcus Hans (Marc)" said:
one-size-fits-all model like the hotels try to do. Imagine a residential ISP that offers castration at a lower price point than what is currently charged for monthly "raw" access.
The gene pool needed some chlorine anyhow, but this is a creative approach. :) But seriously - would this be significantly different than the model that many ISPs already use, where "consumer" connections get port 25 blocked, no servers allowed, etc, and "business grade" skip those restrictions? Or are you saying that ISPs should go *further* in blocking stuff, and use the resulting support savings to lower the consumer grade price point? Only big stumbling block is what percent of customers will be willing to skip file-sharing networks and online games that use oddball ports? Any ideas there?
The gene pool needed some chlorine anyhow, but this is a creative approach. :)
But seriously - would this be significantly different than the model
Valdis said: that
many ISPs already use, where "consumer" connections get port 25 blocked, no servers allowed, etc, and "business grade" skip those restrictions? Or are you saying that ISPs should go *further* in blocking stuff, and use the resulting support savings to lower the consumer grade price point?
Only big stumbling block is what percent of customers will be willing to skip file-sharing networks and online games that use oddball ports? Any ideas there?
Better than the typical "block outbound 25" filtering we do now. In fact, in a perfect world ISPs would offer residential customers "reduced experience" versions of castration that decrease the cost along with decreasing what you have access to. At the bottom level it would be essentially a thin client running a terminal service (or an emulated thin client using a web browser) with all applications "in the cloud" and nothing sitting on the home PC; mid-level would be web plus common email clients and chat/IM; high level adds popular apps like Skype, P2P, games, etc. I think that a fairly large percentage of homes that only want access to online content and email would be very happy with the bottom tiers. Many would probably like the cloud approach where all of the crazy updating, rebooting, etc. is taken out of the hands of the consumer. WebTV, meet the 21st century.... :) Marc
On 29/12/09 12:20 -0500, Sachs, Marcus Hans (Marc) wrote:
Better than the typical "block outbound 25" filtering we do now. In fact, in a perfect world ISPs would offer residential customers "reduced experience" versions of castration that decrease the cost along with decreasing what you have access to. At the bottom level it would be essentially a thin client running a terminal service (or an emulated thin client using a web browser) with all applications "in the cloud" and nothing sitting on the home PC; mid-level would be web plus common email clients and chat/IM; high level adds popular apps like Skype, P2P, games, etc.
I think that a fairly large percentage of homes that only want access to online content and email would be very happy with the bottom tiers. Many would probably like the cloud approach where all of the crazy updating, rebooting, etc. is taken out of the hands of the consumer. WebTV, meet the 21st century.... :)
The customers in the market for such a service would be least likely to understand your explanation of the service. Do you offer a new lower tier service, or rebrand your residential service, and try to explain how you're taking away services they probably don't need. It's been my experience that if you tell someone you're taking away something, they tend to value it even if they don't know what it is. -- Dan White
On Dec 29, 2009, at 12:59 PM, Dan White wrote:
On 29/12/09 12:20 -0500, Sachs, Marcus Hans (Marc) wrote:
Better than the typical "block outbound 25" filtering we do now. In fact, in a perfect world ISPs would offer residential customers "reduced experience" versions of castration that decrease the cost along with decreasing what you have access to. At the bottom level it would be essentially a thin client running a terminal service (or an emulated thin client using a web browser) with all applications "in the cloud" and nothing sitting on the home PC; mid-level would be web plus common email clients and chat/IM; high level adds popular apps like Skype, P2P, games, etc.
I think that a fairly large percentage of homes that only want access to online content and email would be very happy with the bottom tiers. Many would probably like the cloud approach where all of the crazy updating, rebooting, etc. is taken out of the hands of the consumer. WebTV, meet the 21st century.... :)
The customers in the market for such a service would be least likely to understand your explanation of the service.
Do you offer a new lower tier service, or rebrand your residential service, and try to explain how you're taking away services they probably don't need. It's been my experience that if you tell someone you're taking away something, they tend to value it even if they don't know what it is.
As well they should. As well we all should. None of us knows precisely what we're going to absolutely require, or merely want/prefer, tomorrow or the next day, much less a year or two from now. Unless, of course, we choose to optimize (constrain) functionality so tightly around what we want/need today that the prospect of getting anything different is effectively eliminated. TV
None of us knows precisely what we're going to absolutely require, or merely want/prefer, tomorrow or the next day, much less a year or two from now. Unless, of course, we choose to optimize (constrain) functionality so tightly around what we want/need today that the prospect of getting anything different is effectively eliminated.
this is the telco solution to the nasty disruptive technologies spawned by the internet randy
On Tue, Dec 29, 2009 at 5:22 PM, Randy Bush <randy@psg.com> wrote:
None of us knows precisely what we're going to absolutely require, or merely want/prefer, tomorrow or the next day, much less a year or two from now. Unless, of course, we choose to optimize (constrain) functionality so tightly around what we want/need today that the prospect of getting anything different is effectively eliminated.
this is the telco solution to the nasty disruptive technologies spawned by the internet
I could be mistaken, but I think Tom's point was "we could give people the ebony black bell phone, that'd really suck for us as a business/community." -chris
None of us knows precisely what we're going to absolutely require, or merely want/prefer, tomorrow or the next day, much less a year or two from now. Unless, of course, we choose to optimize (constrain) functionality so tightly around what we want/need today that the prospect of getting anything different is effectively eliminated.
this is the telco solution to the nasty disruptive technologies spawned by the internet
I could be mistaken, but I think Tom's point was "we could give people the ebony black bell phone, that'd really suck for us as a business/community."
sorry, i should have been more clear that i was agreeing with tom. replies might not be assumed to be in opposition. randy
On Dec 29, 2009, at 5:47 PM, Randy Bush wrote:
None of us knows precisely what we're going to absolutely require, or merely want/prefer, tomorrow or the next day, much less a year or two from now. Unless, of course, we choose to optimize (constrain) functionality so tightly around what we want/need today that the prospect of getting anything different is effectively eliminated.
this is the telco solution to the nasty disruptive technologies spawned by the internet
I could be mistaken, but I think Tom's point was "we could give people the ebony black bell phone, that'd really suck for us as a business/community."
sorry, i should have been more clear that i was agreeing with tom. replies might not be assumed to be in opposition.
I got that ;-) Chris is right, but so is Randy. IMO if the net is ultimately diminished in this manner, either through commission or omission, eating anything other than our own dog food would be neither defensible, nor sustainable for long. The rotary phone was great in its time, but that time has passed -- today there's lot more at stake than handset color. TV
On Tuesday 29 December 2009 22:22:05 Randy Bush wrote:
None of us knows precisely what we're going to absolutely require, or merely want/prefer, tomorrow or the next day, much less a year or two from now. Unless, of course, we choose to optimize (constrain) functionality so tightly around what we want/need today that the prospect of getting anything different is effectively eliminated.
this is the telco solution to the nasty disruptive technologies spawned by the internet
randy
It surely is. Also, when was the last time you had a customer ring up and ask for a product "like the Internet but with bits missing"? Nobody wants it, and the evidence of this is that nobody asks for it, and further that nobody's started an ISP that provides it, although people have been talking about it for years. The support for "the Internet but not quite" is usually from either: 1) Telcos who secretly wish the Internet would go away 2) Security/morals bureaucrats (who secretly wish it would go away) 3) Engineers noodling on the idea, who don't have a business model for it Note that this list doesn't include "users" or "customers" or anyone willing to offer "money" for it. Also, I don't think it's at all clear that Internet-minus service would be cheaper to provide. Basically, if you have an IP network you can provide all the applications over it by default. Therefore, if you want to get rid of some, you've got to make an effort, which implies cost. There is no such thing as a Web DSL modem or a Web router. In terms of traffic, as over 50% of the total is WWW these days, and a sizable chunk of the rest is Web-video streaming, once you've chucked in the e-mail, it's far from clear that you'd save significant amounts of bandwidth. Obviously, if you were intending to offer proper Internet service as an extra- cost option, you wouldn't have two lots of access lines, backhaul, transit - you'd filter more ports for some subset of your addressing scheme, or put the less-than-Internet customers on a different layer 2 vlan. So you'd still need the extra bandwidth for the other customers. Where is the saving? Fewer support calls due to...what exactly? aren't the biggest malware vectors now web-based drive by download, sql injection and the like? Of course, there'll be a fair few wanting to know why slingbox, skype, IM protocol of choice, work vpns etc don't work. The exercise is pointless.
Joe wrote:
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.
Yes, taking away the mechanisms will result in a "castrated" Internet experience for the clueful ones which is why I don't think this can be a one-size-fits-all model like the hotels try to do. Imagine a residential ISP that offers castration at a lower price point than what is currently charged for monthly "raw" access. I think that many consumers would opt for that choice, while those who need access to everything would continue to pay the same rate. The price drop would be the incentive to get castrated, and what you give up would be access to things you likely don't use anyway. This castration process would be a big help to spam-blocking, evilware-blocking, ddos-blocking, etc. in addition to mitigating attacks against the mechanisms from hijacked residential computers.
Then, by all means, approach your management and make a proposal to sell reduced fee "Web only" access. You can already force all such traffic through a transparent HTTP proxy, a DNS server of your choosing, and filter out everything else. I am still failing to see why what you're talking about cannot be done with today's technology. And if it can be done with today's technology, and isn't being done with it, either that's a business opportunity for you, or it says something about the model. ... 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.
Joe wrote:
I am still failing to see why what you're talking about cannot be done with today's technology.
And if it can be done with today's technology, and isn't being done with it, either that's a business opportunity for you, or it says something about the model.
The later. It can be done today. So why is it not being offered? There must be other forces at work. Marc
Joe wrote:
I am still failing to see why what you're talking about cannot be done with today's technology.
And if it can be done with today's technology, and isn't being done with it, either that's a business opportunity for you, or it says something about the model.
The later. It can be done today. So why is it not being offered? There must be other forces at work.
It is (/was). You had things like WebTV. Spectacularly unsuccessful as time went on. The problem is that the Internet is very powerful and very big. Offer people a basic box that does basic things, and one person will want to (also) pull up a PDF, another will (also) want to be able to install a more modern version of Flash to support the latest video capabilities being offered by $YOUTUBE_LIKE_SITE, a third will (also) want Java support in order to play some trite online game, etc. Offer people a basic Web-only Internet connection, and they'll want to know why their gaming console doesn't work, etc. Fundamentally, we have worked very hard for a very long time to create a sort of baseline level of what is expected as part of "Internet" connectivity. That's a basic IP connection. We've created standards on top of that to allow applications to interoperate. It is hard to dip down below that bar in terms of functionality. Anyone who tries is going to end up eating support costs. How do you offer a "cheaper" level of (let's say) Web-only Internet access, when the support costs will be higher? Where's the value? What's the business plan? Where's the profit in that? I really meant what I said: [I]f it can be done with today's technology, and isn't being done with it, either that's a business opportunity for you, or it says something about the model. ... 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.
On 29/12/2009 21:10, Joe Greco wrote:
How do you offer a "cheaper" level of (let's say) Web-only Internet access, when the support costs will be higher? Where's the value? What's the business plan? Where's the profit in that?
As an unrelated footnote, these are questions which will become highly relevant when RIR address space depletion occurs and when providers initially believe that they can create viable product sets based on provider NAT, once their v4 address space can no longer service their customer base. [As a further sub-note, the "believe" bit is not a statement of scepticism, but rather a statement of fact; many providers will almost certainly believe that end-users will swallow provider NAT, regardless of whether the product models turn out to be viable or not.] So, although it's a different context, I think you'll see the answer to these questions in this context in the next couple of years. Nick
-----Original Message----- From: Sachs, Marcus Hans (Marc) [mailto:marcus.sachs@verizon.com] Sent: Tuesday, December 29, 2009 11:43 To: Joe Greco Cc: NANOG list Subject: RE: ip-precedence for management traffic
Joe wrote:
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.
Yes, taking away the mechanisms will result in a "castrated" Internet experience for the clueful ones which is why I don't think this can be a one- size-fits-all model like the hotels try to do. Imagine a residential ISP that offers castration at a lower price point than what is currently charged for monthly "raw" access. I think that many consumers would opt for that choice, while those who need access to everything would continue to pay the same rate. The price drop would be the incentive to get castrated, and what you give up would be access to things you likely don't use anyway. This castration process would be a big help to spam-blocking, evilware-blocking, ddos- blocking, etc. in addition to mitigating attacks against the mechanisms from hijacked residential computers.
Marc
My $.02 or so - This "widespread castration" would force application developers to jump through the same NAT-traversal hoops all over again, adding more code-bloat / operational overhead and stifling innovation. Naturally, once created, this lower-class of internet user would probably become the "norm" and force a race to the bottom in terms of capabilities and performance (or perhaps, another "arms race" between the proxy implementations and the proxy avoidance implementations) ... rinse-repeat-fail_to_learn, all over again. /TJ PS - could we choose a different term; "cut-rate castration" brings unpleasant medical-accidents to mind ...
My $.02 or so - This "widespread castration" would force application developers to jump through the same NAT-traversal hoops all over again, adding more code-bloat / operational overhead and stifling innovation. Naturally, once created, this lower-class of internet user would probably become the "norm" and force a race to the bottom in terms of capabilities and performance (or perhaps, another "arms race" between the proxy implementations and the proxy avoidance implementations) ... rinse-repeat-fail_to_learn, all over again.
That was kind of my point.
/TJ PS - could we choose a different term; "cut-rate castration" brings unpleasant medical-accidents to mind ...
How about "net neuterality." ... 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.
On Dec 29, 2009, at 11:43 AM, Sachs, Marcus Hans (Marc) wrote:
Yes, taking away the mechanisms will result in a "castrated" Internet experience for the clueful ones which is why I don't think this can be a one-size-fits-all model like the hotels try to do. Imagine a residential ISP that offers castration at a lower price point than what is currently charged for monthly "raw" access. I think that many consumers would opt for that choice, while those who need access to everything would continue to pay the same rate. The price drop would be the incentive to get castrated, and what you give up would be access to things you likely don't use anyway. This castration process would be a big help to spam-blocking, evilware-blocking, ddos-blocking, etc. in addition to mitigating attacks against the mechanisms from hijacked residential computers.
I think there are a few challenges here. What you are describing is a castrated/walled-garden internet. The technical nuances are lost on the average person. The same way that cybersecurity month, or others are lost on the average user. All they care about is the recent panic for the day. I find it impossible to deal with some vendors that are stuck with their lock-in models. The way that the majority of $major_networks is managed is in a method that is not always congruent with their visions. This is true from their ideas on how to manage devices (Hey, everyone sits at a corp controlled windows machine behind a firewall so you can keep the *exact* version of java installed, right?) How does one reach the OOB network when you are not in the office? How do these "SCADA" for the "internet" networks get reached? Some people have implemented DSL or other vpn methods to reach their oob devices. Others use POTS. As others mentioned here the POTS over "NGN" (what marketing crap is that) may have fate sharing properties that are problematic. What if the vendor is horrible and you actually "need" console/video to run their win32 crapware to manage the devices? (Netgear comes to mind, can't upgrade my snmp capable switch at home without booting windoze so it can tftp). The inband management is a direct result of needing a good method to tie the link failure directly into the control plane of the devices. Sure, we could do the DLCI/pvc/DS1 in parallel to each 10G/40G circuit installed, but is that cost-effective? Does it introduce more pain vs less? The average neteng clearly can't configure their devices correctly, while the additional complexity may provide some networks benefits, this does not reduce the systemic risk created by nobody implementing BCPs like simple route filtering. I've watched BCPs be diluted at various companies due to market pressures. $major_provider did not require me to register my routes, why should I have to do that in order to give you $X MRC for the next 12-24-36 months? I was asked recently by someone that operates a small wireless ISP what the deal was with this "Internet2" thing and how was it supposed to interact, etc.. Honestly, I wish we could have a "better" network. One where we have mutually agreed "I will filter my customers if you do". I've not seen many people step-up to improve the systems. It's the same small set of people that are trying to make things better. Apparently I forgot the <rant> tag, but really, if you have sane CoPP policies, you are mostly protected. If the vendor does not provide this capability, please STOP BUYING THEIR CRAP. </rant> - Jared
On 29 Dec 2009, at 17:19, Jared Mauch wrote:
I've watched BCPs be diluted at various companies due to market pressures. $major_provider did not require me to register my routes, why should I have to do that in order to give you $X MRC for the next 12-24-36 months? [...] Honestly, I wish we could have a "better" network. One where we have mutually agreed "I will filter my customers if you do".
You can (should) still filter their prefixes - the customer get added pain because changes have to be done by hand, through tickets, maybe as a billable incident. :-) Andy
On Tue, Dec 29, 2009 at 12:19:32PM -0500, Jared Mauch wrote: [snip]
Apparently I forgot the <rant> tag, but really, if you have sane CoPP policies, you are mostly protected. If the vendor does not provide this capability, please STOP BUYING THEIR CRAP.
Another fine example of broken fate-sharing when management plane (executives with purse strings) is strictly segmented from control plane (engineers and operators). -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
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.
-----Original Message----- 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 traffic
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
-----Original Message----- 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
On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote:
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 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
On Dec 29, 2009, at 7:08 AM, Steven Bellovin wrote:
On Dec 29, 2009, at 9:29 AM, Sachs, Marcus Hans (Marc) wrote:
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
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. On Tue, 2009-12-29 at 12:02 +0100, Luca Tosolini wrote:
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.
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 -----Original Message----- From: Luca Tosolini [mailto:bit.gossip@chello.nl] Sent: Tuesday, December 29, 2009 1:38 PM To: nanog Subject: Re: ip-precedence for management traffic 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. On Tue, 2009-12-29 at 12:02 +0100, Luca Tosolini wrote:
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.
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 On Tue, Dec 29, 2009 at 1:17 PM, Sachs, Marcus Hans (Marc) < marcus.sachs@verizon.com> wrote:
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
-----Original Message----- From: Luca Tosolini [mailto:bit.gossip@chello.nl] Sent: Tuesday, December 29, 2009 1:38 PM To: nanog Subject: Re: ip-precedence for management traffic
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.
On Tue, 2009-12-29 at 12:02 +0100, Luca Tosolini wrote:
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.
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) On Dec 29, 2009, at 3:02 AM, Luca Tosolini wrote:
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Dec 31, 2009 at 12:08 AM, Fred Baker <fred@cisco.com> wrote:
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 -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLPF2Yq1pz9mNUZTMRAhv/AKCNk2WiQt+zhO3o9EI/aOR2IMgvzwCgwSkQ ueQBckYm/1cTx5/atLaFd0A= =ooNM -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
participants (24)
-
Alexander Harrowell -
Andy Davidson -
Christopher Morrow -
Dan White -
David Conrad -
Dobbins, Roland -
Dorn Hetzel -
Fred Baker -
Jared Mauch -
Joe Greco -
Joe Provo -
Julio Arruda -
Luca Tosolini -
Mehmet Akcin -
Michael Thomas -
Nick Hilliard -
Paul Ferguson -
Randy Bush -
Sachs, Marcus Hans (Marc) -
Steven Bellovin -
TJ -
Tomas L. Byrnes -
tvest＠eyeconomics.com -
Valdis.Kletnieks＠vt.edu