Hello Lotte,
On 3/31/2016 10:23 AM, Lotte Steenbrink wrote:
Hi Charlie, hi all,
Am 30.03.2016 um 01:55 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>>:
I don't understand this. We explicitly say that the ad hoc network can be connected through a Internet Gateway, and that AODVv2 control messages don't traverse that gateway. This means that the threat from the Internet is not due to AODVv2.
Yeah, but we don’t state that explicitly in the Sec Considerations, I think? If I'm interpreting this excerpt from BCP 72 correctly, we should write down that AODVv2 isn’t meant to be deployed across the Internet (there may be gateways, but you can’t run AODVv2 between two AS etc)…? But since I’ve struggled to follow the discussions around gateways and big-I Internet stuff I figured it’d be better if someone else wrote that down properly. :) (maybe Stan could lend us a hand here?)
TODO
"This description MUST
include the reasons it was either unreasonable or out of scope to
attempt to avoid these denial of service attacks.":
(a) we don't have a good mechanism for doing this [but no one else does either]
(b) wireless is vulnerable to interference in a way drastically worse for DoS than RERR.
So you can say that the additional threat is tiny compared to simply jamming the medium.
Well, but if you’re jamming the medium, you’re jamming communication for everyone, whereas a DoS could take down a specific node while the rest of the network stays (somewhat) healthy?
Therefore it was considered improper to burden the protocol to counter a proportionately tiny threat.
- Authentication of senders may prevent "foreign" nodes from DoSing, but does
not protect from rogue routers (note that we currently don't propose any
authentication mechanisms)
What is a rogue router? Is it one that is authenticated?
Yup, sorry, those were just my imprecise notes because I wasn’t quite sure if they were good enough to be turned into proper text– what I meant was that if an attacker gets hold of an authenticated node (or an authenticated node has a bug and misbehaves), there’s not much we can do.
In that case, we can say that the authentication mechanism is assumed to eliminate the threat of rogue routers. This is reasonable for obvious reasons because authentication security associations are developed based on trust. So I am agreeing with you that this is a proper mechanism.
Cool! Do we want to suggest an authentication mechanism as well? (I really don’t fell qualified to do this so I’m inclined to say that this is out of scope– but then that’s an interop issue... :( )
- In the corner case that network architecture is previously known, "legal"
addresses could be administratively configured?
I don't know what this means, sorry
I meant that routers could store a list of addresses of all other routers in the network (because they’r statically preconfigured) and drop everything from or containing other addresses. But disregard that point, I was just rambling...
As written, yes of course addresses can be administratively configured. Why not? And so I also agree with this but I don't think it buys very much over and above what is gotten from enabling authentication.
Yeah, it would essentially be a quick and dirty and inflexible auth mechanism. :D
(- is this sufficient? Am I overlooking a way to prevent this here?)
See above. The threat from interference is far worse than RERR DoS.
That doesn’t mean nobody would want to mitigate (D)DoS threats…
TODO (like OLSRv2 section 23.6)
I didn't go read this, but presumably since it's RFC it should be O.K.
TODO: choose HASH_FUNCTION and CRYPTOGRAPHIC_FUNCTION.
Is this still needed? Can we use AES and HMAC_AES?
TODO: "If the protocol incorporates cryptographic
protection mechanisms, it should be clearly indicated which portions
of the data are protected and what the protections are (i.e.,
integrity only, confidentiality, and/or endpoint authentication,
etc.). Some indication should also be given to what sorts of attacks
the cryptographic protection is susceptible. Data which should be
held secret (keying material, random seeds, etc.) should be clearly
labeled."
Why isn't this already accounted for in step 2?
Mhm, you could argue that the „which portions of the data“ part is accounted for, but the protection type isn’t quite clear, is it?
TODO:
"There should be a clear description of the residual risk to the user
or operator of that protocol after threat mitigation has been
deployed." (i.e. detail what happens if parts are compromised, weak cipher
is deployed etc)
If routers are compromised the threats have already been listed. If the weak cipher is deployed the routers would be more susceptible to being compromised.
Could you write some text about that so I can copy & paste it there? :)
