Subject: [mobile-ip] A question on the replay protection mechanism in draft-ietf-mobil eip-reg-revok-04.txt

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 17 Dec 2002 22:40:05 -0600

Hello all,

I understand that this draft has passed the MIP WG last call,
However, I have a serious question on the replay protection mechanism
presented in this draft.

To make the story short, I have been in contact with Steven and Madhavi, the
authors of this
draft for the last probably FOUR weeks. I exchanged many emails on this
issue with the authors
and here I would like to summarize what we agreed on as the replay
protection mechanism as
presented in this draft.

This replay protection mechanism is supposed to work and as discussed with
the authors as follows:

From the Home Agent prospective as a receiver for revocation message:

   "Every Home Agent keeps track (some how, implementation specific) of the
timestamp 
   of the last received revocation message from every FA the MN roamed to."

   In other words, HA keeps RECORD for the same MN (e.g. MN1 of the
following:
   1. Timestamp of last revocation message received from FA1.
   2. Timestamp of last revocation message received from FA2.
   3. Timestamp of last revocation message received from FA3.
   ...
   ...
   ...
   n. Timestamp of last revocation message received from FAn.

   "Where n is the possible number of FAs that the MN is possibly to roam to
or visit."

   HA keeps SIMILAR records for EVERY MOBILE NODE it serves.   

As I discussed with the authors, this mechanism has the following problems:

1. In the case when the HA loses track of the timestamps of the last
revocation messages for every Mobile
Node from every FA it roamed to, (HA crashed) the HA will be vulnerable to
replay protection attack. 
After the HA loses the timestamp records, it does not have anything that it
reference for replay protection. 
A man listening on the network, can replay any of the old revocation
messages and the HA will accept it.

2. The fact that the HA MUST be prepared to keep track of the timestamp of
the last revocation message
for every Mobile Node it serves and from every FA that the MN is possibly to
roam to, is a very huge
overload and not scalable at all, especially in the case of Dynamic HA
implementation.

3. Item 2 becomes critical when using this draft mechanism as suggested by
3GPP2 for resource management due
to the fact that many Mobile Nodes does NOT send MIP deregistration message
to clean resources on the HA, the FA
is very much expected in many cases to send revocation message to the
serving HA to clean up resources. This makes
the possibility HIGH that every FA may ends up sending a revocation message
for possibly most of the MN served by
this FA.

4. In the case of implementing this mechanism on the FA as a receiver to
revocation messages, the storage and memory
impact to have this mechanism working is much greater than the HA.
Especially, due to handoff scenarios when HA
sends revocation message whenever a MN handoff from one FA to another. The
fact that FA is available for possibly
every MN, makes the scalability of this mechanism very EXPENSIVE.

Now: I would like to propose another replay protection mechanism which is
much simpler than this and
does not suffer from the weakness of the draft's mechanism. I would like to
propose this mechanism in 
another thread unless people prefer to have one thread for all of this.

I hope that the ADs would have a chance to review the points raised by this
thread and the proposed replay 
protection mechanism before approving this as an RFC.

Regards,
Ahmad