On 15-sep-2005, at 9:57, Pekka Nikander wrote:
So, as I state in my little web page, I think we really should
work hard to create a new waist for the architecture. I, of
course, have my own theory where the new waist should be and how
it should be implemented,
Well, don't be shy: where can we absorb these insights?
Unfortunately I don't have any concise summary of my "theory", but
wading through my academic papers (available through my home page)
should give a fairly good view.
[HIP]
But, as I wrote, I am trying to take distance from these and trying
to understand alternative approaches, like "virtualising IP" or
"domain-based internetworking" that some people are thinking
about. It is now mostly other people that are continuing the HIP-
based work, for example, at the CEC funded Ambient Networks project
and at the IRTF HIP Research Group.
I think HIP is on the right track in some areas, but I don't like the
protocol as such because the overhead is too large, and I think even
though it's fairly radical in some ways, it doesn't go far enough.
For instance, the first sentence of any new internet architecture
would have to be: one size does NOT fit all. The assumption that it
does has allowed a lot of great work in the past. For instance, for
some time, TCP was able to accommodate the slowest possible links and
the fastest. But that's no longer true, so now we have to choose
between enabling RFC 1323 high performance options to allow high
speed downloads across the globe, or disable them and allow for
header compression to optimize for low speed links. Unfortunately
most operating systems enable the options, killing header
compression, while applications fail to use buffers that are big
enough so long distance high speed downloads aren't possible either.
That kind of stuff is very common in today's internet.
We also need to address the need of intermediate systems to influence
the communication between two endpoints in various ways, without
killing the end-to-end principle wholesale.
Routing, naming, addressing and layering is a big mess in the current
"architecture". (I'm using quotes because all of this evolved over
time without noticeable architectural oversight.) CIDR was a step in
the right direction, but now it's time for the next step: make
addresses variable length. (One size doesn't fit all.) Port numbers
should be part of the address to allow for easier filtering. Having
DNS names is great, but applications shouldn't have to deal with name
to address mappings: we need a new API that hides addresses from
applications that don't have any need to look at them. HIP does get
the locator/identifier idea right. In addition to that, we need to
abandon the notion of one single network with a fixed root. By
allowing each point in the network to be the root, and map all other
parts of the network to arbitrary parts of the hierarchy as seen from
a given root, we can impose the constraints required by many
organizations. Interdomain routing needs more link state like
mechanisms in order to get rid of BGP's version of the count to
infinity problem. It also needs to work when the view of the network
is incomplete, while at the same time taking advantage of additional
topological information when available. (This includes taking
advantage of geography in routing.) And interdomain routing shouldn't
be subvertable like it is today.
Coming back to IPsec: we need more of this. TLS is broken because it
doesn't protect the underlying TCP session. We need an API that
allows applications to do an IPsec version of "STARTTLS". (It would
be nice if we could do authentication first and then encryption,
unlike it's done today, to get rid of at least SOME of the huge IPsec
overhead: the auth data can then be the encryption IV.)
In other words: we now need to do everything that we didn't do until
now because it was too hard.
Ok, that's my rant for today. :-)
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf