[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: multi6-threats-00.txt vs. MIPv6 - different strength verifications?



> But, based on the MIPv6 model, one could also envision a weak but
> time limited
> verification that builds on some earlier verification (whether the earlier
> verification was weak or strong).
> For instance, if the peer shows that it knows a clear-text random number
> which was exchanged during the earlier verification, then it
> might be reasonable to allow redirection to a new locator *for a
> limited time*.

The problem here is how to extend the lifetime of the binding after an
outage. (using mip terminology)
The clear text random number has to be exchanged form both locators the
initial one (HoA) and the new one (CoA)
Once the outage has occurred, you cannot longer verify the HoA, since it has
become unreachable.
So the resulting solution only preserved established communications for the
*limited time* that the redirection last for.
this IMHO is an inherent problem of using IP addresses as identifiers and it
due to the fact that the way to prove the ownership is only provided by the
routing system( a possible workaround is to use an external authority to
secure the binding, such as the DNS), but in the nature of the IP address,
the only verifiable characteristic is the routability
The other possible workaround would be not to limit in time the binding but
limit it by connection, so that checks are performed when a connection is
set up, In this case, an attacker can hijack a connection but not a complete
IP address (in its identifier role).
This would change the scope of permitted attacks from some minutes in the
case of MIP to a single connection.

Regards, marcelo

>  An on-path attacker could use this, but would have to repeat the
> attack every
> few minutes i.e. it is not sufficient for the attacker to "drive by" some
> link and launch an attack that lasts forever.
> If the attacker needs to be on the path all the time the residual threat
> wouldn't be much different than what an on-path attacker could do today.
>
> Comments?
>    Erik
>
>