[aodvv2-discuss] Security considerations -- considerations
- From: "Charles E. Perkins" <charliep@xxxxxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Mon, 27 Apr 2015 16:44:24 -0700
Hello folks,
First, here is some interesting email from Chris Dearlove, March 24 2015:
Stan:
If we added text in the Security considerations to say that
implementations needing security should refer to RFC 7182, and
saying that message signatures should be employed as well, would
that address your concern?
Chris:
More than one issue there. First, what will make the ADs happy? My
guess is maybe. Second, is that a workable option? Yes, in fact you
don't need the message signatures. If messages are created new then
message signatures are pointless (applies to RREQ?). Third, I think
there currently are vague suggestions that don't have enough definition
to be interoperable. Those I think need work (could remove, could
improve),
Notably, Chris seems O.K. with removal. So, we can remove a lot.
Maybe, the more the better.
We don't need the Timestamp TLV for messages that have SeqNum.
The ICV will prevent changes to message contents. But, since most
AODVv2 messages don't include identifying information for the router
regenerating the message, the ICV cannot protect against masquerading.
In order to do that, we would have to include a node identifier of some
sort in the control messages.
However, within RREQ and RREP messages, masquerading may not be
any more of a threat than simply publishing erroneous or malicious
information. If I tell you lies, I can do it while not pretending to be
anyone
else. And, in an ad hoc network, it is expected that nodes will move away,
so that I can tell lies and then disappear.
Within RERR and RREP_Ack messages, masquerading could be harmful.
The threats are as follows:
- RREQ messages can appear to offer "better" routes to OrigAddr,
and thus disrupt existing routes.
- RREP messages can appear to offer "better" routes to TargAddr, and
thus similarly disrupt existing routes, or misdirect new traffic.
- RERR can disrupt existing routes.
- RREP_Ack could establish false expectation of bidirectionality
Notably, OLSRv2 and NHDP were published, and the security mechanisms
were done much later. If we describe the threats and possible mechanisms
for protection in our Security Considerations, maybe we can make another
document for any needed additional protocol mechanisms outside 7181.
For instance, it could be that we would need some sort of "proof" that
a node advertising updates to a route is authorized to do so. This will
require a bit of thought...
Regards,
Charlie P.
--
Regards,
Charlie P.
Other related posts:
