[Hipsec] Re: draft-nikander-hip-mm-01.txt

[[e-mail] (Pekka Nikander)]

Tom, Julien and Marcelo,

> I have some questions regarding the mobility draft.  Some
> things have changed considerably since the time that REA was in
> the base spec, and I don't understand the motivation for many of
> these changes, and am wondering whether they are necessary.

Very good question.  I will try to give some motivation below.
However, it is far from clear whether -01 is any better than
the -00 mechanism.  It was mostly an experiment to see if
it would be possible to make REA a parameter instead of
a separate packet.  I don't know whether it adds or reduces
semantic complexity.  That is something that we need to
discuss.

> i) we used to have a REA that updated the (primary) destination
> address to use for the HIP SA.  This did not cause rekeying or
> new SPI generation, nor did it require a return routability
> check. REA could be authenticated based on signature.  We now
> seem to have drifted far from this basic approach.

Well, REA still still updates the primary destination address.
I will add the option of being able to use REA without RR,
as I already wrote.

I'm not sure if the tight integration with NES, as is done
in -01, is the right way of performing RR.  I wanted to see
whether it is possible at all, and what are the resulting
semantics.

I think this was a good exercise, even if we decided to
abandon it.  It showed that we really need HIP
association specific sequence numbers to prevent replay
attacks.  We probably would have noticed that anyway,
but probably much later.

> Why does readdressing require return routability check (what
> is the attack?) and new SPI generation?

Return routability check was discussed already.
SPI generation is a side effect of integrating with NES.

But there is more.  When you readdress, your may temporarily
loose your connectivity.  This may lead one end
to send lots of packets that get dropped, and that may
eventually lead to a situation where the IPsec SAs replay
protection windows get out of sync.

Secondly, if you move to a network which is behind a NAT
box, you have to inform the NAT box about your SPIs, or
otherwise the NAT box is not able to map the SPIs to your
IP address.

> Asked another way, what is it about a simple REA/REA-ACK
> handshake, and modification of the preferred outbound IP address
> without otherwise changing the SA, that is undesirable?

Considering the going-behind-a-NAT-box case, there were
basically two alternatives.  One would be to include
both SPIs (incoming and outgoing) to the REA, allowing
the NAT box to learn the mappings from a single REA.
However, that leads to a potential vulnerability, where
the sender of the REA lies about the the SPI of the
direction where it doesn't have control.  It also
leads to complications if there are cascading NATs.

The other alternative is the one I chose, changing the
SPI in both directions in separate packets.

Now, Tom, would it suffice to you if the spec allowed one
to have the old SPI and new SPI identical, in which
case there would be no drawing of new keying material
nor other changes in the SA?

> ii) There is an additional level of abstraction introduced called
> an "interface."
> (also, the overloading of the term "interface" may cause confusion
> because most people have rather concrete conceptions of what an
> interface is.)

The name "interface" was a poor choice.  I've already now
changed it to "address group", more to indicate that it is
a logical concept.

The basic reason for this concept is that if you have a
multi-homed host with different QoS characteristics on
the different interfaces, you need different SAs or
otherwise some of your packets will arrive outside of the replay
protection window.

I have no desire to use them for something else.  Some
other people may have, though.  I don't see any reason
why they couldn't be used, provided a suitable local policy.
But that would be a different extension from REA, I think.

> For HIP to support more
> than one SA between any two hosts requires some way to index
> SAs within the context of the HIP association.

Well, you need that in the kernel, yes.  But as far as I can
see, you don't need to expose that to most applications.  (Some
applications may want to know, through some new API.)

> But I question whether it is necessary, and if it is, shouldn't
> it be in the base spec and in the architecture doc?

I see it as an extension, extending the logical concept of a
single SA just over different paths with different latencies
and bandwidths.  Due to replay protection you just can't use
a single SA any more.  On the other hand, all of the parallel
SAs have the same policy, and the kernel may select which SA
is used, based on the current multi-homing situation.

> iii) as for multihoming, the architecture is unclear.  How does
> this play with SCTP dynamic address reconfiguration, which
> looks similar to me (allows multiple addresses to be in use,
> for purposes of recovery via alternate path-- and in the future,
> load balancing?-- and allows one address to be "primary").

This is a good question to be discussed at the multi6 wg.

> Are both needed?

No.

> Should HIP mechanism replace transport level multi-address
> handling?

I think so, but apparently a number of people disagree.

> Should more work on the SLAP concept be done?

Definitely, IMHO.  But maybe slightly later.

> Note also that if congestion control
> continues to live in the transport protocol above
> HIP, it is not appropriate to hide the presence of multiple
> possible source and destination addresses (multiple paths)
> from transport, so it is probably not appropriate to infer
> that transport level connections need not have any notion
> of underlying IP addresses anymore with HIP.

We are envisioning to implement this by having different
set of transport QoS estimate data structures, and having
the HIP layer to change the structure "underneath".  In
that way you "change TCPs memory" without TCP being aware
of that.  However, that is more thought as an implementation
hack allowing quick prototyping that the proper way of
doing it.

> This also gets into the question of whether it is HIP's job
> to determine which of possible addresses should be primary.

Indeed.

> Maybe the approach, suggested by Marcelo in a previous post,
> towards specifying only a basic mechanism for mobility (change
> primary destination address to use for IPsec transport
> layer outer header) is the prudent approach for now, with
> more comprehensive multihoming (and perhaps mobility
> extensions) coming later.

Hmm.  Given the current situation in multi6, I think that
the kind of proposal I wrote is valuable.  Indeed, I was
asked to write a HIP based multi-homing spec.  The two drafts,
   draft-nikander-hip-mm-01.txt and
   draft-nikander-multi6-hip-00.txt,
form that now.  (I will try to update both before the final
Seoul deadline.)

> minor comments:

I'll address these in -02.  Thanks.

My current plan is to issue a -02 based on -01, with these
minor comments and more text based on this discussion.
In parallel, we can discuss whether the -01 approach is any
better than -00 approach.  Apparently -01 is still not the
"right" way.  More thinking and experimenting is needed.

--Pekka Nikander