Hello Lotte,
No, I think it is fine to list security exposures and also fine to
describe how they do or do not add to the security exposure of the
protocol taken as a whole. My main point is that a security exposure of
a message that does not degrade the security of the network taken as a
whole should not be considered as a "fault" of the protocol. But yes we
should list these things and offer as complete an analysis as we can.
Today I cannot do the matrix, but tomorrow looks good.
Regards,
Charlie P.
On 2/27/2016 2:09 AM, Lotte Steenbrink wrote:
Hi Charlie,
Am 25.02.2016 um 17:18 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto: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'm not quite sure I get what you mean exactly– I'm reading your text as "yes, dropping RERRs can cause dead routes to be used, but that can be achieved through other measures as well, so we don't have to list dropping as an extra risk", but I'm not sure if hat's the correct interpretation... Could you clarify what you mean?
Thanks,
Lotte
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 onmanet@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]
