Subject: [Hipsec] Comments on draft-nikander-hip-mm

From: [email-masked] (Jonathan Wood)
Date: Fri Apr 16 17:28:01 2004

I have some comments about the current design for the
mm draft (draft-nikander-hip-mm-0*). These comments are
mostly high-level and apply to both version 00 and 01.

Use of SAs in MM
----------------
I'm not very comfortable with the use of new/multiple SAs
to handle new addresses. It is a pretty heavy weight and
complex way to add a new address, and getting IPSec policy
management to select the right SA based on the ultimate IP
address selected would be pretty tricky (and require lots
of hacking :).

 From reading back over the archives, it appears that
the primary motivation for this approach is to handle
the case of packets sent on different links with
different latencies falling outside the ESP replay
window.

However, if you have a decent RTT estimate for each
path to the peer, it should be possible to adjust the
replay window according to your link conditions. (More
on RTT estimation later). If this is the case, is there
still a need to create a new SA for each new address
put in use?

Address States
--------------
Currently the drafts specify that a host maintain
address state on each peer address (active, unverified,
deprecated), and one of the addresses is preferred.

I think that there are some problems with this approach.
A host really only cares about active addresses -
if it wants to switch to a new address in the case of
path failure, it wants the backup to already be active
so there is no delay in failing over. If it wants to
send some packets on one path and other packets on
another path, it also wants both paths to be active and
verified. Keeping track of unverified and deprecated
addresses seems to be a waste of resources.

So perhaps dropping the unverified and deprecated states
might be a better approach. All addresses are verified
for return routability (if policy dictates) upon receipt.

The other mechanism that probably needs to be in place
for this to work is some sort of periodic probe to verify
that the path is still alive. This probe can also be used
to estimate RTTs for each path, which can then be used to
set the ESP replay window. The path RTTs can also be fed
to transport protocols.

For a mature example on how to do this sort of thing, see
SCTP (rfc2960) and its heartbeat mechanism.

3-Way Exchange Reliability
--------------------------
Adding a new address involves a protocol exchange
conceptually like this (RR = return routability check):

Initator       Responder
         REA
   -------------->
   RR Request/Ack
   <--------------
      RR Reply
   --------------->

Currently the RR request doubles as an ack for the REA.
Presumably the REA will be retransmitted if no RR
request is received after some time (via the UPDATE
protocol in draft version 01). However, there is no such
mechanism in place to ensure the the RR reply gets
best effort delivery (whether it be data or a HIP TLV).
If it gets lost, the address verification is left in limbo.
I think we need something more reliable. Two (not terribly
attractive) possibilities are having the responder retransmit
the RR request, or going with a 4-way exchange with the
initiator retransmitting the RR reply if necessary.
[ Does this also apply to the UPDATE exchange in the base
   protocol? ]

A Security Consideration
------------------------
Currently the drafts with allow a peer to add an
unlimited number of addresses to an assocation. This could
open a window to an attack where a host attempts to
exhaust its peer's memory resources by adding lots of
addresses. HIP implementations should allow administrators
to place limits on the number of peer addresses added.
However, when the limit is reached, will we need some
protocol mechanism to inform the peer that the address
addition has been rejected?

CGA Addresses?
--------------
Just curious:
If a peer's address is a CGA and can be verified against
the peer's public key, can we skip RR?

---

From: [email-masked] (Pekka Nikander)
Date: Sun Apr 18 13:32:01 2004

Jon,

> to handle new addresses.

As have been discussed earlier on the list, it is fairly
necessary for multi-homing due to replay protection,
and it seems to beneficial for mobility since it exposes
the SPIs in UPDATE packets, allowing middle boxes to
learn them and create appropriate mappings.

I guess we need to add more text to Section 4 of the
draft where we discuss the scenarios, though Tom apparently
already added some text about replay protection.  [I haven't
had time to read -02-pre1 yet.] The middle box thinking
is not explained anywhere, though, IIRC.  It needs to be
added.

> It is a pretty heavy weight and

Well, I don't quite follow your thoughts.  Right
now in our implementation we first select the SA,
and the ultimate IP address is stored in the SA.
Before the upper protocols get an ability to perform
congestion control and flow management simultaneously
on multiple paths, we can't use more than one path
on a single TCP connection anyway.  Hence, setting
up the policies is pretty simple:  You select the
SA based on the destination HIT, protocol, and
ports.  No hacking at all.  The SA determines the
destination address.

Now, if we fast forward to the future where we
can envision an application being able to have
better control on the addresses, the baseline case
is still easy.  You just use socket options to select
the SA and thereby the destination address on your
socket.  Only when we want applications to have
more complex policies or the upper layer protocols
to really utilise multi-path, the situation gets
tricky.  But then you have to rewrite much of your
stack anyway.

> still a need to create a new SA for each new address

Tom already answered this.  Creating new SAs is your
own choice.  Alternatively, you can just add a new
address on an existing SA.

In -01 replacing SPI was the only way of performing
return routability check.  However, the intention of
the new text in -02 is to allow using UPDATE as an
alternative.

