[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Straw-man charter
Hi,
I don't think size is a good choice for differentiating requirements.
Requirements should be mapped to functionality.
A Tier 1 provider and a Tier 2 provider offering similar (or the same)
functionality will have similar (if not the same) requirements. Two Tier 2
providers that offer totally different functionalities don't have the same
requirements.
My $.02
Dave Harrington
dbharrington@comcast.net
> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On
> Behalf Of Steven Matkoski
> Sent: Thursday, June 03, 2004 11:18 AM
> To: Smith, Donald; gmj@pobox.com; Ross Callon
> Cc: opsec@ops.ietf.org
> Subject: RE: Straw-man charter
>
> I think maybe using the "Tier" distinction may help here.
> Tier1 for large providers (NSP as termed below) and Tier2 for
> regional and below (ISP as termed below). This would break it
> up by size.
>
> Breaking it up by services may be a bit tougher, since I
> believe size and services do not correlate to each other.
> There are many small providers that offer many services.
>
> At 11:02 AM 6/3/2004, Smith, Donald wrote:
> >NSP should imply additional Networking services beyond what an ISP
> >traditionally offers.
> >The reason for a split like this is NSP's tend to have LARGE FAST
> >backbones and LOTS of routers.
> >ISP's may have a single router with fairly low bandwidth.
> They may also
> >sell basically ONE service (dialup, wireless ...).
> >
> >I would be just as willing to call such providers SSP (small service
> >providers | simple service providers) but do not want to
> insult anyone
> >or any company.
> >
> >I think the reason for a split like this would be because of
> the order
> >of magnitude difference in complexity when you have to
> manage 100's of
> >routers in lots of cities with 1000's of dynamic routes
> (NSP) vs 1 (or
> >10) router(s) a single static default route to an NSP (SSP|ISP).
> >
> >George do we want/need a category for CSP Content service provider.
> >Some ISP's are moving away from providing ANY network connectivity.
> >They provide content and host mail/ personal web pages etc... but do
> >NOT sell the customer any network access. This model is becoming
> >popular. They would not be doing routing for the customers.
> >
> >Finally I think ATM providers and other L1, L1, L3 network providers
> >could be covered by the NSP class but am not sure if the
> model will fit.
> >
> >
> >Donald.Smith@qwest.com GCIA
> >http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC
> >pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00
> EDCC Brian
> >Kernighan jokingly named it the Uniplexed Information and Computing
> >System (UNICS) as a pun on MULTICS.
> >
> > > -----Original Message-----
> > > From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On
> Behalf Of
> > > George Jones
> > > Sent: Thursday, June 03, 2004 4:59 AM
> > > To: Ross Callon
> > > Cc: opsec@ops.ietf.org
> > > Subject: Re: Straw-man charter
> > >
> > >
> > > 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
> > >
> > >
>
>