Re: [ipcdn] draft-ietf-ipcdn-device-mibv2-01.txt

[RJ Atkinson <rja@extremenetworks.com>]

On Monday, April 22, 2002, at 03:17 , Andy Bierman wrote:

> At 11:23 AM 4/22/2002, RJ Atkinson wrote:
>
>>> ...
>>> This statement seems to suggest that implementations must 
>>> differentiate
>>> operations by security user (i.e., use VACM and USM).
>>> I think such features should not be mandated. SNMPv1(2c) over IPSEC 
>>> should
>>> be considered secure enough.
>>
>>        Not hardly secure enough, though I know that cisco is trying to
>> push that approach so they can sell a more proprietary approach
>> to SNMP and MIB security for their own profit reasons.
>
> Please explain why IPSEC is not secure enough,

	Does not provide the right security properties,
particularly in the key management arena, but also in
other areas.  IPsec was not designed to secure SNMP
-- it was designed to provide a different set of properties.

	I'm modestly familiar with IPsec, having invented it,
chaired the WG in the past, and having worked on an
early implementation of it.  So it should bother folks
when I suggest that IPsec is not well suited to protecting
SNMP network management.  Saying "just use IPsec" is an
increasingly common cop-out for folks unwilling (for whatever
reason) to actually address the security needs of particular
protocols.

> why multiple security users per application are mandatory,

	The ability to grant different levels of access to different
users is long-standing in SNMP and would be lost by just using
SNMP/IPsec.  Many examples exist of this.  There is VERY broad
agreement in the network management community that multiple
user support is a requirement and this agreement dates back
at least a decade.

	One example is that we have a system where I should have
read-only access to the MIBs, but another person should have
read-write access to the MIBs.  With SNMP/IPsec, this box cannot
be deployed by me as an operator and provide that property.
There are other defects of SNMP/IPsec in terms of the provided
security properties as compared with SNMPv3.

	The requirement is on *implementations* of SNMP, so that
operators can use the capability (or not use it) as the operator
prefers.

> and why IPSEC is proprietary.

	SNMP/IPsec is proprietary to cisco as are several other foo/IPsec
approaches that cisco is selling.   Even if it provided the right
security properties (which it doesn't), one needs a separate *spec* for
SNMP/IPsec, because that by itself isn't even clear in what
is being used.  Possible values for that phrase include at least:

1st axis:		(SNMP/AH, SNMP/ESP-auth-only, SNMP-auth-encrypt)
2nd axis:		authentication algorithms (MD5, HMAC MD5, SHA-1, HMAC 
SHA-1, others)
3rd axis:		confidentiality algorithms (DES-CBC, 3DES-2key, 3DES-3key, 
AES-CBC, others)
3rd axis:		key management protocol in use (and which of its
			algorithms, modes, initialisation methods, etc.)

	IKE, by itself, has a very large set of possible configurations
-- so many that it is not in fact interoperable amongst independent
implementations, which is one reason the IPsec WG plans to replace
it with (either IKEv2, which is different, or JFK, or something else).

	Ignoring IKE, there are at least (3 * 5 * 5 = 75) meanings of
"SNMP/IPsec".  If one adds in IKE (or another less openly specified
key management mechanism), one easily is into large hundreds or
even thousands of combinations that could each mean "SNMP/IPsec".

	How is this *interoperable* with anyone other than cisco ?
Answer, it is not without an open IETF spec, so it is a *proprietary* 
approach.

Ran
rja@extremenetworks.com