Re: [Mipshop] NS-NA Exchange in draft-vidya-mipshop-handover-keys-aaa-01

[Vidya Narayanan <[e-mail]>]

Hi Christian,
Thanks for providing comments on this issue. Actually, optimistic DAD
will not work in this case as you said. Also, the threats of ND can't
really be solved without SEND.

We have been having an offline discussion on whether or not the CoA
validation is even in the scope of the draft. The thought is that this
is typically not a AAA issue - so, perhaps we can mention it in the
security considerations section and leave it at that. Short of CGAs, a
clean solution for this is not available.

We are waiting for Jari and Mohan to review and give us comments. If
you have any comments on the scope of this, please let us know.

Thanks,
Vidya


On 12/13/05, Christian Vogt <[e-mail]> wrote:
> Hi Vidya and co-authors,
>
> I read draft-vidya-mipshop-handover-keys-aaa-01.txt (henceforth called
> "the draft") and caught up with the meeting minutes from Vancouver.
>
> There was a brief discussion in Vancouver on the way CoA uniqueness is
> verified in the draft.  The suggestion is to have the acess router (AR)
> send an NS and wait for responding NAs, where the mobile node claiming
> the CoA does *not* send an NA.
>
> This is sort of a DAD-like approach.  Greg proposed that you better use
> OptiDAD instead.
>
> I do not fully agree.  The draft uses the NS-NA exchange in order to
> mitigate the threat of connection hijacking by malicious (or
> inadvertent) redirection, whereas OptiDAD tackles inadvertent address
> collisions only.
>
> It's ok for OptiDAD to expose nodes to a short "phase of uncertainty"
> during which two nodes may use the same address because (a) the
> probability for such an event is vanishingly small anyway, and (b) other
> nodes' communications won't be affected due to the way OptiDAD handles
> use of Optimistic Addresses.
>
> But in draft-vidya-mipshop-handover-keys-aaa-01.txt, we talk about (a)
> malicious connection hijacking, which won't happen by an unlikely
> coincidence, and (b) packet redirection, which OptiDAD's rules for
> Optimistic Addresses cannot do much about.
>
> Running the NS-NA exchange in an OptiDAD style would have to be
> supplemented with a variant of Credit-Based Authorization, which in turn
> would require existing credit to be transferred from AR to AR.
>
> But note that the NS-NA exchange is concurrent anyway because it happens
> prior to handoff.
>
> Having said that, I guess that the suggested NS-NA exchange is fine from
> the perspective of performance...
>
> ...however, I have concerns with respect to the security it provides:
>
> Assume an attacker, spoofing a neighbor's CoA, jams the link when the AR
> sends the NS and/or when the victim sends its NA.  The AR won't receive
> an NA from the victim then, and it will falsely assume that the attacker
> uses a correct CoA.
>
> F-MIPv6 solves this issue thus:
>
> [From RFC 4068, section 8]
> >   If an access router can ensure that the source IP address in an
> >   arriving packet could only have originated from the node whose
> >   Link-Layer Address is in the router's neighbor cache, then a bogus
> >   node cannot use a victim's IP address for malicious redirection of
> >   traffic.  Such an operation is recommended at least on neighbor
> >   discovery messages including the RtSolPr message.
>
> This approach does not help if the attacker spoofs its L2 address,
> unfortunately.  Seems that SEND is the only way to solve the issue.
>
> Without SEND, you could still force the attacker to stay on the old link
> if the old AR re-sends NSs until the tunnel is torn down, each
> successive transmissions spaced by a random amount of time.  The
> attacker would have to jam the old link every so often, thus exposing
> itself as someone malicous.
>
> Besides, the new AR would never see the attacker arrive.  You might be
> able to communicate this information back to the old AR, which could
> then tear down the tunnel.  But this doesn't help much if the attack's
> purpose is DoS rather than connection hijacking...
>
> Regards,
> - Christian
>
> --
> Christian Vogt, Institute of Telematics, University of Karlsruhe
> www.tm.uka.de/~chvogt/pubkey/
>
>
>
>
>
>
> _______________________________________________
> Mipshop mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mipshop
>

_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop