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]