Hi Charlie,
Am 31.03.2016 um 19:43 schrieb Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx>:
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?)
I think it might be enough to say this:
An ad hoc network with AODVv2 routers can be connected through a Internet
Gateway; AODVv2 control messages don't traverse that gateway. Therefore, any
threat from the Internet from the ad hoc network is not due to AODVv2, and
AODVv2 messages from the Internet would never pose a threat to the AODVv2
routers in the ad hoc network.
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?
You could say exactly that in the security considerations, while also
observing that jamming can be directionally aimed at the victim node. In any
case the threat is not proportionately so great as to warrant heavyweight
mitigations.
However this could be tackled as a new charter item if people have any ideas
about it. I don't.
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.
I think it's fine to say exactly that.
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... :( )
The 7182 mechanisms provide authentication.
- 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?
The protection types are authentication and message integrity. Snooping and
traffic analysis are still threats.
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? :)
I'm running on negative time. For the meanwhile, can you use the existing
text? It's short but accurate.
Regards,
Charlie P.
