Re: Scope, Profiles

[George Jones <gmj@pobox.com>]

> Hmmmm....specific implementation detail is usually not part of an IETF
> standard

I don't think we're (eric's ?) talking about implementation in the
sense of "You must use TACACS for authentication", more in the line
of:

   IF the device is managable via IP
   THEN the device must support filtering of traffic TO the box

or

   IF the device is to be used as an edge device
   THEN the device must support filtering of traffic THROUGH the box

>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

So do I.

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

No.


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