2.6.6 Operational Security Requirements (opsec) Bof

Current Meeting Report

Minutes of Operational Security Requirements BOF (opsec)
Tuesday, March 2 at 0900-1130

CHAIR:  Ross Callon <rcallon@juniper.net>


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?


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 

> Is this a useful direction?
Should this document, or its successor, be published in 
approximately the current form   - with appropriate updates and 

> 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? 


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 

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 

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 

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 

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 
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 

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 

George: Agrees that this should be a process, the start of a 

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 

We should publish this sooner as an informational, and then follow it up as a 
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 

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 

Regarding the venue: Taking on the long term talk of producing a BCP 
document seems to indicate the need for a working group. 


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 

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 

Steve Bellovin: Are the ANSI/ITU concerned with procedures as well as 

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 

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 

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.


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 

(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 

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 

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 
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 

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. 


Questions for Op Sec BOF -- General