[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-jones-opsec-00.txt

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.

if it's operated correctly.  I'd say that it will be a network that
provides the best tools we know of for being available in the presence
of attacks.  I can't tell to what extent your recommendations help the
network maintain confidentiality and integrity of their users' data,
other than by helping to thwart some kinds of redirection attack.


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 ?

such as filtering of legitimate traffic, with or without issuing ICMP
prohibited messages.  (it's worse if you fail to issue those messages)


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

the zeroconf group is suffering from mass delusion.  perhaps another
group will be able to figure out how to run a network without so many
knobs.


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.

right, and I don't have a problem with having the knobs there - in fact
I agree that they're needed.  at the same time, the more knobs there
are, the greater the ability of expertise required to run the network -
and the greater the need to educate people as to how to set those knobs.


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.

I don't care whether it's in the same document or not, but the amount
of text needed for operational considerations is probably double the
amount of text that's there already.


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.

 ^^^^^^^^^^^^^^^^^^

this is fine but it misses the point I was trying to make.  to state it
differently, you don't want to make a blanket requirement to implement
informational or experimental RFCs.  standards-track RFCs (including
BCPs) are fine.




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.



perhaps.  I guess I wonder, from a general "network operations"
point-of-view,
what the justification for the "no additional devices" requirement is.
it's not like they're inherently insecure or they scale poorly.




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 ?



Not being a security person, I'm not sure I could word it better than
"MUST support an adequate number of distinct authentication
principals", but perhaps someone else has a better idea.




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.



interesting,  I probably  wouldn't consider something that exists
entirely to protect the network to be above layer 4, but management
never fit very well into the layer model anyway.




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 ?



Well, I imagine that you'd want some sort of asychronously  generated
notification whenever, for instance, the percentage of ICMP echo
request or TCP SYN packets rose above some percentage of the overall
bandwidth, and you'd also want some kind of mechanism to rate-limit
forwarding of those packets.  I don't know what specific mechanisms
would be best for this, but it seems like you need some mechanism.

Keith