Re: [manet] Find Sender of Route Reply

"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> Wed, 11 November 2015 13:32 UTC

Return-Path: <chris.dearlove@baesystems.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979621ACD87 for <manet@ietfa.amsl.com>; Wed, 11 Nov 2015 05:32:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.103
X-Spam-Level:
X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4neaDSdCE2iH for <manet@ietfa.amsl.com>; Wed, 11 Nov 2015 05:31:59 -0800 (PST)
Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED381ACD8D for <manet@ietf.org>; Wed, 11 Nov 2015 05:31:58 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.20,275,1444690800"; d="scan'208";a="18304499"
Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta2.baesystems.com with ESMTP; 11 Nov 2015 13:31:39 +0000
X-IronPort-AV: E=Sophos;i="5.20,275,1444690800"; d="scan'208";a="119887926"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 11 Nov 2015 13:31:39 +0000
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.152]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Wed, 11 Nov 2015 13:31:39 +0000
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Ahmad Haghighi <haghighi.ahmad@gmail.com>, "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] Find Sender of Route Reply
Thread-Index: AQHRHHDayekepuqihEiTNryky7X6IJ6Wzo1w
Date: Wed, 11 Nov 2015 13:31:38 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D6BAC1D7C@GLKXM0002V.GREENLNK.net>
References: <CAJVE_fUFEAY1nWGOW_7G=pBraTj+HeLBNuxK9B1PwEzeBb11+w@mail.gmail.com>
In-Reply-To: <CAJVE_fUFEAY1nWGOW_7G=pBraTj+HeLBNuxK9B1PwEzeBb11+w@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/qZYUXPCge3xFPVgICie7U4QQ07E>
Subject: Re: [manet] Find Sender of Route Reply
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Nov 2015 13:32:01 -0000

There are two potential choices:

- RREQ has an integrity check value to indicate that someone trusted created it, if not necessarily the destination. That someone might be identifiable or not.
- RREQ has a signature that indicates that the destination created it.

Unfortunately, an RREQ that changes as it is forwarded (aggregating data of any sort) makes the second option tricky, unless there’s some sort of aggregating signature as it is forwarded. But I’m not an expert on the latter.

The most trivial case of the former is simply that everyone trusted has a single shared key. That has obvious issues – although it was good enough that embodied as RFC 7183 we could get 7181 through the system (as a “must implement, do not need to use” minimal case). Alternatively something identity-based (e.g. draft-ietf-manet-ibs) could be used, so you know who created the message you received, but you are relying on a chain of trust, hop by hop. At which point you might as well just sign packets (see RFC 7182).

But in even the weakest case (the single shared key used hop by hop) there has to be a failure for things to go wrong - either loss of key (in which case all bets are off) or suborning one router (who can do quite a lot of damage).

I haven't read the latest AODVv2 draft yet, but this sort of thing should be described in its security considerations - the previous draft though didn't discuss this as far as I recall.

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP


From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ahmad Haghighi
Sent: 11 November 2015 11:05
To: manet@ietf.org
Subject: Re: [manet] Find Sender of Route Reply


*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here.
If you feel the email is suspicious, please follow this process.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Thanks. I think so
But my supervisor wants another reason for that!!! 

On Wed, Nov 11, 2015 at 10:50 AM, Ahmad Haghighi <haghighi.ahmad@gmail.com> wrote:
Thanks. I think so
But my supervisor wants another reason for that!!! 

On Sun, Nov 8, 2015 at 8:37 PM, Henning Rogge <hrogge@gmail.com> wrote:
Hi,

a malicious node could easily pretend to be a different node... or try
to "frame" a different node further away.

Without a source-specific signature, how do you want to be sure that a
data field is reliable?

Henning Rogge

On Fri, Oct 16, 2015 at 11:28 AM, Ahmad Haghighi
<haghighi.ahmad@gmail.com> wrote:
> Hello
> I'm working on MANET security and Blackhole/Grayhole detection.
> I have a question, so please help me, or  If you have little time and so
> can't answer me, please refer me to some people or book for finding my
> answer. my question is:
> In MANET (with DSR or AODV) when a Route Reply (RREP) packet received by the
> source node, the source node can not be sure who is the sender of RREP, (it
> is a assumption in all papers) so source node (the node which initiated
> Route Discovery) should do some operations for detecting exact address of
> Malicious node (sender of malicious RREP).
> But e.g. in DSR Header we have a "Source Address" field which carries
> address of sender. or also in IP header of ADOV RREP.
> I don't understand why source node is *not sure* about identity of sender of
> RREP?
> I don't know the reason of above assumption.
>
> Let me explain my question more oblivious.
> Source node, receive a malicious RREP, the source node use it's path for
> sending packets. As expected Malicious node drops all packets.
> Ok.
> Now we want to find malicious node (sender of RREP), If value of "Source
> Address" Was reliable, we be able to easily find malicious node (sender of
> RREP).
> But in all papers, authors employs some mechanisms for detecting malicious
> node (sender of RREP). so we can conclude value of "Source address" field is
> not reliable.
> My question is, why? why source node can not use this field for detecting
> and removing malicious node?
> One answer is because of IP Spoofing i.e malicious node can use another
> address as source address
> but this not the only reason, I need to find another reason for that
>
> I hardly need the answer.
> So please guide me
> Thanks
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>




-- 
Ahmad Haghighi.
​
​Secure Communications MSc
 Student.
Department of Electrical & Computer Engineering.
Yazd University. 
Islamic Republic of Iran.




-- 
Ahmad Haghighi.
​
​Secure Communications MSc
 Student.
Department of Electrical & Computer Engineering.
Yazd University. 
Islamic Republic of Iran.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************