The rationale for combining SPI change and RR
was actually simplicity.  If you have any middle boxes
in your route, you have to tell the middle boxes about
your SPIs anyway.  Furthermore, you may loose quite
a lot of traffic while you change your network attachment.
Resetting your SPI makes the protocol more robust.

Anyway, the intention of the -02 text is to be more
flexible, and allow you to continue using the same
SA and SPI.  But you still need to send the SPIs both
ways so that middle boxes can learn them.

> Keeping track of unverified and deprecated

It is really up to you what you do here.  Some people
may defer return routability check; hence UNVERIFIED.
If UNVERIFIED is just a very transient state for
your implementation, it shouldn't harm interoperability.
If you don't want to keep track of deprecated addresses,
you don't need to.

> might be a better approach.

Well, I guess we need to change the language here.  The
section already starts with "In a _typical_ implementation,"

Do you have a suggestion on how to make the text
more clear that it is really up to you what you
implement, as long as the external behaviour *could*
be implemented in the way described in the draft?

> All addresses are verified

That would be an unnecessary restriction in the spec.
Of course, you are free to implement in that way if
you wish.

> that the path is still alive.

There is nothing that prevents you from doing that,
pretty much the same way SCTP has heartbeats.

Right now the text just says that unused addresses
should be deprecated after some time, without dictating
any policy.

> This probe can also be used

As far as I see, there is nothing in the draft that
prevents you from implementing it in this way.

Would you like to write an appendix where you describe
some of these implementation options?  The text Tom
provided is fine, but I don't see why we should
include it in the protocol proper?  Is there some reason?
Or could it be in an appendix?

> SCTP (rfc2960) and its heartbeat mechanism.

I'm pretty familiar with that; see the following
paper, aware on my publications page.  :-)

Tuomas Aura, Pekka Nikander, and Gonzalo Camarillo,
"Effects of Mobility and Multihoming on Transport-Layer
Security,"  to appear in  Proceedings of IEEE Symposium
on Security and Privacy,  Berkeley/Oakland, California,
May 9-12, 2004, IEEE Computer Society, to appear.

> Currently the RR request doubles as an ack for the REA.

This was (and still is) an important optimisation, IMHO.
Of course, as Tom described, you don't need to initiate
RR at the same time, you can just ack REA.

Adding to the five scenarios Tom described, I still think
that it is OK to implicitly finish RR with new traffic to
a new SPI.  However, I haven't had time to carefully
read -02-pre1 to see what the text says, and if any
changes are needed there.  Hence, the reply UPDATEs
in Tom's scenarions #3, #4 and #5 *MAY* be replaced
with implicit traffic.  In fact, IMHO in scenario #4
where a new SPI is created the reply update is really
unnecessary.  But apparently people's opinions
differ on this.

Furthermore, I think that Tom's scenario #5 where
there are two UPDATEs from the recipient to the sender
of REA is not likely to happen in real life, though
there shouldn't be anything in the spec forbidding it.

A piece of history:  When I started to think about using
ESP traffic as implicit ack, I found it ugly and originally
rejected it.  (It was present already in some of the early
drafts by Bob M.)  However, my mind has slowly changed.
Especially when I realised that you don't need to have
any triggers from ESP.  It is sufficient that you poll
your ESP to see if there has been any traffic.  That
can be implemented easily: you get a timeout, you poll,
and you process the result of the poll either as an
ack (if there had been traffic) or timeout (if there
had not been any traffic).

> ... there is no such

Is this a problem?  The address will stay in UNVERIFIED
state, and you will need to re-initiate return routability
on that if you intend to use the address.

I don't see where you have a problem here.  But perhaps I'm
missing something?

> addresses.

As far as I can see, there is nothing in the draft
that mandates the peer to accept that information.
But I admit that adding some text to security
considerations section is probably a good idea.

> HIP implementations should allow administrators

Yes.

> addition has been rejected?

Hmm.  Do we?  At Tom wrote, we _could_ use NOTIFY
for that.  Maybe we could define a notify message
that MAY be used for that purpose, but IMHO it should
also be perfectly OK for a host not to notify its
peer that it is not storing all addresses.

> the peer's public key, can we skip RR?

In general, no.  Flooding is not only about flooding
hosts, it is also about flooding subnets.  CGA doesn't
prevent you from generating CGAs for subnets where you
aren't.

--Pekka

---

From: [email-masked] (Jonathan Wood)
Date: Tue Apr 20 13:01:01 2004

On Apr 18, 2004, at 11:23 AM, Pekka Nikander wrote:

<...>

> tricky.  But then you have to rewrite much of your

OK, this is the hacking I was talking about :) I was having
trouble figuring out how we could actually use multiple
SAs for multi-homing. There seems to be lots of other
work needed before all the pieces are in place for it. I'm
not sure that keying multihoming policies by SPIs will
be palatable to the rest of the stack, but I guess if HIP takes
over the world that will be motivation enough.

<...>

> address on an existing SA.

Right - I sent my mail just before Tom sent out notice about
his draft. Making it optional is better, I think.

