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

[[e-mail] (Pekka Nikander)]

>> No, we are not achieving [demultiplexing] through SPIs.  We are
>> achieving [that]=A0through 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.
>
> I understand this point. And I totally agree with you that keeping
> the SPI (or even HIT, if someone so wanted) in every packet is the
> right architecture.  What I don't agree with is that the protocol
> that does the binding between the current IP address and a
> corresponding HIT should also be an IP protocol type.

Ok.  I understand your stance, but disagree.  A perhaps major
source of my disagreement is that I don't consider HIP just as
a binding management protocol, but as a new, full layer.
But let's see...

> I guess the difference in opinion is because in my mind,
> multiplexing connections and managing bindings are separate
> issues (and it might just be my tunnel vision).

I don't quite understand what do you mean with that statement.
Reading further...

> To me the present HIP key-exchange is a connection oriented
> protocol, unlike the traditional connectionless model of IP.

Ah.  But by adding replay protection to IPsec you basically make
the whole IP layer to have state, i.e., connection-oriented.

Apparently we need to go into fundamentals.  For more on my
stance on this, see

Tuomas Aura and Pekka Nikander, "Stateless connections," in
proceedings of International Conference on Information and
Communications Security ICICS'97, Beijing, November 1997,
pp. 87-97, Lecture  Notes in Computer Science 1334, Springer
Verlag 1997.

Trying to summarize some of the thoughts in that paper, the basic
difference between connection-oriented and connection-less
protocols is where the state is maintained.  The organization
of retransmissions is less relevant, as is congestion control.
They are different aspects, and almost orthogonal.

In a connection-oriented protocol you keep state on both ends.
(According to this classification, a bound UDP socket is
connection-oriented.)  In a connection-less protocol you
typically keep state only at the client/initiator/whatever end,
or at neither end.  In the latter case the state is typically
kept at the higher protocol layers.

In traditional IP, all state is at upper layers.  The only state
that IP needs to keep is the routing state.  Especially, there
is no state associated with a given peer IP address.

This all changes with the introduction of IPsec, and especially
when you apply replay protection.  Then you have to keep state
per peer address, including the session keys AND the replay counter.

 =46rom this point of view, making the HIP control protocol something
that is more or less parallel to ICMP is the right choice.  (This
stance is strengthened with middle-box considerations.)

> So I am a little reluctant to mix the key-exchange
> (ip-to-hit-binding-management) with the actual packet processing
> (which I want to keep connection less).

Well, that is not mixed, currently.  In effect, you are now
arguing that instead of allocating one protocol number, we should
allocate two:  one for HIP control traffic, and the other one
for HIP data traffic.  The fact that we are using ESP for the
latter _is_ problematic, but currently it is the best we can
easily do without allocating yet another protocol number.

> Note that the way ESP is designed, is connection less

But it is not :-)  Already the keys create a kind of peer-to-peer
connection, and that is made much stricter and stronger with
the introduction of replay-protection counters.

> (even though aalmost all key exchanges, even for Multicast, will be
> connection oriented running as applications on some transport=20
> protocol).

Remember my earlier comment about the relationship between a control
protocol and the corresponding payload protocol?  I don't want to
repeat that.

Think about parallels in modern design:
- ICMP runs on the top of IP, which it controls.
- SIP runs on the top of UDP, which it typically controls.
- HTTP control is in-band.
- SCTP and TCP control is in-band.
- most routing protocols run on the top of IP, which they control

Hence, the majority of IP world control protocols seem to run either
directly on the top of the protocol that they control, or in-band.

The notable exceptions are IKE and some routing protocols.  In the
routing protocols' case TCP is used for retransmissions.

 =46rom an architectural point of view, I consider the IKE case
especially problematic, as it requires a specific exception to
the default IPsec policies in order to allow IKE to get through.
Such exceptions make any architecture less beautiful.  (Read:
I still think that some aspects of IKE stink, even with IKEv2.)

In summary, to me it is almost impartial whether the future
HIP will be based on a single protocol number, where both the
control and data protocols share the same protocol number,
or whether we use two protocol numbers.  What I am opposing is
moving the control protocol to an upper layer, where it does
_not_ belong.  I slightly favour two protocol numbers, as using
two protocol numbers makes it easier to separate control and
data traffic at middle boxes.

> I would like to keep the connection-less model of IP as it is,
> even after introducing the layer 3.5, and to me this means
> separating the binding management from the actual packet processing.

I don't have anything against separating the control protocol
(your binding management) and the data protocol (your packet
processing).  That is what we effectively do today.

What I am opposing is the idea of unnecessarily inserting another
protocol between the control protocol and the data protocol.
That opposition is purely architectural, as I have written a
number of times.  Practical matters weight otherwise, and as I
have written, if people want to write a HIP-over-UDP draft, I will
be in favour of accepting it as a WG item.

> I think it's okay to gain experience using the present draft
> (i.e., IP as MUST as you want, and UDP as SHOUD/MAY/OPTIONAL--
> pick one).  We can always come back during STD track discussion.

Agreed other than that if there is UDP, it should be OPTIONAL,
or at most SHOULD implement, MAY use, default use being IP.

> I guess the implementation viewpoint is just the reflection of
> present architecture. I like the present architecture, but I
> also like the ideas  of HIP. And I want both. :-)

You want the benefits but not the drawbacks. :-)  How nice. :-)

More seriously, for me the new architecture that HIP presents
is much more important than the features it gives.

>>>>>     IKE is implemented on UDP for a good reason.
>>
>> Out of curiosity, what are those good reasons?
>
> ... I am just extrapolating what I understand ...

Still, it would be nice to explicitly hear what you understand
so that I can rip it down and tear in pieces :-)

> Another point that Steve Deering made during the IETF plenary
> session of August 2001 was to look at Internet Protocols as an
> hourglass whose waistline is IP. There is advantage in keeping
> that waistline thin (and straight), IMO.

I was there.  Many people think that it is time to move that
waistline on the top of IP (or around IPsec), which is exactly
what HIP is doing.  (The motivation for moving the waistline
up is that we currently have two waists, IPv4 and IPv6.)

> My rule of thumb: if its not related to routing, don't put it
> near IP (take it of leave it; I'm not going to argue either
> way on this. :-) ).

The current IP has much more than just routing.  IPsec is a
main culprit (if not the main culprit) for that.  Based on your
argument, we should get rid of IPsec and use TLS.

The "lower" part of IP, which implements routing, fragmentation
and few other things, is fine and dandy.  It is the upper,
host-specific part of IP which has become bloated and ugly.
If I was to blame a single party, I would point to the VPN and
IPsec gateway folks in the IPsec WG, and Paul Francis for inventing
NAT.  But that would most probably be unfair.  More seriously,
I think that the current situation results from too little
direction from the IAB and too little architectural house-keeping
from the IESG members.

--Pekka