[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-jones-opsec-framework-01 comments



On Tue, 9 Nov 2004, George Jones wrote:
On Tue, 9 Nov 2004 15:34:01 +0200 (EET), Pekka Savola <pekkas@netcore.fi>
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.

Right. RADIUS vs. TACACS comes to mind.

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).

I'm not sure I have a good answer. The minute we say "you must support SSH for remote access", something better will come along or 3 out of 4 operators will choose to use rsh over IPSEC or some such.

In the end, I think the best we can do is sort of what's there:
have the capability (nee requirement) be generic, list examples
of how to do it with current technology (if any), and leave it up
to individual operators to decide what capabilities are
actually requirements for them.

Do you have a better idea ?

Sorry for being unclear. I think I tried to propose a "procedural" approach to this problem:


1) have an explicit subsection of known techniques under each capability (whether Examples is good enough or not can be considered).
(So that good technologies, known as of the time of the writing, are consistently listed in a concise format for each technology.)


2) state that the vendors who advertise that they implement capability X should always also describe which technologies they use to implement X.

3) state that the operators who require certain capability X could/should also additionally describe which technologies for X they would find most appropriate.

In other words, an "ABC on how to use this effectively for operator/vendor dialogue, RFPs, or capability/feature documentation.

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