Comments on the SNMPv2* presentation at 35th meeting of the IETF

• in Bert's analysis,
• in Jeff's presentation,
• in this response to Jeff's presentation, and,
• in whatever responses are made to our analysis,

Features (page 7)

Claim: v2* has proper layering

As explained in both the USEC FAQ and in the comparison document presented at the 35th meeting of the IETF, there are no actual advantages in the way v2* attempts to separate the security protocols and the administrative infrastructure; further, we note that v2*'s approach adds complexity to both its procedures and corresponding documentation. (Parenthetically, we also note that the currently available v2* document set has not fully achieved a clean layering between the security framework and the administrative framework.)

Claim: v2* has seamless multilingual support

v2* defines a mapping from v1/v2c communities into the v2* model; however, this mapping adds complexity. An implementation supporting v2u can also realize v1 and v2c, albeit with less complexity and reduced cost, as v1 and v2c do not need to be mapped into yet another protocol, as would be required if the implementation also supported v2*.

Claim: v2* has done considerable work with proxy, but v2u* has not completed work on proxy, which is an important market requirement

To begin, v2u support for proxy is defined in RFC 1910.

Next, it should be noted that proxy agents are an optional feature in both specifications. In order for v2* to support proxy, it adds overhead to the protocol-over-the-wire and complexity to the procedures, regardless of whether proxy agents are either deployed or provisioned in the network. In contrast, v2u has taken a straight-forward approach, allowing for proxy to be completely separated from the base specification if desired.

Finally, although proxy is an attractive feature for some environments, it is hardly a universal requirement. It seems odd to use this feature request as justification that all implementations suffer this additional complexity and burden.

Similarities (page 8)

Claim: v2* has near-identical security

We agree, once v2* incorporates the security enhancements recently incorporated into v2u. However, this will likely require that the sPI field be removed from the v2* packet.

Claim: there are serious design flaws in v2u

Broad claims such as that do not aid either proposal in resolving any technical issues that may or may not exist. We invite the v2* design team to describe the flaws in as much detail as possible, so that we can have technical discussions.

Claim: v2u lacks a remote configuration MIB

The second draft of the v2u configuration MIB was published in February, and work on this effort is continuing. This topic is being discussed on an open mailing list, which you can subscribe. For further details, consult the USEC FAQ.

Claim: v2* has necessary additional features

v2u has taken a minimalistic approach in the name of simplicity. Any feature that is not useful to a large majority of the community was not added to v2u. We invite the v2* design group to list each additional feature with the reasoning as to why that feature is needed; further, we invite them to explain the cost-benefit analysis associated with supporting each of these features.

Model Differences (pages 10-11)

Claim: v2u makes it easier to change the administrative model

We again refer the reader to the USEC FAQ. (Parenthetically, we also note that we find it unlikely that future generations of designers will change the administrative framework ``just for the fun of it''.)

We agree that it is useful to have solid design guidelines for the administrative framework, so that future designers will realize that they should only change it if there is a justification and a cost-benefit for such changes. We propose that we lay down these guidelines in the remote configuration MIB document.

Claim: multiple security protocols per v2* user is good

v2u requires each user to have a single security protocol. Supporting multiple security protocols per user adds complexity, that is simply unwarranted: this complexity manifests itself in adding overhead to both the protocol-over-the-wire and also to the remote configuration MIB. In the latter case, not only does each security-related table indexed by a user require an additional indexing column, but great care must be taken to ensure that future, as yet unspecified, security protocols are consistent with the syntax and semantics of the columns in those tables, e.g., limitations on key size, algorithms for key update, and so on.

Further, there is some doubt as to whether v2*'s approach will work for multiple security protocols, since:

• it is not possible in v2* for a manager to query the agent's MIB to determine which security protocol(s) are in use for a particular user
• it is not possible in v2* for a manager to configure an agent to use a particular security protocol for a particular user; and,
• it is not possible in v2* for one user to have multiple security protocols for which the format of the security keys are incompatible.

Claim: v2* supports the partitioning of ``people'' and ``policy''

v2u also supports this form of administrative configuration; however, it is done at the administrator's option: the network management decides if a userName represents a individual or a group. Again, v2u achieves the same overall functionality, at a reduced cost.

MIB (pages 12-13)

Claim: there is an important linkage between the model and the MIB

We agree; however, the model may still be defined before the MIB. This approach is consistent with the approach taken in designing all the other MIBs on the IETF standards track. Furthermore, the IESG's position is that a MIB does not have to be developed in lock-step with the protocol (although the MIB must closely follow the protocol). We are ready to work together to define the best possible MIB. Let us work together and define that MIB on top of the v2u model, which is a robust protocol.

Claim: a MIB is an important requisite for security, and without a MIB, it will not be secure

A MIB module, while being convenient, does not make either model secure or insecure. Further, as stated earlier, v2u has released a second draft of its remote configuration MIB.

Claim: the v2u MIB has considerable fate-sharing, which is bad

Unfortunately for v2*, its remote configuration MIB replaces fate-sharing with spin-locks. This results in additional complexity in adding or modifying management information, as management applications must engage in multi-step transactions. As a consequence, a lossy network makes it more difficult for those tasks to complete, and greatly increases the chance of inconsistencies.

Fate-sharing requires that a MIB implementation be able to examine and manipulate multiple objects during a single operation. Providing these objects all reside within the same process-space (i.e., all the information is available in the same memory-space to a single program counter), then implementation strategies exist which make this straight-forward.

This design choice is important for robust behavior: although a MIB can specify the use of either spin-locks or fate-sharing for complex tasks, and although implementations of either approach can be realized, in practice, the fate-sharing approach is more resilient to transient network outages.

Claim: v2*'s authorization bitfield has fewer bits than v2u

We are happy to replace our bitfield which supports operation-level granularity (all 7 bits) with fewer bits.

Handling of IDs (pages 14-17)

Claim: two IDs in the packet are needed for proxy support

There is no such need. v2u is able to support proxy with a single ID, and at a reduced cost in comparison to v2*. See our earlier discussion on proxy.

Claim: two IDs in the MIB are needed for proxy support

There is no such need. A proxy context in v2u is either a ``local-proxy'' or a ``remote-proxy'', this allows a proxy-agent to examine an the agentID and contextSelector pairing contained within an incoming packet and then correctly route the packet.

Claim: a single ID requires the sender of an inform to be authoritative, which is bad

To begin, a tenet of v2u is that the entity which is closer to the data is the one which is authoritative with respect to clocks. As such, any entity which contains management information, is clock-authoritative, e.g., agents which respond to retrieval operations. Similarly, since the entity which sends the inform operation is the one which contains the management information, it too should be clock-authoritative.

Next, although it is claimed that the receiver of a v2u inform needs to block in order to time-synchronize with the sender, this is false. Specifically, clock-synchronization occurs automatically for a non-authoritative entity when it receives an authentic packet whose time-stamp has increased. (The details are a bit more complicated, interested readers should consult Section 2.7 of RFC 1910, and look for ``latestReceivedAgentTime''.)

Finally, although it is claimed that v2u's approach requires that the requester must maintain a long-lived secret database, the fact remains that both v2u and v2* rely on shared secrets. As such, we note that there is no concept of secret-authority in v2u.

(Parenthentically, we wonder if this claim doesn't highlight an inconsistency in v2*: v2* has two IDs, and yet the sender of a v2* trap is ``authoritative''.)

Claim: v2u violates the principle that the semantics of the data should be path independent

To begin, consider the case of two agents accessing the same instrumentation to provide redundancy. In the case of either v2u or v2*, where a context is identified by an agentID/snmpID and an contextSelector, data from the two agents appears to be from different contexts, as each agent has a different agentID/snmpID. If correlation is desired, then both v2u and v2* requires that each context be configured with a unique contextSelector, in which case the agentID/snmpID is irrelevant.

Next, the example on page 16 of the presentation illustrates two proxy agents accessing the same instrumentation and shows how v2*, by propagating the snmpID from the agent, allows a management application to correlate the data, regardless of which proxy agent it was routed through. If correlation is desired, this can be achieved in v2u by assigning a unique contextSelector to each context, the same solution which v2* requires in our first example.

Finally, it should be noted that because data correlation requires uniqueness, and uniqueness is hard to achieve, that solutions to either problem may be costly to provision. Regardless, note that the administrative cost is identical for both v2u and v2*, despite the fact that the v2* packets, because they have two IDs, have more overhead on the protocol-over-the-wire and more complexity in the procedures.