Re: Scope, Profiles

["merike kaeo" <merike@groovy.com>]

Hmmmm....specific implementation detail is usually not part of an IETF
standard so I hesitate to agree with the model of first specifying a
requirement for a profile followed by how the capability is to be
implemented. (although from a user's point of view it sure would be nice to
have something consistent).  Need to think about this some more but please
chime up if you have an opinion.  I am currently finishing the profiles part
since I promised George to help provide text.

Anyone here think a SOHO box needs OoB management?  I personally don't since
none of my isdn/cable/dsl providers have ever managed them nor do I expect
them to ever want to.  However, would like to hear from you providers to see
*if* the capability were there that they would use it?!? Really truly?

- merike

----- Original Message -----
From: <ericb@digitaljunkyard.net>
To: "George M. Jones" <gmjones@mitre.org>
Cc: <gmj@pobox.com>; "Dan Hollis" <goemon@anime.net>; "Wang,Nai-Pin K."
<knwang@mitre.org>; <opsec@ops.ietf.org>
Sent: Monday, June 23, 2003 5:28 PM
Subject: Re: Scope, Profiles


> "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
>
>
>
>
>