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. > 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.) Besides, I would suggest addition of "destroy/suppress packets", to fully cover MitM capabilities of an "on the wire" attacker. 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". 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... >> 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). Greetings artur _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
