Comments: How to avoid Yesterday's Unknowns - Algorithm Agility in Protocols


This problem of agility is one which has an underlying problem (lack of foresight).

NIST amongst others are addressing "the how" not "the why" of the issue.

That is they are specifing specific ways to do a particular job (AES etc) but not a suitable framework within which it operates.

One of the issues with this is that the "how" method gets to tightly bound within specific applications, which gives rise to the issues of inflexable legacy systems.

It might be ok to talk about a five year cycle for software only application, but not for infrastructure hardware systems where twenty five to fifty year life cycles are more likley.

Although it sounds superficialy like just an API, the framework needs to be more indepth than that partly due to the nature of "embeded systems".

It needs to give consideration to "the why" of what people do at all levels of application.

Unfortunatly it is not going to be an easy task but the sooner it starts the less pain there will be in the long term.

As an example consider the US DOD Internet Protocol -v- ISO OSI X model that originated in Europe. The OSI X protocols were at the time generaly considered so over engineered and specified as to be impractical to implement, and it was certainly true that the resources required in many cases where just not available.

The US took a pragmatic approach with DOD IP, which now predominates.

However IP has had very significant growing pains, backward compatability issues are a nightmare, and security not even an afterthought.

In practice what is now happening is that "the why" that was envisioned in the European OSI framework is retrospectivly being built into the US DOD IP bit by bit.

However this bolting on what is now needed is causing inefficiency incompatability and add hoc protocols that are ill thought out within the greater context they have to work in and frequently are found to be defficient to the point of being broken in that context.

Although from a "market perspective" obsolecensse is a given, an assumption of a short 18months life cycle (for software and FMCG) is not valid for all markets (Infrestructure for power, water, comms etc).

Environmental considerations are going to push more and more long life cycle systems into the world, as is legislation for National Security of Infrestructure and environment.

The current "hamster wheel of pain" of patching, upgrading, and throw away technology seen, is not sustainable even in the SOHO PC and low cost server market.

But unless the appropriate frameworks are put in place the hammster will run for practical purposes indefinatly without getting any where.

This will put significant limitations on what can and will be achived, due to resources being wasted on the inordinate update process.

As an example think about your home heating and air conditioning being controled by the utility supplier to manage demand against resources and capability.

Some juresdictions are looking at making this a legal requirment.

Now consider what could happen if the equipment is designed "optimaly" for todays market and with little thought about the security context.

Two things are going to happen.

The first is utility suppliers will opt to not upgrade long term fundemental supply infrastructure, just more and more limit supply against increasing demand (cheapest option for them). As time progresses the supply network will become more and more brittle.

At some point something will happen, such as an operator will make a mistake or a natural event will occure or somebody with deliberatly intent will make changes. A cascade failure will occure and if you are lucky all that will happen is a few hours black out while the fault is found and the utility network restored.

But what happens if it is a person of ill intent who wants to deliberatly bring down the utility network?

The chances are that if they know what they are doing they can do damage that is so fundemental to the utility network that it could take months to repair or replace (see Peter Gutmanns paper on what happened when a major electricity supply was lost).

And unless the security is changed in all those heating and air conditioning units the same thing will happen again and again.

Now think of the cost and work involved with making the security changes...

If however the apropriate framework was inplace prior to the controlers being built, then although the unit cost would be fractionaly higher (by a cent or two) making the changes could be done as and when required with minimal cost.

However if built in correctly as an overal system it would be more flexable and importantly resiliant thus significantly reducing the future risk and thus cost.

Posted by Clive Robinson at September 9, 2009 05:26 AM
Post a comment

Remember personal info?

Hit Preview to see your comment.
MT::App::Comments=HASH(0x55cf8e20a278) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/ line 125.