Subject: [Hipsec] RTT field in AC_INFO

From: [email-masked] (Mika Kousa)
Date: Thu Aug 21 21:11:02 2003

Is the RTT field really needed in the AC_INFO payload ?

The current draft-nikander-hip-mm-00 does not say anything about the
correct usage of this field, but I have had discussions with the HIP4BSD
team on some possible uses of this field. For example, one way to use this
field that was pointed out is to put a timestamp in host specific format
into the RTT field of the AC packet. Then we assume that the host
receiving the AC packet is not supposed to change the contents of the RTT
field, so it just copies the value into the corresponding ACR packet. When
ACR is received, the receiving host gets the current time and substracts
the RTT field from it to get the actual RTT.

However, we can assume that HIP implementations allocate some memory for
the data structures needed to remember the AC packets the host has sent
(like the AC ID, REA ID, and other stuff). Additionally, we can add one
more field to this data structure, that is, a timestamp when the AC was
sent out. The rest goes on practically the same way as before, but without
using the RTT field of the AC_INFO payload. When the ACR packet is
received, the host looks up its data structures if it has sent the
corresponding AC. If yes, it consults the same data structure to get the
timestamp when the AC was sent and substracts current time from the this
saved timestamp. Therefore, we would not need the RTT field anymore.

Then there are some more or less relevant issues related to the RTT field
if we apply the first approach of the RTT field usage described before
(that is, we assume the receiver of an ACR (from now on called as host X)
trusts that the sender of the ACR (from now on called as host Y) has not
altered the AC's RTT in any way):

-Y's promotion of particular interface to cause more load on some route:
host Y's ACR containing an altered value of the RTT might have effects on
host X (e.g. for outgoing packet host X selects the peer (Y) address based
on the lowest RTT value calculated). This might be an issue if Y wants to
force X to send packets destined to Y using some particular route which
finally ends at the interface X selected. This is not a problem if the
approach I described is used, because now X can calculate the real RTT
values.

-information leakage of X's current time: if we know the format of the
timestamp X uses in its RTT field, Y knows the (possibly even quite
accurately) current time of the host X. This information might be useful
if Y needs the host X's time for some attacks which need to know the
peer's time. This is also not a problem if we don't have the RTT field.

-paranoid people will make up more scenarios where the peer's timestamp
could be useful, like a rough estimation of peer's geographical location:
"peer's time is now 1 AM, let's see in which timezone the peer might be"
etc.