Re: Straw-man charter

[George Jones <gmj@pobox.com>]

On Wed, 2 Jun 2004, Ross Callon wrote:

> >   The working group will produce requirements appropriate for:
> >
> >     * Network Service Providers (NSP) Networks
> >     * Internet Service Provider (ISP) Networks
> >     * Enterprise Networks
>
> Is it clear what a "Network Service Provider" is? From the context, I am
> figuring that it whomever offers a network service other than Internet and
> Enterprise networks. This seems to include Layer 3 VPN services. Does
> it also include Layer 2 VPN services? Does it include ATM services?

You're right.   Definition is needed here.    I was mainly trying
to draw a distinction between large nets that provide a good deal
of transit and joe-I-have-a-T1-and-provide-wireless-to-my-neighbors.

Do others (Don Smith, Steve Matkoski, Fred Budd ?) have thoughts
on defining this split ?

>
> >   Once these are done, it may be appropriate to broaden the scope (and
> >   recharter) to address the operational security requirements of of:
>
> This sentence doesn't quite read the way that charters typically read, and
> might be interpreted as saying that these *will* be added, rather than *might*
> be added. How about:
>
> The following areas are excluded from the charter at this time. They
> may be considered for inclusion in an updated charter at a later
> time:

OK.

> >Methods
> >
> >   A road-map document will be produced describing the scope, format,
> >   intended use and sequence of future documents. A series of small BCP
> >   documents will be produced covering various areas of security
> >   management functionality...
>
> Very minor nit: I would leave out the word "small", on the basis
> >that the size

OK.

> >   Much of the operational security knowledge that needs to be codified
> >   resides with operators. Operators have shown a tendency to be too busy
> >   with day-to-day operations to be as involved in standards bodies as
> >   one would hope. They have shown a greater tendency to be involved in
> >   operators forums such as NANOG and RIPE. In order to access their
> >   knowledge and reach the working group goal, interim meetings may be
> >   held at such operator forums.
>
> How about abbreviating this to:
>
>    Much of the operational security knowledge that needs to be codified
>    resides with operators. In order to access their knowledge and reach
>    the working group goal, interim meetings may be held at operator forums
>    such as NANOG and/or RIPE.

OK.

>
> >Goals and Milestones:
> >
> >   Jun 04                Hold charter discussions on mailing list,
> > identify chair+authors, submit charter
> >Jul 04          Schedule Working Group
> >Aug 04          Working Group Meeting @ San Diego
> >Sep 04          Submit Roadmap Draft
>
> This is rather optimistic.

That's why we're involving seasoned IETF pros :-)

 I think that we will be doing well to have an 80%
> complete draft by September, as a working group document. There might
> still be some discussion regarding what should be in the roadmap. It will
> take some work to get this 100% completed and through working group
> last call. I would expect that two IETFs later would be more realistic (which
> puts it out to March 2005).

Does it make sense to try to list the other documents before the
roadmap is hammered out ?  Would it make sense for the initial charter
just to list the path to the roadmap document with the understanding
(stated in the charter) that the milestones for the other docs will be
set once it is agreed what they are ?

>
> >Oct 04          Submit In-Band, OoB and Interface Reqs Drafts
> >Oct 04          Interim meeting @ NANOG
> >Nov 04          Working Group Meeting @ Washington, Roadmap to IESG
> >Dec 04          Submit Stack, Rate Limiting, Filtering Drafts...
> >Jan 05          In-Band, OoB and Interface Reqs to IESG
>
> I would push the other document milestones out a bit also.

If you want to take a stab at a timetable, I'd be all eyes.

>
> I am not sure whether we explicitly need to mention the interim meeting
> at Nanog in the charter, although it seems like a good idea to have such
> a meeting.

The first one will serve two purposes.   Generation of raw
ideas/feedback/brainstorming about what's actually used and
to try to further engage operators who may not attend IETF
meetings.

>
> >.
> >Aug 05          Working Group Meeting/Wrap up
>
> This depends upon what happens after we finish the first charter
> items. It would seem that at that point we would want to decide
> whether to wrap-up, or to extend the charter. I don't think that we
> need to put this line item into the charter.

OK.

>
> >Internet-Drafts (to be written):
> >
> >     * OPSEC Roadmap (info)
>
> Should we call this "roadmap" or "framework"?

...or "marching orders arrived at by rough consensus".   I'm
ambivalent.   If there's precident, let's follow it.


> >     * OPSEC IP Stack Requirements (BCP)
>
> Is there enough in IP stack to warrant its own document, or should this
> be put into the "other" document?

Perhaps not now.  There used to be more.  Here's a case where it may
not make sense to name exact docs before framework doc is worked out.

>
> >     * OPSEC Rate Limiting Requirements (BCP)
> >     * OPSEC Filtering Requirements (BCP)
>
> I would tend to put rate limiting and filtering in the same document (there are
> of course a number of different things that you can do in response to a filter,
> which rate limiting only being one of many).

Sure.   Let's have  the discussion.


> >     * OPSEC Assurance Requirements Requirements (BCP)
>
> I don't understand what this is...

Assurance requirements are things that are neither functional
(do this) nor documentation, but which give some level assurance
(or facalitate testing to attain that level of assurance) that
the device will function as advertised.

The two reqs listed here in the opsec draft are "identify source of IP
stack" and "identify source of OS".  I'm going to have a different
level of comfort with an single-purpose OS developed and proven
with formal methods than with, say, a commercial OS around which
an entire anti-virus industry has been built (of necessity).

In addition, having such knowledge allows focused testing...it's one
thing for the marketing department to say, "yes, we've fixed all known
bugs in the FOO OS on which our product is based", it's another to
take it into the lab and see it not fall down when hit with all known
FOO exploits.

Having this type knowledge assists customers in assuring themselves
that the procuct is secure.   Hence, assurance requirements.

OK, that was more specific and less charter than I wanted to do here.

The assurance and IP stack requirements sections in the opsec draft
may be small but may not be complete.   It may be worth revisiting
the question "are there other assurance requirements" ?  "Are there
other IP stack requirements"....perhaps the authors of the various
drafts could drive those discussions.

>
> >     * OPSEC NSP Operational Security Requirements Profile(info)
> >     * OPSEC ISP Operational Security Requirements Profile (info)
> >     * OPSEC Enterprise Operational Security Requirements Profile (info)
>
> I am assuming that the timeframes for these would need to be after the
> other documents are done, on the basis that you can't decide whether
> you need to support a feature until you define what the feature is.

I don't think it would hurt for people to get started on profiles
before the other docs are worked out....people thinking about reqs for
one particular environment may come up with something that should be
included in the BCPs.  You're right though, the BCPs would have to be
published first.

Thanks,
----George