Subject: [mobile-ip] Problem in Rate Limiting of RR messages

From: "Krishna Kumar" <[email-masked]>
Date: Thu, 10 Oct 2002 15:26:42 -0700

Hi,

In draft 18 as well as Charlie's new draft, I feel there are two problems
with the rate limiting of RR messages :

1.  Rate Limiting of HoTI/CoTI, according to the draft, needs to be done as
long as the COA doesn't change. And once the MN moves from network A to B,
the rate limiting feature is restarted from scratch. But why is rate
limiting needed in the first place for HoTI/CoTI messages since :
      a. If you stay in the same network, the only reason you would send
more HoTI/CoTI messages is due to retransmission timeout. Retransmission is
being done at 1 sec interval, while rate limiting is also at the same
interval (not that it matter, you can always achieve rate limit by keeping
a suitable value for retransmission timeout), hence rate limiting is being
done automatically as part of retransmission timeout.
      b. If you moved to another network, rate limiting is anyway not done
(basically it goes back to the 'init' stage).

So effectively, rate limiting of HoTI/CoTI need not be done ?

2. Shouldn't HoT/CoT be rate limited to avoid CN's responding to DoS
attacks from nodes pretending to move ?

Thanks,

- KK

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Oct 2002 16:49:56 +0300

> So effectively, rate limiting of HoTI/CoTI need not be done ?

See issue 126, where we decided that we need normal back-off
scheme for individual bindings AND a rate limitation scheme that
affects everything that is sent to the same CN. The motivation
for the latter is that we may want to limit the number of RRs
and BUs sent if there are multiple home addresses. The current text
says:

    The mobile node SHOULD start a separate back-off process for
    different message types, different home addresses and different
    care-of addresses.  However, the mobile node MUST NOT send a
    particular mobility message to any individual node more often than
    once per MAX_UPDATE_RATE seconds.

But upon reading this, perhaps the difference between rate limitation
and back-off wasn't clear. Maybe this would make it clearer:

    The mobile node SHOULD start a separate back-off process for
    different message types, different home addresses and different
    care-of addresses. However, in addition an overall rate limitation
    applies for messages sent to a particular correspondent node. This ensures
    that the correspondent node has sufficient amount of time to answer
    when bindings for multiple home addresses are registered, for instance.
    The mobile node MUST NOT send Mobility Header messages of a particular
    type to a particular correspondent node more often than
    once per MAX_UPDATE_RATE seconds.

> attacks from nodes pretending to move ?

Let's look at this first from the point of view of other nodes.
It is indeed possible for the HoTs and CoTs to be reflected from a
CN and directed to a victim node. However, (a) this requires that
no ingress filtering is applied and (b) other protocols such as ICMP,
TCP could easily be used for the same task. So it does not appear
to be useful from the point of view of other nodes.

What about the CN then? As 14.4.5 describes, the CN may have to give
up on RO if its under an attack. What 14.4.5 doesn't say is that there
are different ways of doing this, and good implementations would
first start dropping a fraction of HoTIs and CoTIs, then stop accepting
any new bindings, finally give up RO alltogether. But I'd prefer to
leave these optimisations to smart implementers.

Jari