Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[LinkSec] scope (resend)





Well of course we all hope wisdom and broad vision succeeds in all things
(with no time penalty, the net present value of perfection at some
undetermined future time being low).

However I have to say that 20:20 foresight is rare and that extensibility
often turns out not to have been provided in the direction that was actually
required with hindsight, but in fact in some other direction , not actually
required but only vaguely, wishfully conceived, and 'obvious', but bringing
in many complications. If something can't be fully worked out it has not
been future proofed, but just complicated.

There is a means of extension for all layer 2 protocols, it is called
another Ethertype/protocol.

A less wasteful extension, in some circumstances, is the protocol version,
but that brings in the need for considerable foresight and discipline on the
behavior of current implementations to process future versions.

So the question, I submit, is how any aspect of extensibility can be
incorporated in any aspect of the protocol (let's take a secured packet
format as a simple thought experiment, and much the easiest to get right)
such that the following tests can be applied to the extensibility:

(1) The design imposes no or miniscule implementation burden over a possible
substitute design which is not extensible, and as such is not prey to being
substituted out in favor of 'more efficient' proprietary protocols or indeed
completely different standard solutions.

(2) The extension does not provide a number of options which can be
conformantly selected in different ways by different vendors, such that the
standard becomes only a cloak for lack of vendor to vendor interoperability.

(3) The behavior of any conformant implementation in following the design
does not differ in 'immediate' use from the behavior in 'future extensible'
use, and the fully range of behavior is exercised in current deployment, or

(4) The future use is tightly specified, and mechanisms are in place to
ensure that all implementations will be both rigorously tested by the QA
organizations of their developers and conformance test organizations across
the complete spectrum of potential use (as opposed to how they are going to
be used for the next few years in customers networks).

If the last condition is not met all that will be achieved is the ability of
the standards group to say simply and smugly 'not our fault, we provided
extensibility' when it turns out that the world has been populated with
implementations that will work according to the realistic immediate goals of
the standard, but require any given network to have a 'flag day' on which
all old implementations are removed before the new extensible
implementations are deployed. This can actually be worse than deploying a
new completely distinguished protocol to meet the new, and by then fully
designed, extended objectives.

There is of course another form of 'extensible' as applied to a standard.
This means that the standard has been technically constructed to allow
additions to be made to it over a period of many years by the originating
group, rather than ceding the turf to any other group with a
newer/broader/different scope. This form of extensibility is quite easy to
arrange, but is a tax on rather than a benefit to the end user, since it has
no hurdles of future compatability to overcome, just vague promises of
inves_ment protection. I hope we can recognize this error if we ever come
close to it.

Mick




-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Rene
Struik
Sent: Monday, April 28, 2003 8:10 PM
To: Russ Housley
Cc: Dolors Sala; Mats Naslund; LinkSec
Subject: [LinkSec] scope



Dear all:

The proper approach is to define a security conceptual blueprint that allows
for
extensibility. Once this is done, one can care about the partitioning of the
security in things that are inside and those that are outside scope. As far
as
extensibility goes, it is not so easy to extend single-hop scenarios to
multi-hop ones if one has not given the latter proper consideration first;
the
other way around, however, is just a special case. I hope wisdom and a
borader
vision will prevail.

Rene