Subject: [manet] #36 (aodvv2): Security Considerations: Reactive protocol concept

From: "manet issue tracker" <[email-masked]>
Date: Thu, 03 Apr 2014 21:36:02 -0000

#36: Security Considerations: Reactive protocol concept

 (Thomas Clausen)
 First, there is the whole "react to failure to deliver an IP datagram
 due to not having an entry in the routing table, and by way of
 flooding control traffic", which is a formidable vector for making
 every router in the network participate in a DDOS attack.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-manet-
  [email-masked]  |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  aodvv2       |    Version:
 Severity:  Active WG    |   Keywords:
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/36>
manet <http://tools.ietf.org/manet/>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 13 Apr 2014 19:33:38 +0100

On Thursday, April 3, 2014, manet issue tracker wrote:

>  flooding control traffic",

Not sure where in the document texts you find a react to failure to
delivery by flooding.

which is a formidable vector for making
>  every router in the network participate in a DDOS attack.

Where is the attack related to the AODVv2 functions or informations?

AB

---

From: John Dowdell <[email-masked]>
Date: Tue, 15 Apr 2014 16:32:45 +0100

I think what Thomas is getting at is:

- a datagram arrives from a host, addressed to a destination that is not
listed in the handling routers table of routes.

- handling router reacts (as it is supposed to) by sending RREQ messages
and expecting either RREP or RERR messages in return.

It is possible for an intermediate router with malicious code to send a
message that creates inconsistencies in the tables of all routers in the
network. Therefore some consistency checking should take place to sense
check recently received messages against the previously known state.
However, this may be difficult since a reactive protocol by nature will not
achieve consensus among all routers and only fragments of the whole picture
will ever be formed.

It could be argued that certificates could be used to verify the
authenticity of the received information. To a certain extent that may
defend against the above problem, but not always, and I believe that the
problem of making sure all code is not malicious is out of scope of this
draft.

Regards
John

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 15 Apr 2014 22:12:51 +0200

> On 15 avr. 2014, at 17:32, John Dowdell <[email-masked]> wrote:
> 
> - a datagram arrives from a host, addressed to a destination that is not listed in the handling routers table of routes.
> 
> - handling router reacts (as it is supposed to) by sending RREQ messages and expecting either RREP or RERR messages in return.

That which I am concerned with is, that receipt of a simple unicast data packet will trigger a router to do a network-wide flood of RREQs...a formidable way for a malicious router to get all it's neighbors to perform a DDoS on the network, essentially transforming each unicast packet into a network-wide flooding operation.

So a bad guy can just generate a stream of *unicast* data packets, with each packet addressed to (different) non-existing destinations. Use each (known) neighbor as next hop in a round-robin fashion, and essentially the network is effectively brought to an un-usable state - not just locally, but globally.

> It is possible for an intermediate router with malicious code to send a message that creates inconsistencies in the tables of all routers in the network.

> Therefore some consistency checking should take place to sense check recently received messages against the previously known state. However, this may be difficult since a reactive protocol by nature will not achieve consensus among all routers and only fragments of the whole picture will ever be formed.
> 

That's a different - but also interesting - issue. I had actually not thought about that, but you are right, that definitely needs to be documented and alleviated.

> It could be argued that certificates could be used to verify the authenticity of the received information. To a certain extent that may defend against the above problem, but not always, and I believe that the problem of making sure all code is not malicious is out of scope of this draft.

With all due respect, I do believe that publishing on std. track entails that there are no known problems and security issues with the protocol. I forget the exact wording, but it's something to this effect.

It seems to be the case here that we very much are aware of several security issues -- and that therefore they must either be resolved, or publication on std. track is premature.

Best,

Thomas

> Regards
> John
> 
>> On Sunday, April 13, 2014, Abdussalam Baryun <[email-masked]> wrote:
>> Not sure where in the document texts you find a react to failure to delivery by flooding.  
>> 
>> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: John Dowdell <[email-masked]>
Date: Wed, 16 Apr 2014 11:46:24 +0100

On Tuesday, April 15, 2014, Thomas Heide Clausen <[email-masked]>
wrote:

>
> On 15 avr. 2014, at 17:32, John Dowdell <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> wrote:
>
> That which I am concerned with is, that receipt of a simple unicast data
> packet will trigger a router to do a network-wide flood of RREQs...a
> formidable way for a malicious router to get all it's neighbors to perform
> a DDoS on the network, essentially transforming each unicast packet into a
> network-wide flooding operation.
>
> So a bad guy can just generate a stream of *unicast* data packets, with
> each packet addressed to (different) non-existing destinations. Use each
> (known) neighbor as next hop in a round-robin fashion, and essentially the
> network is effectively brought to an un-usable state - not just locally,
> but globally.
>
>
> network.
> Therefore some consistency checking should take place to sense check
> recently received messages against the previously known state. However,
> this may be difficult since a reactive protocol by nature will not achieve
> consensus among all routers and only fragments of the whole picture will
> ever be formed.
>
>
> That's a different - but also interesting - issue. I had actually not
> thought about that, but you are right, that definitely needs to be
> documented and alleviated.
>
>
> With all due respect, I do believe that publishing on std. track entails
> that there are no known problems and security issues with the protocol. I
> forget the exact wording, but it's something to this effect.
>
> It seems to be the case here that we very much are aware of several
> security issues -- and that therefore they must either be resolved, or
> publication on std. track is premature.
>

