Subject: [Hipsec] New and revised text for HIP arch: Why not IKE(v2)

From: Pekka Nikander <[email-masked]>
Date: Tue, 12 Oct 2004 10:50:40 +0300

Here is my attempt for some new text to the arch
draft:

       <t>While it would be possible, at least in theory, to use some
       existing cryptographic protocol, such as IKEv2, together with
       Host Identifiers to establish the needed SAs, HIP defines a new
       protocol.  There are a number of historical reasons for
       this, and there are also a few architectural reasons.  First, the
       authors feel that the way IKE used UDP is architecturally wrong.
       A protocol controlling another protocol (like ICMP controlling
       IP) should be located either at the same layer with or the layer
       immediately above the controlled protocol, unless there are
       important reasons for doing otherwise.  For example, in the case
       of IKE, the current design requires that certain UDP ports are
       excepted from the normal policy processing.</t>

       <t>Second, IKE and IKEv2 are, by design, very secure protocols.
       As an unfortunate side effect, that makes them unfriendly
       towards middle boxes.  As adding a new naming layer allows one
       to potentially add a new forwarding layer, it is very important
       that the HIP protocols are friendly towards any middle boxes.</t>

       <t>Third, from a conceptual point of view, the IPsec Security
       Parameter Index (SPI) in ESP provides a simple compression of
       the HITs.  This does require per-HIT-pair SAs (and SPIs), and a
       decrease of policy granularity over other Key Management
       Protocols, such as IKE and IKEv2.  Future HIP extensions may
       provide for more granularity and creation of several ESP SAs
       between a pair of HITs.</t>

Comments?

--Pekka

_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Oct 2004 12:20:55 +0300

Hi Pekka, and thanks for your text. It looks

>       excepted from the normal policy processing.</t>

Well, presumably the HIP protocol number would also be excepted?
Suggestion: delete the example.

>       <t>Second, IKE and IKEv2 are, by design, very secure protocols.

I have a feeling that the parts of the design that affect
middle boxes are more of an accident that design on purpose.
I wasn't present when the protocols were being designed, but
look at IPsec NAT traversal, for instance. Due to the placement
of the SPIs deep inside the packet in an encrypted part
and unidirectional SAs, NAT passage was not possible.
In latest standards this has been fixed by UDP tunneling
which on the other hand is quite open to modifications by
middle boxes or even other parties.

Suggestion: just say that the IKE-IPsec protocol set has
not been designed with middle boxes in mind.

>       between a pair of HITs.</t>

--Jari

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 12 Oct 2004 12:30:56 +0300

Tnx, Jari.

Here is the revised text:

       <t>While it would be possible, at least in theory, to use some
       existing cryptographic protocol, such as IKEv2, together with
       Host Identifiers to establish the needed SAs, HIP defines a new
       protocol.  There are a number of historical reasons for this,
       and there are also a few architectural reasons.  First, the
       authors feel that the way IKE uses UDP is architecturally wrong.
       A protocol controlling another protocol (like ICMP controlling
       IP) should be located either at the same layer with or the layer
       immediately above the controlled protocol, unless there are
       important reasons for doing otherwise.
       Second, IKE and IKEv2 were not design with middle boxes in
       mind. As adding a new naming layer allows one to potentially add
       a new forwarding layer (see Section <xref target="nat">, below),
       it is very important that the HIP protocols are friendly towards
       any middle boxes.</t>

       <t>Third, from a conceptual point of view, the IPsec Security
       Parameter Index (SPI) in ESP provides a simple compression of
       the HITs.  This does require per-HIT-pair SAs (and SPIs), and a
       decrease of policy granularity over other Key Management
       Protocols, such as IKE and IKEv2.  In particular, the current
       thinking is limited to a situation where, conceptually, there is
       only one pair of SAs between any given pair of HITs.  In other
       words, from an architectural point of view, HIP only supports
       host-to-host (or endpoint-to-endpoint) Security Associations.
       If two hosts need more pairs of parallel SAs, they should use
       separate HITs for that.  However, future HIP extensions may
       provide for more granularity and creation of several ESP SAs
       between a pair of HITs.</t>

--Pekka

---

From: Yu-Shun Wang <[email-masked]>
Date: Tue, 12 Oct 2004 10:14:46 -0700

Hi, Pekka & all,

Jumping into this really, really late. Aplogized in advance
if I missed some previous context.

