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

[[e-mail] (Henderson, Thomas R)]

> -----Original Message-----
> From: Pekka Nikander [mailto:[e-mail]]=20
> Sent: Friday, January 23, 2004 11:27 AM
> To: Henderson, Thomas R; Julien Laganier; Marcelo Bagnulo
> Cc: <[e-mail]>
> Subject: Re: [Hipsec] Re: draft-nikander-hip-mm-01.txt
>=20
>=20
> Tom, Julien and Marcelo,
>=20
> > 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.
>=20
> 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.
>=20
> > 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> > Why does readdressing require return routability check (what
> > is the attack?) and new SPI generation?
>=20
> Return routability check was discussed already.
> SPI generation is a side effect of integrating with NES.
>=20
> 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.
>=20

Good point.  Maybe the replay protection window is temporarily inflated =
during periods of mobility? =20

> 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.
>=20
> > 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?
>=20
> 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.
>=20
> The other alternative is the one I chose, changing the
> SPI in both directions in separate packets.

Understood now-- it is difficult to decouple NES from REA because of =
NAT.

>=20
> 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?

Yes, that sounds like the most flexible approach.

>=20
> > 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.)
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> > 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.
>=20
> 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.)
>=20
> > But I question whether it is necessary, and if it is, shouldn't
> > it be in the base spec and in the architecture doc?
>=20
> 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.


Let me see if I can add some structure to what you are saying, modulated =
by what I was arguing for, and you can correct me where I am wrong.

                            address11    =20
                      SA1 <              =20
                     /      address12    =20
                    /                    =20
       association  - SA2               =20
     /                                    =20
    /                SA                 =20
host - association <                      =20
                     SA                    =20
 ...                                     =20

Hosts are defined by their unique host identities.  Sockets are bound to =
host identities and ports. =20

Each host can have multiple HIP associations, which are stateful   =
signaling relationships between hosts.  Each host has only one HIP =
association active with any other given host at a given time.  The HIP =
associations exist to create and manipulate the SAs. =20

Each HIP association can create one or more SAs used for data transfer =
for data emanating from sockets bound to the particular host identities. =
 The different SAs are indexed by their SPIs and directionality =
(inbound/outbound).   =20

Each SA is affiliated with a subset of local addresses on the host =
machine.  By default (without REA), a single outbound SA is set up to =
the peer host, with a single destination address affiliated with the =
outbound SA.   A single inbound SA is set up as well, and the peer host =
knows of one address to send data to on that inbound SA as well.  =20

A given IP address may be affiliated with more than one SA.  Likewise, a =
given SA can be affiliated with more than one source and destination =
address.  Multiple SAs can exist for an association, governed by similar =
policy.  For outbound packets, the kernel selects the appropriate =
outbound SA, and also the appropriate source and destination addresses, =
based on the host identities that are bound to the socket and the =
current multi-homing situation.  (Note:  how to select is an open =
issue).  Inbound packets are accepted on any inbound SA, provided that =
they decrypt and pass replay window protection, and the IP addresses are =
not used as selectors for the SA.  Inbound packets are demultiplexed =
based on the host identities bound to the incoming SPI, and the =
transport ports.

REA is the mechanism for adding an address to or deleting an address =
from a SA.  More generally, REA is used with NES to set up new SAs with =
new SPIs.  To possibly traverse NATs at a new location, upon relocation, =
both hosts should send NES so that they expose their SPIs to the NAT.  =
It is the policy of the mobile or multihomed host to decide when to send =
REA or NES.  There are unresolved issues with respect to transport layer =
signaling or hooks to handle the fact that transport connections may be =
changing paths over time.

>=20
> > 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").
>=20
> This is a good question to be discussed at the multi6 wg.
>=20
> > Are both needed?
>=20
> No.
>=20
> > Should HIP mechanism replace transport level multi-address
> > handling?
>=20
> I think so, but apparently a number of people disagree.

I think so too, but we would need to come up with a compelling mechanism =
that would convince e.g. SCTP that their mechanism is redundant. =20

>=20
> > Should more work on the SLAP concept be done?
>=20
> Definitely, IMHO.  But maybe slightly later.
>=20
> > 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.
>=20
> 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.
>=20
> > This also gets into the question of whether it is HIP's job
> > to determine which of possible addresses should be primary.
>=20
> Indeed.
>=20
> > 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.
>=20
> 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.)

Sorry, I must have missed the multi6-hip-00 document.  Or maybe it is =
not published yet.

Tom

>=20
> > minor comments:
>=20
> I'll address these in -02.  Thanks.
>=20
> 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.
>=20
> --Pekka Nikander
>=20
>=20