update

Tue Sep 30 03:10:45 UTC 2014

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