Interesting People mailing list archives

Re: UN calls for global cyber treaty


From: David Farber <dave () farber net>
Date: Mon, 1 Feb 2010 22:08:43 -0500



Begin forwarded message:

From: Karl Auerbach <karl () cavebear com>
Date: February 1, 2010 8:43:00 PM EST
To: dave () farber net, tongia.cmu () gmail com
Cc: ip <ip () v2 listbox com>
Subject: Re: [IP] UN calls for global cyber treaty
Reply-To: karl () cavebear com

On 02/01/2010 02:55 PM, Dave Farber wrote:

*From:* Rahul Tongia <tongia.cmu () gmail com <mailto:tongia.cmu () gmail com>>
*Date:* February 1, 2010 5:53:04 PM EST
*Subject:* *Re: [IP] UN calls for global cyber treaty*

One REALLY has to design cybersecurity up front - and this may mean
NOT using the public internet for anything even remotely critical, or
adding layers of security, access control, gateways, and segmentation.
One can use internet *protocols* - that doesn't make it the Internet.
It's not that hard to create a separate network for a smart grid -
SCADA systems have been doing it for years. The world's largest SCADA
of its kind is actually up and running in India (built by ABB).

While I agree that it is a good idea to keep important infrastructures clearly separate from the main body of the 
internet as a practical matter there will almost always be leakage as a result of human error, the introduction of new 
equipment (and the need to install the latest updates to that equipment), and from ad hoc test rigs used when working 
around problems.

But in addition, even well run and isolated networks can collapse.  I've seen it happen.

A typical cause is the introduction of a new piece of equipment that speaks a more extensive or newer dialect of a 
protocol.  I've seen older equipment go bizonkers (that's a word of art in the network repair biz) when it gets hit 
with packets from the new equipment.

In one case I saw a bit of new gear that decided, quite legitimately, that when it fragmented an outgoing IPv4 packet 
that it would send the last fragment first (the argument to do this has to do with the ability of the receiver to have 
earlier knowledge of how much reassembly space it might want to set aside; such information is available only from the 
last IPv4 fragment.)  Trouble began when that new box was introduced onto a net was full of brand X gear.  The Brand X 
gear had been running smoothly for a year or more but it had a latent fault - it would promptly up-and-crash when it 
got a last-fragment-first chain of fragments - but that fault never surfaced until the new box came to town.

The point I want to make is this - there is a lot of code out there on the net that is very poorly written and may 
never have been tested in circumstances beyond the developer's pristine lab network.  Such code may well be code that 
is waiting to go "boom".

My company (InterWorking Labs) is in the business of testing the robustness of certain internet protocols, so we see 
this kind of stuff fairly frequently.

Unfortunately the internet-software business has inherited a tendency to do only minimal or limited conformance testing 
without much concern for the flip-side, the susceptibility of the code to error or failure when odd (sometimes RFC 
legit, sometimes not) packets arrive.

        --karl--




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com


Current thread: