Final pass on BOF issues for -01

[George Jones <gmj@pobox.com>]

Below is the final pass/feedback on the BoF issues for -01.  Also
includes a summary of USENIX securtiy symposium BoF on logging
(relevent to/overlap with opsec).

The work-in-progress draft is available at

    http://www.port111.com/opsec/draft-jones-opsec-00a.txt

speak SOON if you want to see something changed in -01

---George

> OPSEC BOF - Operation Security Requirements for
> IP Network Elements Session
>
> 17 July 2003, IETF #57, Vienna
>
> BOF Lead: George Jones, MITRE
>
> Base document:
> Individual Submission "draft-jones-opsec-00.txt"
> dated 9 June 2003
>
> Area Directors:
> Randy Bush, Operations & Management Area
> Steve Bellovin, Security Area
>
> [[Note takers: Chris Lonvick and Neal Ziring]]
>
> [[meeting started about 13:05]]
>
> WH: current draft lists minimal and conditional security
>     requirements, ok.  Need to make sure draft sticks to
>     security reqs and doesn't branch off into other arenas.

Please point out areas you think it is off topic.

>
> PS: (Pakka Solva) Separation of mgmt and data planes in the
>     draft is confusing; in practice there is always some
>     crossover.  Nice goal though.

I think a lot of this confusion came from the assumption in -00
that you have an out-of-band management solution for all devices.
-01 allows for either in-band our out-of-band mgt and seperates
the requirements.  I think this will clear up a lot of the confusion.

> PS: Regarding requirement to filter all traffic THRU the
>     device: how to implement?  Most devices filter into and/or
>     out of interfaces.  confusion ensued - eventual result:
>     effective interface filtering can satisfy this; GJ to fix
>     wording for -01 draft

Reworded example.

x.x.x Ability to Filter Traffic Through the Device

   Requirement. It MUST be possible to apply the filtering mechanism to
      traffic that is being routed (switched) through the device.
   .
   .
   .
   Examples. One simple and common way to meet this requirement is to
      provide the ability to filter traffic inbound to each interface
      and/or outbound from each interface. Ingress filtering as
      described in [RFC2827] provides one example of the use of this
      capability.

>
> BF: (Barbara Frasier, Cisco) If this doc goes through IETF,
>     what about conflicts with existing RFCs?  Are there any?
>     GJ: admits yet.  BF: resolution?  GJ: not sure, there
>     are warnings in the document
> RB: (Randy Bush) Update that section of the [other] document,
>     or obsolete that portion of the document
> SB: (Steve Bellovin) This may be good to update old-time RFCs
> PX: (Piotr) When this updates the old RFCs, that should be
>     carefully noted in the document
> PS: would prefer that revisions to other RFCs appear
>     in some other document.  GJ: we'll make a list
>     and take to ADs for guidance

Known conflicts/updates are listed in the "Warning" section of
each requirement section.

>
> WH: What about scope,  Core devices or edge devices?
>     GJ: answer - needs to be decided [see also below remarks by MK]
> WH: worried about intro of current draft; does it
>     describe scope accurately?  GJ: needs polishing

See previous post to opsec list about changes to the front matter/scope.

Short version:  scope is managed IP infrastructure of large networks,
excludes hosts and special purpose devices

Scope may include wireless and SOHO/CPE if managed, but will require
extra requirements/profile work.  Waiting on contributions of
requirements and profile definitions such devices.

>
> BS: (Bill Somerfeld, Sun) Vendors will have trouble
>     with 2.3.8.  No vendor could comply with
>     2.3.8, it is too hard as written.  GJ: admits that
>     2.3.8 needs work.  BS: it is also a moving target!

OK.  I've reworded the requiremnt, changed it to a SHOULD,
and moved it to the (new) assurance (not functionality) section.
The new text is below.

I know we're going to have disagreements on this one, but having
a box not fall over due to well known exploits is a pretty basic
user requirement, so I'm not going to drop it out/split it off
without at least further discussion.

x.x Ability to Withstand Well-Known Attacks and Exploits

   Requirement. The vendor SHOULD provide software updates or
      configuration advice "in a timely fashion" to mitigate the effect
      of "well know vulnerabilities" in the device itself and "well
      known exploits" directed to the device.

      For the purpose of this document, well-known vulnerabilities and
      exploits are defined as those that have been published by the
      following:

      ...bugtraq postings deleted...

      While "in a timely fashion" is open to interpretation, one
      measurable, customer-centric metric is "before the vulnerability
      is exploited in my device causing loss of confidentiality,
      integrity or availability".