However, you didn't address my primary concern, regarding
handling the replay window issue by managing it intelligently
(and if this was addressed in the archives, I apologize, I must
have missed it). If you don't need to address the issue by
using multiple SAs, I think a great deal of complexity will fall
out of the protocol. Just one SA at a time between two peers,
no need to sort out the semantics of sending REAs with updates
with or without NESs or in notifies, etc. Also, fewer SAs means
less load on a hosts kernel memory usage and fewer cycles
spent managing the SAD.

> Resetting your SPI makes the protocol more robust.

I'm not following you here - how does it make the protocol
more robust?

> ways so that middle boxes can learn them.

I understand. How does this work in the 02-pre1 draft
when the REA does not accompany a NES?

<...>

> be implemented in the way described in the draft?

I think Tom's suggestion of just making the deprecated
state an implementation option would be better.

<...>

> Or could it be in an appendix?

Well, the issue of whether it should be in the protocol proper
or in an appendix depends on whether you use multiple SAs
or an RTT  estimate to manage the replay window. If the latter,
it should be in the protocol, IMHO. I am also concerned about
overloading messages too much. We have 255 message types
to play with, so adding a heartbeat message for clarity might
not hurt too much (and shouldn't necessitate too much extra
code). But I think we need to resolve the primary focus of this
thread first - if I am convinced that using multiple SAs is necessary
and good, then I don't think heartbeats will be necessary (but maybe
optional? Need to think about that more...)

<...>

> had not been any traffic).

Yes, this is the way I have implemented it. I still find it
ugly, though...

<...>

> I don't see where you have a problem here.  But perhaps I'm

What about the case where a MN moves and gets a new CoA.
It sends its peer an REA with the new CoA as the new preferred
address. The RR fails due to a dropped packet. Now the peer
host cannot communicate with the MN since the only verified
address it has is the MN's old CoA. Detecting that the old address
is unreachable could take some time, during which all packets
to the MN are lost.

<...>

> prevent you from generating CGAs for subnets where you

How would subnet flooding work? If a host isn't on the subnet,
ndisc or arp will fail and the router won't put the packets on the
subnet, right?

---

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 27 06:25:01 2004

> less load on a hosts kernel memory usage and fewer cycles

I am pretty pessimistic about being able to handle replay
window under all imaginable situations.  What if you want to
use, for some strange reason, GPRS and 50 Mbps WLAN at the
same time?  During the 900 ms RTT on the GPRS side you
can send some 5 Mbytes of data over the WLAN.  Is it acceptable,
from the security point of view, to have that lax replay window?
Don't you easily open vulnerabiliites in some non-idempotent
operations in some UDP based application protocols.

Implementing multiple SA support right is tricky, I agree.
But it still looks about an order of magnitude easier to
me than properly getting dynamic replay window management
right.

> I'm not following you here - how does it make the protocol

When you reset your SA, you don't have replay window
problems with possibly lost larger amounts of data.
Remember, IPsec doesn't resent data, ever.  If you run
loose of your replay window, you are lost.  You have to
renegotiate you SA.

I agree that running out of replay window is something
that should be avoided.  However, if you have a fat pipe
and get disconnected for a couple of seconds, that may
happen, since your replay window may be just a few
milliseconds on a fat pipe.

We have to deal with a conflict of interest here.  The
security requirements (and policy) dictate that the
replay window should be small.  If we need to widen it
due to mobility requirements, that may not be acceptable,
depending on the security policy.

> state an implementation option would be better.

Text/diff against -02-pre1, please?

> ndisc or arp will fail and the router won't put the packets on the

You flood the pipe leading to the router.

--Pekka

---

From: [email-masked] (Jonathan Wood)
Date: Wed Apr 28 21:39:00 2004

> me than properly getting dynamic replay window management

Hmm, OK... you make a good point that in some extreme cases there
could be security problems. I'm not sure I agree that replay window
management is as hard as you think it is, but this question is probably
better addressed in a research context.

I am still having some concerns about how I understand
the multiple SA scheme to work. Your application
selects an SA, in which is stored the destination address
(actually, one or more destination addresses).  In effect,
you are conflating locators with security associations,
and naming destinations by the SAs, not the locators.
This seems harder for applications to deal with, and
furthermore the conflation seems lossy - if you have a
group of addresses bound to an SA, there is no guarantee
that all addresses in the group represent the same path.
It seems much more logical to me for multipathing
applications to deal with locators than SAs.

Having said that, however, this may just be an issue
with the language of the proposal - could not an
implementation have an augmented SPD that allows
selection of an SA based on the ultimate IP address?

> loose of your replay window, you are lost.  You have to

My knowledge of this aspect of IPsec is limited to reading
the specs, so I'll take your word in it. However, I'm not
clear on how you are lost if you run loose of your replay
window - the ESP spec says that if a sequence number is
to the right of the sliding window, (which is what would happen
if you were disconnected briefly), you proceed with processing
the packet. Would the subsequent ICV calc or decryption fail?

Jon