Subject: Re: [Isms] achieving market saturation with ISMS (fwd)

From: Wes Hardaker <[email-masked]>
Date: Tue, 01 Mar 2005 09:21:02 -0800

David> I have seen many complaints that SNMPv3 is hard to deploy; I
David> have been trying to address the deployment issue, and I think
David> the bulk of the WG are focusing on the deployment issue. In an
David> IAB workshop for network management, with numerous operators
David> present, there were complaints about the SNMP ease-of-use, but
David> none about SNMPv3 not being secure enough. I think 90% of
David> operators are satisifed that USM is secure, and the WG is
David> trying to make it possible for that 90% to deploy SNMPv3 (with
David> security comparable to USM) more easily.

[I've been away or unavailable for the last two weeks and am trying to
catch up...]

The survey I conducted asked operators (reminder: almost entirely from
NANOG advertising, but not a few others responded as well):

When asked the question:

  Is the current SNMPv3 with USM sufficiently secure for your needs?

The responses were:

     38 Abstain
     37 No
     74 Yes

Thus the data from my side resulted in 69% of one set of operators
thought it was secure enough.  This is certainly above half, but
certainly a lot lower than a complete agreement.

-- 
Wes Hardaker
Sparta

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 1 Mar 2005 14:17:09 -0500

Hi Wes,

