Re: [colorforth] DARPA takes aim at IT sacred cows

["Samuel A. Falvo II" <kc5tja@xxxxxxxx>]

On Friday 12 March 2004 03:08 pm, John Drake wrote:
> Linux isn't invurnerable either.  He might be

Yes it is.  It's the *services* that run *under* Linux that is 
vulnerable.  I can't think of a *single* exploit under Linux that 
doesn't involve the server software itself, somehow.

I raise this point because it's far, far easier to retrofit (or start 
from scratch) new server software than it is to develop a totally secure 
operating system from scratch.

> interested in eros, KeyKOS or any of the other
> "capability" system.
>
> See: http://www.eros-os.org/

Yes, I've been advocating key-based/capability-based operating systems 
for years.  But having a good ACL-based architecture will be just as 
usable.

> I'm not sure why you would add "hopefully" to that
> last sentence.  First of all the Internet was
> originally designed for military use.  Now they

Yes, but it was never designed for *command and control* applications.  
It was designed to facilitate communications between academia and 
government organizations -- e.g., to assist the researchers in their 
quest to develop new technology for the military.

I would like to point out, however, that IPv6 addresses *every* *single* 
*problem* that Mr. Gibson brings up.  I cannot fathom how he cannot 
possibly know this.  IPsec has been part of the IPv6 initiative from the 
very *beginning*, and has been part of *commercial* demand, not 
military.  So go figure.

NSA, we know you're watching this.  Do us a favor, and forward this 
message to Mr. Gibson in DARPA.  It will make his life way, way easier.

> are rethinking that design.  If this "rethinking"
> results in more resilient systems then we'll likely
> see the new technology crossing over into the
> private sector.  If it doesn't work then we won't.

The technology is HERE ALREADY.  It is simply not being adopted.  IPv6 
addresses *every* issue.  The packet headers are much simpler than IPv4.  
It's easier, more modular to implement.  IPsec provides a level of 
security which heretofore *NO* other network service provider has been 
able to compete with.  Etc.  Etc.  Etc.

Yet, where is it?

What needs to be done is this:

1.  The adoption of FEC in addition to the existing ARQ methods.  This 
means, should a packet get corrupted during transmission, FEC codes 
(which are usually smaller than the packet itself) can be requested, 
thus saving network bandwidth.  When both nodes keep track of how often 
they request FEC packets, they can optimize by pre-broadcasting the FEC 
data directly, thus reducing the 3-way handshake (costs time) involved 
with retransmissions over channels which are *known* to be unreliable.  
When conditions improve again, the FEC codes can be scaled back in favor 
of more data.  Voila -- automatic bandwidth management.

2.  Get rid of CSMA/CD!!  It worked great in the late 70s and early 80s 
because it was cheap to implement.  It has been shown to cut bandwidth 
utilization by up to 50% however; thus, on even a mildly congested 
Ethernet network, don't expect throughputs to exceed 5Mbps (or 50Mbps 
for 100-base-T on a HUBBED network).  Since nearly *every* modern 
network is built on *switches* today instead of hubs, we should instead 
switch to token ring or DAMA, which will eliminate the whole chunks of 
time wasted for CSMA listening, and it'd eliminate collisions 
all-together.  Token ring with Early Token Release makes 100% bandwidth 
utilization a reality.  DAMA easily matches token ring performance, AND 
provides ATM-like quality-of-service capabilities on top of that.

If adopting a DAMA or Token Ring approach, we can get rid of those stupid 
6-octet Ethernet MAC addresses too.  They can be easily reduced to one 
or two octets, and can be automatically assigned by the MSAU as nodes 
join the network.  Thus, MAC-address spoofing becomes moot, and leaves 
more room for what really matters: IP packets.

(for the record: amateur packet radio typically occurs at 1200 bits per 
second.  Yes, that's 1200.  Hence, when digipeater owners adopted DAMA 
over the normal CSMA to control contention on their networks, they 
noticed a 100% improvement in network throughput.  At 1200bps, this is 
*readily* observable.  Folks are generally very pleased with its 
performance.  The only time the DAMA network slowed down at all was when 
a local node accessed another local node; however, this has to do with 
the nature of radio when two stations can log into the digipeater, but 
cannot hear each other [called "hidden transmitter syndrome"].  Thus, 
the digipeater must repeat any and all packets, including those that 
remain on the local network.  Clearly, on a wire-based network, or in a 
radio network where all nodes are guaranteed to hear each other [like 
802.11], this necessity can be optimized out.)

> one could build a complete "peer-to-peer" wireless
> net that operated in the unregulated "Wifi"
> bandwith.  My PDA sends a message to your PDA

We ham radio operators have been doing this for decades.  And we continue 
to do it today.

RF transmission is essentially true "Ether"-net -- the electromagnetic 
spectrum is the ultimate peer-to-peer interface.  When one node 
transmits, *all* other nodes in reception range can hear it.

It's a pity that to get long-range communications, one still must use 
'digipeaters' (a cross between a ham radio repeater, and a 
store-and-forward node similar to an Ethernet repeater).  Thus, packets 
are typically ''source routed.''

Something which I will be exploring in the future is a network route 
management system similar to the technique employed in "The Circle."  
Which brings us to . . .

> which keeps forwarding it till it gets to the
> correct destination.  Just one idea, there are

You might want to check out the old P2P network called "The Circle."  I 
*loved* that network concept, and it even builds its own routing 
structure dynamically.  Because the degenerate Circle network is a ring 
that behaves similarly to token ring (though not quite; it's hard to 
explain), it's possible for a node to learn of its neighbors.  Since 
each node either knows or will learn which neighbors (which need not be 
adjacent on the Circle) are reachable on its local network media, the 
routing table is truely distributed, truely dynamic, and almost always 
in working condition at all times.

In short, it blows away our current routing infrastructure in terms of 
robustness.  The disadvantage is it takes a short while for the network 
to learn of which neighbors are present (over long distances, this can 
take up to 24 hours -- but this isn't really a critical problem: it 
takes about that long to update a DNS record *anyway*), and it doesn't 
permit hierarchializing the network (as implemented in the Linux 
software implementation; obviously, it has no need for doing so).  But, 
as you say, the research possibilities are there.

> many.  But don't worry.  The current generation
> of the Internet won't disappear just because
> DARPA is thinking.  But the future may be better

No way.  The commercial industry is WAY too heavily invested in the 
current IPv4 infrastructure.  I feel this, more than anything else, is 
the primary reason why IPv6 hasn't been adopted by now.

--
Samuel A. Falvo II


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com