Reply to comments on opsec draft from Bert Wijnen/OPS directorate. Part 1.

[George Jones <gmj@pobox.com>]

bw> Date and Time: 2004-01-25, 18:13:52
bw> Version: 03
bw> Commented by: Wijnen, Bert
bw> State before Comment: 0
bw> State after Comment: 0
bw> Comment: ----------------
bw> comments from OPS Directorate
bw>
bw> Overall: This document is not publishable in its current form.

I'll address the issues raised as best I can.   I'll wait for input
from the BoF/ADs as to where to go with it.

bw>  While
bw> the goal of the document (getting vendors to provide better security
bw> facilities in switches and routers) seems laudable, the guidance
bw> provided is just not specific enough in many places. There are too
bw> many choices allowed, so that vendors could claim compliance but not
bw> actually interoperate, or even be secure.

*sigh*.  Ted Hardie's comments idicated that it was too rigid.  These
indicate that it's too flexible.  There's no way to reconcile those.

Perhaps a note about the origin is in order again.  This started as UUNET's
list of things we wanted from vendors.   We were tired of being told
"you're the only one who wants...xxx", so the idea was to put out
the list of features in a form that was useful to the community so
that where other people had the same needs, they could have a concise
way of saying to vendors, "yes, xxx is important to us".

It was recognized that not all devices (edge, core, layer 2, layer 3,
etc) had the same needs, so the profiles mechanism was added.
Same goes for different organizations needs.

The belief was and is that the set of feature requrirements in the doc
was not unique to UUNET and that other organizations would have a
large overlapping set of requirements.  The attempt was to define a
minumum, common subset in the minimum reqs profile.

How to best express that (BCP, Info, etc.) and in what forum (IETF, other)
was a seperate question.

bw>  As a result, publishing the
bw> document at this point could do more harm than good.
bw>
bw> Here are some specific comments:
bw>
bw> Section 1.4:
pbw>
bw> This section is entitlted "definition of a secure network" yet many of
bw> the requirements have little to do with security, such as
bw> availability.

For some definitions of security, "security = confidientiality +
integrity + availability".

For large network operators, availability (e.g. resistance to DoS
attacks, continuing to pass customer bits) is a LARGE part of the
equation.  Availability as in being able to access managment functions
even in the middle of an attack is also very important to operators.

bw>
bw> "The following assumptions are made:
bw>
bw>   o  Devices are physically secure.
bw>   o  The management infrastructure (AAA/DNS/log server, SNMP
bw>      management stations, etc.) is secure."
bw>
bw> More specific guidance is needed. Are we saying that we are assuming
bw> that an attacker can't access the console port?

Yes.

bw>  If not, is this
bw> because of a recommended practice (e.g. use of token card security),
bw> or just because we are assuming that the door to the closet is always
bw> kept locked?

Physical security is outside the scope

bw>
bw> Rather than assume that management infrastructure is secure, it would
bw> be more helpful to provide some guidelines as to how to ensure they
bw> are in fact secured.

Yes, but that is a separate seperate document.   See Barbara Frasier's
fine Site Security Handbook (RFC2196) for starts.

bw> For example, one might recommend ensuring that
bw> AAA clients have decent random number generators or implement IPsec or
bw> at least use different shared secrets.  One might use SNMPv3, etc.
bw> The draft never gets specific enough on this, in my opinion.

Again, this is about what features are needed, not about how they are
used.   Clearly a companion/closely related work, but a different one.

I've reformatted the scope, pulling in the bits about mgt hosts.

04> 1.3 Scope
04>
04>    The scope of these requirements is intended to cover the managed
04>    infrastructure of large IP networks (e.g. routers and switches).
04>    Certain groups (or "profiles", see below) apply only in specific
04>    situations (e.g. edge-only).
04>
04>    The following are explicitly out of scope:
04>
04>    o  General purpose hosts that do not transit traffic including
04>       infrastructure hosts such as name/time/log/AAA servers, etc./,
04>    o  Unmanaged devices,
04>    o  Customer managed devices (e.g.  firewalls, Intrusion Detection
04>       System, dedicated VPN devices, etc.),
04>    o  SOHO (Small Office, Home Office) devices (e.g. personal firewalls,
04>       Wireless Access Points, Cable Modems, etc.),
04>    o  Confidentiality of customer data,
04>    o  Integrity of customer data,
04>    o  Physical security,
04>    o  Security of the management infrastructure (AAA/DNS/log server,
04>       SNMP management stations, etc.).


bw>
bw> Section 2.1.1
bw>
bw> I was expecting some specific guidance here.  For example, support for
bw> SNMPv3, SSH, etc. Instead, this section just talks about some ways
bw> that things *might* be secured.  Based on this section, I guess one
bw> could use SNMPv2 over TLS over TCP *or* SNMPv3 *or* SNMPv2 over IPsec
bw> to secure management traffic and be compliant.

Yes.

To be continued...

---George Jones