I am not a big fan of IKE (v1/v2), but just feel something
is still missing in the reasoning below.

>       important reasons for doing otherwise.

I am not sure about this argument. In a way, the HIP exchange is
analogous to DNS, you contact somebody to resolve an identity in
one domain into an identity in another domain. It just happens
in this case the 'somebody' is also the destination you want to
communicate with. This exchange should be considered a separate
communication, and is free to use whatever protocol or even out-
of-band information if available.

It is just a process of resolving identities, I am a bit unsure
about the phrase "A protocol controlling another protocol..."
Maybe I miss something here?

>       it is very important that the HIP protocols are friendly towards

Not a very strong one, but I agree.

>       between a pair of HITs.</t>

This sounds like what we want is a subset of what IKEv1/v2 have.
This is an efficiency and optimization issue. I guess what I'd
like to see is a more compelling reasoning why we have to use
a different protocol. Otherwise another side of the argument
would be why not define HIP exchange as a profile of IKE to save
the trouble of inventing another protocol? (I'm sure you hear
about all that by now. Maybe even an ID in the work?)

(Again, I missed the previous discussion. Feel free to give me
pointers if all have been said.)

Thanks,

yushun

-- 
Yu-Shun Wang <[email-masked]>
USC Information Sciences Institute

---

From: Yogesh Prem Swami <[email-masked]>
Date: Wed, 13 Oct 2004 00:12:01 -0500

>       authors feel that the way IKE uses UDP is architecturally wrong.

I think you also need to say something about connection-less-ness and 
connection-oriented-ness. The way HIP is right now, it makes layer 3.5 
connection oriented, and honestly, I don't like it. (I remember you said 
ESP is connection oriented because of sequence number. But I checked 
rfc2401bis and it says sequence numbers are optional. ESP supports 
multicast, so it has to be connectionless.)

Also, the draft needs to say how HIP architecture affect multicast. If 
HIP doesn't target multicast, then that should also be stated, IMO.

Yogesh

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 13 Oct 2004 11:29:16 +0300

> is still missing in the reasoning below.

Well, as Bob has written before, there is a largish number of
historical reasons.  First, I don't even know them all.  Second,
even if I did, I am not sure if we should list them in the draft.

As Bob wrote, he was told to remove any argumentation about HIP vs.
IKE from the earlier versions of the architecture document.  However,
lately people have asked about this, and therefore IMHO it would be
a good idea to say something.  But I don't know what.

One of my personal problems is that I've been doing this HIP thing
now for a little bit too long.  I start to be blind to many things.
That is, I take some things for granted, while they are not that
for people coming from outside.  Hence, community feedback in getting
this argument right is very important.

I already answered to a part of this argument in a separate mail.
Let me consider the rest here:

> In a way, the HIP exchange is

Hmm...  Interesting thought.  Yes, HIP does involve a resolution
or translation concept, and even more so in the case of Hi3.

It is a nice idea that maybe we could disentangle the HIP protocol
from the rest of HIP architecture.  In a way, both BEET and CELP
are steps into that direction (though in almost completely different
levels.)  Perhaps we need a kind of API that could be used both
to control BEET IPsec based translation and CELP like translation?

However, IIRC, we were not in that level last fall.  As the intention
is to publish the architecture document as reflecting our thoughts
as they were a year ago, it may not be possible to include anything
about this into the draft.

> Maybe I miss something here?

Well, the HIP protocol is more than just identity translation.  It is
also about maintaining those translations in the face of mobility and
multi-homing.  Some people have thought about adding QoS signalling
features to HIP.  And so on.

Besides, if we think about some other "control plane" or "signalling"
protocols, such as SIP, their primary function seems to be creating
connection (id to address translation, if you will), and then
maintenance of the session.

>>       Protocols, such as IKE and IKEv2. ...
>

I think it would be a very useful exercise to try to write an
IKEv2 profile that would allow HIP-like SA creation.  You probably
also need MOBIKE extensions.  Indeed, if that would become good
enough, it might be even good to trash the current HIP protocol
almost completely and move to IKEv2.  However, I'm almost sure
that some important aspects of the current HIP design would probably
be lost.  It is then another question to decide whether such loss
is important enough to retain a separate protocol or not.

However, even if such an exercise would be quite useful, that
should not slow down current progress with HIP.  It is most
important to get some deployment experience.  Only that helps
us with the next stages of design.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 13 Oct 2004 15:14:04 +0300

