On 18/10/17 15:01, Artur Hecker wrote:
Hi
Please find below some short additional comments, hopefully on time :-)
Michael, these things are indeed a pain to formulate correctly, so please feel
free to disregard, if it becomes too bulky.
Artur, thanks for the comments, I'm very happy to get feedback! :-)
Somehow I was afraid someone would say this. :-( It's not easy to explain, in
simple terms...
How does this sound:
"In an outsider attack all network elements and protocols are securely managed
and
operating, and an outside attacker can sniff packets in transit, inject and
replay packets.
In an insider attack, the attacker has access to an autonomic node, or can
insert packets
directly into the protected ACP."
[[AH] ] Minor point: as an attack is a practical instantiation of potential threats exploiting some vulnerabilities, I believe
that what we describe here is better called a "threat model". We can still call those presumed actors "inside
attacker" and "outside attacker" respectively, both being "threat agents", but I wouldn't talk about
"inside attack". (Rationale: a specific attack could be an arbitrary combination of all these.)
Well, a threat model is more comprehensive than what we have right now,
and would result in a bigger analysis than I think we want here. Maybe
we should spin off another document on this some time. But I'm a bit
hesitant in using this term in the current version.
Besides, I would suggest addition of "destroy/suppress packets", to fully cover MitM
capabilities of an "on the wire" attacker.
Good point. I'll use the term "drop packets", I think that's the
generally used term. Added: "and that the AN protocols are robust
against packet drops."
For the second phrase, I would add something like: "<...> access to an autonomic
node or any other means (e.g. remote code execution in the node by exploiting ACP-independent
vulnerabilities in the node platform) that would allow the attacker to produce arbitrary
payloads of the protected ACP channels".
Changed (with a few small edits).
Finally, probably it would be good to categorize these "arbitrary payloads": if
the inside attackers only produce some twisted packets and wrong syntax, we can discover
them by sanity checks of ACP related protocols. But for more complex scenarios, we would
seem to need behavioural node analysis or majority votes, etc., which imo still have too
many false positives / negatives. I guess we cannot require TC/TPM with remote
attestation? Especially, because all this is somehow orthogonal to ANIMA...
For now, I suggest we leave it as it is, essentially: "an insider can do
anything". Again, a deeper analysis should go into a separate document,
in my view.
o protected against modification.
o authenticated.
o protected against replay attacks.
o encrypted."
- I'd rather be consistent using "protection on Confidentiality,
Integrity, Availability, and Non-repudiation".
That's not the same :-) You don't cover re-play attacks.
[[AH] ] I would agree with Michael here. C.I.A. refers to data protection, we
talk about a protocol. I would even add MitM specifically in the list above, as
it very probably will be the first choice... (See KRACK).
So now I added a bullet combining both of the comments received: "and
that the AN protocols are robust against packet drops and
man-in-the-middle attacks."
These were all the comments received so far, and I tried to address them
appropriately.
I'll now update the github repo, and publish the new version. The chairs
should decide whether we're good for a WGLC, I think that would be a
good next step. Surely there will be more comments during that process.
Thanks Artur for your comments!
Michael
Greetings
artur
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
