Hi Charlie, hi all,
Am 25.02.2016 um 16:31 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:
Hello folks,
We really don't want to use malicious nodes for routing at all. I agree that
a malicious node could have the effects as listed, but since in those cases
we don't want to use Mal, so much the better.
The problem with RERR will solve itself for all TCP connections.
A malicious node could pretend to forward packets but then throw them away,
but that is a problem regardless of RERR.
What we could do is have a matrix of threats versus AODVv2 messages, and
indicate which matrix entries are feasible threats with or without
authentication, assuming transitive trust. Has anyone already suggested
doing this? A lot of the information is already there, but a matrix-style
presentation provides some sense of completeness.
If this is agreeable, I'll work on making the matrix and send it out.
Regards,
Charlie P.
On 2/24/2016 10:30 AM, Lotte Steenbrink wrote:
Hi all,
another thing I was just thinking about is dropping packets– say we have the
following setup:
Originator <-> A <-> MaliciousNode <-> B <-> Target
if a malicious node drops
* RREQs, it might disrupt route discovery, especially in a sparse node where
OrigNode might only have one or a few neighbors
* RREPs, it would stall the route for MAX_SEQNUM_LIFETIME since A can't
transmit anything over the route since it is unconfirmed
* RREP_Acks, I'm not sure– I think it wouldn't really make a difference to
the current route since data traffic might (?) still be forwarded, at least
I couldn't find any text suggesting otherwise?
* RERRs, it might lead to dead routes being used, and they wouldn't time out
since the Originator thinks it is still using them.
Without ICVs, (I think) a node could even try to launch a black hole attack
where it makes sure that it is picked as the best possible next hop by
manipulating the metric value and then start (selectively) dropping packets?
Does that make sense? Are there errors in my thinking? If there's any truth
to this, I think we should mention it in the sec considerations as well :)
Regards, Lotte
Am 23.02.2016 um 21:55 schrieb Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx>:
Am 23.02.2016 um 21:34 schrieb Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx>:
Hello Lotte,Yup :)
Without going back and reading the RERR sections, I can only think of the
following:
- not using security features when a security association has been
established
- failing any sort of format check, but we probably already discard the
packet in all such cases
So, if the RERR is valid and no ICV/timestamp mechanism is employed, ad
forged RERR can't be detected solely by it being boug? Makes sense, but I
don't think " However, since the sender of the RERR
message with erroneous information MAY be presumed to be either
malicious or broken, it is better that such routes not be used
anyway."
should be kept in the document then.
RERR should not be vulnerable to replay attacks because once the next hop
has been invalidated, the next replay would have no effect.
True. And if the attacker waits a while until the link is re-established
and *then* replays the RERR, the RERR is dropped because all the sequence
numbers in SeqNumList are stale by then, right? I think we should state
that explicitly, I'll add some text for that. :)
Cheers,
Lotte
I can't think of anything else right now.
Regards,
Charlie P.
On 2/23/2016 11:16 AM, Lotte Steenbrink wrote:
Hi Charlie,
Am 23.02.2016 um 19:58 schrieb Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx>:
Hello folks,
I haven't read all of the emails -- that's what I am working on now.
But if the next hop is sending an RERR message, and the next hop is
doing something wrong, I think it is O.K. to invalidate the route.
I agree, what I don't get is– how is "it's doing something wrong"
defined? And how does a router detect that? I think I'm missing something
obvious here.. :/
The danger would be that a malicious neighbor might impersonate the next
hop. If that were detected (by verifying authentication), then no
action should be taken (i.e., the route should not be invalidated).
O.K. I will catch up on emails more now.
Regards,
Charlie P.
On 2/23/2016 4:53 AM, Lotte Steenbrink wrote:
Hi Stan again,
Am 19.02.2016 um 15:35 schrieb Stan Ratliff <ratliffstan@xxxxxxxxx>:
Hi there!
On Fri, Feb 19, 2016 at 9:11 AM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky, hi all,
<snip>
* ”However, since the sender of the RERR
message with erroneous information MAY be presumed to be either
malicious or broken, it is better that such routes not be used
anyway.”
To be honest, I don't really get what this sentence is trying to
say.
I think it's a (pretty formal) way of saying "Since the guy sent you
crap, assume he's either busted, or he's trying to subvert the
network, so don't use the route." ;-)
Yeah, but how do we determine that he's sending us crap?
OK - This is the *perfect* example of a discussion we should probably
be having on manet@xxxxxxxx. What I'd like to see is to take the text
that Lotte has already formatted, plus the text she proposes for
clearing up encryption, *and posting*, along with a short description
of what we've done.
My discussion with Justin last night revealed a bit of a "chicken and
egg" scenario - with DLEP (and I suspect with AODVv2 as well), there's
something of a "I'm not going to review the document, because there's
an error in the document". That is, I couldn't get reviews & gather
information on the DLEP Security Considerations section, because there
was an issue with the DLEP Security Considerations...
Somebody has to "break the cycle" - so let us do it! We can post,
along with an email synopsis of this very thread, basically saying "OK
gang, here's or current best take - help us make it better."
Regards,
Stan
[snip]
