Core vs. add-on architecture

[Michael O'Donnell]

I think that it is crucial for us to classify most proposals quickly into

1. Core architecture that must be agreed upon
2. Add-on architecture, for which we may try variations rather freely

For example, the switch from IPv4 to IPv6 is an issue in core architecture. In this category, consensus is crucial, and the Internet will move forward (or not) in a fairly homogeneous way, for better or for worse.

But, most other questions, even some that seem conceptually fundamental or overwhelmingly important, can be treated as add-ons. In the area of add-ons, we should "let a thousand flowers blossom," and let some reproduce, while others wither. Rather than debating whether or no some add-on idea is good, we should identify groups willing to try each.

For example, even something as important as DNS is probably in the add-on area, in the sense that we can try alternatives (Google, Yahoo, and other search services are alternatives to some of the value provided by DNS).

Now, I have convinced myself that a proposal is add-on by default, and we should have a list of the small number that are not, presumably starting with IPv6.

[Michael O'Donnell]

Followed by the dissenting view that my taxonomy entails:

I think that "overarching" is generally a bad idea. We should focus on underpinning design constraints. We should not treasure a set of principles that drive many different network activities. We should rather look for the minimal underpinnings that allow all sorts of different principles to be applied.

And now, for the total blasphemy, taking the name of NSF in vain: We should not seek a trustworthy network. Rather, we should seek a network that we don't have to trust, but one that allows us to build trust through the network when appropriate. The right infrastructure for building trust almost certainly does not involve support at the packet-forwarding/IP level. But, it probably does require a very small amount of global agreement on the distribution of public keys. This very small amount of global agreement almost certainly does not include the mechanisms by which those keys become trusted---those should be various and added on as the need justifies the expense.

I am rather astounded that trust got in as a fundamental starting point. It appears to me quite analogous to reliable delivery, which was so wisely omitted from IP. IP is valuable in spite of not providing reliable delivery. It gives us a platform upon which to build reliable delivery when it is worth the cost.

[Michael Rabinovich]

I think you are right we should carefully examine which of the use cases require redesign of the network architecture and which could be accomplished by writing better applications at the end-hosts. But I disagree that trustworthy is among things that should be an add-on to the untrusted network. I think Internet attacks, like spam, phishing, DoS, etc., are the biggest impediment to the Internet, and we have seen that the best industrial and research effort to combat it have failed to solve the problem. So, I think this makes it a good case that this could be a killer motivating use case for the new architecture.


Michael O'Donnell said:

Followed by the dissenting view that my taxonomy entails:
I think that "overarching" is generally a bad idea. We should focus on underpinning design constraints. We should not treasure a set of principles that drive many different network activities. We should rather look for the minimal underpinnings that allow all sorts of different principles to be applied.
And now, for the total blasphemy, taking the name of NSF in vain: We should not seek a trustworthy network. Rather, we should seek a network that we don't have to trust, but one that allows us to build trust through the network when appropriate. The right infrastructure for building trust almost certainly does not involve support at the packet-forwarding/IP level. But, it probably does require a very small amount of global agreement on the distribution of public keys. This very small amount of global agreement almost certainly does not include the mechanisms by which those keys become trusted---those should be various and added on as the need justifies the expense.

I am rather astounded that trust got in as a fundamental starting point. It appears to me quite analogous to reliable delivery, which was so wisely omitted from IP. IP is valuable in spite of not providing reliable delivery. It gives us a platform upon which to build reliable delivery when it is worth the cost.

[Michael O'Donnell]

Hmm. Among other things, you've reminded me that there are many different things that we might mean by "trustworthy." I wasn't even thinking of SPAM and other forms of flooding, which I think of as performance/reliability/congestion issues. I thought we meant things like authenticating identies.

Anyway, I'm not at all impressed with the "best industrial and research effort" in either case. Many of these things should be thought of in terms of adversarial strategy. It appears to me that we have mostly responded to immediate challenges. This is the way weak boxers lose matches. They keep responding to the last punch, while the adversary starts the next one.

In the case of flooding problems, we should focus on flanking moves that avoid much of the conflict. As far as I know (I'm not an insider in any emergency response operation), our long-term attempt to control congestion is embedded in TCP at the end points. This works very well when it works, because the sender can do the best job of reducing flow. But, it fails to combine power, knowledge, and incentive. The end points can be competent, or even malicious. Congestion is the desired result of a flooding attack. So, we probably need some sort of installed forwarding level inhibition to congestion/flooding, since the intermediate forwarders are controlled by those with the incentive to keep operations smooth. This probably means a more intelligent approach to dropping certain packets, based on congestion conditions. This is indeed a piece of core infrastructural architecture, and I just didn't think of it in the "trustworthy" category.

Regarding authentication, we have never taken the IPish, "end-to-end" approach. All of the deployed methods that I know of involve chains (or perhaps webs) of trust, involving serious administrative overhead to vet agents, and as far as I can tell, not actually providing much value. I think that a "best effort" on this problem would start with a promiscuous deployment of the basic resources for authentication, which at present are mostly public encryption keys, with no prejudice as to how they will be used. I predict that the most valuable (in the sense of number of uses times value per use) uses of public keys will not involve any rigorous connection to verified real-life identities. Rather, they will establish continuitity among sets of transactions, so that participants can evaluate the behavior of the other participants. Verified connection to external "identities" (which are often not nearly as reliable as they seem at first glance) will be expensive, and done only for particular transactions that require it. We will also depend, as does the world outside the net, on the ability to unwind erroneous and fraudulent transactions in many cases.

Promiscuous distribution of keys is probably a core architectural thing, but quite simple to do as a minor variation on DNS. The stuff that really generates bits of trust will probably be mostly add-on.

Michael Rabinovich said:

I think you are right we should carefully examine which of the use cases require redesign of the network architecture and which could be accomplished by writing better applications at the end-hosts. But I disagree that trustworthy is among things that should be an add-on to the untrusted network. I think Internet attacks, like spam, phishing, DoS, etc., are the biggest impediment to the Internet, and we have seen that the best industrial and research effort to combat it have failed to solve the problem. So, I think this makes it a good case that this could be a killer motivating use case for the new architecture.