Prelimary BOF meeting notes

[George Jones <gmj@pobox.com>]

Below are the preliminary BOF notes for the proceedings.  Let me know
in the next day or two if there are any gross inaccuracies that need
to be corrected.

Discussion/clarification (on list) would also be fine.

Also, for the record, the main presentation is available at
http://www.port111.com/opsec/opsec-bof.ppt and Chris Lonvick's
presentation on ANSI/T1M1 is at http://www.port111.com/opsec/t1.pdf

---George Jones

---------------------------cut here--------------------------

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

GJ: welcome, introduced session --
    emphasis for this work is to write down solid req.
    for "what knobs we need on network devices in order
    to make them secure".

GJ: walked through agenda, no changes from audience

GJ: asked:
	- who has downloaded draft?  [most? over 2 dozen]
	- who has read the draft? [fewer, but still quite
	  a few, more than a dozen]
	Survey of room: about 1/3 vendors, 1/3 operators
	or service providers

GJ: listed some resources that were background to this
    draft: security testing work at UUNet and ANSI T1M1
    committe were biggest.  Common Criteria may also
    be useful.

GJ: end game is to get device makers/vendors to sell
    devices that have the knobs we need to secure
    our networks (install, deploy, operate, maintain)
    More goals: aid operator-vendor communication,
    guide testing of products in labs

    Mechanism to use: publish document.  Note that
    correct IETF track/area needs to be chosen carefully

GJ: Review of Goals:
    discuss draft's contents/structure, discuss IETF
    way forward [invited audience to bring forward
    other related work, or to become contributors]

GJ: review of history and current status of the draft;
    originally grew out of UUNet security lab product testing,
    some coverage at IETF #55 and #56.  While at UUNet, GJ and
    colleagues got tired of hearing "but you're the only ones
    who want feature XYZ" from vendors.  This effort will go
    toward concensus on what features are needed.

GJ: Large-net-scale requirements scale down better than
    small-net requirements scale up -- therefore current draft
    concentrates on requirements of large networks (ISPs, big
    provides, telcos)

GJ: Scope is still under discussion, but can't let it
    get too broad or we'll never finish.

GJ: Recent changes to the draft (prior to -00) included
    breaking monolithic set of requirements into a set of
    'device profiles'.  (idea by Merike Kaeo)

GJ: There are major tensions in the requirements
    set (evident from discussion on mailing list).
	1. cryptographic v. physical separation
	   of control and data planes
	2. requirements that are BCPs versus
	   requirements that push the envelope
	3. lack of published specifications for a
	   few areas, including IETF XMLCONF and SYSLOG WGs.
	4. overlap, repetition, harmonization
	   with related work, esp. ANSI T1M1.
	5. Draft is getting big -- how to reduce?
    For requirements that are "way out there", might be
    preferable drop them and refer them to IRTF for analysis.

GJ: [long discussion of scoping of document, no particular
     resolution, generally scope toward large-scale deployments]

GJ: Reviewed related work:
	1. IETF work: psamp, Netconf/XMLCONF, Syslog
	   ForCES, CCAMP?
	2. Non-IETF: ANSI T1M1 T1.276.

GJ: introduced Neal Ziring from US DOD, for brief
    overview of International Common Criteria

NZ: (Neal Ziring, US DOD) CC is a standard, ISO 15408, that
    describes how to write security requirements for IT
    devices, programs, systems, & products.  Allows for
    official certification of equipment that meets criteria;
    administered by nat'l programs of signatory countries.  US
    program is called NIAP.

NZ: Two kinds of requirements in CC: functional requirements
    (what the device has to do) and assurance requirements
    (how you know that is meets the functional requirements)
    Most of GJ's I-D is functional requirements, with a few
    assurance ones.

NZ: Two kinds of CC documents: Profile and Target.
    (properly, "Protection Profile" or "Security Target")
    Profile describes desired security functionality and
    assurance (such as a firewall, etc.)  A Target
    describes an actual product or system (such as
    Product XYZ from Company A).  The goal is to have the
    product evaluated by an accredited lab and that
    evaluation [actually, evaluation passed result and
    Target] published.
    This I-D (draft-jones-opsec-00) is like a profile.

GJ: introduced Chris Lonvick from Cisco, a
    member of ANSI T1M1 committee and IETF Syslog WG chair

CL: (Chris Lonvick, Cisco) T1M1 committee deals with
    management plane in telecomm systems; much concerned
    with the security of the management plane.
    (T = telecomm, M = management)

CL: discussed background of T1 committee and
    M1 subcommittee, and their goal for the T1.276
    standard: "ensure common minimal baseline for
    security features in the management plane for
    network elements".

