Subject: [OPSEC] charter skeleton rev4 - your thoughts requested...

From: Joel Jaeggli <[email-masked]>
Date: Tue, 25 Dec 2007 23:17:37 -0800

This version incorporates comments from:

Ron Bonica
Tom Petch
George Jones

References to the previous charter have been eliminated.

----

Goals:

The OPSEC WG will document best current practices with regard to network
security. In particular an effort will be made to clarify the reasons
behind current operational practice, address gaps in currently
understood best practices for forwarding, control plane, and management
plane security and make clear the liabilities inherent in security
practices where they exist.

Scope:

The scope of the OPSEC WG is intended to include the protection and
secure operation of The Forwarding, Control and Management planes.

Documentation of best common practices, revision of existing practices
documents and proposals for new approaches to operational challenges are
in scope.

Method:

It is expected that most of the work product of the working group will
fall into the category of current practices documents. Taxonomy or
problem statement documents may provide a basis for best current
practices documents.

Best Current Practices Document

A single document will be produced that attempts to capture
current practices related to secure operation. This will be
primarily based on operational experience. Each entry will
list:

* threats addressed,

* current practices for addressing the threat,

* protocols, tools and technologies extant at the time of 	
writing that are used to address the threat,

* the possibility that a solution does not exist within existing tools
or technologies.

Taxonomy and Problem Statement Documents

A document which attempts to describe the scope of particular
operational security challenge or problem space without necessarily
coming to a conclusion or proposing a solution. Such a document might be
a precursor to a  best common practices document.

The work product of the working group is intended principally for the
benefit of network operators rather than equipment vendors or protocol
developers.

Non-Goals:

The Operations security working group is not the place to do new
protocols or requirements documents.

New protocol development or requirements work should be addressed in a
working group chartered in the appropriate area or as individual
submissions. The OPSEC WG may take on documents related to
the practices of using such work.

_______________________________________________
OPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/opsec

---

From: Ron Bonica <[email-masked]>
Date: Wed, 26 Dec 2007 12:43:28 -0500

Joel,

This looks very good. I have picked a few nits below, but they are all
grammar issues.

The one thing that we are lacking is a list of deliverables. I think
that we have reached agreement on an ICMP filtering document. Can we
think of any others?

                             Ron

> behind current operational practice, address gaps in currently
s/reasons behind/rationale supporting/
> secure operation of The Forwarding, Control and Management planes.
s/The Forwarding, Control and Management/the forwarding, control and
management/
> It is expected that most of the work product of the working group will
s/most of//
> fall into the category of current practices documents. Taxonomy or
s/current practices/best current practice/
> A single document will be produced that attempts to capture
s/A single/For each topic addressed, a single/

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 26 Dec 2007 11:23:06 -0700

We may want to include testing methods and processes.
This would be more of a framework then an actual step by step testing guidance.
 
For example:
Recommending a specific ICMP rate limiting level without discussing how to test the network elements that the rate limits would be applied to is likely to lead to operations issues.
In testing things like that I usually try to discover how many pps of a specific packet type causes a certain level of cpu or other limited resource exhaustion/consumption.
 
With out that type of testing how can anyone estimate much rate limiting is required before a network element is protected well enough to continue it's primary functions.
 
Most of us could agree  "An attack that was consuming 50% of the cpu would cause our routers to drop legitimate management and control traffic and therefore any type of packet that at a specific rate of pps causes >50% cpu consumption should be dropped."
 
An alternate approach would be to see pps of certain types of packets as they exist in your network today and base your rate limiting on that information. However I think that is much harder then finding the "performance impacting level" of a device and rate limiting to some acceptable performance level.
 
One issue with this is you may have to test to the I/O card levels, IOS levels, etc...
 
It would be helpful if vendors would actually make reasonable suggestions in these areas but from past experience I don't believe they will. They are very reluctant to tell any "performance impacting levels" for any specific type of packet/protocols.
 
It would be helpful if vendors at least documented their default rate limits especially those that are hard coded and not configurable.

[email-masked] giac

________________________________

From: Joel Jaeggli [mailto:[email-masked]]
Sent: Wed 12/26/2007 12:17 AM
To: [email-masked]
Subject: [OPSEC] charter skeleton rev4 - your thoughts requested...

Ron Bonica
Tom Petch
George Jones

----

Goals:

Scope:

Method:

* threats addressed,

Non-Goals:

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

---

From: John Kristoff <[email-masked]>
Date: Thu, 27 Dec 2007 07:46:37 -0600

On Wed, 26 Dec 2007 11:23:06 -0700

> Recommending a specific ICMP rate limiting level without discussing how to test the network elements that the rate limits would be applied to is likely to lead to operations issues.

Even still there are likely going to be problems in some configurations.
Just as a for instance, if you rate limit to 1 Mb/s at each edge, and
also have the same limit somewhere upstream, any one edge can fill that
upstream limit.  Probably not what you want.  Very tricky to codify hard
and fast rules here.

John

---

From: Merike Kaeo <[email-masked]>
Date: Thu, 27 Dec 2007 11:32:36 -0800

Agree with the hard to codify.  But I'd be willing to explore more  
what makes sense for performance testing and could be reasonable to  
codify........performance limitations are always a pain since no  
vendor will ever want to disclose limitations..........note that in  
1993/1994 I was responsible for performance testing for a major  
router vendor........the games I saw.......sigh.

But as George pointed out, this sort of performance benchmarking work  
really does belong in the benchmark methodology wg.   I participate  
in that wg......happy to help if needed.

- merike

On Dec 27, 2007, at 5:46 AM, John Kristoff wrote:

>> Recommending a specific ICMP rate limiting level without  
>> discussing how to test the network elements that the rate limits  
>> would be applied to is likely to lead to operations issues.
>>
>

---

From: George Jones <[email-masked]>
Date: Fri, 28 Dec 2007 08:05:35 -0500

> that we have reached agreement on an ICMP filtering document. Can we

Talk to Tina Bird about logging.   I think she's actively hacking her wiki
aimed a the "What is being logged/what should be logged" question.

Also see the skeleton that I just sent you about creating a list of 
vulnerabilities
in common ports....think a very abbreviated IANA ports list  with cross 
reference
to to vulnerabilities lists (CVE?)...kind of a security hitchhikers 
guide to ports.

---George

---

From: Danny McPherson <[email-masked]>
Date: Fri, 28 Dec 2007 07:35:47 -0700

> practices where they exist.

What does that mean, "make clear the liabilities inherent in
security practices where they exist"?  Are you talking about
gap analysis there or something else?

> Documentation of best common practices, revision of existing practices

s/existing practices/existing operational security practices/

> current practices related to secure operation.

I'm a bit confused by the "a single document" bit here, what
do you mean by this?  A single document for each threat set,
each 'plane', or something else?  And either way, why would
we unnecessarily scope to a single document?

> This will be

Could 'extant' be augmented with envisioned here?  Given the
'Scope' section above, 'proposals for new approaches' are
explicitly within scope.

> benefit of network operators rather than equipment vendors or protocol

I'm not sure the above sentence actually holds true.  I believe
that by compiling a list of functions or BCPs that seem to be
common among WG participants, operators in particular, that
'equipment vendors' benefit from the output of that document
by knowing where to focus, with referencable discussions and
WG product.  I suspect this text is perhaps aimed more at
encouraging operators to participate, but it'd seem to me this
should be implicit already.

> the practices of using such work.

I think it's perfectly reasonable (desirable?) for OPSEC to provide
requirements to other WGs, be it folks like BMWG or folks designing
protocols.  Perhaps the above text should allude to this.

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 28 Dec 2007 11:01:24 -0700

I agree the testing methodology probably  belongs on the benchmarking group wg. However in order to arrive at a non-production impacting level of ratelimiting some mention of testing should be made here too.
Ideally we would be able to point to a document that described the testing methods and goals that is being done by the benchmarking WG.
The closest document I see to that right now are the stress testing documents.

From: Merike Kaeo [mailto:[email-masked]]
Sent: Thu 12/27/2007 12:32 PM
To: opsec wg mailing list
Subject: Re: [OPSEC] charter skeleton rev4 - your thoughts requested...

- merike

---

From: George Jones <[email-masked]>
Date: Fri, 28 Dec 2007 16:53:14 -0500

> The closest document I see to that right now are the stress testing documents.

RIght.

I talked to Scott Poretsky about these a while back and gave some input.

We should defiantly  get their input on the charter and  testing  
aspects of documents.

---George

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 30 Dec 2007 09:16:11 +0100

> -----Original Message-----
> From: Danny McPherson [mailto:[email-masked]] 
> >
> I'm not sure the above sentence actually holds true.  I 
> believe that by compiling a list of functions or BCPs that 
> seem to be common among WG participants, operators in 
> particular, that 'equipment vendors' benefit from the output 
> of that document by knowing where to focus, with referencable 
> discussions and WG product.  I suspect this text is perhaps 
> aimed more at encouraging operators to participate, but it'd 
> seem to me this should be implicit already.
> 

I agree with Danny here. While the principal input of the Working Group
are operational experience and needs, the output should be I think
directed both to provide guidance to the operators community as well as
to Working Groups that develop protocols or the community of protocol
developers at large, as well as to the implementers of these protocols,
many of them working for 'equipment vendors'. 

Dan