I recall that your survey had a caveat about the sum being greater
than 100%. Can you quickly explain what the percentages mean, and how
much overlap might exist between the categories. I have difficulty
understanding how to interpret any answer overlaps in a binary yes/no
question (assuming the abstains didn't actually vote). Do you have the
raw data still? Is this overlap because some voted both yes and no? Is
the overlap because those that abstained also voted?

I didn't say that 100% of operators felt it was secure enough; I used
the 90-10 rule to argue we should try to meet the needs of the
majority. I would be happy to apply the same argument to a 74-36 or
69-31 split. If the WG can only focus on one security model, I suggest
we address the need of the majority rather than the minority. Of
course, if we can develop something that will address the needs of the
majority and most of the needs of the minority at the same time, that
would be ideal.

While I recognize that certain segments of the community are most
concerned with strong security, I have learned from history. The
SNMPv2 Party Model focused on the needs of the security community, but
was totally unusable by most operators because it prevented such
things as autodiscovery of a network. I don't want to see us repeat
that mistake here.

I would hate to hold up progress in addressing the needs of the
majority to meet the "requirements" of a vocal minority. As Uri points
out, SNMPv3 was deliberately developed in a modular architecture so
different segments of the industry could develop solutions to meet
their specific needs, without requiring that the SNMP community find
one and only one standard solution that meets everybody's needs. The
SNMPv2 wars and subsequent WG meltdown demonstrated very effectively
that such a one-size-fits-all approach is unlikely to ever reach
resolution.

Is it unfortunate that we might need to field multiple security models
to meet all needs rather than just one standard? Yes. But the nice
thing about the modular architecture and allowing multiple
supplemental security models is that developers of specific security
models will need to convince vendors and operators that they need the
specific security model. If they cannot *sell* their solution, it will
simply never be adopted by the industry; if the solution really is
needed, then they should be able to sell it without much trouble. It's
a let-the-market-select the approach to supplementing/replacing USM
that best meets their needs.

I think it is unfortunate that the area directors insisted the ISMS WG
select only one direction to work on, when two supplemental models
with much common infrastructure might better serve the industry, but
that's their choice, and given the track record of SNMP-related WGs
over the past five years, I understand their decision. I do expect
that the WG will try their best to address as many "requirements" as
possible.

We need to pick one direction to focus on. It appears to me that the
greater market demand is for improved ease-of-use. There are more
operators complaining about the difficulty of deploying SNMPv3 than
are complaining about the security being too weak, and Wes's survey
results support that assertion. I think the first
supplemental/alternate security model to USM should be focused
primarily on improving the ease of deployment. Another security model
can be developed independently to address the need for stronger
security than USM offers. Then the operators can choose which they
want to use for their environment.

That's my $.02
David Harrington
[email-masked]
co-chair IETF SNMPv3 WG, concluded

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Tuesday, March 01, 2005 12:21 PM
> To: [email-masked]
> Cc: 'Fleischman, Eric'; 'Randy Presuhn'; [email-masked]
> Subject: Re: [Isms] achieving market saturation with ISMS (fwd)
> 
>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 01 Mar 2005 14:04:57 -0800

>>>>> On Tue, 1 Mar 2005 14:17:09 -0500, "David B Harrington" <[email-masked]> said:

David> I recall that your survey had a caveat about the sum being greater
David> than 100%

That was only true for the questions that involved multiple choices
where they were deliberately allowed to select multiple choices.  EG,
I asked them to mention all the security infrastructures they used,
and thus they could have picked both ssh and radius and local-accounts
if they were using all 3.  Thus, the percentages for which were in use
by the various environments were specific to each protocol (local
accounts was at the top with 99 of 149 responses saying they used
local accounts.  73 of 149 responses said they used ssh authentication
(which really meant they used ssh).  Obviously, 73 + 99 > 149 since
they were independent choices.  (Think "multiple checkboxes")

However, in the case of the question that I just reported the answers
for (again; all of this was made available on the list a long time
ago; I'm merely repeating the results at this point), it was a fixed
choice between 1 and only 1 of 3 possibilities "yes", "no", and
"didn't answer" (abstain).  (Think "radio box") Thus those percentages
added up to exactly 100:

  Is the current SNMPv3 with USM sufficiently secure for your needs?:
  %       Raw
  25.6     38   Abstain 
  24.8     37   No
  49.6     74 Yes
  ----    ---
  100.0   149 Total

Now the real question you should be asking at this point is why is the
yes percentage 50 when I said it was 60 earlier?  Err...  I don't
know.  I must have done the math wrong before.  It's certainly right
above.  Of those that didn't abstain, 66.7% think it's secure which
might have been what I did...

David> Do you have the raw data still?

Yes I have the raw data still.  I can post everything again if you
like and indicate which were multiple options (checkboxes) and which
were single options (radios or menus) if you like?

David> While I recognize that certain segments of the community are most
David> concerned with strong security, I have learned from history. The
David> SNMPv2 Party Model focused on the needs of the security community, but
David> was totally unusable by most operators because it prevented such
David> things as autodiscovery of a network. I don't want to see us repeat
David> that mistake here.

Agreed.  I don't think we should force ourselves down a secure but
unusable path.  However, I don't see a problem with going down a "more
secure" and "more usable" path if that is helpful.

David> As Uri points out, SNMPv3 was deliberately developed in a
David> modular architecture so different segments of the industry
David> could develop solutions to meet their specific needs, without
David> requiring that the SNMP community find one and only one
David> standard solution that meets everybody's needs.

Agreed.  What's interesting is that many years later, people suddenly
don't want to change away from that security protocol.  Although it's
modular people (some) don't want to exercise that option.  We've
supported SNMP/Kerberos for a good number of years now (3) as a
vendor-add on and it is in use (4/149 people from the response, eg).
The advantage of coming to a common ground is that we can help more
people use what they want.  Having a single vendor support a given
authentication scheme isn't as useful as having multiple vendors
support it.

David> I think it is unfortunate that the area directors insisted the
David> ISMS WG select only one direction to work on, when two
David> supplemental models with much common infrastructure might
David> better serve the industry

It is sad, but I agree understandable.  Though when you have this much
interest I don't see the harm in trying.  It's better for us to try
and fail than not try at all.  Surely if we don't try to converge at
all then no commonality will result.  Even if we stand around and
argue for a very long time, it's likely we'll at least converge a
little and reduce the possibilities down to a smaller set.

David> We need to pick one direction to focus on. It appears to me
David> that the greater market demand is for improved
David> ease-of-use. There are more operators complaining about the
David> difficulty of deploying SNMPv3 than are complaining about the
David> security being too weak, and Wes's survey results support that
David> assertion. I think the first supplemental/alternate security
David> model to USM should be focused primarily on improving the ease
David> of deployment. Another security model can be developed
David> independently to address the need for stronger security than
David> USM offers. Then the operators can choose which they want to
David> use for their environment.

This is where we start to disagree.  I agree absolutely with your
statement that "There are more operators complaining about the
difficulty of deploying SNMPv3 than are complaining about the security
being too weak, and Wes's survey results support that assertion".
However, my fundamental point is that unless you tie the "something
new" to existing architectures *in use* it will do no good.  SNMP is
and will always be a service turned on later rather than immediately.
Operators are much more concerned about getting a router to route than
getting it managed.  They will always want to turn it on and start it
routing and *then* set up management.  They may seem backwards to the
NM community, but it's a fundamental aspect that won't be changed.
Thus, the operators will always be setting up some form of user
database/system before hand.  Thus the argument that "if you get them
to set up USM and then they can manage all the rest of the users"
simply doesn't fly with me.  If there is any work toward deploying
something beyond what they already have running, then it will result
in a delay in them deploying it.  If they're not running radius, then
deploying radius will be a pain to them.  If they're running radius
but don't have a radius server that supports key delivery extensions
or doesn't have configured shared secrets to protect the traffic, this
will be a pain.  The question is: what is the least amount of pain you
can offer them.  If the answer is not as close as possible to 0, you
will loose deployment time and deployment saturation.  There is no way
around that IMHO.  SNMP isn't the reason they bought the box, and it
will never be.

-- 
Wes Hardaker
Sparta