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

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> Yes, but this gives you additional time to do a more heavy-weight
> verification
> (whether using the DNS or PK for verification).

Ok, agree that this is an option, but it is an expensive option, i guess.
You will have to echange packets periodically (HoTI/HoT CoTI/CoT like
exchange) to always have valid authorization information available
(if authorization information lifetime is long you expose the host to more
dangerous attacks)
So, i guess that we would better off if we don't use such a mechanism (if we
can) and we just use the strong one.
But i agree that we should keep it in mind as a last resourse

[....]

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

Well we could generate an ephemeral AID so that the every app has a
different AID. So we can distinguish every communication using its AID.
The other option is not to do it at the M6 layer, but do it at the TCP layer

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

Yes, i may agree with that.
But the time limited option has a very important drawback: it is time
limited :-)
So it can be used as a bridge solution while you verify the binding with
stronger methods, as you mention, but not for much more than that.
The connection oriented solution can be used without any additional strong
mechanism

Regards, marcelo

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