Subject: Re: [manet] Security question for draft-ietf-manet-aodvv2-04

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 13 Sep 2014 14:33:27 +0200

My comment Subject draft: draft-ietf-manet-aodvv2-04 (last
version submitted in 20 July).

Dear Thomas,

Thanks for your questions, my delay to reply have some reasons. I
thought your question was for the WG chairs or AD or draft authors (the
message was multiplexed with some texts that I have no part in), but it can
be understood that it addresses all WG. As I am taking a position of
answering and editing on the list to help in this draft's progress, I will
answer your review-questions regarding the new submission
version-draft, because any part of WG still did not reply.

On Tuesday, July 22, 2014, Thomas Clausen wrote:
>
> Given that  we were told that a way forward for security had been
identified, but we were not allowed to know what that way forward was,
 I'll  ask some specific questions that I hope can be answered.

It is strange that you as a participant in the WG to be not allowed to know
about our/your work way (IMHO the WG chairs are responsible for such
issue). I will do my best in discussing and participation with you for
the draft progress.

>
>
> Page numbers refer to the document in <subject>
>
> --- Page 4 ---
>
> Draft text:
> > When a data packet is received to  be forwarded but there is no valid
route for the destination,
> > then  the AODVv2 router of the source of the packet is notified via a
Route  Error (RERR)
> > message.

I think that The route state is not valid or break as it was active, so it
needs to send error message. Error messages are for sources to stop sending
data, to reduce losses.

> Comment:

>
> This, then, essentially, means that for every non-routable packet, the
protocol must be informed -- as for with routing table "hits" for marking a
route as active, this is uncommon, and somewhat intrusive, as has been
discussed elsewhere.

Yes the route is informed to stop sending data from nodes of the reverse
forwarding path.

>
>
> Question:
> With that being said, as a router must send a message for each
non-delivered message, this also does sound like a formidable attack vector
against a router: pump it data packets to a set of non-existing address,
and watch it exhaust itself generating RERRs.
> How is that being guarded against?

No, the routers don't react only to its routes if there is no route entry
the packet is dropped. That is normal to any router. If the data packet was
for existing entries which are not valid then error is send back.

>
>
> Draft text:
> > Each upstream router that receives the RERR  marks the route as broken.
>
> Comment:
> So, essentially this implies that it is possible to do a
denial-of-service attack, by injecting RERRs and cause other devices to do
a RREQ flooding on the network -- draining battery, causing channel
congestion, etc.

This gets us out of context of draft, that text is in first section as
overview (not full details), so you need to read RERR handling. RERRs are
not listened only from neighbours.  See section 8.4 of handling RERR which
examines messages and secures that example you refer to. However, do you
want to suggest some edit to this overview section to make it refer to
other sections?

>
> Question:
> How is this protected against?
>
> Bigger Question:
> It is possible to attack a router, and the network *both* by sending
control signals and by sending data packets.

If any MANET router does not know its neighbours then yes attacks are
possible. Our protocols know their neighbours and active routes.

>
>
> One might device an "admission policy" based in ICVs on control signals,
that could be used to exclude (as in the above) a rogue RERR.
>
> How to protect against attacks-by-data-packets? Requiring ICVs on all
data packets seems unfeasible, what's the "way forward" for this?

When Routes are active then each router only forwards its neighbour.

Best Regards,

AB