|
OPSEC BOF Minutes - August 2004
Minutes taken by Brian Ford and Sharon Chisholm Agenda bashing Ross Callon starts by calling the meeting to order This is the 3rd OPSEC BOF No charter yet Ross asked if there were any other agenda items (no response). Charter bashing Ross introduced charter The charter has already been editted and worked on using the mailing list. Ross and George discussed the charter this week with IESG members (operation area directors and security area advisor), minor changes were suggested. There will be more than one co-chair, which will be chosen by the IESG. This Working Group will be in the operations and management area. David Kessens will be area advisor to this group. The entry showing "Security area directors" was crossed off the charter since the group is not in the security area. However, Steve Bellovin will be security area advisor to this group. The Mailing list will stay as is. There was an editorial change to the charter to remove "OSI layers 2 and Layer 3" and instead say at "the data link and IP layers" A number of acronyms have been spelled out. Dates for the milestones might required re-work. In particular the IESG would like some of the further out milestones to be done sooner. Also, milestones for the first draft of each of the documents will be added to the charter (note that milestones were already there for first drafts of the framework and survey documents -- both of which already exist as rough drafts.) The names of people who have volunteered as potential authors will be removed from the charter. We are hoping to get the charter approved in 4 to 6 weeks, well before the next IETF. Ross pointed out that it would be valuable to get the charter out before next NANOG, since we may want to present or have some form of meeting at the next NANOG in order to encourage service providers / network operators to participate in the effort. Dave Kessens commented: "Good charter" Framework document George introduced the framework document. George asked for a count of operators (about 1/3 of people present) and from vendors (about 2/3 of those present). The framework document front matter defines what the WG will work on and not work on. Coming out with a series of documents that defines requirements for devices. Wasn't clear whether this was fit as an informational or BCP RFC. Aim is to go very light on keywords "must", "should" and define scenarios. What is best? Is it what vendors do? Users do? What is done? What is current? Implemented versus feasible? Idea is to identify what operators want? Does anyone have feeling about this? George asked for comments. Barb Fraser: Ingress / Egress: It may not have been proactive to do that filtering but the products had capabilities. Are you specifying practices or feasibility? GJ: Good question. If we see a ground swell that points to every operator doing the same thing it will be documented. If there is ground swell that will be captured. Barb Fraser: regarding these features and capabilities some comment has to be given as to whether capability exists exist widely in products today GJ: Yes Pat Cain(?): BCPs already have some well defined terms. Right now BCPs indicate whether things are implemented. We've been through this fight before. Ross: We have looked at the documents which define "BCPs". The best definition seems to be in section 5 of RFC2026. We have also discussed this with the IESG. There seems to be some flexibility there. If a wide range of operators say that something is done, or that it should be done, it can be in a BCP. If they want to do something it should be documented. Gerry Wilson: Will scope include "requirements". GJ: Yes. The documents that we produce are intended to describe device capabilities that are required to support secure operation of networks. Whether we use the word "requirements" is something for us as a group to determine. Eliot Lear: The host and router requirements docs are now Internet standards and changing standards usually takes much work. It is important to well define scope of these recommendations. GJ: We see the need for multiple profiles that will explain what the recommendation is targeted at. Eliot Lear: We should keep the OPsec documents simple and on target ??: It would be much more interesting to start from the threats to these networks and working to a solution; rather than finding a home for a solution. If we had a document that defined this is what we want to achieve and these are the issues that would help. GJ: Some of that is in the framework. If you can suggest where we can make that fit it would help. Merike Kaeo (MK): Threat models are important Bora Akyol (BA): There are operational requirements for an operator and also requirements for elements. If there are operational requirements or suggestions they should be separate from what the requirements for elements are. Is your goal to have a kind of "certified' secure network? GJ: The goal is to capture what some operators do to run a secure network and what vendors offer to make this happen. GJ: This came out of operator world and has applicability to enterprise. The document attempts to describe this. BA: One place this is documented is in RFC 1812 GJ: An update to RFC 1812? This work will be more focused on security and as such its own work. Ross: One comment that is in the framework is a warning that it is not appropriate to mandate what is in the other docs. The goal here is BCP, captured knowledge about best practices and that is not the same as a requirement. I think should be a collection of wisdom. This same warning not to mandate this work might want to be included in the various capability documents that we produce. GJ: Agreed GJ: Spoke about the logging and trapping overlap with Syslog. Most all of that overlap has been addressed. Overlap with other WGs and Standards Developing Organizations (SDOs) will need to be worked out. BA: In the framework it spoke a little about operator and provider and it is suggested that we talk about backbone routers versus edge routers. BA: Except log management where big and small ISPs have drastically different requirement. GJ: Agreed Ross: We are not a WG but by a show of hands how many 1) have read and 2) how many agree that the framework document should become a working group document when we become a working group. Very low show of hands, only 10-15 people had read the framework document. Most people who raised hands as having read agreed that this should go forward as a WG. However, since most people had not yet read the framework, we will discuss this further on the mailing list before the framework would become a working group document (assuming that we become a working group). Liaison and other efforts Chris Lonvick gave a presentation on other security-related standards efforts, and how we might liaison with them. IETF Liaisons - handled by the IAB Fred Baker and others are working on a formal doc that addresses liaisons between Standards Developing Organizations (SDOs). Liaisons at other SDOs are often handled in a very well known and formal manner. Liaisons statements must be dealt with by the proper group. Since this isn't a WG yet no liaisons are appropriate now. Before we ask for liaison statements we should review the work of the other SDO and have defined targets. Other operational security work (3 parts) - glossaries - SDOs - SDO efforts There are lots of glossaries out there. There are a number of SDOs The intent of this ID: awareness The goal of liaisons is to avoid many PCPS (different definitions) from different SDOs that confuse the audience. Chris defined work going on in a number of other SDOs. See Chris Lonvick's slides for more details on SDO activities. In summary there is much overlap here and we should be talking to these SDOs, and taking their work into consideration for our work. Outreach to Operator Communities Ross : We have asked to set up a table meeting at NANOG. Naturally this is a North American organization, and we would also like to solicit input from operators in other parts of the world. GJ: We like to hear from the operator community for help. Call for Volunteers Ross: We need help from folks with operator experience. Comments on existing documents would be helpful. If you look at the list of documents described in the draft charter, some have volunteers to help write them, some don't. We would like to solicit help from people to extract ideas and sections from George's longer (draft-jones-opsec-06) document. Open Comment Session Barb: There are a number of important questions that need to be answered here. It is important to separate features or requirements on devices (an addendum to router requirements) as opposed why features are needs or used. Which one of these are requirements that are imposed on Internet technologies and which are practices. GJ: The goal is to collect the wisdom from the operators about features that they need. BF: Isn't that what has already been done? Is this the place for a BCP? Ross: We don't want to document how to break a network. The reality is that the operator community has good ideas about what could be done so as not to break a router or a network. Largely this is based on operational experience. Instead we want to write this is how you build a network that can't be taken down. BF: As BOF we should be exploring what this is about and what the work items might be. The framework says that we should work these chunks. Are we after features and practices? Current work (draft-jones-opsec-06) is fuzzy. Ross: Not clear whether these should be called "requirements" or "capabilities". Don't know. We need to determine which term to use. (later we appeared to reach consensus on the word "capabilities") Christian Huitema (CH): You need to document the threat. If you don't document the threat you miss an important part of the problem. Steve Bellovin (SB): You have to define the threat. The bad guys already know what they can do. We need to educate everyone else. GJ: The proposed focus is on making sure that network equipment has the right "knobs" available, not on mandating how these knobs are used. ??: We need to increase the robustness of the network, so that it doesn't fall apart or go down in an attack. GJ: Its about keeping networks running and packets flowing. CH??: If we want to be precise in how we protect the network we need to define and explain the attacks. Not doing the threats completely means that we may miss something. GJ: We're concerned about scope. You saw how large the existing doc is and the concern is it would be too large if configurations were discussed. Ross: I am concerned about how long it would take to agree on a complete threat model. If we are talking about a couple of months, or one IETF, then this makes sense. However, a complete threat model could take years. I don't want to slow down the work by a very large amount of time. I also wouldn't want to duplicate the work that is already going on elsewhere on threat models. MK: Accomplish 2 things best operation practices and best suggested feature for vendors. Do we want to push this from an operational or a vendor point of view. Another concern is creating yet another threat model document. The people working in the front lines (ie, those operating networks) generally understand the threats and they could lose interest (and fail to participate). Mike Behringer: Defined a more involved three level model of defining the issue and then defining remediation and then defining the operator features to remediate. BF: Is this proposed BOF and WG about defining capabilities for devices. SB: Is this about device requirements? yes. This is about the capabilities of devices rather than procedures. If this room wants to do more than boxes then that is reasonable to propose. Given the history then that is not what has been proposed BA: So we should change the title of the proposed WG to Operational security of IP devices Ross; There are three things that various people or groups could in principle do: (1) We could talk about the threat models. (2) There are capabilities of devices. (3) Then there is if you have these threats and you have these capabilities how an operator could improve security and mitigate threats. I am interested in doing the second. If people want to work on the first or third then we can discuss this. The capabilities described in George's document are based on operator experience, which in general means that they are based on problems which have occurred. It should not be too difficult to add a bit more text outlining briefly what the problems are. BF: We need to be clear to the IETF community what the WG is about. As Steve described it. SB: If you have a better title please send it to list. There is precedence for the IESG to request a change in name before chartering a working group. ??: I have heard "we all know the threats", do we really know the threats? GJ: Lot of this was coming from an assumed threat model. But we could agree that delivering products without certain features (eg, logging or authentication) is wrong. Ross: We should recognize that threats can change. The title "best current practice" includes the term "current". Implicitly a BCP can change over time, as will the threats. ??: You can always set limits on the threat model. There is always benefit in brainstorming new ideas and wind up with new insight that you did not have before. Ross: As a parallel effort that could be accomplished in a fixed time that may be interesting. If there is a proposal? It needs to be documented. MB: If we do a threat model we need to define what is the trusted space/ the port? A component? The chip? As an example, is the operating system on the router trusted? We need to document these assumptions before we could get started. ??: If we are trying to look at too much, it could take years of work. GJ: Polls: We are seeking to charter documenting capabilities in devices. Is that reasonable? Yes: Medium small number. No: Very few (couple of people) How many want to see more work done of the threat model. Yes: Medium small number. No: About half of the medium small number. Elliott Lear (EL): Do we have volunteers to work on a threat model? (a few hands went up to volunteer). ??: What threat model? What is the topology the threat model would be built around. GJ: Assuming that we add a threat model do we include proper use of features in the BCP? Hank M: Are we writing best practices or documenting features? SB: This BOF was intended to be aimed at "knobs for boxes' Should this group also produce a doc saying how to use the knobs to secure the network? Tony Li: No threat model. Wants a practical list of threats. Send something to NANOG today. Tell us what the threats are, what knobs alleviate those threats, and delver that so operators can use that to acquire product. MB: Operational requirements should result in features. Not features driving operational requirements. ??: Are knobs and features what is being discussed here? GJ: What is intended now are requirements and how to meet those requirements. BF: BCPs are usually about how to use a feature not on how to solve a problem. SB: I don't see a conflict. This isn't a proposed requirement. We are aiming at something more general. ??: It would be useful to describe an operational practice and then say it is best done using this capability or feature. TL: Is the primary purpose of this WG to educate operators? GJ: No. It is to collect the scattered wisdom of the operator community and make it relevant to a larger audience. Greg Lebowitz: Is this limited to SPs or SPs and network operators? GJ: SPs and others. ??: I got involved because we wanted to educate..., I was thinking mostly to educate smaller ISPs and enterprises. I think that they need the most education. Review of the Goals Statement There was some discussion about add the word "educational". Another sentence was proposed specifically stating "educational" but could not be agreed upon. Co-chairs of the BOF: gmj@pobox.com rcallon@juniper.net Mailing List: Opsec@ops.ietf.org To join: Opsec-request@ops.ietf.org Wrap-up How many people think we should continue to WG ? For: a little more than 20 Against: 4 |