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

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

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.


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.


That's why 2.3.7 is there.




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)
What to filter is an operational decision. We're just saying we want mechanism to do it.

And you're right: not getting ICMP unreachables, etc. can make it harder for apps to know
what's going wrong. Most of what we're talking about in the (to be renamed) "stealthing"
section is the ability to have the internals (core) of the network be a black box form the
consumers point of veiw. The idea is to present as samll a surface arae as possible to
potential attackers. It the attacker can't get any traffic FROM the core router
(ICMP timeouts, unreacables, etc), he has to guess at the addresses to attack. If he *can't*
route packets *to* the core devieces, then no direct attacks are possible.

This is an area that needs work. I've got one volunteer already to
work on combining OoB and stealthing.

And yes, this one is *very* large-provider centric.

 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. 
If you say so :-).   I though about running this by that group since
they seem be assuming little to no user input, and I'm tending
to assume a good deal.


perhaps another
group will be able to figure out how to run a network without so many
knobs.


Or how to run a cell phone, or a WAP, or a personal firewall...I've got a
couple other people offering to look at it from the samll/home device
and wireless angles.  It will be interesting to hear what they come up with.
I expect that in the end, we will wind up with a more generic list of
requiremnts and a larger, more specific set of "profiles" (layer 3 core,
layer 3 edge, appliance, moble wireless...)


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.

Start writing :-)
Seriously, I'll take contibutions wherever people think the're
needed. I've recurited other peole to help edit various sections: aaa, logging,
filtering, OoB Mgt, profiles, but if there's an area that you (generic you) are
interested in, let me know.



specific comments below: 


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.






All we're trying to say is "if you claim to implment FOO, it should be 
FOO as defined by the

FOO RFC".   If FOO is an approved standards track RFC, then that's the 
one that applies.

We're not saying what has to be implmented, but that anything that is 
implemented must

be RFC compliant.   See "for all protocols implemented" clause.










2.12.8 Ability to Authenticate Without Reusable Plaintext Passwords


     *  MUST NOT require additional devices (e.g., encryption cards,
        etc.)




perhaps.  I guess I wonder, from a general "network operations"
point-of-view,
what the justification for the "no additional devices" requirement is.






I thihk this was aimed at prevening the if you buy X you also have to 
buy Y syndrome.






it's not like they're inherently insecure or they scale poorly. 




Scale/cost can be an issue if you have to by 1000's of tokens  on a 
recurring basis.








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,



That's starting to be IDS-like functionality.




and you'd also want some kind of mechanism to rate-limit

forwarding of those packets. 



See 2.4

Thanks,
---George