> connection oriented, and honestly, I don't like it. (I remember you 
> said ESP is connection oriented because of sequence number. But I 
> checked rfc2401bis and it says sequence numbers are optional. ESP 
> supports multicast, so it has to be connectionless.)

We didn't think in that way back last fall.  It is hard to say anything 
about
that in the draft, as that was not thought about.

Going to the actual issue, host IP is not stateless.  In addition to 
the ESP
state, it has quite a lot of state, e.g. ND cache, routing entries, etc.
When people speak about the stateless nature of IP, they typically mean 
that
there is no per-connection state, especially in the network.  Some IP
implementations do maintain some state per active peer IP address, e.g. 
MTU,
cached best route, etc.  See e.g. BSD sources.  That is soft state.

In HIP case, there is still no per-connection state, there is just 
host-to-host
(or end-point-to-end-point) state, and that is soft.  It can be taken 
down
and re-created independent on the upper layer state.

The only real exception where I do see a difference is the HIT->IP 
mapping,
which currently needs to be maintained at the HIP layer.  But that kind 
of
mapping you do need to maintain on any layer 3.5 solution.

But apparently you mean something else by HIP being connection-oriented.
Could you be more specific?

> HIP doesn't target multicast, then that should also be stated, IMO.

I'm adding a statement that back in 2003 nobody, AFAIK, had thought
about HIP and multicast.

--Pekka

---

From: Yogesh Prem Swami <[email-masked]>
Date: Wed, 13 Oct 2004 09:03:51 -0500

>
>> Also, the draft needs to say how HIP architecture affect multicast. 
>> If HIP doesn't target multicast, then that should also be stated, IMO.
>
>

This should be good enough.

Yogesh

---

From: Yu-Shun Wang <[email-masked]>
Date: Wed, 13 Oct 2004 10:19:34 -0700

> a good idea to say something.  But I don't know what.

Understood. I suspect not all reasons back then were technical.

<snip>

> or translation concept, and even more so in the case of Hi3.

Yes, I know most people don't think of IKE-style of exchanging
keys as a form of resolution, but in the aspect of HIP, the
result of exchange is then used as a form of IDs. That's why.

> to control BEET IPsec based translation and CELP like translation?

Another part is to re-use existing protocols if it's good
enough to support what we want.

> about this into the draft.

Fair enough. I wasn't aware of this context.

> maintenance of the session.

Actually, I was expecting something closer to what you said
above as the argument of why IKE isn't enough. (But then you
also mentioned MOBIKE below which sort of fill this gap...:-)
Anyways, this type of reasoning is imho stronger than the
architectural point of view at the beginning.

> is important enough to retain a separate protocol or not.

Yes, I don't know HIP well enough to enumerate what could be
lost if we use IKE. But the comparison and what's lost if IKEv2
is used are what most of us would really like to see. Though it
doesn't have to be in this document as it would surely delay the
process.

> us with the next stages of design.

Good enough for me. As a practical suggestion, I think your original
first reason (the arch point of view) should probably be removed.
Then we just need a simple, high level list of what could be lost
or hard to do if using  IKEv2 in place of HIP exchange with the
statement that we are not closing the door on future development of
HIP exchange as an IKE profile.

Though this seems like a reverse of what brought on this whole
discussion, the original text IMO does not really serve the
purpose of explaining "why not IKE(v2)".

Thanks,

yushun

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 14 Oct 2004 09:07:59 +0300

<snipping some text that I agree with; no need to comment>

> architectural point of view at the beginning.

Well, AFAIK, the real reasons for a separate protocol were mostly
political (attitude at IPsec WG, among other things) and
architectural.  Back when Bob began, technically it would have
been fairly easy to develop IKE into a direction where it would
have also served HIP purposes.  Unfortunately, few people
understood the HIP idea, and quite a few people opposed it,
some bitterly.  Hence, making IKE HIP-friendly would never have
worked out politically.

Hence, if we now list technical arguments why we need a separate
protocol, that is more an afterthought than the original,
architectural baseline.  The architectural stance towards middle
boxes is one big difference, the other one being policy granularity.
Both are _architectural_ in nature.

