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

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



> 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.

Yes, but this gives you additional time to do a more heavy-weight verification
(whether using the DNS or PK for verification).
Before a failure is likely to occur it is desirable to have a strong 
verification for at least one alternate locator for the peer.
But if you don't, this weak verification could be used for some time
(a few minutes was the number that was picked for MIPv6). 

> 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

That is true for MIPv6.
But in multi6 there are approaches like using the DNS or public key CBIDs
for a strong verification.

> 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.

I don't know how that interacts with application assumptions.
The fact that some applications, in order to perform some work,
creates multiple parallel or sequential transport connections,
means that an application might implicitly assume that such connections to
the same IP address actually reach the same peer.
Then there is the issue when the ULPs notion of "connection" isn't known to
the multi6 layer; for example applications layered over UDP.

My gut feel is that the time limited weak verification has more predictable
behavior than basing things on some notion of ULP "connection".

But the point of my note was really that MIPv6 provides an example of
another building block that can be considered when looking
at performance/security tradeoffs for multi6.

  Erik