Dear Scott, Interesting as this matches the conclusions of our own meetings in Dec/Jan on national vulnerability to internet.
At 03:48 14/03/04, Scott Michel wrote:
DARPA's network research direction has been somewhat aenemic over the last couple of years, given the force protection focus and GWOT mission to which DARPA has adapted. It's pretty easy to overreact to the DARPAtech stuff, esp. when a PPT slide or news article says "IP is broken".
Agreed. But for a non US observer this sounds in line with the pro-IPv6 stance of DoD: obeying http://whitehouse.gov/pcipb marching orders.
IPv6. IPSec, DNS and Gateway protocol redesign (more detailed, may be, in preparatory 2002/11/15 document)?
IP isn't broken. From a program management perspective, "IP" is merely referring to a large number of interacting protocols, from the lowest level physical layer to the application layer. If one reads the article with a little more care and not as a manifesto, DARPA is interested in a protocol suite where static (wired) networks are a special case. What exists is a network system where the dynamic (mobile/unwired) network mgmt is grafted onto the static network, treating the dynamic network as a special case. DARPA wants to change the way protocols are designed, where the network is primarily designed for dynamic nodes (and all of the overhead that entails). I wouldn't read much more into the program statements than that, despite the fact that controversy makes good press.
May be am I candid, but I tend to think that when a military person speaks, it is with a purpose. And usually that telling what you exactly want is the best way to obtain it. The article does not say they want to kill IP, but that they want solutions. There are three possibilities to support changes:
- to fix IP - to change IP - to replace IP
I would read they are interested in the three of them, in parallel.
I read they have identified a need (the same as NSI said they had a need through PathFinder) and that the ball is in the IAB and IETF's field (for a short while if you consider how long NSI awaited before suing ICANN)
Let us hope reactions in here will be more positive than to Richard Clarke. Or to my own December queries..
One really good example of what the program is most likely aiming toward is the MIT RON research. It's not the IP routing protocols or the 2-tier routing hierarchy that's broken, it's the fact that these protocols converge so slowly to repair the network. Thus, RON is successful in the fact that traffic can continue to get to its destination via the RON overlay despite the routing reconvergence and the time it takes for reconvergence. Currently, RON claims to improve reliability by orders of magnitude rather than fixing routing protocol brokeness.
Let see the situation through military eyes. The battlefield is what it is. For the new Cyber Forces, the internet battlefield is what is used today. So they are interested in what is available/under serious development - or in what worked before/aside the IP technology and which could be deployed quick (so, most probably a total change for a clean sheet, low cost and confidential restart).
They also want to get their own controlled solutions. The same as an Army uses existing bridges and bridges, even poor ones. The same it mends them if needed. And builds it own ones when necessary.
May I suggest, that these guys' priority is not really to respect RFCs, but to protect your lifes?
The article also mentioned something along the lines of "Redesign The Seven Layer Model!" Frankly, I've always preferred the four layer IETF model because it didn't have the extra useless layers; but hindsight is 20/20, after all. I could look at the ceiling and foresee the session and presentation layers suffering the death they truly deserve, but the remaining layers staying intact. Layers may need subdividing or even outright addition to the current model so that overlays and the recovery semantics they provide are more explicit.
Real life is not monolithic. Fighting for one model against another is a very strange idea. Would aggregating models, so they may have some consistency (as the low layers do) and synergy, and picking the one which works for each task at hands, not be a more pragmatic and scientific approach?
SMTP is not a good example of what's wrong with IP and I'm not even sure why COL Gibson or the other presenters even used what's arguably the most successful Internet protocol example.
May I suggest that the example is good as an image. Datagram, mail, file concepts are part of the "postal like" paradigm of the 60s. This paradigm is that everyone can send you a text and you sort them when received. You are to authentify every piece of data you receive and can be subject to saturation deliveries (DoT, spam, viruses). Under this paradigm you defend yourself at your gate, like a fort. You are under enemies's fire.
You may imagine other paradigms where you protect yourself remotely. And put the enemies under your own fire first, and protect your communications lines.
Of course, if DARPAtech had worded their presentations with less controversy, most participants would have yawned and said "Oh, yeah, business as usual -- nothing interesting here." Death and complete redesign of IP? Not likely in my lifetime 'cos "It just works, mate!"
In my own lifetime I saw three working technologies (based upon three different paradigms) used for what the users name "internet" today (Tymnet, OSI, Internet). Only the first one supported them three (as well as most of the leading private ones). And whet I hear every where is "when you think of it, it just does not work". So I suspect I will see one or two other ones.
Why not to have a try at:
- analyzing an extended network model where the datacoms various models and layers are encapsulated into the physical, operational and usage layers?
- accepting that the datacoms ecosystem needs to support many different data and objects granularities, including the current IP ones. And to have a try at a universal packet protocol, starting from IP as the prevalent one, and progressively extended its capabilities?
- working also on a progressive unification of the same layers, across models, when possible. To maintain the funding uniity and the consistency a distributed system needs.
jfc