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

From: "Jones, George" <[email-masked]>
Date: Thu, 27 Dec 2007 10:25:38 -0500

I will point out that the benchmark 
Methodology WG exists.

---George

----- Original Message -----
From: Smith, Donald <[email-masked]>
To: opsec wg mailing list <[email-masked]>; [email-masked]
<[email-masked]>
Sent: Wed Dec 26 13:23:06 2007
Subject: RE: [OPSEC] charter skeleton rev4 - your thoughts requested...

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

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

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.

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