I agree that the possibility of the problem needs to be stated in the draft
under security issues.

The resolution to the problem is really just to follow industry best
practice. Does your organisation enjoy sole rights of administration over
the routers? If so, are all configuration changes logged, is all activity
logged, and is everything audited regularly to make sure everything is ok?
If not, then how much can you trust that router and what standard security
countermeasures are you putting in place to defend against attack,
misconfiguration, or implementation holes? Is your own code checking every
message for correctness and consistency?

Regards

John

> Best,
>
> Thomas
>
> Regards
> John
>
> On Sunday, April 13, 2014, Abdussalam Baryun <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> wrote:
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 16 Apr 2014 11:02:41 +0000

“Just follow industry best practice” really won’t do it.

You can either look at it from the point of view of what the IESG will buy – and look at the security ADs DISCUSSes on OLSRv2 for a start. Unless they change policy, they will at the least require a specified integrity security mechanism. And before you’re allowed to publish your routing protocol. As a starting point to build one there is RFC 7182 (replacing RFC 6622) we’ve written for you.

Or you can look at it from the point of view of it being a wireless network , inherently open to spoofed message injection. You could delegate the problem to layer 2 if using e.g. Wi-Fi. But now you’ve limited what layer 2s you can run over. I don’t think we want that. Or you will need an integrity mechanism as part of your routing protocol. Don’t forget that until routing has succeeded there’s no one else to help, you don’t have a network to contact anyone else.

What the IESG will allow you (in the standards “mandatory to implement, but not to use” fudge) is actually a fairly lowest common denominator. I for one am interested in better approaches, and it would be good to be able to support those too. But you will at least need something.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet [mailto:[email-masked]] On Behalf Of John Dowdell
Sent: 16 April 2014 11:46
To: Thomas Heide Clausen
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] #36 (aodvv2): Security Considerations: Reactive protocol concept

*** 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<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.

On Tuesday, April 15, 2014, Thomas Heide Clausen <[email-masked]<mailto:[email-masked]>> wrote:

On 15 avr. 2014, at 17:32, John Dowdell <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
I think what Thomas is getting at is:

I agree that the possibility of the problem needs to be stated in the draft under security issues.

The resolution to the problem is really just to follow industry best practice. Does your organisation enjoy sole rights of administration over the routers? If so, are all configuration changes logged, is all activity logged, and is everything audited regularly to make sure everything is ok? If not, then how much can you trust that router and what standard security countermeasures are you putting in place to defend against attack, misconfiguration, or implementation holes? Is your own code checking every message for correctness and consistency?

Regards

John

Best,

Thomas

Regards
John

On Sunday, April 13, 2014, Abdussalam Baryun <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
On Thursday, April 3, 2014, manet issue tracker wrote:
#36: Security Considerations: Reactive protocol concept

 (Thomas Clausen)

AB
_______________________________________________
manet mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
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.
********************************************************************

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 16 Apr 2014 15:57:31 +0200

> What the IESG will allow you (in the standards “mandatory to implement, but not to use” fudge) is actually a fairly lowest common denominator. I for one am interested in better approaches, and it w…

I agree with Chris, but just want to add one thing. It actually is - in general - not that unreasonable to expect that protocols are designed to be robust, including being secured against attacks of various kinds.  MTI security provisions are, as Chris say, a *lowest* common denominator in that regard.

Then, consider some quite common deployments of MANET protocols - tactical networks, for example, but not only - and the MTI security provisions are woefully inadequate. It's therefore in MANETs even more important to be able to support development of more "advanced" or "better" approaches.

> The resolution to the problem is really just to follow industry best practice. Does your organisation enjoy sole rights of administration over the routers? If so, are all configuration changes logg…

Staying with a tactical network, "Red Force" may "enjoy sole rights of administration over the routers", but once deployed, "Blue Force" sure will go to great length to change that -- starting with, probably, listening to the wireless channel for what signals are sent, and then starting to inject its own signals to disrupt. Once you get to be able to log, audit, anything, the war will have been already lost. 

This applies to pretty much any deployed network - tactical or otherwise, if it can be "poked at" somebody will.

> [email-masked] | http://www.baesystems.com
> 
> 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.
> 
> 
> 
> On Tuesday, April 15, 2014, Thomas Heide Clausen <[email-masked]> wrote:
>

---

From: "Farrag, Osama" <[email-masked]>
Date: Wed, 16 Apr 2014 13:26:11 -0400

We have published a paper entitled "TAM: A Tiered Authentication of Multicast Protocol for Ad-Hoc Networks" in the IEEE Transactions on Network and Service Management, Vol 9 No. March 2012. The paper proposes a scalable Multicast/Broadcast message integrity/source authentication approach suited for reactive routing in MANET.  I think this approach would address the valid concerns in previous discussion.  You can get a copy of the paper at this site, if you are not able to read it. Feel free to contact me, and I will send you a copy.

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=06094287

