Subject: [manet] SAODV next hop (non-)authentication?

From: Sebastian Nanz <[email-masked]>
Date: 15 Feb 2006 08:23:11 +0000

I have a question about the security of SAODV with respect to ensuring
that nodes acquire correct topological information:

Neither AODV RREQ and RREP messages nor their SAODV extensions contain
the immediate sender of a message which becomes the next hop on the
route between the current receiving node and the originator of the
message. I understand this information is taken from the IP header.

This however seems to imply that modifying the sender field of the IP
header can be used to launch an attack. In the most trivial case,
consider the scenario S --- A --- D, where an attacker A for a RREQ
from S to D pretends to be S by modifying the IP header (and otherwise
forwards the RREQ unchanged to D), and for the RREP pretends to be D.
Thus A forces S and D to accept wrong topological information (namely
that they are direct neighbors, which they are not). 

Other protocols seem to go through much trouble to secure against this
critical flaw (e.g. per hop signatures in ARAN), but I cannot see how
this issue is addressed in SAODV and would be grateful for
clarification.
 
Best wishes,
Sebastian

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Thu, 16 Feb 2006 13:12:59 +0100

Dear Sebastian,

if SAODV uses SAKM, the IP address is derived from a hash of the public 
key of the node. Therefore, 'A' cannot impersonate another node, and the 
attack you mention is not possible. Remember that the public key is 
included in the security extension messages.

In addition, per hop signatures are, IMHO, too expensive. They require 
each intermediate node to sign and others to verify, which requires more 
processing power and longer discovery route times.

Best regards,

	Manel

---

From: Sebastian Nanz <[email-masked]>
Date: 16 Feb 2006 14:04:01 +0000

Dear Manel,

> included in the security extension messages.

I'm not convinced. The public key included in the extension messages is
the one of the source (RREQ) or destination (RREP) of a route request.
The IP address I was talking about is the one of an arbitrary
intermediate node and thus cannot be confirmed by hashing the included
key (this would only yield the IP address of one of the endpoint nodes).
In the mentioned scenario, 'A' still seems to be able to impersonate any
node it knows the public key of.

In any case, you seem to imply that the attack is valid if SAKM is not
used. SAKM is an optional component in your current draft. You might
want to point out explicitly in one of the next drafts what implications
the use of one or the other key management scheme has on the security of
the parent protocol.

> processing power and longer discovery route times.

This is of course a valid design decision, if confirmed by performance
analyses.

Best wishes,
Sebastian

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Thu, 16 Feb 2006 16:07:29 +0100

Hi Sebastian,

> key (this would only yield the IP address of one of the endpoint nodes).

In that case, the malicious node would need to get itself in the 'going 
to be selected path' (which is not an easy thing to do) and the only 
thing that would achieve would be DoS (which is out of the scope of 
SAODV) because the route discovery would fail and the routes expire.

Doing it on the RREQ or on the RREP the effect is that the RREP will not 
  be able to travel back to the originator. The node that received the 
message with the changed src IP would try to forward the RREP to the 
forged src IP address (either it won't be a neighbor or it will be a 
neighbor without route to the route discovery originator).

> node it knows the public key of.

No, because it also needs to know the private key to be able to sign the 
message.

> the use of one or the other key management scheme has on the security of

Well, of course the attack is valid if you use a non appropriated key 
management. :)

Anyway, I'll put the requirements for other possible key management 
schemes on the next draft version. It was not clearly stated in the 
current version because SAKM was still part of SAODV in the previous 
draft version.

Regards,

	Manel

---

From: Sebastian Nanz <[email-masked]>
Date: 16 Feb 2006 15:47:00 +0000

On Thu, 2006-02-16 at 14:31, Vincent Toubiana wrote: 
> Well I agree that the "flaw" is valid in SAODV, however I do not
> understand why you say that ARAN is protected against this kind of
> flaw. It is engouh for an attacker to replay (without any change)  the
> received packet to the next node on the route to create false topology
> information. Per hop signature does not prevent that.
>
> Plus you have to consider that if A forward the packet wihtout any
> change, then S will heard that a replay the packet. So S will be aware
> that it has a malicious neighbor.

I agree. But in ARAN, replay without any change is also the only thing
you can do, whereas in SAODV the attacker can set the sender field in
the IP header to *any* value.

My initial scenario is thus too simplistic if it comes to comparing ARAN
and SAODV. But if you consider something slightly more elaborate, such
as S --- A --- D --- N, and A impersonates N, then A's attack will
eventually produce additional route errors/requests in SAODV, which
would be prevented by ARAN.

> SAODV) because the route discovery would fail and the routes expire.

I think my motivation for asking my initial question was to find out
whether SAODV has similar ambitions as ARAN. That these kinds of attacks
are considered "out of scope" for SAODV is thus a good enough answer for
me. Many thanks for clarifying this.

Best wishes,
Sebastian