On 09/29/2014 01:14 AM, Larry Sheldon wrote:
On 9/29/2014 00:32, Pete Carah wrote:
For that matter, has the*specification* of tcp/ip been proven to be "correct" in any complete way?
I find that question in this forum really confusing. I was adding it to Valdis's statement about proven correctness of the TCP/IP stack. It is only possible to prove correctness of software in relation to a (assumed) correct (and complete) specification. Correct software relative to a spec that doesn't relate to the real world may be considered correct but will still fail in application. Many of the famous failures of military systems (and many more from commercial systems) come from bad (or missing) assumptions in the spec, (and many also from bad implementation, to be sure...)
The thread in question is more about security than interoperation, and real-world effects of both compliant and non-compliant uses of the net. The real point is that many of the features included in tcp/ip to handle random occurrences make purposeful interference *worse*. In a world with purposeful attacks, those specifications have to be amended; in that sense they are not "correct".
I thought all of the RFC-descriptions of protocols were taken to be statements that "if you do it this way, we think we can inter-operate" but at no time to be taken as "right" or "wrong".
The use of modals (MUST, MUST NOT, SHOULD) in the specification implies a sense of correctness. Indeed that is mostly there to guarantee interoperation. In the early days (pre-mid-80's) the security aspects of the protocols was minimal; it was assumed that people would pay attention to the specs. Now we have players that (use spam for an example, again) (mostly) completely comply to the technical specifications but manage to bring the net to its knees anyhow, and also players that test what (mostly) minor violations to the spec will do to the rest of the net. (try to defend against a joe-job using stock qmail, for example; that system is completely compliant to the (older) RFCs and cannot handle significant amounts of forged mail, mostly due to its completely compliant handling of bounces. And some of the MUST statements in earlier application protocols (821/822, for example) have had to be turned off in order to defend against such purposeful actions (e.g. bounce all messages that fail delivery; doing so makes the spam problem MUCH worse.) The protocols have to be adapted to handle attacks, there is no alternative. In that way, there is (in some sense) correctness or not. At least the RFC system does allow for fairly easy (but not too easy) modification with experience. -- Pete