Best regards
Osama Farrag
Sr. Prof. Staff
The Johns Hopkins University /APL

From: <Dearlove>, "Christopher (UK)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 16, 2014 7:02 AM
To: John Dowdell <[email-masked]<mailto:[email-masked]>>, Thomas Heide Clausen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [manet] #36 (aodvv2): Security Considerations: Reactive protocol concept

From: manet [mailto:[email-masked]] On Behalf Of John Dowdell
Sent: 16 April 2014 11:46
To: Thomas Heide Clausen
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] #36 (aodvv2): Security Considerations: Reactive protocol concept

*** WARNING ***

Regards

John

Best,

Thomas

Regards
John

 (Thomas Clausen)

AB

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 16 Apr 2014 20:09:04 +0200

Osama,

The link you sent doesn't bring me to anything meaningful - I get a 404 "page not found". Searching for the paper on IEEEXplore brings me an abstract, but the full-text version requires coughing up $$$'s ;(

If you would indulge in my making a suggestion: if you think that what you propose in this paper would solve the security issues present in reactive protocols, then why don't you write up an I-D with a mechanism/protocol-exension? I am sure that it would be of interest to many (this thread alone should indicate that it's a hot topic).

Best,

Thomas

On 16 Apr 2014, at 19:26, Farrag, Osama <[email-masked]> wrote:

> From: <Dearlove>, "Christopher (UK)" <[email-masked]>
> To: John Dowdell <[email-masked]>, Thomas Heide Clausen <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: "Farrag, Osama" <[email-masked]>
Date: Wed, 16 Apr 2014 16:45:47 -0400

Thomas;

Apologies for the unpleasant experience with IEEE journal web site, I get access to many journals through my employer, so I have no idea which papers require payments. And to be clear, I don't get any financial gains from publishing this paper in this IEEE publication. And to prove it, I attached a copy of the paper. Not just for your convenience, but for the benefit of every one in the IETF MANET working group distribution. As to writing I-D mechanism/protocol extension. I recommend that the IETF MANET working group community evaluate this approach and provide feedback before spending too much time and then facing roadblocks.

Best,
Osama  Farrag
Sr. prof. Staff

From: Thomas Clausen <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 16, 2014 2:09 PM
To: Osama Farrag <[email-masked]<mailto:[email-masked]>>
Cc: Christopher Dearlove <[email-masked]<mailto:[email-masked]>>, John Dowdell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [manet] #36 (aodvv2): Security Considerations: Reactive protocol concept

Osama,

Best,

Thomas

On 16 Apr 2014, at 19:26, Farrag, Osama <[email-masked]<mailto:[email-masked]>> wrote:

Best regards
Osama Farrag
Sr. Prof. Staff

[email-masked]<mailto:[email-masked]> | http://www.baesystems.com<http://www.baesystems.com/>

*** WARNING ***

Regards

John

Best,

Thomas

Regards
John

 (Thomas Clausen)

AB

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 16 Apr 2014 23:27:23 +0200

Osama,

Ah, to have an employer as generous as yours....

Fear not, I know that IEEE doesn't redistribute fees to authors, so I didn't suspect your having commercial motives ;)

Thank you for sending the pdf, I'll queue it for reading in the days to come.

Best,

Thomas

Sent from my iPad

> On 16 avr. 2014, at 22:45, "Farrag, Osama" <[email-masked]> wrote:
> 
> Thomas;
> 
> From: Thomas Clausen <[email-masked]>
> To: Osama Farrag <[email-masked]>
> Cc: Christopher Dearlove <[email-masked]>, John Dowdell <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> <TAM-Tiered Authentication of Multicast Protocol for Ad-Hoc Networks.pdf>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 17 Apr 2014 12:50:48 +0000

The IEEE takes fees from authors, doesn’t it? Making money at both ends.

(I do have access here, and I’ve put this on my reading list. It is however a long and leaky reading list.)

From: Thomas Heide Clausen [mailto:[email-masked]]
Sent: 16 April 2014 22:27
To: Farrag, Osama
Cc: Dearlove, Christopher (UK); John Dowdell; [email-masked]; [email-masked]
Subject: Re: [manet] #36 (aodvv2): Security Considerations: Reactive protocol concept

*** WARNING ***

Best,

Thomas

Sent from my iPad

On 16 avr. 2014, at 22:45, "Farrag, Osama" <[email-masked]<mailto:[email-masked]>> wrote:
Thomas;

Best,
Osama  Farrag
Sr. prof. Staff

Osama,

Best,

Thomas

Best regards
Osama Farrag
Sr. Prof. Staff

*** WARNING ***

On 15 avr. 2014, at 17:32, John Dowdell <[email-masked]<mailto:[email-masked]>> wrote:
I think what Thomas is getting at is:

Regards

John

Best,

Thomas

Regards
John

On Sunday, April 13, 2014, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:
On Thursday, April 3, 2014, manet issue tracker wrote:
#36: Security Considerations: Reactive protocol concept

 (Thomas Clausen)

AB
[email-masked]<mailto:[email-masked]>