Hi all,
in the interest of transparency, we (the AODVv2 author team) want to send out
more updates on what we've been doing, and this is the first of these e-mails.
We've restructured (and sometimes rewritten) our security considerations a bit
and added a subsection about the Trust Model, and we'd love to hear your
opinions on those changes. You can find the result and a diff to the current
considerations in the attachments. (the formatting was done manually, so it
might be a bit wonky)
Some notes:
* This is all work in progress, so please poke holes into it where you can!
* While (afaik) the Availability/Confidentiality/Integrity model may be
considered a bit dated, I thought it might be a good starting point.
* I was wondering if “Encryption will not only protect against unauthorized
devices obtaining
information about network topology” isn't a tad too short and bold– maybe we
could add a clarification along the lines of:
Encryption will not only make it more difficult for unauthorized devices to
obtain
information about network topology but will also ensure that only trusted
routers participate in routing operations: When messages are encrypted,
a malicious observer would have to monitor the entire network to understand
its topology and traffic flow. And even then, due to the hop by hop
nature of the protocol and the fact that messages are regenerated rather
than forwarded (resulting in a different payload every time),
following the path of a message would be hard if its transmission is not
the only encrypted traffic produced by the network.
Regards,
Lotte
13. Security Considerations
This section describes various security considerations and potential
avenues to secure AODVv2 routing. The main objective of the AODVv2
protocol is for each router to communicate reachability information
about addresses for which it is responsible, and for routes it has
learned from other AODVv2 routers.
Networks using AODVv2 to maintain connectivity and establish routes
on demand may be vulnerable to certain well-known types of threats,
which will be detailed in the following. Some of the threats described
can be mitigated or eliminated. Tools to do so will be described also.
13.1 Availability
Flooding attacks using RREQ amount to a denial of service for route
discovery: By issuing RREQ mesages for targets that don't exist, an
attacker can flood the network, blocking resources and drowning out
legitimate traffic.
Valid route table entries can be replaced or modified by maliciously
constructed RREQ and RREP messages, destroying existing routes and the
network's integrity.
Links could be erroneously treated as bidirectional if malicious unsolicited
or spoofed RREP and RREP_Ack messages were to be accepted.
Maliciously crafted or replayed RERR messages can be used to disrupt active
routes.
However, The on-demand nature of AODVv2 route discovery automatically reduces
the vulnerability to route disruption. Since control traffic for
updating route tables is diminished, there is less opportunity for
attacks and failure.
Processing requirements for AODVv2 are typically quite
small, and would typically be dominated by calculations to verify
integrity. This has the effect of reducing (but by no means
eliminating) AODVv2's vulnerability to denial of service attacks.
13.2 Confidentiality
Passive inspection of AODVv2 control messages could enable
unauthorized devices to gain information about the network topology,
since exchanging such information is the main purpose of AODVv2.
13.3 Integrity
Out of the box, AODVv2 provides no integrity protection. Any participating
router may pose as another router by sending RREQ, RREP, RREP_Ack and RERR
messages in its name. Replaying of (old) RREQ or RREP messages, however,
would be of less use to an attacker, since they would be dropped immediately
due to their stale sequence number.
Encryption MAY be used for AODVv2 messages. If the routers share a
packet-level security association, the message data can be encrypted
prior to message transmission. The establishment of such security
associations is outside the scope of this specification. Encryption
will not only protect against unauthorized devices obtaining
information about network topology but will ensure that only trusted
routers participate in routing operations.
The data contained in AODVv2 routing protocol messages SHOULD be verified
using
Cryptographic Integrity Check Values (ICVs)values, to
avoid the use of message data if the message has been tampered with.
Replay attacks SHOULD be prevented by adding timestamps to the messages.
While the generation of these ICVs and timestamps is out of scope for
this document, they MUST be represented as defined in [RFC7182].
13.3.1 Recommendations for ICV and timestamp generation
This section provides specific recommendations for
the use of the integrity checking and timestamp functions defined in
[RFC7182] to ensure the integrity of each AODVv2 message. The
calculation used for the Integrity Check Value will depend on the
message type. Sequence numbers can be used as timestamps to protect
against replay, since they are known to be strictly increasing.
When more than one message is included in an RFC5444 packet, using a
single ICV Packet TLV and a single TIMESTAMP Packet TLV is more efficient
than including an ICV Message TLV and TIMESTAMP Message TLV in each
message created. In this case, the RFC5444 multiplexer must be instructed
to include the ICV and TIMESTAMP Packet TLVs in packets containing AODVv2
messages, or must be selected because it always performs these additions.
If the multiplexer is not capable of adding these Packet TLVs, they SHOULD
be included in each AODVv2 message.
RREQ messages advertise a route to OrigAddr, and impose very little
processing requirement for receivers. The main threat presented by
sending an RREQ message with false information is that traffic to
OrigAddr could be disrupted. Since RREQ is multicast and likely to
be received by all routers in the ad hoc network, this threat could
have serious impact on applications communicating by way of OrigAddr.
The actual threat to disrupt routes to OrigAddr is reduced by the
AODVv2 mechanism of marking RREQ-derived routes as "Unconfirmed"
until the link to the next hop is confirmed. If AODVv2 routers
verify the integrity of the RREQ message data with the help of ICVs,
then the threat of disruption is minimized. Since OrigAddr is included in the
RREQ, the ICV can be calculated and verified using message contents.
The ICV SHOULD be verified at every step along the dispersal path of
the RREQ to mitigate the threat. Since RREQ_Gen's sequence number is
incremented for each new RREQ, replay protection is already afforded
and no extra timestamp mechanism is required.
RREP messages advertise a route to TargAddr, and impose very little
processing requirement for receivers. The main threat presented by
sending an RREP message with false information is that traffic to
TargAddr could be disrupted. Since RREP is unicast, this threat is
restricted to receivers along the path from OrigAddr to TargAddr. If
AODVv2 routers always verify the integrity of the RREP message data with the
help of ICVs,
then this threat is minimized. Since TargAddr is included as a Data
Element of the RREP, the ICV can be calculated and verified using
message contents. The ICV SHOULD be verified at every step along the
unicast path of the RREP. Since RREP_Gen's sequence number is
incremented for each new RREP, replay protection is afforded and no
extra timestamp mechanism is required.
RREP_Ack messages are intended to verify bidirectional neighbor
connectivity, and impose very little processing requirement for
receivers. The main threat presented by sending an RREP_Ack message
with false information is that the route advertised to a target
address in an RREP might be erroneously accepted even though the
route would contain a unidirectional link and thus not be suitable
for most traffic. Since RREP_Ack is unicast, this threat is strictly
local to the RREP transmitter expecting the acknowledgement. A
malicious router could also attempt to send an unsolicited RREP_Ack
to convince another router that a bidirectional link exists and
subsequently use further messages to divert traffic along a route
which is not valid. If AODVv2 routers always verify the integrity of
the RREP_Ack message data, then this threat is minimized.
The RREP_Gen SHOULD use the source IP address of the RREP_Ack to identify the
sender, and so the ICV SHOULD be calculated using the message
contents and the IP source address. The message must also include
a timestamp to protect against replay attacks, using TargSeqNum from the RREP
as the value in the TIMESTAMP TLV.
RERR messages remove routes, and impose very little processing
requirement for receivers. The main threat presented by sending an
RERR message with false information is that traffic to the advertised
destinations could be disrupted. Since RERR is multicast and can be
received by many routers in the ad hoc network, this threat could
have serious impact on applications communicating by way of the
sender of the RERR message. However, since the sender of the RERR
message with erroneous information MAY be presumed to be either
malicious or broken, it is better that such routes not be used
anyway. Another threat is that a malicious RERR message MAY be sent
with a PktSource included, to disrupt PktSource's ability to send to
the addresses contained in the RERR. If AODVv2 routers always verify
the integrity of the RERR message data with the help of ICVs, this threat is
reduced.
The receiver of the RERR SHOULD use the source IP address of the RERR to
identify the sender. The message must also include a timestamp to protect
against replay attacks, using SeqNum from RERR_Gen as the value in the
TIMESTAMP TLV.
13.4 Trust Model
Since routing information is distributed to neighbours on a hop-by-hop basis,
and route messages are regenerated at each router, AODVv2 assumes a security
model of transitive trust. The sender of a message must be trusted in order
for receiving one-hop neighbours to store the routing information it
provides and regenerate the message to their own one-hop neighbours.
Routes are installed based on information received from trusted neighbours.
Therefore a chain of trust back to the originator of a message is assumed
by any router using the routing information received.
Since messages are regenerated rather than forwarded, the message concepts
known as RREQ, RREP and RERR do not travel as a single unchanged entity
between source and destination, and therefore message integrity cannot be
assured end-to-end. Using ICVs and timestamps, messages can be protected
on a hop-by-hop basis, allowing only those routers with knowledge of a
shared secret key to participate in routing information exchanges, and
protecting against replay attacks.