The third issue, a separate protocol instead of running on the
top of UDP, is also architectural in nature, but much harder to
argue about.  Here people seem to have widely different opinions.
My firm belief is that we've made the right choice.  As an
indication of this is that we don't need separate IPsec policy
rules to except some UDP ports from others.  That may seem as
a minor issue, but getting the architecture right often manifests
itself initially in very subtle ways, and the big picture becomes
fully visible only later on.  Other people believe that the choice
is detrimental since it makes it harder to work with current NATs.
As I have repeatedly stated, from a practical point of view I agree
with the UDP proponents, but I can't agree from an architectural
point of view.  Maybe I am stubborn, dull, and stupid.   Or maybe
I'm just dense and got my intuition right.

Anyway, I think it is useless to argue too much about this point
now.  We'll have much better perspective once we have some initial
deployment experience.

> is used are what most of us would really like to see.

Please go ahead.  There may be other people that are interested.
At this point, the results belong to the HIP RG.  However,
I presume that they would be very useful at the next HIP WG
re-chartering time.

> ... As a practical suggestion, I think your original

I understand.

It looks like that people agree with

   - the middle box friendliness argument (enable layer 3.5
     routing)
   - the policy granularity argument (layer 3.5 is end-point-
     to-end-point, as connection multiplexing happens only on
     layer 4)

I can certainly remove the separate protocol argument.  However,
if we are able to find a wording that the WG deems easy enough
to understand, I'd like to preserve something of it.

What I want to say, basically, is that most "signalling"
protocols either

   - use in-line signalling (TCP, SCTP, SSH, ...)
   - are directly on the top of controlled protocol (ICMP,
     portmapper, SIP, PPP control protocols, ...)
   - and this seems to be right.

There are a few notable exceptions, BGP and IKE being the
prime examples.  They both may get it "right", given their
requirements, but I doubt the IKE case.  In the BGP case,
my (perhaps flawed) understanding is that they wanted to use
the reliability mechanisms from TCP.  I don't remember what
(if any) the arguments were in the IKE case.  I'm sure there
are other exceptions, but I can't remember them now.

Now, the real question is why would it be better to place the
signalling protocols either in-line or directly on the top?
Here I am more on my own wits than on anything that I've
heard or read, hence be careful.  But let's go.

   1. If there is a protocol X between the protocol P and its
      control protocol S, the protocol X may have its own control
      functions that make the system complex and unstable.

      [In the IKE case, UDP has little control at all.  In the
       BGP case, TCP control is in-line.  Hence, this problem
       doesn't manifest itself there.]

   2. If the protocol P somehow controls the functions of the
      protocol X on the top of it, the system becomes complicated.
      This is the case for IKE.  This complication manifests
      itself in the exception policy rules; see above.

      [This would not be a big deal if we considered HIP alone.
       However, some people (me included) would want to be able
       to run HIP in parallel with IKE, and there this is an
       issue.]

   3. When designing fast middle boxes, it often becomes
      important to separate the data plane and control plane
      from each other.  One wants to process data plane packets
      using the fast path, e.g., a few tens or hundreds of
      micro code instructions per packet, while the control
      protocol goes to slow path.

      [This requires more complex micro code for IKE, since you
       have to check UDP ports, while in HIP case you don't.]

There are probably other technical issues embedded in this,
but they evade my mind now.

Now, the question is how to put this all in a succinct way
to the architecture document.  I don't want to go in this
detail there, as the document is also otherwise quite
content laden, and expanding all the details wouldn't serve
the purpose.

I'd be grateful if someone could propose some text.  I'll try
to do it myself tomorrow, but help is appreciated.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 16 Oct 2004 08:42:55 +0300

> to understand, I'd like to preserve something of it.

I decided to remove the argument about any architectural needs
for a separate protocol.  After contemplating it a little bit,
I came to the conclusion that

   a) the argument is not very well baked, at least not yet
   b) historically, it was not really so in the beginning
      of the HIP process

As a result, the proposed text now looks like the following:

       <t>While it would be possible, at least in theory, to use some
       existing cryptographic protocol, such as IKEv2 together with
       Host Identifiers, to establish the needed SAs, HIP defines a new
       protocol.  There are a number of historical reasons for this,
       and there are also a few architectural reasons.  First, IKE (and
       IKEv2) were not design with middle boxes in mind.  As adding a
       new naming layer allows one to potentially add a new forwarding
       layer (see <xref target="nat" />, below), it is very important
       that the HIP protocols are friendly towards any middle
       boxes.</t>

       <t>Second, from a conceptual point of view, the IPsec Security

I'm now posting the draft to the repositories.  If anyone feels
so, we can return to this issue during the forthcoming WC LC.

--Pekka