Re: netsec-reqs document: what is, where it is, what to call it.

["Merike Kaeo" <kaeo@merike.com>]

I am wondering if we can come up with the following:

- BCP which is 'stable' and acts as core requirements for what vendors
should implement (filtering capabilities, scriptable configs,
authenticated/encrypted device access, blah, blah...)

- Informational doc which lists specific bcp implementation details for
current capabilities (ex: access to boxes via ssh or in some cases telnet
with IPsec).  This informational doc can also act as a place to define
industry acceptable security defaults (for those implementers that may not
be so knowledgable (some say clueless)).  This informational doc is modified
regularly (every 2 years?) to reflect new security capabilities.

I'm struggling whether the latter belongs in the IETF (since this document
requires updates in a *timely* fashion) although it will have more clout for
industry folks if it is there.  I will leave that decision for
others.....(punt)....

- merike


----- Original Message -----
From: <gmj@pobox.com>
To: <ericb@digitaljunkyard.net>
Cc: <gmj@pobox.com>; <randy@psg.com>; <opsec@ops.ietf.org>;
<morrowc@ops-netman.net>; <lamour@uu.net>; <mkrause@uu.net>
Sent: Wednesday, March 19, 2003 4:05 PM
Subject: Re: netsec-reqs document: what is, where it is, what to call it.


> ericb@digitaljunkyard.net writes:
>
> >  "g" == gmj  <gmj@pobox.com> writes:
> >
> > g> Why it's being published?
>
> > One reason is (possibly justifiable) UUNET hubris.  We would present
> > our requirements to a vendor, and they'd say "None of our other
> > customers are asking for these things."
> >
> > By publishing it beyond UUNET, we hoped to spark ideas in other
> > customers, to get them to say "Wow, that's a great idea, we want you
> > to implement that too."  Basically, "You want it, you just don't know
> > you want it yet."  There was also the hope that once the document got
> > out, other customers would chime in with their own ideas, which we at
> > UUNET had not thought of.
> >
> > This document comes from very base origins.
>
> And make se
>
> >
> > g> Why this matters?
> >
> > g>      We have comments to integrate now.  We need to know
> > g>      what sort of document is being produced to
> > g>      integrate them properly.
> >
> > Personally, I think that the original mission of the document is as
> > yet uncompleted.  It might be appropriate to split the document, it
> > might not.  Whichever way you go, at least one document should come
> > out of this where end users swap ideas for security enhancements, and
> > then present them to the vendors with the power of collective
> > bargaining.
> >
> > This is a moving target.  Bad things on the Internet evolve rapidly,
> > old requests get implemented or supplanted.  You will never get
> > multiple customers with different focuses (or even customers with
> > similar focuses) to agree on a set of features, and certainly not a
> > priority list for implementation of those features.  It may be that
> > this should not really be a document, but that the existing document
> > should be a foundation for a forum.  There, enhancements can be
> > suggested, discussed, refined, and prioritized.  Different customers
> > can sign up for different enhancements, and then vendors can check in
> > and make informed decisions on what to implement next.
> >
> > SourceForge, anyone?  Push for Cisco to open source IOS?  It worked
> > for Mozilla, right?
> >
> > ericb
> >
>
> --
> George M. Jones    |  Contra bonum morem ("Against good custom")
> Network Security   |
> Architect, JAPH    |
>                    |      Seneca (Dialogues, vi, i, 2)
> gmj@pobox.com, PGP Finger=CB97 C772 7685 0E15 E27E  C78D A50F 3AAD C1D6
D49E
>
>