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

[[e-mail] (Pekka Nikander)]

Tom, (Jari, see a note about MOKIKE close to the top.)

[Writing off-line, not seeing possible replies in between.]

>> 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.
>
> Good point.  Maybe the replay protection window is temporarily
> inflated during periods of mobility?

Maybe.  This is probably something that we want to consider
at the MOBIKE WG.  They have the same problem.
Jari, do you have an opinion on this?

>> 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.
>
> Understood now-- it is difficult to decouple NES from REA
> because of NAT.

It can sure be expressed in that way.  I would say that
because of NAT, it is always necessary to explicitly carry
the SPIs in REAs, leading to considerable overlap in NES
and REA syntax.  Secondly, for multi-homing with paths with
different QoS characteristics, it is often necessary to
introduce new SAs in REAs announcing new addresses.
 =46rom there on, it is a small step to integrate them also
functionally and semantically.

However, I am still not sure whether this is the right
thing.  I thought so before writing -01, but I am not *so*
sure any more.  I guess I need some implementation insight.

>> 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.

Ok.  I'll try to add that.

> 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.

Ok.  In general, your text looks excellent.  Maybe we should
add it to the introduction in -mm-02?

>
>                             address11
>                       SA1 <
>                      /      address12
>                     /
>        association  - SA2
>      /
>     /                SA
> host - association <
>                      SA
>  ...
>
> Hosts are defined by their unique host identities.
> Sockets are bound to host identities and ports.

Ok.

> 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.

Ok.

> The HIP associations exist to create and manipulate the SAs.

Well, this depends on your point of view.  If you take a
different angle, you could say that HIP associations exist
to allow transport layer sessions to survive changes of
underlying IP addresses.

> 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).

Ok.  [Well, to be precise, each HIP association seems to
require at least two SAs (instead of just one).]

> 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.

Right.

> 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 [HIP]=A0association, [all] governed by similar policy.

Yes.

> 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.

Agreed.

> (Note:  how to select is an open issue).

Right.  Right now we are looking at simple heuristics
based on data coming from the PF_ROUTE socket.

> 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.

Right.

> REA is the mechanism for adding an address to or deleting
> an address from a SA.  More generally, REA [can be] 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.

Yes.

> It is the policy of the mobile or multi-homed host to decide
> when to send REA or NES.

Yes.

> 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.

That's right.  And a very interesting area to study, in my
opinion.

>>> Should HIP mechanism replace transport level multi-address
>>> handling?
>>
>> 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.

Patience :-).  I discussed with Randall Stewart and Michael
T=FCxen.  Sure they were skeptical, but they were also very
interested.  And I learned a lot.

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

I sent it to the drafts editor a few days ago.  I don't know
when it will be public.  Once it is, I will announce it also
at hipsec list.

--Pekka