[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft status, BoF, replies to issues
Hi George,
Comments inline.
> -----Original Message-----
> From: George Jones [mailto:gmj@pobox.com]
> Sent: Thursday, February 19, 2004 8:09 AM
> To: Harrington, David
> Cc: opsec@ops.ietf.org
> Subject: RE: draft status, BoF, replies to issues
>
> On Tue, 17 Feb 2004, Harrington, David wrote:
>
> > Hi,
> >
> > Some comments:
> >
> > Section 2.9.6 - 64bit counters per filter may be onerous on
> switching
> > devices
>
> Better ?
>
> 04> 2.9.6 Filter Counters Must Be Accurate
> 04>
> 04> Requirement. Filter counters MUST be accurate. They
> MUST reflect
> 04> the actual number of matching packets since the
> last counter
> 04> reset. Filter counters MUST be capable of
> holding up to 2^32 -
> 04> 1 values without overflowing and SHOULD be
> capable of holding up
> 04> to 2^64 - 1 values.
Over what period do you need to keep these counts?
Realize that a 32-bit counter can track up to 4,294,967,295 events. How
long would the typical filter need to count its hits to exceed that
capacity?
In SNMPv3, we introduced a 64-bit counter, but since it cannot be
reported using SNMPv1 or SNMPv2, we only use it if a 32-bit counter
might rollover in less than an hour. The 32-bit counter can handle more
than 1 million events per second and take an hour to reach capacity.
What's a reasonable rate to plan for in tracking filter hits? If a
device is being inundated by the fastest known worm, and you have a
filter to detect it, what is the maximum number of hits you will get in
an hour? If you're being inundated, how much time do you want your
system to spend counting the hits?
Over what period is it useful to count those hits? Is it useful to know
how many hits have occurred over the past hour? Of course. Is it useful
to know how many in the past day? The past week? The past month? The
past year?
How necessary is it to keep all this counting data on the device itself,
as compared to polling for the data, say daily or weekly, and
aggregating the rolled-over counters offline?
How long will it take to exceed 4 thousand million filter hits?
>
> > Section 2.13 - this, especially coupled with 2.9.6, would
> be onerous on
> > a low-end L3/L4 policy switch.
I think the issue is that you're using MUST for too many situations,
with no consideration for the circumstances.
A L2 switch does a L3/L4 lookup to determine the forwarding path for a
flow, and having done the lookup sets a corresponding L2 forwarding rule
and then ignores the L3/L4 lookup for subsequent packets in that flow.
In some cases the L2 device may be able to aggregate some flows for
faster forwarding. If the L2 device needs to count each L3/L4 hit that
would have occurred had the L2 "shortcut" not been used, then this will
be onerous to determine, especially in low-end switching devices.
>
> For context:
>
> 03> 2.13 Layer 2 Devices Must Meet Higher Layer Requirements
>
> What this is saying is that we can't ignore layer 3+ security issues
> for devices that are primarily layer 2 devices. If you use layer3+
> mechanisms to manage the device, you need layer3+ security features.
> Hackers won't stop sniffing telnet passwords just because you're "only
> telnetting to a switch".
I certainly concur with the observation about hackers, but your section
doesn't say it should ensure the security of L3 passwords, it says the
portion operating at or above layer3 MUST conform to the requirements
listed inthis document. Some of the "requirements" are really
nice-to-haves, and not implementing a L7 "nice-to-have" would not
necessarily jeopardize the security of the device the way exposing a
telnet password would do.
>
> Also, and here the scope may need refinement, the target of the doc is
> not generally low end gear.
>
> > Section 2.12.9 - From a security standpoint, this is good
> practice, and
> > I personally drink the security koolaid,
>
> :-)
>
> > but not having default
> > passwords would not be popular with many customers because
> it increases
> > the burden of configuring a new device.
>
> Again, back to target audience + scope. I believe that for "large IP
> networks" provisioning will be done according to a defined process
> and/or by skilled network engineers. Adding a step to the process
> vs. having core networking elements compromised seems like a fair
> tradeoff. If we're talking about SOHO devices ("why do I need
> password ?"), I could see your point.
I'm not talking about SOHO devices. SOHO is easy because there are so
few devices involved.
I'm talking about large enterprises that want to use, say, an SNMP
application like HPOV to "discover" their network using default
passwords, or applications to zero-config out-of-the-box devices using a
default password designed for that purpose (which might be eliminated as
part of the zero-config process). Being able to discover/identify and/or
autoconfig devices coming into your network can be critical for security
purposes.
When SNMPv2 was first designed by security geeks who liked the "party
model", they made it impossible to autodiscover a network; the keys for
each device needed to be entered manually at both the agent and the
manager before the manager could detect the presence/identity of the
device. Hiding a device's identity seems prefectly reasonable if you're
only thinking about security, but disabling autodiscovery greatly
reduces ease-of-use, and hides rogue devices added to the network.
After months (years) of debate, the SNMP community realized they would
never be able to convince people to use the protocol if they took away
autodiscover capabilities for the sake of security, and the result would
be a less secure management environment. Autodiscovery of new
out-of-the-box devices depends on having some standard pre-configured
passwords (or lack of passwords). The SNMP community defined a way to
keep autodiscovery but to limit what could be accessed during a
discovery process.
Standardizing the default passwords across vendors and standardizing
rigorous security surrounding their use is a better approach than not
allowing any standard/default passwords at all.
>
> >
> > Section 2.4.6 - which is the BCP - SCP, SFTP, or FTP over a secure
> > channel? Which is best under which circumstances? It would
> be good to
> > provide guidance to those who need to decide on one approach, and it
> > would be best to have a consistent answer to the question
> about which to
> > use. (i.e. BEST current practice?)
> >
> > David Harrington
> > dbh@enterasys.com
> > co-chair, IETF SNMPv3 WG, concluded
>
> The BEST practice is to have a way to store the config (principal).
> The examples (which you cite) are there to illustrate at least one way
> to implement the practice using current technology, with conscious
> attention given to the fact that there may be better ways to do it in
> the future. The best practice is the principal (something that is
> being done now), not the particular implementation.
I understand the importance of the principle, but you're mentioning some
possible solutions. Implementors will often take the low road - "see,
the opsec doc says FTP is OK to use, so we'll just put FTP on our
device, and leave it to the operator to make sure it's secure."
You want the ability to retrieve configurations. So will you use SCP or
SFTP or FTP over some undefined security mechanism to do so? What if
vendor A supports SCTP, vendor B supports SFTP, vendor C uses FTP with
an Ipsec VPN, vendor D uses FTP with an L2 VPN, vendor E uses FTP and
it's up to you to figure out how to secure the transport, and vendor E
has multiple models each of which supports different or no mechanisms to
provide such transport security?
How will you standardize your process in that environment?
It would be really helpful to explain (or better yet standardize) when
SCP is the right solution, when SFTP is the right solution, and when FTP
over a secure channel is the right solution. And you can always say that
new solutions may appear in the future that would supercede the current
best practices.
>
> Would you like SNMPv3 added to the list ?
No. Your examples seem to be about bulk transfer of a config snapshot.
SNMPv3 is not designed for that purpose, and is inefficient when used
for such a purpose. SCP and SFTP and FTP were designed for that purpose.
>
> Thanks,
> ---George Jones
>
> >
> >
> > > -----Original Message-----
> > > From: George Jones [mailto:gmj@pobox.com]
> > > Sent: Tuesday, February 17, 2004 9:16 AM
> > > To: opsec@ops.ietf.org
> > > Subject: draft status, BoF, replies to issues
> > >
> > > OK. It's been quite here. Status of things is the -03
> draft went to
> > > IESG last call. There have bee a number of comments in
> the id tracker
> > > (https://datatracker.ietf.org/public/pidtracker.cgi?command=vi
> > > ew_id&dTag=10387&rfc_flag=0)
> > > as well as in other fora (routing-discuss mailing list, etc.) and
> > > private mail to me. I'm going to try to clear out the backlog and
> > > respond to all issues raised, CCing this list with all responses.
> > >
> > > The doc apparently got a very mixed reception and there was enough
> > > concern in the IESG that they've scheduled a BoF to discuss
> > > what to do.
> > > Likely options seem to be (in no particular order):
> nothing, spin up a
> > > working group, publish current doc (with revisions) as an
> info RFC and
> > > spin up a working group, revise current draft and publish
> as BCP rfc.
> > >
> > > As I've said all along, I will do whatever the wise Area
> Directors,
> > > IESG, etc. see best. I'm in this to produce useful substance in
> > > whatever form makes sense.
> > >
> > > I will not be @ the BoF (though I might be able to do
> Jabber or AIM if
> > > someone who will be there sets it up.)
> > >
> > > Thanks to all who have read the draft and provided feedback
> > >
> > > Responses to follow.
> > >
> > > George M. Jones | Gulta cavat lapidem non vi sed saepe
> > > cadendo ("The drop
> > > | hollows the stone not by force but by
> > > often falling")
> > > |
> > > | Ovid (Latimer, 7th sermon)
> > >
> > >
> >
> >
>