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

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
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop