[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-jones-opsec-framework-01 comments
Specifically referring to comments on attacks. Agreed that existing
attack classifications should be reused.....can you give examples of
specific docs that can be referenced? Most of the current
classifications were taken using rfc 3552. Wouldn't bogon and hijacked
address space re-advertisement from valid peer be a subset of message
insertion or message modification?
On Nov 9, 2004, at 5:34 AM, Pekka Savola wrote:
A couple of quick comments:
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
I think there has been significant for attack classifications. Maybe
this could reused instead of reinventing the wheel?
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
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
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).
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
(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