Subject: Re: [manet] Security Considerations of AODV

From: "Claude Castelluccia" <[email-masked]>
Date: Thu, 18 Apr 2002 17:11:12 +0200

Hello Manel,

If i understand well the hash chains mechanism described in your
draft prevents a bad guy from modifying the HopCount field, right?
But why prevents a bad guy from not performing the hash of the HopCount
and just forwarding the packet as it is?  As a result, the path might appear
shorter that what it really is and might end-up being selected (this might
be the goal of the attacker..)?
Did i miss something?
thanks in advance for the clarification,
Claude.

-----Message d'origine-----
De : Manel Guerrero Zapata <[email-masked]>
À : ext Pekka Savola <[email-masked]>
Cc : [email-masked] <[email-masked]>
Date : jeudi 18 avril 2002 10:28
Objet : Re: [manet] Security Considerations of AODV

>Moi Pekka,
>
>Securing AODV messages is possible.
>I recomend you to take a look to my SAODV draft:
>http://ant.eupvg.upc.es/~tarom/draft-tarom-manet-saodv-00.txt
>
>You have pointed out one of the biggest problems I had when designing
>SAODV: the mutable fields (i.e. hop count). Luckily Asokan came with
>the proposal of using hash chains to secure the hop count. And,
>although there are certain possible attacks against the authentication
>of the hop count, I'm pretty satisfied about the overall security
>that SAODV is now providing. (Except maybe in the RERR messages, where
>more work still needs to be done)
>
>BR/ManelG
>
>
>ext Pekka Savola wrote:
>> Hello,
>>
>> The first paragraph of the AODV security considerations basically says
the
>> AODV packets should be authenticated.
>>
>> The second paragraph seems to suggest that the _data_ sent between the
>> nodes could be authenticated.  This appears to be the case.  This could
>> also be interpreted to mean about AODV control packets, which would be
>> wrong.
>>
>> Where is the discussion about securing AODV control messages?  If it
>> cannot be done, it should also be stated.
>>
>> From Hop Count and other values which seem to be modifiable in transit it
>> appears that "hop-by-hop" security associations, every node having to
>> trust its neighbors (thus expanding the ring of trust) would be
necessary:
>> security of AODV protocol between non-neighbor AODV nodes does not appear
>> to be possible.
>>
>>
>
>
>
>
>_______________________________________________
>manet mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/manet
>

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

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Thu, 18 Apr 2002 19:16:05 +0300

Hi Claude,

you didn't miss anything ;)
That's why I said: "although there are certain possible attacks against
the authentication of the hop count"...
That is exactly the attack you can perform:
Bad guys can avoid the increasing of the hop count when they
forward the packet.

So the first part of a composed attack would be to try
that enough bad guys get in one of the paths the RREQ travels through
and try to be close enough to the optimal path so the difference that
they cheat is enough to be selected as best path.
That is not as easy as you might thing.
If nodes move you have to have a lot of bad guys moving close to the best
path, or just a huge amount of bad guys (people accept that if a 1/3 of
the guys are bad there is not much you can do).
I thing that in the real world the probability that the bad guys get the
path going through them is not much higher than if the they wouldn't be cheating
(because if you put a lot of bad guys close to the best path, even if they
do account for the hop count they also get the possibility to be in the
best path).

Therefore I thing hash chains are pretty reasonable, and _very very cheap_!
There are other mechanisms to protect the hop count but they are so much more
expensive that they are not really feasible ones.
But if you (or somebody else) come with a better idea, I'll be glad to
study it.

Regards,

	Manel

P.D.: Another way to do the attack is that no matter how close they are to the path,
but be one hop away from src & dst and have a whole path of bad guy
no matter how long it is. (but then you need more bad boys than hops
has the optimal path and being just one hop away form src & dst)
So I thing bad guys will have a hard time doing this (now: imagine all nodes
moving).

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Thu, 18 Apr 2002 19:16:05 +0300

Hi Claude,

Regards,

	Manel

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Fri, 19 Apr 2002 17:52:04 +0300

Hi Casey,

That is a very good observation. Because if two nodes simulate that
they have a link, it is very complicated to detect that they actualy don't
have a link (even with misbehavior detection schemes).

I've been thinking about the whole problem for a while
and I realized about a funny thing:

I usually thing about AODV route discovery assuming that it returns
the shortest path between originator and destination.
But that's not really true. Is it?

It returns the shortest path among the paths through which the RREQ
traveled faster from the originator to each final or intermediate node
that has the route to the destination.
(Or just the fastest one, in the case no intermediate nodes know a route
to de destination). And that's the selected path in AODV.

8<-------------------------------------------------
6.5. Processing and Forwarding Route Requests

    When a node receives a RREQ, it first checks to determine whether it
    has received a RREQ with the same Originator IP Address and RREQ ID
    within at least the last PATH_TRAVERSAL_TIME milliseconds.  If such a
    RREQ has been received, the node silently discards the newly received
    RREQ. The rest of this subsection describes actions taken for RREQs
    that are not discarded.
------------------------------------------------->8

According to this ...

A-----B------C------D
\           /
  --E--F--G--

... if A initiates a route discovery to D,
and C receives first the RREQ from G than from B the discovered
route will be this one: A E F G C D
and not: A B C D.
Because when C receives the RREQ from B, C "silently discards" the packet.

So for the attack you are suggesting to succeed, they would have to manage that
the RREQ forwarded by the second bad guy (with the faked hop count) will
be the fastest one to reach one of those nodes who can issue a RREP back
(because they are intermediate nodes that have a route to the destination,
or because they are the destination).
And that is not easy because that means that they actually have to be the
fastest path (acording to AODV policy of RREQ forwarding) to at least that
intermediate node. Or, just the fastest path if there are no intermediate nodes
(And in SAODV you can tell intermediate nodes not to respond RREQs if you
want more security by sacrificing performance in route discovery.
That is by using Single Signature Extensions (SSE) instead of Double Signature
Extensions (DSE)).

So actually with the increase level of security provide by SAODV when
we don't allow intermediate nodes to reply (SSE); the attakers should be in
the best path (acording to AODV way of selecting the path) to succeed to make the system
believe that they are in the best path ;) So they are achieving nothing.

And even in Double Signature Extensions, the attackers should manage
to be the fast ones to arrive to one of the intermediate nodes to succeed.

I should have thought about this before, because now if we look to the
attack that Claude was proposing it is even less feaseble (for the same reason)
that what I was originaly thinking. It does not matter that they lie about
the hop count, they still have to be the fastest ones (therefore they have
to be the path that would be picked up by AODV anyway).

Best regards,

	Manel

P.D.: If I'm missing something or you come up with new possible attacks,
please, let me know.

ext Casey Carter wrote:
> Manel Guerrero Zapata wrote:
> 
>> Hi Claude,
>>
> Or, have one bad guy next to the source, and one next to the 
> destination.  The two bad guys collude by tunneling route requests/route 
> replies between src and dst to make it appear that the bad guys know a 
> three-hop route between them.  Only requires two bad guys to divert 
> traffic.
>

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Fri, 19 Apr 2002 17:52:04 +0300

Hi Casey,

According to this ...

A-----B------C------D
\           /
  --E--F--G--

Best regards,

	Manel

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Mon, 22 Apr 2002 20:01:07 +0300

Hi Casey,

Comments bellow.

> Manel Guerrero Zapata wrote:

[...]

> Unfortunately, you have to assume that the attacker always knows what he 
> is doing; we replace the notion "shortest" with "fastest".

Yes, but my point here is that it is not so important that there
is some possible attack to the hop count integrity, because that is not a key
element to get a route selected among others. It does not give a real benefit
to the attackers.

> Although I 
> can't find anything on the subject in the draft, it is well known among 
> implementors of ad hoc routing protocols that immediate rebroadcast of 
> flooded packets (e.g., route requests) is a bad idea: the synchronized 
> broadcasts from multiple nodes cause extremely high contention, and 
> (especially in simulations)  lots of collisions.The solution for this
 > problem is for each node to choose a small random backoff timer to
 > better distribute the rebroadcasts.

I thing this is something you find only in the simulation world (that if
you broadcast a RREQ all your neighbors will rebroadcast it at the very
same time and all the packets will collide).
But in the real world, if you use some wireless card they already have
(like the ethernet cards) this small random backoff,
to avoid collisions, for every packet they send.

> The consequence of this is that a 
> route request travels slower through the MANET than regular unicast 
> traffic.  So if my attackers have a clue, they will maintain an active 
> route between them to support the packet tunnel. This tunnel will 
> deliver the route request from the  source's tail to the destination's 
> tail slightly before the route request flood reaches the destination's 
> region of the MANET, and the first route request the destination 
> receives will be through the "magic" link.

Since there is no added delay for rebroadcasting, the attackers
have more or less the same chances to be the fastest as if they wouldn't
be bad boys. So tunneling and breaking the hop count does not give
any advantage to the attackers in order to get the traffic going between
them.

> The attackers can coordinate 
> to make sure that they are on or near the shortest path between the 
> source and destination, so this attack should be quite effective in 
> denying communication betweem source and dest.  The attack is assisted 
> by expanding ring search (Section 6.4 in draft 10), since the attackers 
> can probably tail the source and destination fairly closely. In this 
> case, the attackers need only be "close" to the fastest path.

If people are using expanding ring, then the attackers have a big chance
to be the fastest. But in scenarios more security demanding the originator
of the RREQ could decide not to use the expanding ring search technique.
And that's it. There is no attack then.

> If the attackers have more resources at their disposal, they can improve 
> upon this margin.  The attackers can purchase better radios than what is 
> commonly used in the MANET, so that they actually DO have the fastest, 
> shortest link across the MANET.  AODV/DSR/whatever will then choose the 
> path through the attackers as the shortest path.  The gist of this 
> argument is that simply authenticating the RREQ/RREPs is not sufficent 
> to preserve availability of communication between source and 
> destination, but only to verify that a route exists.

Well, if attackers just by having better radios than the rest able to be in the
faster/shorter path. They don't need to misbehave to be in the path. So then
they are just as good boys which happend to have better radios.
So their route should be selected.

And if an attacker can put himself _in_ the fastest path, then he is in
the fastest path. Although that is not so easy if nodes are moving.
 From experiences with real implementations (not simulations) a communication
between two nodes does not happen through the same path all the time,
it is changing the route quite a lot.

I have never stated than SAODV is able to "preserve availability of
communication between source and destination". Actually in the abstract of
the draft it says:

8<---------------------------------------------------------------------
     The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension
     of the AODV routing protocol that can be used to protect the route
     discovery mechanism providing security features like integrity,
     authentication and non-repudiation.
--------------------------------------------------------------------->8

But I don't say anything about Denial of Service. If an attacker wants
to do a DoS it will probably find easier to flood the network with
packets or to send a packet every time it detects one it's being sent
(so they'll collide) or just emit interferences with the max power it can.
Then, not even simetric cryptosystems will save you.

Regards,

	Manel Guerrero

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Mon, 22 Apr 2002 20:01:07 +0300

Hi Casey,

Comments bellow.

[...]

Regards,

	Manel Guerrero

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 22 Apr 2002 13:20:45 -0400

Can we agree to simple premises for MANET security?

A).  Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is
       deployed with trusted fixed infrastructure that shares the MANET algorithm.
B).  This means key management is the only REAL issue.
C).  There are plenty of research papers on key management issues for ad hoc
        networks, I suggest the security enthusiests read these.
D).  In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network
       a good solution for key management does not yet exist.  Please find one.

It is silly to talk about what parts of MANET (in this case AODV) messages are
vulnerable.  All messages (payload and control) MUST be encrypted.

Thanks,

Phil

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 22 Apr 2002 13:20:45 -0400

Thanks,

Phil

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 Apr 2002 10:58:32 -0700

Hello Phil,

I cannot agree to your premises.

I am confident that a reasonable approach can exist,
that does not rely on a trusted fixed infrastructure.

I also do not believe that all data needs to be
encrypted.  Some data is just not that important.
I also do not think that all control messages need
to be encrypted.  In the case of control messages,
however, many of them would be appropriate for
verification by way of authentication data.  Of
course, this is also true for a lot of data.

None of this should be interpreted to mean that I am
against privacy, for applications and protocols where
it is desirable.  But that is a far different assertion
than (A) below.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 Apr 2002 10:58:32 -0700

Hello Phil,

Regards,
Charlie P.

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 22 Apr 2002 14:15:28 -0400

Hi Charlie,

----- Original Message ----- 
From: "Charles E. Perkins" <[email-masked]>
> I cannot agree to your premises.
That's OK, I just want to reduce the polution on the list.  I must advocate
STRONGLY that even if you don't have a PKI or fixed infrastructure to
rely on, all messages MUST be encrypted.  I see no other way to guarantee
against dozens of potential attacks that could occupy this list from now until
eternity.  Also, messages must be authenticated, and this implies that a portable
authenticator must be running on hosts that are pure ad hoc, and for foreign 
nodes, they must be treated as suspect (untrusted) until a manual intervention
by the MANET group is provided (or contact with a trusted certificate authenticator
is made).  I have thought about this for a bit and  and it makes absolutely no
sense to put control or any other message in the clear on a MANET (specifically
a wireless one).  This just invites too many known attacks.  

> that does not rely on a trusted fixed infrastructure.

Statements like this can hinder the commercial deployment of MANETs.  We can 
deploy MANETs with trusted infrastrucute peppered in and have pretty 
darn secure networks.  I advocate we specify how to do THIS first, before
we go off waiting for a "known research topic" to materialize into something
useful.  In fact your recent draft for global IPv6 hints at this.
> encrypted.  Some data is just not that important.

So you can turn off encryption when your are playing games.  Otherwise,
most things MUST be encrypted.  People expected wired equivalent 
privacy from 802.11b for a very good reason (they didn't get it but they
expected it).

> to be encrypted.

IITM, replay, message insertion, stack smashing, should I go?  In a 
commercial implementation of a MANET, where people are paying for
a level of service, ALL packets MUST be encrypted and authenticated.

>  In the case of control messages,

Yes, I agree, however, the encryption is not as heavy weight in general
as the authentication right?

> it is desirable.  But that is a far different assertion

So I will qualify A below to mean  "in commercially deployed MANETs"

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 22 Apr 2002 14:15:28 -0400

Hi Charlie,

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Mon, 22 Apr 2002 21:14:07 +0300

Hi Phil,

I'm gonna try to explain why I don't thing that encrypting everything is the
right thing to do in manet in all kind of scenarios.

If in a MANET network all routing messages are encrypted with a symmetric cryptosystem,
it means that everybody that we want to be able to participate in the network has to
know the key. That is not a big problem if we are a 'team' of persons that meet
to let every member of the team to know the 'team-key' and then we go to
play on the ground creating a MANET network. A member of the team trust the other
members of the team, so they assume that a member of the team won't do anything
nasty to the manet communications. They trust and authorize the other members to change
their routing tables.

Maybe this is the best thing to do for military scenarios (besides the problem
of the compromissed nodes and some others).

But now, let's thing that we want to create a MANET network where everybody can participate.
Maybe in a convention, in a meeting room, in a campus, or in our neighborhood.
Then we have a problem, we don't trust the others. We are not a team.
So what do we do now? How do we force everybody to be honest?
Maybe what we can do is to only believe a routing information if the
originator of such information is the destination of the route
(in such a way that if you lie (since you can only lie about yourself) the only
_benefit_ you get is that people is not able to communicate with you.

 From this starting point, for me, the direction is to use an asymetric
cryptosystem (with public an private key pairs) so that the originator
of the route messages signs the message. We don't need to encrypt it because
it is not a secret. What we want is that people will be able to detect forged
routing messages.

When you do that, the main problem you have is that this RREQ or RREP that
you originate and that travels hop to hop has mutable fields. Mutable fields
are the fields or routing messages which value changes during its transmision.
And in manet, the typical one is the hop count. So we cannot sign the hop count
because when we originate the message, it is zero, but after one hop it will
be one and the signature will be broken.

Luckily, hop count changes, but it does in a monotonical way, so still
we can find some ways to secure it (till certain extend) hash chains
in the case of SAODV.

Besides all this, encryption is not costless, so one should only encrypt
what he or she only wants to be readed by the ones who have the key.
So I thing the: "All messages (payload and control) MUST be encrypted"
is quite a strong afirmation, and not correct for most of the possible
manet scenarios.

Best regards,

	Manel Guerrero

[...]

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Mon, 22 Apr 2002 21:14:07 +0300

Hi Phil,

Best regards,

	Manel Guerrero

[...]

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 22 Apr 2002 14:34:15 -0400

Hi Manel,

Thanks for the rebuttal.  I respond below.
----- Original Message ----- 
> right thing to do in manet in all kind of scenarios.

Would you agree its the thing to do in commercial money making scenarios where
people are paying for service on a MANET?  Would you agree its the thing to do
when hots spots allow MANETs in public venues like airports, hotels, busses, and
restaurants?

> know the key.

Not necessarily.  It could mean that each node has a "born on certificate" that is stamped into
tamper resistant storage by the OEM.  It could mean that the unit has to periodically reathenticate
to use services besides E911.  It could also be possible to re-imprint the certificate when the 
unit is stolen lost or has been black listed for some reason.

> That is not a big problem if we are a 'team' of persons that meet

This doesn't scale to well. It would be far better to have an OEM key that is unique and have
routing use that, i.e. all units that agree to some standard, can talk (they can't talk anyway if
they are not standardized right?).

> of the compromissed nodes and some others).

Its the best thing for everything, except gaming, and casual use of devices.  If MANETs
are to succeed, they must succeed in the business world, and this means really REALLY
good security.

> So what do we do now? 

If there is a host causing trouble, it had to have a certificate providing non-reduiation so the 
source can identified and black listed by all other nodes, possibly via flooding a black list
request and acheiving group consensus.

> How do we force everybody to be honest?

Not possible, best bet is to required authentication and non-repudiation.

> _benefit_ you get is that people is not able to communicate with you.

Better, yet, use the OEM key to encrypt all control messages including the
routing messages.

> it is not a secret. What we want is that people will be able to detect forged

Routing messages do reveal things.  They reveal who is communicatig to who.
That is simply too much.  They also reveal sequence numbers.  The overhead
for digital signatures is far higher than for block or stream ciphers in embedded
devices right?

> be one and the signature will be broken.

Encrypt the message and CRC it if you wish, then this is not a problem.
> we can find some ways to secure it (till certain extend) hash chains

Encrypt the messages!
> what he or she only wants to be readed by the ones who have the key.

Is what is being proposed going to cost less or more than encryption?  I
would like to see the analysis on this.

> is quite a strong afirmation, and not correct for most of the possible

It is probably the only correct solution for "profitable" MANET scenarios,
which are the type I am interested in, since I work for one of the few companies
on the planet attempting to commercialize MANET technologies!

Thanks,

Phil

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 22 Apr 2002 14:34:15 -0400

Hi Manel,

----- Original Message ----- 

Encrypt the messages!

Thanks,

Phil

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 Apr 2002 11:45:25 -0700

Hello Phil,

Phil Neumiller wrote:

>                 ..................                  I must advocate
> eternity.            ...........

If I'm getting something for free, and it would cost $0.10/minute to encrypt
it, and the data isn't worth that much (e.g. webcam cows), I don't want
to be required to buy the encryption.

> useful.  In fact your recent draft for global IPv6 hints at this.

If you offer a solution today that relies on fixed infrastructure,
and people are willing to pay, then that's fine.  My statement
is in no way adversary to your solution.  However, I hope I'm allowed
to believe that other better solutions can exist, even if I don't
have one ready to sell.  I'm realy at a loss to understand what
I said that you find objectionable.

> privacy from 802.11b for a very good reason (they didn't get it but they

I'd say instead that most things do NOT need to be encrypted.
In fact, I'd say that the way encryption is used in the Internet
today represents a good model for the way things ought to eventually
be for ad hoc networks.  Further, I'd say that as things evolve
in the Internet, we can notice the reasons why.  Those reasons
will also probably apply to ad hoc networks, at least for some
applications.

> a level of service, ALL packets MUST be encrypted and authenticated.

I didn't parse IITM.  And, commercial implementation doesn't equal
encryption, nor paid service.  In fact, I'd hope we could have
ad hoc radio programming on campus, with zero encryption and cost.
There are so many possibilities!

> as the authentication right?

I guess it depends on hardware and algorithm.

> So I will qualify A below to mean  "in commercially deployed MANETs"

From the above, I guess you can tell I still believe this is
too restrictive.  I might want to make a commercially viable
MANET that does not enforce encryption for all services.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 Apr 2002 11:45:25 -0700

Hello Phil,

Regards,
Charlie P.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 22 Apr 2002 21:47:53 +0300 (EEST)

On Mon, 22 Apr 2002, Phil Neumiller wrote:
> A).  Its best to run all messages encrypted, [...]

In some cases, it may be.  In some others, maybe not.  Nevertheless, it is 
a very valuable capability of being able to do that if necessary.

> B).  This means key management is the only REAL issue.

I don't see how B follows from A.

With most MANET protocols, encrypting data -- end to end -- is not
problematic with proper key management.

Being able to encrypt control data is usually a more difficult problem, 
even with key management.

That is not all to the security: in some cases even byzantine robustness 
(e.g. a military application) might be desirable.

Encryption and such do not solve the problems with trust, e.g. prevent 
someone from blackholing all traffic.  

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Pekka Savola <[email-masked]>
Date: Mon, 22 Apr 2002 21:47:53 +0300 (EEST)

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 22 Apr 2002 12:37:30 -0700

Time for some term clarity.

You get two major items out of security at this level:
- confidentiality
- authenticity (which is a superset of integrity).

Now, divide the traffic on a MANET into two parts: one is the 
application data.  Set it aside; not part of this discussion.  The 
other is all the routing information.

The routing information needs authenticity as a matter of course.
>  I also do not think that all control messages need
So this statement is partially correct.  If it said 'digitally 
signed' instead of 'encrypted' I'd fully agree.
      I can easily envision situations where I'd want the routing 
information to be fairly openly available and others where I'd want 
it encrypted.  But I cannot envision situations (of any scale) where 
I'd want it unauthenticable.

Situation A.  We have a multinational laydown for peacekeeping 
operations -- a lot of infrastructure is contributed by numerous 
coalition partners.  We want to be able to advertise the MANET 
structure to them all (and are willing to risk the Bad Guys cribbing 
the data).  But, while we're willing to let the Bad Guys know what 
our topology is, we're not willing to let them disrupt it by 
spoofing.  Therefore, all the data is authenticated via digital 
signature (for which we have a PKI to support).  Authentication 
failures result in doubt about authenticity but not loss of the data, 
so the consumer of the routing data is in the caveat emptor position 
-- it might be a lesser contributor to the coalition who hasn't got 
act completely together.

Situation B might be another multinational laydown, but this time for 
combat operations.  In this case, topology is a protected asset (it 
would have useful order-of-battle information, somewhat similar to 
what you could get from traffic analysis) and it's shared with a 
smaller number of coalition partners.  In this case I'd want the 
encryption for confidentiality in addition to the digital signature. 
(Note that the PKI overhead is a sunk cost -- I had to buy that for 
the authenticity part of the problem).  In situation A, inability to 
authenticate doesn't render the data unusable, just of doubtful 
origin.  In this situation, inability to decrypt would result in 
inability to use the MANET.

-- 
b

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 22 Apr 2002 12:37:30 -0700

-- 
b

---

From: Casey Carter <[email-masked]>
Date: Mon, 22 Apr 2002 15:57:24 -0500

> Comments bellow.
well, there's no need to bellow. ;)

[snip]

> communication between source and destination". Actually in the 

This attack is slightly more powerful than denial of service: the 
attacker is forcing the source to route through him, so there's some 
traffic stealing going on here that is not possible with a pure DoS 
jamming attack at a lower layer.  Not having any kind of a security 
background (except for some petty shoplifting when I was a kid) I guess 
I just don't see the point.  What is the advantage in a providing 
authentication, integrity and non-repudiation if an attacker can still 
trick you into routing where he wants you to?  What exactly are the 
goals that SAODV is trying to achieve with these mechanisms?

-- 
Casey Carter
[email-masked]
[email-masked]
AIM: cartec69

-- 
Casey Carter
[email-masked]
[email-masked]
AIM: cartec69

---

From: Casey Carter <[email-masked]>
Date: Mon, 22 Apr 2002 15:57:24 -0500

[snip]

-- 
Casey Carter
[email-masked]
[email-masked]
AIM: cartec69

-- 
Casey Carter
[email-masked]
[email-masked]
AIM: cartec69

---

From: [email-masked]
Date: Mon, 22 Apr 2002 19:37:34 -0400 (EDT)

Hi Phil,

>        a good solution for key management does not yet exist.  Please find one.

A good approach (well, at least in my opinion (;-)) is that of distributed
trust through threshold cryptography. One of our early references on this
topic is:

L. Zhou and Z.J. Haas, "Securing Ad Hoc Networks," IEEE Network Magazine,
vol. 13, no.6, November/December 1999 

Zygmunt.
==--======
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas                    http://people.ece.cornell.edu/haas 
Wireless Networks Laboratory		 http://wnl.ece.cornell.edu
School of Electrical Engineering         
Cornell University			 tel: +1-607-255-3454
323 Frank Rhodes Hall			 fax: +1-607-255-9072
Ithaca, NY 14853			 e-mail: [email-masked]
U.S.A                             
	WNL web page: http://wnl.ece.cornell.edu
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

---

From: [email-masked]
Date: Mon, 22 Apr 2002 19:37:34 -0400 (EDT)

Hi Phil,

Zygmunt.
==--======

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Tue, 23 Apr 2002 13:13:06 +0300

Hi Casey,

I don't see that you have a feasible way to build an attack against
SAODV more powerful than DoS. In the part you have [sniped] in your
reply is where one by one I've been showing why the different attacks
you where suggesting are not feasible.

The only feasible way than an attacker has to make the traffic go
through him is that the chosen path (without misbehaving nodes) would
be through him anyway (so I don't see a big deal with that).

And if a node has bigger antena and that makes him to get more chances
to get the path, that has nothing to do with misbehaving.

And if you don't want this node to listen to your conversations with
another node, what you should use is encryption for the data packets.

SAODV protects routing, not data.

Thanks,

	Manel

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Tue, 23 Apr 2002 13:13:06 +0300

Hi Casey,

Thanks,

	Manel

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 23 Apr 2002 08:42:17 -0400

Hello Dr. Haas,

Yes I have read this paper and many of the others.  Fascinating stuff, except I see some holes
here.  For instance if I am the first in a conference room and wish to access the projector,
presumably in a PAN/MANET like fashion, I have no fellows to imply that I am trusted right?
Maybe I am misunderstanding something about thresholding though.

----- Original Message -----
From: <[email-masked]>
To: "Phil Neumiller" <[email-masked]>
Cc: "Manel Guerrero Zapata" <[email-masked]>; "ext Casey Carter" <[email-masked]>; "ext Claude Castelluccia"
<[email-masked]>; <[email-masked]>; "Seung Yi" <[email-masked]>
Sent: Monday, April 22, 2002 7:37 PM
Subject: Re: [manet] Re Security considerations in MANET

---

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 23 Apr 2002 08:42:17 -0400

Hello Dr. Haas,

---

From: Jim Kaba <[email-masked]>
Date: Tue, 23 Apr 2002 11:14:59 -0400

Hi Manel,
  This reply is not related to the security discussion (thus, the subject
change).  It has to do with the packet rebroadcast comments in the previous
post.
 
> > Manel Guerrero Zapata wrote:

8<---------------------------------------------------------------------------

> to avoid collisions, for every packet they send.

I have seen this in the real world--specifically with Orinoco 802.11b cards
in ad hoc mode.  (I'm talking specifically about the "pseudo-IBSS" mode,
where the nodes are truly peer-to-peer.)  When the network is lightly
loaded, the rebroadcasts (and subsequent replies) are highly synchronized
and are extremely likely to collide unless additional jitter is added.

I haven't looked at the 802.11 spec in quite a while, but I recall
discovering that the backoff mechanism is only enabled _after_ contention
has been discovered.  If the cards aren't already in contention mode (from
previous traffic), they will just do the usual collision avoidance: they
will all do a carrier sense (synchronized), see no traffic (synchronized),
and transmit their packets (synchronized-------->COLLISION!).  That is, if
they don't sense traffic and aren't already in contention mode, they
transmit immediately.

Note:  even if I have misinterpreted the spec (which is easy to do), I did
see synchronized retransmissions and corrected them with jitter.

Jim

-- 
--------------------------------------------------------------
James T. Kaba                   
Sarnoff Corporation      Time flies like an arrow...
[email-masked]                ...Fruit flies like a banana!
609-734-2246

---

From: Jim Kaba <[email-masked]>
Date: Tue, 23 Apr 2002 11:14:59 -0400

Hi Manel,

Jim

---

From: Panos Papadimitratos <[email-masked]>
Date: Tue, 23 Apr 2002 13:06:26 -0400

Dear fellow “security enthusiasts”, (:-)

a few things I would like to contribute to your interesting discussion:

First, it is important to realize that not all security solutions can be 
applied in all ad hoc networking environments. At one extreme, the 
conference room resources can use location authentication, i.e., no access 
constraint other than the mobile device location (e.g., short range IR of 
RF connectivity). At the other extreme, a MANET of trusted military 
devices, can be capable to perform expensive cryptographic operations and 
have all the infrastructure support we can imagine. In short, the 
interaction between nodes is the one that dictates how to do the trust 
management.

Second, the point of crucial importance for the securing MANET, at least as 
far as I am concerned, is to make clear distinction between:
-Security of the MANET-based application.
-Security of the basic networking services.

The challenge is exactly to achieve the latter. And, it has to be done for 
the wide range of network instances between the two above-mentioned 
extremes. And, it has to be done in a way that “understands” the MANET 
paradigm, and does not transplant secure Internet routing solutions.

This is what seems to be happening with most of the secure routing 
solutions for MANET, as we explain in:

P.Papadimitratos and Z.J. Haas, "Secure Routing for Mobile Ad Hoc 
Networks," SCS Communication Networks and Distributed Systems Modeling and 
Simulation Conference (CNDS 2002), San Antonio, TX, January 27-31, 2002.

The rationale behind the Secure Routing Protocol (SRP) in a few lines is:

Even if you have the appropriate distributed CA instantiation (which you 
can have  - see Zhou & Haas), it is not feasible to cryptographically 
validate every single in-transit control packet, even with the upcoming 
commercial mobile devices.

Even if you have a service- or group- based distribution of credentials, 
the basic network functionality will not be supported only by your trusted 
peers.

Even if you have a heavy-weight crypto-based solution, how do you deal with 
a node that does not comply with a protocol? That is, correct operation 
equals correct connectivity information. And SRP does exactly this, 
avoiding the pitfall of ‘correct is whatever is cryptographically ok’.
(BTW, that’s the main issue in Internet secure routing s well…)

For clarifications, or if you want to hear some possible attacks on the 
discussed protocols (:-), please, don’t hesitate…

Cheers,

Panos

---

From: Panos Papadimitratos <[email-masked]>
Date: Tue, 23 Apr 2002 13:06:26 -0400

Cheers,

Panos

---

From: "Philippe Jacquet" <[email-masked]>
Date: Wed, 24 Apr 2002 17:15:17 +0200

Hi Jim,

I agree with you, jitter is important. The IEEE 802.11 can support some
traffic burstiness but it is limited (it prefers poisson traffic). The
routing protocol should avoid to stress the MAC protocol with too bursty
traffics.

Philippe
----- Original Message -----
From: Jim Kaba <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 23, 2002 5:14 PM
Subject: [manet] packet rebroadcasts

> > > Manel Guerrero Zapata wrote:
8<--------------------------------------------------------------------------
-

---

From: "Philippe Jacquet" <[email-masked]>
Date: Wed, 24 Apr 2002 17:15:17 +0200

Hi Jim,

Philippe

---

From: "Phil Neumiller" <[email-masked]>
Date: Wed, 24 Apr 2002 13:40:57 -0400

> routing protocol should avoid to stress the MAC protocol with too bursty

Well, the MAC is going to experience high burstiness anyway (self-similar
fractal patterned data) if its carrying IP traffic.  I don't see the burstiness of
the routing packets affecting this one way or another.  To me its the chattiness
(frequency of route control messages) is what the bigger affect on performance
(at least according to my traffic models, routing overhead is only a small 
percentage of the traffic when the MANET is not too big).  I agree that in
large MANETs this could get to be an issue but you are more like to run
out of bandwidth before you smash your queues with bursty route messags.

-Phil

-Phil

---

From: "Phil Neumiller" <[email-masked]>
Date: Wed, 24 Apr 2002 13:40:57 -0400

-Phil

-Phil

---

From: "Philippe Jacquet" <[email-masked]>
Date: Thu, 25 Apr 2002 14:05:47 +0200

Hi Phil,

I think the burstiness caused by fractal patterns of traffic (TCP for
example) is by far much much smoother than the burstiness incurred when 10
nodes or more strive to rebroadcast at the same time (1000% peak). CSMA/CA
hates that kind of traffic and lot of packets may be lost due to collisions.
This is not a traffic percentage that matter with this respect but the
concentration of traffic on very small periods of time. And since it is
control traffic, it may impact on the reliability of the routing protocol
itself even if at the end, the control traffic average may be low.

Philippe
----- Original Message -----
From: Phil Neumiller <[email-masked]>
To: Philippe Jacquet <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, April 24, 2002 7:40 PM
Subject: Re: [manet] packet rebroadcasts

---

From: "Philippe Jacquet" <[email-masked]>
Date: Thu, 25 Apr 2002 14:05:47 +0200

Hi Phil,

Philippe
----- Original Message -----
From: Phil Neumiller <[email-masked]>
To: Philippe Jacquet <[email-masked]>; <[email-masked]>;
<[email-masked]>

---

From: Casey Carter <[email-masked]>
Date: Fri, 19 Apr 2002 17:24:40 -0500

> to de destination). And that's the selected path in AODV.

Yes, this is characteristic of on-demand routing protocols, not just AODV.

is doing; we replace the notion "shortest" with "fastest".  Although I 
(especially in simulations)  lots of collisions. The solution for this 
better distribute the rebroadcasts.  The consequence of this is that a 
receives will be through the "magic" link.  The attackers can coordinate 

> to be the fast ones to arrive to one of the intermediate nodes to 

Exactly.  It is only necessary that the attackers be on the fastest 
path, and they can subvert traffic.

>> destination.  The two bad guys collude by tunneling route 
>> requests/route replies between src and dst to make it appear that the 
>> bad guys know a three-hop route between them.  Only requires two bad 
>> guys to divert traffic.
>>
>
>
>

-- 
Casey Carter
[email-masked]
[email-masked]
AIM: cartec69

---

From: Casey Carter <[email-masked]>
Date: Fri, 19 Apr 2002 17:24:40 -0500

-- 
Casey Carter
[email-masked]
[email-masked]
AIM: cartec69