Last Modified: 2004-10-14
|Sep 04||Complete Charter|
|Sep 04||First draft of Framework Document as Internet Draft|
|Sep 04||First draft of Standards Survey Document as Internet Draft|
|Oct 04||First draft of Packet Filtering Capabilities|
|Oct 04||First draft of Event Logging Capabilities|
|Nov 04||First draft of Network Operator Current Security Practices|
|Jan 05||First draft of In-Band management capabilities|
|Jan 05||First draft of Out-of-Band management capabilities|
|Jan 05||First draft of Configuration and Management Interface Capabilities|
|Feb 05||First draft of Authentication, Authorization, and Accounting (AAA) Capabilities|
|Feb 05||First draft of Documentation and Assurance capabilities|
|Feb 05||First draft of Miscellaneous capabilities|
|Mar 05||First draft of Deliberations Summary document|
|Mar 05||Submit Framework to IESG|
|Mar 05||Submit Standards Survey to IESG|
|May 05||Submit Network Operator Current Security Practices to IESG|
|May 05||First draft of ISP Operational Security Capabilities Profile|
|May 05||First draft of Enterprise Operational Security Capabilities Profile|
|Jun 05||Submit Packet Filtering capabilities to IESG|
|Jun 05||Submit Event Logging Capabilities document to IESG|
|Jul 05||Submit In-Band management capabilities to IESG|
|Jul 05||Submit Out-of-Band management capabilities to IESG|
|Aug 05||Submit Configuration and Management Interface Capabilities to IESG|
|Aug 05||Submit Authentication, Authorization and Accounting (AAA) capabilities document to IESG|
|Sep 05||Submit Documentation and Assurance capabilities to IESG|
|Sep 05||Submit Miscellaneous capabilities document to IESG|
|Dec 05||Submit ISP Operational Security Capabilities Profile to IESG|
|Dec 05||Submit Large Enterprise Operational Security Capabilities Profile to IESG|
|Dec 05||Submit OPSEC Deliberation Summary document to IESG|
Minutes fromOPSEC Working Group meeting
Minutes by Shashi
1. Charter / Scope of Working Group (Pat Cain)
The charter that was approved by the IESG had
discussed for a while on the mailing list and at previous OPsec BOFs.
ruled out (at least for the initial charter) wireless devices,
A comment that was received related to the first OPsec document (RFC3781): It is too big. However, if we continued to flesh out more details, it would be even bigger. Therefore the plan is to make multiple little documents. If some of the documents turn out to be too small without enough content we can merge them, but goal is NOT to come up with a single 400 page RFC.
Proposed working group outputs include: Framework; Current Practices document; a series of focussed capability documents, and a small number of profile documents. The first two of these (framework and current practices) will help to drive the series of capability documents.
It is possible that there could be lots of documents, because the initial list of capabilities is a long list. There is a lot of work to do. If anyone notices anything that we have missed please let us know. Since there are a lot of proposed documents, this implies that we need a lot of authors. Please volunteer for any topics that you are particularly interested in and have subject matter expertise in. Volunteer by talking to one of us (Pat, Ross, George).
2. Framework Document (George Jones)
There have been only small changes to the framework since the BOF that was held at the last IETF. The framework document defines the set of documents which will be produced. It also talks about scope of the effort, and the threats to be covered.
Changes to the framework: A bit more work by Merike on the attacks / threat model (this is a relatively short discussion plus a reference to her "in progress" longer document); We also changed the word "requirements" to "capabilities". "Requirements" may vary from operator to operator.
Merike Kaeo: We are not interested in reinventing the wheel wrt the threat model. The idea is to develop a framework to "plug in" operator's requirements, and to provide a guide to the threats operators perceive. This is a bottom up approach.
George: We still need to double-check that the list of documents to be produced in the framework document corresponds to the charter (unless we decide to drop the list from the framework). We need to clarify the intended status of the documents. If we find that some documents can be combined, we may reduce the number of documents listed.
Pat: The hope is to get the framework document completed relatively quickly.
George: Unless there is feedback to the contrary,
close to being done.
3. Survey of Security-Related Efforts (Chris Lonvick)
Many Standards Developing Organizations (SDOs) are developing standards and/or best practices for security. We would like each of the SDOs to be aware of the other efforts which are in progress.
There is a bit of work still needed: in particular addition of ITU-T SG4 Q18 work. This is an expansion of other ITU work. We also would like review by interested parties (please send comments to authors and/or OPSEC mailing list).
The chairs asked: Should this be a working group document?
Barbara Fraser: This will be a useful document as we are doing our work. Problem is that the content is volatile (ie, will be obsoleted quickly).
Dave Kessens: We need to make sure that this document is within the scope of the charter.
Ross: This is a useful document. It will however get out of date. Whenever it is finally published, the introduction needs to be clear that this is a snapshot.
Richard Graveman: This should be a working group document. As an example it would be useful to have this referenced on the working group web site. People doing the capabilities documents should look at this document. It would be useful to have a table which showed other documents versus capabilities and showed which other documents discuss which capabilities.
Chris Lonvick agreed that it will get out of date.
Straw poll requested by chairs/AD.
Ross: There are really two questions: (1) Whether the document should eventually become an RFC or eventually time out after our effort is complete; (2) Whether the document should become a working group document, or remain as an individual contribution.
Show of hands:
Should the document eventually be published as an RFC: 18
Should the document eventually time out and go away: 12
This is not a clear consensus, and we can discuss this issue further on the list.
Should the document be accepted as a working group document: 28
Should the document stay as an individual document: 0
This is clear consensus that the document should
working group document.
4. Outline of Survey of Current ISP practices (Merike Kaeo)
Merike collected "brain dumps" (rough notes on what security practices are deployed) from service providers at NANOG. Unfortunately this was after the -00 cutoff date for internet drafts and therefore she didn't get a draft submitted. She did however get input from several service provider / network operator sources. She is intending to get more input this week at the IETF.
Howard Berkowicz: You have a number of things in there which seem to be perfectly valid threat characteristics. Under them you have mitigation techniques. Is this intentional?
Merike: Yes. She has been asking SPs "what do you do about <problem>, and is writing down the answers (both threats and counter-measures).
George Jones: This might get to be a big document.
Merike: In principle yes. But at the current time it doesn't look like it will be unacceptably large.
Merike: Yes. This is why I have done most of my discussions with providers privately one-on-one.
Dave Nelson: As a follow-up: Some might have counter-measures which they feel are clever, and don't want them published due to the possibility of counter-counter-measures being developed by miscreants.
Merike: Yes, and this is not very useful since for the purposes of this document it doesn't help to know things that I can't right down.
Ross: Are there cases where they could at least say "We use this capabilities, but can't say how because we want to keep our practices quiet".
Merike: Not really. Also, a major purpose of this document is to educate operators, and they need to know how to use the capabilities.
George Jones: Vendors sometimes complain that they have implemented features that no one uses, this document can also be useful for them.
5. No new issues/topics were received from the floor.
Meeting was ajourned.