Re: [colorforth] DARPA takes aim at IT sacred cows
- Subject: Re: [colorforth] DARPA takes aim at IT sacred cows
- From: Adam Marquis <adam.marquis@xxxxxxxxxxxx>
- Date: Sat, 13 Mar 2004 11:13:37 -0500
Thanks for the update, I learned a lot from this discussion
(as I almost always do!), thats exactly what I want to do,
change the world, perhaps with a forth box ;p
In the car, house, skin, anywhere, as long as I'm in complete
control of (understand) whats going on, would be ok with me.
Would it be With you? With you? With YOU? ;pppp
I went to the NRC in Ottawa, WOW.
Samuel A. Falvo II wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com