Minutes of Operational Security Requirements BOF (opsec) Tuesday, March 2 at 0900-1130 CHAIR: Ross Callon <rcallon@juniper.net> SCOPE draft-jones-opsec, which has been proposed for BCP, is somewhat controversial. Some people claim that its focus is too narrow, or that it mandates functionality that is not yet available. This meeting will consist of a focused discussion by a panel of reviewers. The issues to be considered include: Should this document, or some successor, be published in more or less its current form? What status should the document have? Is there a need for other, related documents, such as operational security requirements for enterprises? What venue is best for developing this or related documents? How do we get participation by operators of all sorts? AGENDA and INTRODUCTION Ross Callon presented the agenda. - Introduction (Steve Bellovin) - Overview of Questions (Ross Callon) - Viewpoints (Panelists) - Open Discussion Elliot Lear agreed to be the "jabber scribe" in order to allow George Jones and others who were unable to attend the ability to follow the BOF and comment remotely. Thanks to Elliot (via the transcript of the jabber session) and Kurt Erik Lindqvist for the minutes. Steve Bellovin (as IESG security Area Director) gave an introduction to the BOF: The BOF is intended to determine what to do with the internet draft "operational security requirements for IP Network Infrastructure" (as published as internet draft <draft-jones-opsec-03.txt> and discussed on the opsec@ops.ietf.org email list). This draft started as an internal UUnet document. Randy Bush and Steve Bellovin watched George Jones present this at a NANOG meeting, and felt that this would be a useful IETF document. The document has since gone through several reviews, and was submitted to the IESG with the intention that it be published as a "Best Current Practice" RFC. The IESG vote resulted in 7 "discuss" votes plus one abstention. This is a large number of "non-yes" votes, and is a strong indication that further discussion and/or review is needed before a decision can be made. As a result of this, a panel has been asked to review the draft. The panel will present their views at this BOF. We will then have an open discussion regarding what if anything to do to progress the draft. Ross Callon presented a list of questions which it was hoped would be answered or clarified by the BOF: > Is there a problem? Are we in agreement that there is a need for improved operational security work to improve the security of the Internet infrastructure? > Is this a useful direction? Should this document, or its successor, be published in approximately the current form - with appropriate updates and corrections? > What status should the document have... - If published in very close to its current form. - If fully vetted by an IETF process and appropriately updated. > How long do we think that it will take to get it to a form which would be appropriate for BCP? (the thought being that if we could get it into BCP shape in a few months, then it might not make sense to publish as an informational draft first). >Is it obvious how the requested capabilities would be used? or do we need some sort of framework? > Is there a need for other related documents, such as operational security guidance for enterprises, for SOHO, or for other types of devices (such as servers)? (the point of these last two questions above is to determine whether there are any other documents which we should also be working on). > What venue is best for developing this or related documents? > How do we get participation by operators of all sorts? VIEWPOINTS BY PANELISTS Each of the panelists was then asked for his opinion: Fred Baker My take on this is that this document addresses something rather different from what the IETF has called security. It doesn't talk about how to configure of set up IPsec for instance. It comes to the IETF as a recommendation from UUnet on how routers can be more useful from a security perspective. I would like to see something along this line. It provides good guidance to router vendors. It don't care whether it is a BCP or an informational RFC. I see fairly practical suggestions. By whatever means this may be published I am interested in the suggestions. Pekka Savola We operate a national and research network, and I have reviewed the document several times. This document presents very good ideas, and it should go forward in some form. There is concern about what is specified as MUST versus SHOULD in a best current practice document, about what an operator or vendor MUST or SHOULD do. I don't see many problems there myself. Perhaps the document should be more of a list of features that operators should ask for, as opposed to a specification of requirements. Vendors could then indicate what sections they support. George Jones (commenting over the Jabber session): The current draft contains a "profile" mechanism that allows different lists of features to be specified. This can be used to clarify what should be supported in products. Dave Meyer (commenting on Pekka's statement): Generally agrees with Pekka. However, there are several situations in which the document says essentially "one MUST not write bugs or poor implementations". This seems like an odd thing to write in a requirements document. As an example, in one location it states that counters MUST be accurate. Steve Bellovin: Accurate counters are important from a security perspective. Dave Meyer: The question was more around whether the 2119 language (MUST, SHOULD, MAY) is the right way to express this. Ross: This is a very reasonable issue to discuss, but first we need to figure out what to do with the document. Pekka (responding to George's comment via jabber, therefore returning to the issue of profiles): There are two problems with profiles... First, when you say you do sections 1,2,3 or whatever, it's a matter of what is conformant behavior as to what the vendor has actually implemented between MUSTs and SHOULD. Second, there has been some pushback about having IETF-blessed minimum secure routers. Perhaps two documents are appropriate, one with default profiles or discussion of tradeoffs Steve: So you would propose one informational document, and a set of BCPs for profiles?? Pekka: yes Ross: Regarding IETF-blessed descriptions of what routers should do: There is a precedent in terms of the requirements for IP routers (RFC 1812). This took quite a while to work out and may have resulted in a lot of gray hair based on lots of negotiation, but there is precedence for the IETF to do this. Pekka: A critical issue is whether MUSTs and SHOULDs will cause excessive amount of time in negotiations. Thus creating feature lists may provide a simpler way forward. Dan Romascanu This document is badly needed. We have customers already referring to this document. This proves that such a reference from the IETF is both needed and taken quite seriously. I've made comments, some of which have been addressed by the author of the document. We need to be careful about making a distinction between service provider and enterprises. Don't try to put everything in one document. Instead it would be better to create a separate doc for enterprise networks. The document in its form right now sometimes says too much, and in some cases it says less than it should, It says too much about op reqs not connected to security requirements (for example, in its discussion of RS232). The document should be more focused. George: At one point the scope was expanded beyond large ISP networks...it became unmanagably large. Dan (continuing): The more focused the effort, the more chances of success I am not sure about format, but I would like a focused fast track process. Host requirements and router requirements are valuable documents in the industry. This is an opportunity for a long lived process. Editing line by line is a very valuable process, but a good focused document shipped earlier would be fine too. It would be wiser to start with an informational document earlier and perhaps do a bcp later. Coming directly as a BCP originated by one author might in fact have less impact. George: Agrees that this should be a process, the start of a discussion. Dave Harrington I come from the management area. My impression is that this is a very valuable document. I had to hold my engineers back because it wasn't ready yet. This is a very valuable doc, but the document requires thorough review. We should publish this sooner as an informational, and then follow it up as a BCP. I am concerned about language and use of RFC 2119 MUSTs and SHOULDs. In order to publish as an BCP, we need to check the document carefully to make sure that it actually matches the best current practices. George: One idea that was floating earlier was that the entire doc could be a "shopping list" which *each customer* could pick items from. In this case *everything* would be a SHOULD or MAY with each customer filling in the MUSTS. This concerns me, as it would not be very strong. Dave: For security to work all pieces are needed and need to work together. Dave Meyer Agrees with what has been said by other panelists. The one comment in addition to what others have said was what he said earlier, that the document shouldn't say in essence "vendors should not implement bugs". Ross Callon I will go through the questions quickly. I agree with Fred that this document covers areas that perhaps are not what the IETF normally means by "security", but that need to be covered to make internet infrastructure more robust against attack. This is a useful direction. If the document is published as is, it should be informational. There are lots of good points, but a few things one could question. Thus it is not quite ready for BCP. In terms of the timeframe for producing a BCP, I have changed my opinion while listening during this session and have realized that it might take a year or more to complete a BCP based on the issues raised. No one answered the question about whether it is obvious how these capabilities would be used. I don't know whether we need a framework to show how these features would be used. I agree with separation of enterprise and service providers. Clearly SOHO would require a different document, if we were to work on it at all. I'm not sure whether we want to work on separate documents related to security for SOHO or for servers. if nobody volunteers to do the work it won't happen. Regarding the venue: Taking on the long term talk of producing a BCP document seems to indicate the need for a working group. OPEN MIKE Paul Hoffman: If we don't work on this, then someone else is going to do this work. There are bureaucrats who are willing to do this elsewhere, but it will not be of the quality of what we could do. We shouldn't do anything at a lower level than enterprise, and even enterprise is questionable. We in general do a poor job on SOHO advice. We do a somewhat reasonably job with very intelligent enterprise operators, but that's about it. So I vote for one document that is aimed at core operators George Jones: Getting active operator involvement has been one of the biggest goals and biggest frustrations at this process. Half seriously: if you want operator involvment, hold the WG at NANOG. Chris Lonvick: TL276 has gone out of the T1 ANSI commitee, and is now in the ITU SG3. It has different roles, including requirements of operators. This has a very serious telco slant. I would like to see this document used to balance that document as a contribution to that process. I think that overall a working group effort to look at the "punch list" would be a good thing. Steve Bellovin: Are the ANSI/ITU concerned with procedures as well as features? Chris: yes Steve: Should the ietf go there as well? Chris: I haven't really formed an opinion yet, but probably not. But it would be good for ietf and nanog participants to look at the work going on in ANSI/ITU. Bill Sommerfeld: I have a clarifying question to Paul Hoffman: Regarding the coment of don't target to enterprises/SOHO, I think it would be useful for vendors to have something building boxes for that space so that they get the defaults right. Paul: Yes it would. it is not clear it should come from the ietf or from this group. Vendors would like something that is very very simple, but that's not what this is and that's a good thing because core routers are not simple. Scott Hollenbeck: The document needs a history section discussing the document's origin, and it should be an informational document. David Black: With suitable disclaimers it's okay to use RFC 2119 in an informational document.With a little more soak time this could be a BCP. Regarding RFC 2119 terminology, we could add some words to the beginning of the document to get an informational out, and then remove them when it goes BCP. CONCLUSION Steve Bellovin: I would like to poll this room on a few questions. Should the document be published in substantially its current form? Consensus: yes (unanimous) Steve: Who wants it to be BCP? Who wants is to be informational (in its current form)? (Show of hands, Strong consensus for Informational in the current form) Steve: Next question: do we want follow-on docs? (Show of hands, Strong consensus for YES). Steve: Do we want a working group? (show of hands, strong consensus for YES) Steve: What sort of docs do we want to deliver? Do we want general strategy to be list of features in one doc and a separate set of profile docs? (show of hands, not very many people voting, not a lot of opinion, and only a small majority for features in one document and a separate set of profiles). Fred Baker: In the work on RFC 1812 as that started out, Jim Forster got 300-400 experts in the room and got some fairly large amount of text that took a long time to make it readable. If we were to do it again, it would take 10-20 docs, and not one. We need to keep it on focused statements on focused issues. George Jones suggests a framework, plus a series of reqs docs (what's needed), companion how-to-now-BCPs for each platform. Steve: So you're suggesting much smaller chunks. Fred: Yes. Chris Lovich (I think): The work of the network reliability and interoperability council work may prove interesting. Steve: Who likes Fred's idea? (show of hands. Theres was strong consensus from those who indicated a preference, but only a small number of people responding) Pekka: Not sure we could find reasonable scenarios, so that might be a considerable task. we should analyse this question more first. Thus it is hard to answer today what the output documents should be. Steve: Yes, it is indeed a hard question or set of questions. Steve: It is premature to have a room full of people try and draft a charter. We need to discuss this more on the mailing list but there is considerable agreement: I hear that this issue is important, and that we (the IETF) need to get involved, and we need to work with other documents. This is not going to be an easy task. Dave Harrington: I have one concerned about Fred's approach: We need to make sure that the pieces fit together properly, so a framework is appropriate. Fred: I agree. (George agreed on the jabber link). Steve Bellovin: All IESG evaluations are on line in the public tracker. This will provide you with concerns iesg members have. (Ross navigated to the site, and displayed it on the projector; see https: //datatracker.ietf.org/public/pidtrac ker.cgi?command=print_ ballot&ballot_id=1200&filename=draft-jones-opsec, or follow links from the IETF Web page, to the working group chairs web page, to the Internet-Drafts Status Tracker, search with a filename of "draft-jones-opsec".) Eliot: Do you want to ask area directors present at this meeting to discuss their comments? Steve: Many of the comments have already been addressed and there will be a new version of the document out soon. Meeting adjourned. |