Bryan Wang writes: Just found one interesting scenatrio when testing
our implemenation of MIPv6:

I have a  MN with two addresses configured, A1 & A2. It sends two BUs to an
CN, one with A1 as the home address, A2 as the alt care of addrews, the
second the other way round. CN sucessfully creats the two bindings . Now
my CN trys to send a packet to A1, it immediately runs out of memory! There
is a never ending recursion trying to find the CoA address. In our
implementation, we optimize it to route looking up and sending packet through
a virtual device, which requires dynamic memory allocation.

Talked to Ed and we realized this might be a real DOS attack issue that we
should bring to the attention of the miling list.

Apparantly the quick solution would be adding a hard requirement as follows
to prevent creating an reverse binding.

CN MUST NOT send an COT message to an MN's care of address if it is the home
address in an exising binding.

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

Bryan Wang continues: Realized that a smart attacker can wait until
the two RRP succeeds, before sending any BUs. Therefore the sulotion
provided in the previous Email doesn't solve the problem. Instead, we
need a requirement like:

"When processing a valid BU that requests a CN to cache a binding, if the
care of address in the BU is the same as the home address of an existing
binding, the CN MUST silently discard the BU without creating any new
binding"

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

Jari Arkko writes: I agree that a rule like this should be added (even
if the scope of the draft could be interpreted to not cover nested
mobility). But your rule doesn't not work for the general case, this
could happen through multiple BCE entries. So I'd suggest the
following wording change in 6.1.7:

  "Binding Updates for a care-of address which is not a unicast
   routable address MUST be silently discarded."

=>

  "Binding Updates for a care-of address which is not a unicast
   routable address MUST be silently discarded. Similarly, the Binding
   Update MUST be silently discarded if the care-of address appears as
   a home address in an existing Binding Cache entry, with its current
   location creating a circular reference back to the home address
   specified in the Binding Update (possibly through additional
   entries)."

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

Jari Arkko writes to the ADs: This information is for the IESG to know
that such clarifications have been made, and to ask for your OK for
these modifications.

The issue is:

- 268: A bad MN configuration resulted in a looping BCE entry at a
  CN. Here the care of address of one BCE pointed to a home address
  of another BCE, which in turn pointed back to the first one.
  I agree that a rule like this should be added (even if the
  scope of the draft could be interpreted to not cover nested
  mobility).

  The suggested text is adding the following text to
  Section 6.1.7 (BU): "Similarly, the Binding Update MUST be
  silently discarded if the care-of address appears as a home
  address in an existing Binding Cache entry, with its current
  location creating a circular reference back to the home address
  specified in the Binding Update (possibly through additional
  entries)."

  For further info, see http://www.piuha.net/~jarkko/publications/mipv6/issues/issue268.txt

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

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

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