Hi Charlie,
Am 25.02.2016 um 17:18 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:
Hello Lotte,
I'm not disagreeing with you. However, I think that it's useful to
understand not only what can go wrong, but also whether or not the bad
effects are already possible. So, for instance, in the case below for RERR
-- yes the bad effect exists, but it does not represent an *additional*
security exposure. My impression is that typically people are most
interested in the additional exposures, but we can certainly list everything.
Perhaps then we will get complaints that we list too many.
I'll try to put together a matrix today.
Regards,
Charlie P.
On 2/25/2016 7:46 AM, Lotte Steenbrink wrote:
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.
I don't quite understand what you're saying here– of course we don't want to
use malicious nodes for routing, the question is just– (how) can we
accomplish this? According to BCP72, we have to list what can and what
cannot go wrong (and why) and how this can be prevented, in a detailed
manner. That's hat I'm trying to do here.
The problem with RERR will solve itself for all TCP connections.
Then we should state that. (most "IoT" traffic probably isn't TCP, though,
so this should be clear imo)
A malicious node could pretend to forward packets but then throw them away,
but that is a problem regardless of RERR.
Of course, but as I said– I'm trying to be as detailed as possible here. If
a node throws them away during forwarding, that's not part of the routing
protocol's security considerations, is it?
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.
So that readers have an immediate overview?
Sounds cool, could you provide such a Matrix? :)
If this is agreeable, I'll work on making the matrix and send it out.
Nice!
Regards,
Lotte
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]
