Re: comments on draft-jones-opsec-00.txt (fwd)

[George Jones <gmj@pobox.com>]

---------- Forwarded message ----------
Subject: Re: comments on draft-jones-opsec-00.txt
From: George Jones <gmj@pobox.com>
To: Keith Moore <moore@cs.utk.edu>
Reply-To: opsec@ops.ietf.org
Date: Thu, 12 Jun 2003 14:02:45 -0400 (EDT)

On Wed, 11 Jun 2003, Keith Moore wrote:

> general: overall the document is well-organized and thoughtfully written.
>
> I'm not an ops person, I'm an apps person.  I read this with the question
> in mind "how will a network built out of such devices affect apps?"

Short answer is: it will be a nework that remains available, and one
that maintains cofidentiality and integrity.

> I conclude that most, perhaps all of these features are essential to
> running a large network, but many of these features are easily misused
> in a way that will degrade network operation and the ability of apps
> to use the network for dubious benefit.

Such as ?

>  I wish I could say that most
> networks were run wisely, but experience indicates otherwise.

So one of the tensions in the document is it's basicly saying
"we want lots of knobs and the ability to set them securely"
vs. for instance, what I think the zeroconf group is trying to
do (few to no nobs), and the needs of home networking "turn it on
and it works".

It's pretty clear that one size can not fit all.  Thats why the
profiles mechanism is there.

But in the end, this is about security features being available,
not about forcing operators to use them.

> This document is begging for a companion document (organized along similar
> lines) that provides guidelines on the impact of these features on
> applications.

Actually, it needs an "operational considerations" section that takes
the place of the usual "security considerations", since the whole
thing is about security.  There is some attempt in the "Warnings"
sections to list particularly severe performance impacts.

> specific comments below:
>
> > 2.3.1 Comply With Relevant IETF RFCs on All Protocols Implemented
> >
> >  Requirement. The device MUST fully comply with IETF RFCs for all
> >      protocols implemented.
>
> this is over-stated, because many RFCs are not standards, and some RFCs
> describe protocol features which are inappropriate or even harmful in
> widespread use.  suggest:  "The device MUST fully comply with current
> standards-track IETF RFCs for all protocols implemented".


Take 2644.  It's a BCP (not standards track).   It says to turn off
directed broadcast.  I want people to do that.

I've cpppppppppppppppphanged 2.3.12 to require directed broadcast to be off by
default in violation of 1812 and made a note in the warnings
to that effec.

I've changed the word wording of 2.3.1 to

> The default configuration of the device MUST fully comply with IETF
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> RFCs for all protocols
> implemented unless otherwise noted in the "Warnings" section of one of
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>these requirements.
 ^^^^^^^^^^^^^^^^^^

> > 2.9.3 Ability to Display Filter Counters per Rule
> >
> >   Requirement. The device MUST provide a mechanism to display filter
> >      counters per rule.
>
> suggest: when multiple rules match a packet, clarify whether
>
> a) each rule should be counted separately
> b) only a single matching rule should be counted
> c) any subset of matching rules should be counted
> d) either a or b but not c
>
> if rule matching were implemented with some degree of parallelism, this might
> make it difficult to satisfy b.  and yet if each rule were counted this would
> slow things down to satisfy a.  it's hard to know what to do with the counters
> if they're not implemented consistently from one implementation to
> > the next.

I'll give that some thought.

>
>
> > 2.12.8 Ability to Authenticate Without Reusable Plaintext Passwords
> >
> >   Requirement. The device MUST perform authentication without the
> >      transmission of reusable plain-text passwords across a network.
> >      The implementation:
> >
> >      *  MUST NOT cause significant performance degradation
> >
> >      *  MUST NOT require additional devices (e.g., encryption cards,
> >         etc.)
> >
> >      *  MUST scale well/be supportable on large numbers of devices
> >         (e.g., the number of keys and configuration settings that need
> >         to be managed should increase at most linearly as the number of
> >         devices).
>
> the "MUST NOT require additional devices" seems over-stated.  this might be a
> reasonable requirement for a particular network, but not for network hardware
> in general.  in particular, there are administrative and security advantages
> (as well as some disadvantages) to having keying material stored in, or
> authentication performed by, external devices.  I suppose you could say "MUST
> support at least one secure auth mechanism that does not require additional
> devices" but basically this seems like something that should be determined on
> a per-network basis.

So, this is a case where there is a compound requiremnt that needs to
be broken down...then an indivual site/network could say "no
additional  devices" does not apply to us, but "scales well" does.

>
> another scalability concern not explicitly stated here is that the
> authentication system MUST be able to support an adequate number of distinct
> principals - e.g. having a single "privileged password" is probably not
> sufficient.  (3.1.4 sort of says this, but not quite)  perhaps no "real"
> router has this problem, but it seems like a valid requirement
> anyway.

Good point.  How would you word that ?

> I'm also surprised that there is no requirement to automagically squelch DoS
> attacks or trigger alarms when such attacks are detected, but perhaps that is
> beyond the state of the art.

Those are starting to move up the stack and require intellegence.
This is not intended to specify firewall, IDS or other higher-order
functionality...it generally goes to layer 4 and stops.

> And in general I'm surprised there aren't
> requirements for alarms separately from event logging.

e.g. SNMP traps ?  What are you thinking of ?

>  Is it assumed that
> the logging facility will be adequate for alarms?

I'm not sure what you're calling an alarm.

Thanks,
---George Jones