Subject: [Hipsec] Including birthday into the base header

From: [email-masked] (Pekka Nikander)
Date: Wed Dec 17 05:06:02 2003

I did some strawman design on how one could put the
birthday value in the base header, so that it would be
present in all packets.  I am NOT happy with the result,
but I'm still posting it so that others might get
better ideas than I've had.

--Pekka

-----------------------------------------------------------

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header   |  Payload Len  |     Type      |  VER. |  RES. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Reply ID    |   Sender ID   |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Controls    |       Birthday, 7 bytes                       |
+-+-+-+-+-+-+-+-+                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Sender's Host Identity Tag (HIT)               |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Receiver's Host Identity Tag (HIT)              |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                        HIP Parameters                         /
/                                                               /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

....

The birthday field contains the sender's bithday from the time
when the HIP association was created.  In other words, when a
host creates an HIP association, it stores its current
birthday to the association, and continues to use that
birthday value for the duration of the association.  If the
association is re-established due to any reason, the new
association MUST get a new birthday value that MUST be
strictly higher than the old value.

A receiver SHOULD ignore HIP packet that have a birthday value
that is smaller than the currently stored peer birthday value.
A receive SHOULD ignore all other HIP packets but I1, R1 and
I2 packets whose birthday value is higher than the currently
stored peer birthday value.

   DISCUSSION: The birthday value used to be in a separate
   parameter in the R1 and I2 packets.  However, including the
   birthday value in all packets has the additional benefit
   that it effectively blocks DoS attacks where an attacker
   records packets from an ongoing HIP association and then
   later re-sends them while a new HIP association is going on.
   In other words, the birthday value functions as a simple
   cookie, limiting capture & replay DoS attacks for the
   duration of the current association.

The Sender ID contains a rolling sequence number, incremented
every time the sender sends or resends a packet.  That is, the
Sender ID is initialized to zero when the association is
created, and incremented every time the sender sends a packet.
When the Sender ID reaches 255, the next packet will have the
zero value again.

Note that the Sender ID is not covered by the HMAC or
SIGNATURE parameters, and therefore can be spoofed by a
man-in-the-middle attacker.  However, a man-in-the-middle
attacker that is powerful enough to change the Sender ID field
in the fly can cause much worse problems.  It is also possible
for an eavesdropper to re-send captured packets with a higher
Sender ID, potentially causing a receiver to ignore future
packets with lower Sender ID.  This is the reason why the
receiver MUST limit its filtering to requests that are
identical with already processed ones.

   DISCUSSION:  Whether to include the Sender ID within the
   HMAC or SIGNATURE is basically a design choice that can
   be made.  Leaving it outside of protection gives a small
   performance gain:  the sender does not have to recompute
   HMACs or SIGNATUREs if it needs to re-send a packet, and
   the receiver may ignore packets that have identical
   contents other than Sender ID.

The Reply ID value depends on the R-bit in Controls.  If the
R-bit is one, the packet is a reply to an earlier packet, and
the Receiver ID contains a copy of the Sender ID from the
replied-to packet.  If the R-bit is zero, the Receiver ID MUST
be initialized to zero by sender and ignored by receiver.

The Sender IDs and Reply IDs are used to associate together
requests and replies.  That is, a sender keeps sending a
request until it either receives a reply to any of the request
it has sent, or a maximum number of retries is exceeded.

As a general rule, the receiver MAY remember the highest
Sender ID (modulo 256) it has received so far, allowing it to
pass handling out-of-order old requests.  If it does so, it
still MUST process all received packet unless a potential
out-of-order request is identical, sans Sender ID, with to a
recently received request.  In other words, the receiver MAY
check if the request is identical to a one it has recently
processed, other than that the Sender ID is smaller than the
one received, and if both conditions are met, drop the packet.
Alternatively, the receiver MAY simply answer to all requests
received.

Note that if the receiver needs to reply to a request that it
has already handled, with a lower or higher Sender ID, it MAY
include the earlier replied-to Sender ID into the Reply ID
field, thereby allowing it to re-send the earlier generated
reply, without needing to recompute the HMAC and/or SIGNATURE
fields.

   DISCUSSION:  While it might first look appealing to leave
   the Reply ID outside of protection, similar to Sender ID,
   the balance seems to go otherwise here.  That is, it is
   often significant to know that a reply is indeed a reply
   to a certain request.  On the other hand, if the sender has
   sent several copies of a request, with different Sender
   IDs, a reply with any of those Sender IDs in the Reply ID
   field are equally good.  Hence, the receiver can simply
   resend an earlier packet, with the protected Reply ID,
   instead of generating a new one with a new Reply ID.

   DISCUSSION: Since the Sender ID and Reply ID fields are only
   8-bit long, and since a typical request may be retransmitted
   5 times, it is possible that an eavesdropping attacker that
   has recorded all traffic during a HIP association is able to
   launch a reply attack with a packet that has a proper Reply
   ID (within the retransmission window) and is also otherwise
   an apparent reply to a request.  However, unless there is
   excessive packet loss so that the original request is
   unlikely to receive the destionation, the real peer will
   also receive the packet and will reply.  As a result, the
   sender will receive two different replies.

   It is unclear what should be done about this attack, if
   anything.  One possibility is to increase the size of the
   Sender and Reply ID fields.  Another possibility is to bump
   the bithday value very time the Sender ID field rolls over,
   and to include the peer birthday or some low order bits of
   the peer birthday in (some) replies.  Yet another
   possibility is to include transaction IDs in sensitive
   parameters.

Note that due to the possiblity that a receiver may re-send a
packet with an earlier Reply ID, the Sender and Reply IDs
cannot be used for reliable round-trip-time estimation.  The
effect is basically that the RTT estimate will be larger than
what the real RTT is.  When this restriction is understood,
they MAY be used for (unreliable) RTT estimation.