draft-jones-opsec-framework-01 comments

[Pekka Savola <pekkas@netcore.fi>]

Hi,

A couple of quick comments:

1)

I think the attacks section 1.4 needs to be be categorized a bit more 
at depth.  For example, one way to would be consider broader 
categories of "on-the-path" attacks and off-path attacks. (There is 
very little you can do about on-the-path except prevent it from 
happening, but off-path is another topic.)

There is also some overlap with "active (and replay) attacks" and 
message (insertion, deletion, ...) attacks, and a better 
categorization would help.

Please also where illegitimate (e.g., a bogon or hijacked space) BGP 
prefix advertisement (but through valid peer) would fit in this 
framework.

I think there has been significant for attack classifications.  Maybe 
this could reused instead of reinventing the wheel?

2)

Capabilities are currently defined to NOT refer to specific 
technologies.  However, this brings up a problem mentioned when we 
tried to figure out what to do with the original opsec document: this 
does not guarantee or give any guidance to providing interoperable 
implementations.

That is, vendor X would provide feature F_x, vendor Y feature F_y, and 
the operator might need to support multiple ones (basically whatever 
provided by the vendors), and it might even be possible the different 
equipment would not have a common set of interoperable features.

There are couple of ways to solve this problem; one could be 
mentioning specific technologies in the format, like "Technologies 
(what)", and recommend that that information is published (whatever is 
implemented) by the vendor.

Then if the operator is looking for specific technology, it could say 
"Capability X, technology Y would be preferable", and the vendor could 
say "Capability X is supported, our technologies are Y, Z, ...".

For example, as an operator, I'm not satisfied with requiring 
capability to do ingress filtering; I want to know which methods for 
ingress filtering are supported by the vendor in question, and I want 
a very specific one if that's reasonable considering the other 
tradeoffs.

There should be a means to communicate what features are supported, 
and what specific features the operator is preferably looking for (to 
maintain interoperability/consistency with other equipment).

3)

Would there be profiles for different kinds of equipment.  For 
example, I as an operator might not want to be as strict for the 
support for some features in the Ethernet switches we're getting 
(depending where they are deployed), compared to e.g. backbone 
routers.

..

(there were also quite a bit of typos, minor issues, etc., but I might 
send those separately.)

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings