RE: Security requirements for identification

["marcelo bagnulo" <marcelo@it.uc3m.es>]

Hi Pekka,
>
> The problem is fairly subtle, though, and may not be very bad.
> It becomes bad only if you can *anticipate* an address someone
> else is going to use in the future, arrange yourself at that
> address (so that you can pass the test of adding the address to
> the pool at your peer), leave, and wait for your victim to
> arrive.  Then, at that point, you can flood your victim by
> claiming that you are no more available at your other addresses,
> thereby forcing the peer to use the (now) victim's address.
> You claim will be trusted since the address is already in the
> pool.
>
> > It is the event of adding a new target address to the initiator's
> > pool of addresses for the target. Regular use of the nonce in packets
> > might detect a failure condition. However, strongly protecting the
> > mechanism for adding to the pool will accomplish the same thing, and
> > it will do it with lower packet overhead. And it will do it as
> > pre-hoc prevention, rather than post-hoc detection.
>
> In my opinion, strongly protecting the adding mechanism is really
> the most important point.  It may be also useful to include a
> check whenever you start to use a locator after a long period of
> inactivity, even if the locator is already in the pool.
>
> Arranging an attack where you use a given address and stop using
> it just before your victim arrives and starts to use it seems
> to be very hard, and probably not worth worrying about.

Well, then why don't we just extend mip BCE maximum lifetime then?
If i understand correctly, this is exaclty the type of attack that the
maximum BCE lifetime bound prevents.

I mean, if we do extend the maximum BCE lifetime, we can have a very
important part of a multi-homing available easily which is the support of
multi-homing in nodes outside the multi-homed site.


Regards, marcelo