Re: New Year's Exploration: Changing the Internet's Infrastructure
On 12/31/2010 6:56 AM, Dave CROCKER wrote: So I would like to ask for folks to help the community develop some concrete information about this, by adding entries and comments to the IETF's Outcomes Wiki: http://trac.tools.ietf.org/misc/outcomes/[2] ... Some infrastructure changes are designed for the router level of things and some are designed for host-level. But they provide underlying services that can then be used for better performance, reliability, or control or to make new applications viable. G'day. On some further thought about this question, the term infrastructure does not seem to be very helpful. I suggest we distinguish where the benefit barrier is. What kind of adoption is required before the adopters can gain benefit? Single: In very rare cases, a single adopter can gain benefit immediately. Even among the cases that qualify for this classification on a theoretical basis, I suspect the fact that they qualify is an accident and that they were expected to have a different adoption requirement, and probably do have a different one, predominantly. That is, the single-adopter benefit is probably deemed insufficient. DKIM is an example of this. Pair: Any communicating pair of systems can gain immediate benefit. I like citing MIME as a stellar example of this. I suppose ARP also qualifies. Path: All of the systems along the path need to adopt the change before it can provide benefit. IPv6 is an obvious example of this. In the email arena, so is Delivery Service Notice. However note that the ability to predict the path is very poor, so that broader adoption is typically required before a particular path will happen to provide the necessary support. Subsystem: Very broad-based adoption by an extended service must first occur. BGP and DNSSEC are examples. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New Year's Exploration: Changing the Internet's Infrastructure
- Original Message - From: John Leslie j...@jlc.net To: Richard L. Barnes rbar...@bbn.com Cc: IETF Discussion ietf@ietf.org Sent: Friday, December 31, 2010 7:38 PM Richard L. Barnes rbar...@bbn.com wrote: ISTM that the success of changes to the infrastructure depends on the value those changes deliver to participants in the Internet economy... So the question is rather how many problems there are in the current infrastructure that cause people enough pain to do something. Indeed -- _an_ interesting question... but perhaps not phrased quite right: in truth, there are an arbitrarily large number of problems that cause _somebody_ enough pain to do something. I think there are at least a couple (improving BGP security, for example), and the number will probably slowly shrink over time, but in the long run, I expect there will ultimately always be a few big things that need to be done that can't be done in end systems. Start from the end: there _will_ be a number of things that shouldn't be done in end systems. End systems _really_don't_ want to worry about the route packets follow -- at most they want to worry about delay, jitter, and order of delivery. But they _will_ work with whatever tools are available to ameliorate such worries. The number of problems will most surely _increase_ over time, not shrink. BGP security is a _dreadful_ example. It conflates weaknesses of the original design with issues entirely out-of-scope of the original design. And the original design was seriously flawed by defining algorithms instead of meanings. Nonetheless, the example does serve to illustrate a weakness of IETF process -- that it's much easier to get traction on small fixes to parts of the problem than on migration to a design which avoids the problems. BTW, I find it interesting to see how little of the work originating in the Security area has gained traction. I wonder to what extent this results from: - cycles being expended on cross-area reviews; - recommending IPsec whether or not it could be deployed for the use; - the inherent complexity of key infrastructure? Security is different in kind from a functional enhancement, of the sort one sees in successive generations of mobile, in successive versions of Windows etc. With these, you pay, you get. Security you pay for what you don't get, fraud and crime. Long experience teaches me that noone will pay until after the security breach has cost them; only when a bank loses billions to fraud will a few millions preventing it seem like a good investment. All we can do is have the solutions ready in advance of the attacks, so that when the latter happen, we can say, what a coincidence, we just happen to have the solution ready and waiting. Tom Petch -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New Year's Exploration: Changing the Internet's Infrastructure
The fundamental problems that infrastructure changes face are cases where 1) Costs are borne by party X, benefits accrue to party Y 2) Costs pers user are independent of number of adopters, benefits are proportional to the number of adopters. The network effect is only a virtuous circle once costs exceed benefits. Until that point is reached it is a chicken and egg problem. One of the interesting features of this analysis is that every time I give it people: 1) Insist that the analysis is not novel, is obvious and unimaginative. 2) Continue to attempt the approach they admit is obviously going to fail. One of the problems with modern academia is that novelty and cleverness are far more likely to advance a career than building stuff that actually works. So when we have a problem there is a bias in the academy towards an approach that is novel and allows the designer to demonstrate their cleverness rather than an approach that was proposed twenty years ago, before the problem was recognized as important. Take the problem of BGP security. People seem to be attempting to authenticate the routes so as to protect the integrity of messages (assuming DNSSEC deployment). That seems to be a rather unlikely objective to achieve given the number of backbone providers, the number of packets and the fact that packets can be dropped. Trying to achieve anything more than preventing against Denial of Service attacks at the BGP layer is probably futile. There are two issues, the binding of IP address range claims to AS numbers and the interchange of routing metrics. We could solve the first problem pretty easily using a straightforward approach. Each 24 hours the NICs all sign a list of the IP address assignments to public key holders they have granted.This can then be used to verify signatures. Quick, simple and does not require exploration in untested parts of the X.509 stack. Instead we get a science project. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
New Year's Exploration: Changing the Internet's Infrastructure
Folks, Feliz Año Nuevo! One of the lessons of efforts such as IPv6 and DNSSEC should be that making changes to the global infrastructure of the Internet is extremely difficult. The technical details are difficult -- especially if the change seeks to work with an existing base of functionality -- and the administration and operation details are difficult. And the time it takes to achieve critical mass is quite long. However we continue to hear claims and see design efforts that are based on the view that changing the infrastructure is easier than changing end-systems.[1] The fact that the infrastructure is controlled by far fewer actors and organizations makes it natural to assume that this preference is well-founded and correct. But does the Internet's track record substantiate this view? So I would like to ask for folks to help the community develop some concrete information about this, by adding entries and comments to the IETF's Outcomes Wiki: http://trac.tools.ietf.org/misc/outcomes/[2] If there is a piece of work that was targeting change to the infrastructure or the creation of new infrastructure, please add an entry for it to the wiki. This will provide an explicit statement about the history and degree of success of that effort. Congestion control, mobility, multipath, multicasting, new transport, MIME, etc. Anything that enables higher-level capabilities. Some infrastructure changes are designed for the router level of things and some are designed for host-level. But they provide underlying services that can then be used for better performance, reliability, or control or to make new applications viable. My expectation is that we are going to find that such efforts are difficult, no matter where they are put, but I suspect we will find that the ones destined for the router level of things are the hardest. Prove me wrong by adding entries to the Outcomes wiki that show otherwise... Or prove me correct. Having clarity about this topic could make for a pretty good start of the new year... d/ [1] Serious pursuit of this topic requires some agreement about the definition of infrastructure and quite possibly agreement on end-system. For now, let's just say that infrastructure is anything that provides services to a layer above. That makes TCP a kind of infrastructure service. But, then, the environment for controlling it is quite different, since it sits in hosts, not routers. So perhaps we need some additional constructs for the venue of infrastructure service?. [2] We might discover that it will help to add a column to the wiki's tables. That's fine to explore on the wiki's mailing list: https://www.ietf.org/mailman/listinfo/ietf-outcomes Given footnote [1], an example of a change might be a column that notes where the service resides in terms of Internet architecture. Granularity that distinguishes more than just host-vs-router might be helpful, since the Internet's range of tussle boundaries has grown more complex, given the operational reality of PCs, servers, organizational nets, local ISPs and transit nets... In the absence of agreements to make changes, use the Comments column in the wiki, for recording information that might warrant a new column in the table. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New Year's Exploration: Changing the Internet's Infrastructure
Hey Dave, I admire your desire for clarity on this subject, but fear you will be disappointed. ISTM that the success of changes to the infrastructure depends on the value those changes deliver to participants in the Internet economy -- i.e., the pain of the problem they solve. Your two examples are actually very appropriate here: IPv6 and DNSSEC both moved very slowly until (1) people started to not have enough numbers to grow their networks, and (2) Dan Kaminsky put the fear of God in people. So the question is rather how many problems there are in the current infrastructure that cause people enough pain to do something. I think there are at least a couple (improving BGP security, for example), and the number will probably slowly shrink over time, but in the long run, I expect there will ultimately always be a few big things that need to be done that can't be done in end systems. --Richard On Dec 31, 2010, at 9:56 AM, Dave CROCKER wrote: Folks, Feliz Año Nuevo! One of the lessons of efforts such as IPv6 and DNSSEC should be that making changes to the global infrastructure of the Internet is extremely difficult. The technical details are difficult -- especially if the change seeks to work with an existing base of functionality -- and the administration and operation details are difficult. And the time it takes to achieve critical mass is quite long. However we continue to hear claims and see design efforts that are based on the view that changing the infrastructure is easier than changing end-systems.[1] The fact that the infrastructure is controlled by far fewer actors and organizations makes it natural to assume that this preference is well-founded and correct. But does the Internet's track record substantiate this view? So I would like to ask for folks to help the community develop some concrete information about this, by adding entries and comments to the IETF's Outcomes Wiki: http://trac.tools.ietf.org/misc/outcomes/[2] If there is a piece of work that was targeting change to the infrastructure or the creation of new infrastructure, please add an entry for it to the wiki. This will provide an explicit statement about the history and degree of success of that effort. Congestion control, mobility, multipath, multicasting, new transport, MIME, etc. Anything that enables higher-level capabilities. Some infrastructure changes are designed for the router level of things and some are designed for host-level. But they provide underlying services that can then be used for better performance, reliability, or control or to make new applications viable. My expectation is that we are going to find that such efforts are difficult, no matter where they are put, but I suspect we will find that the ones destined for the router level of things are the hardest. Prove me wrong by adding entries to the Outcomes wiki that show otherwise... Or prove me correct. Having clarity about this topic could make for a pretty good start of the new year... d/ [1] Serious pursuit of this topic requires some agreement about the definition of infrastructure and quite possibly agreement on end-system. For now, let's just say that infrastructure is anything that provides services to a layer above. That makes TCP a kind of infrastructure service. But, then, the environment for controlling it is quite different, since it sits in hosts, not routers. So perhaps we need some additional constructs for the venue of infrastructure service?. [2] We might discover that it will help to add a column to the wiki's tables. That's fine to explore on the wiki's mailing list: https://www.ietf.org/mailman/listinfo/ietf-outcomes Given footnote [1], an example of a change might be a column that notes where the service resides in terms of Internet architecture. Granularity that distinguishes more than just host-vs-router might be helpful, since the Internet's range of tussle boundaries has grown more complex, given the operational reality of PCs, servers, organizational nets, local ISPs and transit nets... In the absence of agreements to make changes, use the Comments column in the wiki, for recording information that might warrant a new column in the table. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New Year's Exploration: Changing the Internet's Infrastructure
Richard L. Barnes rbar...@bbn.com wrote: ISTM that the success of changes to the infrastructure depends on the value those changes deliver to participants in the Internet economy... So the question is rather how many problems there are in the current infrastructure that cause people enough pain to do something. Indeed -- _an_ interesting question... but perhaps not phrased quite right: in truth, there are an arbitrarily large number of problems that cause _somebody_ enough pain to do something. I think there are at least a couple (improving BGP security, for example), and the number will probably slowly shrink over time, but in the long run, I expect there will ultimately always be a few big things that need to be done that can't be done in end systems. Start from the end: there _will_ be a number of things that shouldn't be done in end systems. End systems _really_don't_ want to worry about the route packets follow -- at most they want to worry about delay, jitter, and order of delivery. But they _will_ work with whatever tools are available to ameliorate such worries. The number of problems will most surely _increase_ over time, not shrink. BGP security is a _dreadful_ example. It conflates weaknesses of the original design with issues entirely out-of-scope of the original design. And the original design was seriously flawed by defining algorithms instead of meanings. Nonetheless, the example does serve to illustrate a weakness of IETF process -- that it's much easier to get traction on small fixes to parts of the problem than on migration to a design which avoids the problems. BTW, I find it interesting to see how little of the work originating in the Security area has gained traction. I wonder to what extent this results from: - cycles being expended on cross-area reviews; - recommending IPsec whether or not it could be deployed for the use; - the inherent complexity of key infrastructure? -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
