IMHO, this thread of this discussion belongs to the HIP WG list. I
am replying there.
--Pekka Nikander
On Sep 17, 2005, at 15:48, Iljitsch van Beijnum wrote:
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