CL: reviewed nature of ANSI standards and relation to
    ITU, with comparison to unofficial status of IETF

CL: reviewed ANSI T1 business case for improving
    security in the management plane.  One
    important motivation was convergence of data
    and management planes in telecomm architectures.

CL: reviewed T1 standard network management reference
    model (see diagram in CL's slides)

CL: T1.276 should be a US National Standard by later July.
    Also submitted to ITU-T Study Group 4, and
    to NRIC IV Working Group 1B.

CL: discussed mgmt and composition of T1M1 committee, and
    general concensus and voting on T1.276.  Good consensus
    from vendors and operators in favor of T1.276.
CL: Gave URL where to get a copy of T1.276 draft (see slides)

CL: reviewed basis of T1.276 requirements:
	1. two kinds: Mandatory and Optional
	2. not IP-centric, but broader

CL: T1M1 subcommittee would like to see this OPSEC
    work go forward and harmonized with T1.276.

GJ: Gave comparison table of this draft to related work: T1.276
    and NSA Router and Switch CC Profile. (see GJ's slides)

NZ: (interrupting) slide says that NSA R&S CC profile was
    certified, but it wasn't.  It was fully completed in 2001,
    but never put in for validation.  [Work on it may be
    started up again in late 2003]

GJ: began review of meat of the current draft -00
	1. current scope is IP devices, this won't change
	2. current set of req. oriented toward net
	   infrastructure (routers, switches, gateways),
	   can use profile mechanism to sub-set the
	   reqs for other devices (e.g. cell phone)
	3. structure of requirements in document will be:
	   functional reqs, assurance reqs, documentation reqs.
	4. Some reqs in -00 that are too 'future' will
	   probably be dropped (e.g. stealthing)

GJ: Motivational example: one requirement in current draft is
    ability to filter traffic TO the device itself.  This
    ability was critical for workaround in recent Cisco IOS
    vulnerability in Cert Advisory.  It is good that Cisco
    supports such a feature: we want this document to list such
    features so that all relevant devices will support them.

GJ: began discussion of specific management reqs in draft -00,
    and possible changes for -01, especially separation of
    control and data planes.

WH: (Wes Hardaker, Mike?) suggested discussion break
    instead of running through all the requirements

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.

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

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

BF: (Barbara Frasier, Cisco) If this doc goes through IETF,
    what about conflicts with existing RFCs?  Are there any?
    GJ: admits yes.  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

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

GJ: introduced Merike Kaeo to discuss the requirement
    groupings, profiles, in the draft -00 appendix.

MK: (Merike Kaeo) battle between "good enough" and "best"
    security.  goal of profiles is to defines sets of
    requirements from body of draft that apply to various
    device roles.  Would be surprised if a minimal set of
    profiles took more than 1 year to standardize.  Later,
    would like to see much bigger set of profiles for many
    other devices not just layer 3 core, such as edge devices.
    send suggestions to mailing list

WH: suggested separating profiles into separate
    draft or RFC.  GJ: demurred

WH: regarding edge devices, noted that 90% of network
    attacks are insider attacks

GJ: back to requirements listing from draft...
    [several issues emphasized:
		1. some requirements could usefully
		   reference work that is still in draft
		   (not yet RFC) form.  Should we wait?
		2. reqs current specify need for
		   managability by standard protocols,
		   prohibit need for proprietary mgmt GUIs.
		3. is a 'display all' feature really
		   needed or even desirable?
		4. need to know what all the services
		   are, and be able to disable any|all.

GJ: req 2.3.8 obliges devices to resist all known
    exploits.  Discussion?

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!

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.

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]

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?

GJ: more review of logging requirements...
    then review of AAA requirements...

UK: (Ulrich Kiermayer) What about requirements on the
    log recipient host?  GJ: out of scope

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

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 ?)
GL: defining message may be a goal of this work

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

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.]
GJ: expressed relation to IETF Syslog WG work
CL: Nope, no such relation; Syslog WG considers
    what happens to messages before logging to
    be out of scope

GJ: Req 2.14.1, Vendor Responsiveness, possibly spin
    this off to some other effort?

GJ: Work areas for this document:
	1. needs work on assumptions and risk analysis
	2. need to decide about IETF path: BCP RFC,
	   Informational RFC, or something else?
	3. need work on the profiles

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)

GJ: Plan for next few months:
	1. take feedback from this discussion, issue draft -01.
	2. get more feedback from groups like NANOG and RIPE.
	3. move forward in IETF

GJ: invites participation on the mailing list
    opsec@ops.ietf.org

[[meeting ended, about 14:35]]