Subject: [Hipsec] Indicating Reply Requested and renaming NES?

From: [email-masked] (Pekka Nikander)
Date: Wed Dec 10 07:01:01 2003

As I am working on the revised Mobility and Multi-homing
scheme, I have come to a tentative conclusion that it might
be good to introduce a new HIP control or alternatively
take one bit from the packet Type field into use.  I would
also like to rename the "New SPI" (NES) packet into a more
generic "Update" (UPD) packet, since it looks like a good
candidate for various kinds of updates, not just SA updates
but also readdressing updates and probably other kinds of
updates in the future.  Furthermore, if we decide to rename
the NES packet into a UPD packet, we can also rename the
NES_INFO parameter into a NES parameter, just for simplicity.

New control option
------------------

The currently defined controls are the following:
   C - CER packets follow
   E - Use 64-bit ESP sequence numbers
   A - The sender's HIT is anonymous
(Actually the E control should be part of the ESP
transform parameter and not a control, but that is a
different issue.)

I would now like to include a new control
   R - A reply is requested

This control would always be set in I1, R2, and I2, and
(almost) never in R2.  However, it looks like that it
would be fairly useful in NES and BOS, at least.

Allocating a bit from the packet type option
--------------------------------------------

The alternative is to allocate a bit in the Packet type
field.  Currently the packet type is 8 bits, with no bits
having any special meaning.  We could now take let's say
the lowest bit and use it to indicate whether the sender
of the packets expects a reply or not.  This would result
in the following changes to the packet types:

   Packet   Current type   New type

    I1           1            1
    R1           2            3
    I2           3            5
    R2           4            6
    NES          5            8/9
    BOS          7           10/11
    CER          8           12
    PAYLOAD     64           64

More background
---------------

The current NES_INFO parameter includes an explicit R-bit,
which indicates whether a NES packet is a reply to a
previous NES packet or an initial NES packet.  In practical
terms, it can also be understood as indicating whether a
NES reply is needed or not.

Now, in the mobility & multi-homing case it has turned
out that it is sometimes necessary to create a new SA or
multiple new SAs whenever a host changes its connectivity.
Therefore we sometimes want to send multiple NES_INFO
parameters in one packet.  Having the R-bit in the NES_INFO
does not make any sense any more.  It is really a packet
level thing, not a per SPI thing.

It also looks like that it would be sometimes useful to
introduce new SAs unidirectionally.  That is, in certain
readdressing situations you really want to update the
SA only in one direction and not in another.  Therefore
it probably makes sense to send NES (or UPD) packets that
contain REA and NES_INFO parameters, indicating that the
recipient should update the *outgoing* SAs related to
the interface identified by the REA, but does not need
to really rekey or change its incoming SAs.

I also think that having a generic update utility with
different kinds of parameters (NES, REA, etc) that
indicate what is to be updated creates a more orthogonal
micro- architecture within the actual protocol.  The
obvious counter-argument is, of course, that such
orthogonality and generality may create unnecessary
complexity.  However, in this specific case I don't see
that much more complexity.  Indeed, a well written
implementation may become less complex since it may
require less code for handling various cases.

Both of the schemes have the added benefit that it would
allow sending I1s just to tell one's HIT (a kind of minimal
BOS without the actual HI or signature), or maybe to send
those R1s that are sent in response to unknown SPIs with
the reply requested bit off?

Especially the ability to send I1s with no reply requested
might be beneficial for delayed HIP context setup; a feature
that seems useful from multi6 point of view.

Any thoughts?

--Pekka Nikander