>
> BS: For 2.3.1, need to strengthen some SHOULDs/MAYs
>     into MUSTs, some reqs too big as written
> GJ: agree we need to split some reqs; also need
>     more emphasis on testable reqs.

x.x.x Comply With Relevant IETF RFCs on All Protocols Implemented

   Requirement. The default configuration of the device MUST fully
      comply with IETF RFCs for all protocols implemented.  "Compliance"
      is defined in terms of [RFC2119].   The device MUST conform to the
      absolute requirements.  Any optional or recommended functionality
      implemented MUST be in conformance with the RFC.  The device MAY
      provide means by which it can be configured in ways that are not
      compliant with the RFCs (for instance, if conformance is
      determined to be insecure).

>
> BS: what about risk analysis, has it been done?  Doc needs a
>     solid basis in this, otherwise it could end up unbalanced
>     [GJ and BS discussed whether to do risk analysis in current
>     BOF session, decided not to do so, but GJ agreed one needed
>     to be done.]
>
> EA: (Emir A. from Cable&Wireless) believes most risks for
>     core and edge routers well-understood, but still
>     should be written down.
>     [later, volunteered to send grad school research
>     on this topic to group]

I added a section "Goals of Security" which states some things
that were implicit about what the document was trying to do:
keep network elements available and managable.

I would welcome contributions to a more formal risk analysis/
threat model.

>
> GJ: reviewed IP stack and filtering requirements...
>
> PS: regarding requirement for logging filter hits:
>     what happens when link to log server fails?
>     discussion ensued...
>     NZ: in many CC Profiles, inability to log tied
>     to device shutdown -- no desirable to core router
>     PS: suggest queuing logs for later transmission?

For now, stop-on-log-failure is being left out: #1 goal
for core/edge is to keep passing packets.

There was a long discussion at the USENIX security symposium
BOF on logging run by Tina Bird (with about half the time
spent listening to Marcus Ranum explain various ideas for
parsing and classifying log events.).

Short version: there was general agreement that the information
that different vendors choose to log varries widely and is incomplete.
There was also agreement that the lack of any standard formatting
of messages and fields makes log analysis an art at best.

There appeard to be two lines of thought about what needs to be
done to improve the situation.

One camp (Marcus being most vocal) seemd to be of the opinion the most
useful path was to write tools to deal with the infomation that is
there now...don't bother trying to standardize what gets logged or
influence vendors/standards...  just code it up now usin the data
that's available.

The second line of thought was that it makes sense to try to
standardize what gets logged, and to do it incrementally.
There has been some work done on firewall logging that may
be mature enough already to easily standardize.

For the current opsec work, I think it makes sense to have a
"SHOULD" requirement listing in general terms what to log,
and to start up related efforts (WG ?) to define specific
list of things to log.

> PS: regarding requirement to list all log messages in
>     documentation: does ANY vendor do this?  Could be
>     nice, though.  GJ: No vendor seems to do this

I'm told (by a Cisco person) that there is a complete list
in the PIX documentation.  For now, I'll leave this a SHOULD.


> GL: (Greg Lebowitz) need better definition of
>     "log messages" in the draft  GJ: okay, will do
> PS: definition of 'events' that generate messages
>     might be nice (possibly re: 2.11.1 ?)

This will be unchanged in -01 ... I will get ahold
of Tina Bird/etc. to get a reasonable set of suggestions
for -02.   I will also work with people interested in
starting work to define explicit sets of minimum things
to log.

>
> [several questions and some discussion about req 2.11.6
> "Ability to configure security of log messages", draft
> definitely needs clarified title and body for that one]

This requirement has been removed for now.   It was ill-defined.

>
> PS: regarding requirement to 'classify' events and log
>     different ones differently (2.11.9), does any vendor
>     allow this now?  Might be nice though.
>     GJ: No, don't think any do this yet
>     [Some other audience member remarked that a Firewall
>     vendor consortium is considering this: turns out to
>     be a hard problem.]

Removed for now.

> PS: Regarding conflicts, current draft as written can't
>     be a BCP, if this document becomes a BCP RFC it
>     will not be able to update old RFCs.  (cf. Barb
>     Frasier's question earlier)

         [RFC2644] "Changing the Default for Directed Broadcasts in
         Routers" is a BCP and does this.