Re: Scope, Profiles

[ericb@digitaljunkyard.net]

 "gmj" == George M Jones <gmjones@mitre.org> writes:

>> Well, things that I want for my powerstrips apply to anything with an
>> IP.  So it's not really profiles, but more "if you supply this
>> capability (IP stack, MPLS, etc), you must implement these features."
>> 

gmj> So you're basicly suggesting:

gmj>   If you implement IP, then

Yes.  So for my current pet peeve, it would look like:

"If you implement password protected logins:
   Implement network AAA
   ... "

"If you provide a configuration service (not you can configure the
device but the "config" of the device is accessible in some form):
   Implement ASCII configs
      Provide the grammar for those configs
   Implement config sanitization (open can of worms here)
   ..."

These are baseline requirements that every "secure" (or "securable"?)
device must supply.  Then there are more advanced requirements that
only apply in certain profiles.  E.g. if it's an edge device, it must
supply these capabilities (which are going to include more invasive
and CPU intensive things than a core device, even though both provide
roughly the same features (IP stack, packet forwarding, ...)).

>> So at the front, there are some capability => feature mappings, then
>> as you dig deeper you get to stuff like "if you use the device this
>> way, you should configure it this way".

gmj> When you say "configure" do you mean things like "turn of directed
gmj> broadcasts"

Yeah, kinda.  This document is aimed at two seperate entities:

1) Vendors.  They must provide the knobs and dials to tweak.  Perhaps
   also with sane defaults, depending on the outcome of several
   religious debates.

2) Users.  These range from kinda clueful to really lost.  (Clueful
   users are either working on this document, or unemployed)

So the capabilities that must exist are addressed to the vendors and
purchasers of devices.

How to twist those knobs and dials is addressed at the network
engineers who actually design, deploy and manage the devices.

gmj> or "include this group of capabilities" ?   I can see groupings like

gmj>   Edge Device
gmj>      1. Filtering of traffic trough the device
gmj>      2. Filtering of traffic to the device
gmj>      3. Support rate-limiting

gmj>   Core Device
gmj>      1. Filtering of traffic to the device

These would fall into the "more advanced requirements" section.

So you have:

Baseline requirements
        Device provides service (IP addr, packet forwarding, etc),
        device must provide capability (IP filtering TO, AAA, etc)

Advanced requirements
        Device is used in a certain profile (customer aggregation,
        CPE, core router), device must provide this (filtering
        THROUGH, etc)

Configuration guidelines
        Given a device with certain baseline and advanced
        capabilities, you, the user, should configure it thusly.  This
        section will further act as justification for the requirements
        above.  Here, we'll describe why the knobs should be turned
        just so.

Basically, I like the idea of profiles, I just think that the common
requirements and config bits should be factored out.  Common
requirements (baseline) are a strong line to hold, things we can push
for from vendors with serious effort.  Maybe filtering THROUGH at
OC192 isn't possible, but you'd BETTER implement filtering TO.

ericb