Hi. I respectfully disagree on C.I.A. and re-play, but I can live with the Michael's original text :) My changes are aimed at the style of the described list. Best. Jéferson
Em qua, 18 de out de 2017 às 11:01, Artur Hecker <[email protected]> escreveu: > 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
