Subject: Re: AODV RREQ forwarding

From: "Elizabeth M. Belding-Royer" <[email-masked]>
Date: Tue, 30 Oct 2001 15:31:16 -0800 (PST)

~> 
~> Thank you for replying so quickly. Ok, so most of the issues I brought
~> up has already been covered by other feedback. The new text you are
~> refering to, is that available somewhere? I would need it for the
~> implementation I'm working on...
~> 

It will be available in the very near future.

~> While I'm at it, I might as well ask about section 8.3. It is a bit
~> unclear if the time for "remembering" RREQ's should be updated with
~> BROADCAST_RECORD_TIME each time the same RREQ arrives or just for the
~> first one?
~> 
~> 

I don't think there will be a significant difference either way,
but I'd say it should be set with the first RREQ incarnation, and
not updated after that (for simplicity).

Elizabeth

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Wed, 31 Oct 2001 11:11:34 +0200

Hi everybody:

I looks like while I was sleeping (I'm in Europe) there
has been some interesting mails on the list.
Let me put my five cents.

-----
Erik> > ~> Even more serious is the case when a node which does not run
AODV tries
> > ~> to communicate with a node that runs AODV. The AODV node will then
> > ~> generate a RREQ for a node to which there exists no route (at least if
> > ~> you depend on hello messages) and a flooding of RREQ's will occur. This
> > ~> could be exploited to attack the ad hoc network. I didn't manage to find
> > ~> anything in the AODV draft that prevents this from happening, but maybe
> > ~> I missed something? Are my findings at all valid?
> > 
Eli> > You mean what happens when the destination is a node which is not
> > running AODV?  I'd assume in that case you won't be able to locate it,
> > unless its neighbors have learned some other way that it is its
> > neighbor.  I don't think this problem is unique to AODV, though.
> 
Erik> Yes, I guess it is a problem shared by most reactive protocols
(that use
> RREQ's of some sort). The result would be that a node, or possibly
> several depending on how many nodes the non-participant node (not
> running AODV) is trying to communicate with, would send "bogus" RREQ's.
> Other nodes would forward those RREQ's and thus generating a lot of
> unnecessary traffic. But maybe not enough to do any harm...
> I was just wondering if there would be some way to avoid this behavior?
> Or is it something which is not seen as a problem?

The problem is much more bigger that what you think, Erik.
It's not only that reactive protocols might suffer from
this denial of service attacks.
The real problem is that in traditional networking you trust your
routers
(which is kind of ok), but in manet all nodes are routers (and trusting
all the nodes in a wireless network is not a good idea).
So, in manet protocols you have many more possible attacks (much more
dangerous than denial of service): You can impersonate people, and do
all kind of "bad things". And denial of service can be achieved
using many more ways.

If you are interest in implementing a manet protocol that has some
security features I'd recommend you to take a look to my Secure AODV
draft
that was sent to this mailing list (in october the 10th).
It's an extension of AODV, so you can just add it to your AODV
implementation
(and make 2 minor modifications to AODV that are documented in the
draft).

-----
Erik> ~> While I'm at it, I might as well ask about section 8.3. It is a
bit
> ~> BROADCAST_RECORD_TIME each time the same RREQ arrives or just for the
Eli> I don't think there will be a significant difference either way,
> not updated after that (for simplicity).

Well, I think it does make a difference.
If you receive periodically a RREQ (for instance, every
BROADCAST_RECORD_TIME/2)
and you update the waiting time for each of the RREQs,
then you will process only the first RREQ. 
You will keep on receiving more RREQs (maybe for years ;) )
and you will not process any of them.
(Which is obviously a wrong thing to do).

So, yeah, the answer is only the first time, but because
a very clear reason.

BR/Manel Guerrero