[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?

- merike

On Nov 9, 2004, at 5:34 AM, Pekka Savola wrote:

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