Protocol type for HIP -- was -- Re: [Hipsec] Moving the base spec forward

[[e-mail] (Pekka Nikander)]

> I strongly disagree with this. Let's backtrack a little bit here. In 
> the
> past (and present) we have used the socket quadruple to demux different
> connection. The assumption was that the quad will not change after
> connection setup. With mobility and multi homing, the IP address 
> change,
> so we need a new mechanism to demux different connections.  You are
> achieving this through SPIs.

No, we are not achieving this through SPIs.  We are achieving this
through using the HITs in the socket and the pseudo-header, as
Tom already wrote.

There rest, like using SPIs as a shorthand, is details, and not
important from the highest architectural-level point of view.

The rest of your argument doesn't hold, as it looks at the situation
from a very different point of view.  While your viewpoint is true
for many of the current implementations, it misses the architectural
change.

> Also, if you want to support multicast using HIP, you will need yet
> another  key exchange--substantially different from HIP key exchange.
> Are you  proposing to use another protocol-type for multicast key
> exchange.

Of course not.  There are more than enough space for extensions
in the current HIP protocol.

> And yes, you can multiplex all of them on the same protocol
> type, but then it will be my turn to cry the complexity wolf.

I still hold the opinion that architectural complexity is well
measured by the number of LOC needed to implement it.  (With
some caveat emptors, of course, like not accepting ugly code.)

As you add more features, you need more code.

If your new protocols can benefit from existing infrastructure,
in a clean way, then you can save in terms of LOC.  In other
words, I don't buy you argument that implementing different
kinds of control protocols within a layer 3.5 control protocol
is necessarily bad design and leads to complexity.  Using
TCP or UDP demuxing may lead to architecturally worse complexity,
like necessitating built-in port based policy rules.

> To me, architecturally it seems cleaner to keep the SA management 
> (i.e.,
> 3.5 layer management) separate from the 3.5 layer itself. HIP key
> exchange is a 3.5 layer manager, and there is no need to mix it with 
> the
> 3.5 demuxing layer itself--which you achieve through SPI.

This is a fundamental difference in opinions.  Some people hold the
opinion that it is better to have separate control protocols and
separate data traffic protocols, like in the telephone networks.
Some people think that it is better to have in-band signalling,
like in TCP.  I guess my opinion is somewhere in the middle ground.
Especially, I think that Layer N signalling should not depend on Layer
N+K protocols for any K>0.  Consequently, Layer N signalling is
always either in-band at layer N, or directly at Layer N+1.

(You can read the comment above that IKE, with is use of UDP,
is badly designed.)

Another issue here is, again, middle boxes.  Having the control
protocol on a separate protocol number makes it easier to separate
data traffic and control traffic on a middle box.  No need to
look inside ESP, TCP or UDP, and therefore simpler fast path.

>>>     IKE is implemented on UDP for a good reason.

Out of curiosity, what are those good reasons?

> http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-06.txt?
> Isn't this draft in RFC queue right now?

-05 was, but was pulled back for a number of reasons.  The current
plan is to resubmit -07.

--Pekka