Definitions of Managed Objects for Middlebox Communication
draft-ietf-midcom-mib-11

[Ballot comment]
Version 10 includes a couple of new edits which I suggest to re-visit:

1. in page 9 all terminology was changed from SNMP manager to MIDCOM client with the exception of the last instance.

'If this is not possible, then the SNMP manager has to perform additional SNMP get transactions as long as necessary to receive all of the reply parameters.'

I suggest to use here 'SNMP manager (MIDCOM client)' for consistency.

2. in section 5 and in the DESCRIPTION clause of the MIB module 'three braches of managed objects' was replaced by 'three kinds of managed objects'. I do not know why this change was made, but I kind of do not like it, as it fails to convey the fact that the MIB module is structured in sub-groups or branches on these line. I would suggest to default back to the previous terms, or make clear that every 'kind' has one single root node each under midcomObjects.

Dave Harrington's full review:

I reviewed the MIDCOM MIB document, paying particular attention to the separation of protocls from the MIB, and paying attention to the distinction between security subsystems and security models, and access control subsystem and access control models. Overall the document looks good. Almost all the fixes proposed here are minor editorial fixes (but one issue is a major problem).

1) section 4.1 mentions "context"; context has a very special meaning in SNMP, so there is some ambiguity. I think this can be ignored here.
I think it's clear enough.

2) also in 4.1, the discussion of security models and access control models is mostly OK because it is preceded by "such as". However, "is controlled by VACM" would be better as "is controlled by access control models such as VACM".

3) The sentence starting "Recommended configuration of VACM ..." is good since it is only a recommendation.

4) IN 4.2.2, /the SNMP needs to take action/the SNMP manager (the MIDCOM client) needs to take action/  - an SNMP protocol engine does not do things like repeat set transactions or checking the success of the initial write transaction ...
/wrote/write/

5) 4.2.2 - /The SNMP agent informs the SNMP manager about the end of processing the request by sending an SNMP notification/The MIDCOM server informs the MIDCOM client about the end of processing the request by sending an SNMP notification/

[The SNMP protocol never indicates the end of processing by sending a notification; it indicates the end of SNMP processing by sending a Response-PDU. It is MIDCOM that requires the sending of a notification to indicate end of transaction processing.]

6) 4.2.4.5 "All atomiticiy problems.." - note that using RowStatus with a createAndWait can also solve the atomicity problem by allowing managers to build the row using mutliple SET requests that do nothing until the rowStatus is turned "active".

7) 4.2.5 /SNMP user according to USM/authenticated principal, such as a USM user/
/user's access rights/principal's access rights/
/the VACM mechanisms at the SNMP agent/access control mechanisms, such as VACM/

8) 4.3 /policies into configurations of the SNMP/policies into configurations of, for example, the SNMP/
/the mechanisms of VACM/the mechanisms of access control models, such as VACM,/g
/an access control policy can specify that MIDCOM policy rules owned by/an access control policy can specify that MIDCOM-MIB policy rules owned by/ [VACM could not do this if it were not for the design of the MIDCOM-MIB policy rules where owner is part of the index, so this is clearer if you say MIDCOM-MIB policy rules rather than MIDCOM policy rules.]

9) 6.2 - good good good - all RECOMMENDS; that's fine.

10) midcomCompliance /SNMP entities that implement/implementations of/



Some editorial nits:
4.2.3. /stronghold/strength/
4.2.4.5 /atomiticity/atomicity/

5.3 and possibly elsewhere. IN SMIv1 MIB modules, everybody separated things into "groups", but SMIv2 made GROUP a reserved word. It is better to use "subtree" than "group" to describe a subtree of the hierarchy.
/statistics group/statustics subtree/
/transaction branch/transaction subtree/

5.3.2 the names of the counters were changed in the MIB but not here.
OwnersTotal no longer exists, right?

10.2 /vulnerate security/make security vulnerable/ ?? I found no vulnerate in my dictionary.

--
Unfortunately, while reviewing I spotted a few things that I think deserve a closer look.

1) the tables need to discuss persistence more I think. It needs to be clear whether the read-write entries must be preserved across reboots.
As an admin, I'd probably be upset if they weren't.

2) There is a particualrly nasty issue about persistence that needs to be looked at. **You're gonna hate this one!**

ifIndex is not necessarily persistent across reboots (hence the presence of ifAlias, which is). Because a physical configuration can change during a reboot (e.g., a card is removed from a chassis), ifIndex values can be renumbered. If the MIDCOM tables are persistent across reboots, what happens if the ifIndices change on reboot? The table entries would now point to the wrong interfaces.

The reason why ifAlias was defined is that an agent cannot necesarily tell, after the reboot, which ifIndex was assigned to which component before the reboot, and netiher can the MIDCOM-MIB implementation, so you cannt say just change the indices of your tables to match.

ifAlias helps by being consistent across reboots, but it is not set initially, so you need to make sure it is set to something other than a zero-length string before using it.

3) Another issue with ifIndex is the "naming scope" issue mentioned in the ifIndex DESCRIPTION clause.

4) there are references to "strings" - SNMP does not support strings, so you need to clarify whether you are talking C-style null-terminated strings, or OCTET STRINGS. Wehn you say a zero-length string, you need to clarify whether that is a zero-length OCTET STRING, or a one-character OCTET STRING in which the first character is a NULL. (I recommend using zero-length OCTET STRINGS, which avoids character set issues.

(obviously I didn't catch the zero-length string reference in the ifAlias text. ;-)

5) midcomRuleTable talks about IP interfaces. Is it deliberate that only IP interfaces are supported?

6) 7.1 2. "The MIDCOM client enables ... from excluded(2) to included(1)". I think included causes the notification to be filtered out, which would be "disable". Using excluded means the notification is not filtered out, and thus "enabled". Right?

7) for RuleOperStatus, a MIDCOM MIB implementation MAY return processingRequest. What happens if it doesn't return this, and it takes a long time to process the request? Does the SNMP Request have to wait until processing is completed? I don't consider this a problem, just somewhat ambiguous.

under terminated, /an SNMP manager/a MIDCOM client/ - it's the client that controls explicit requests for termination.

8) RuleLifetime says the value after a SET can be different than specified in the SET request. This is very close to, if not, illegal SNMP; The SETRequest-PDU contains the desired value, and the Response-PDU should match to indicate the specified value was actually SET. This could benefit from clearer text on this point. If you
**cannot** SET the object to the specified value, then I think SNMP should return an error, per RFC3416.

9) You return 'inconsistentValue' for a number of objects, in conditions that may not be the appropriate conditions for this error code. I did not review them all; they should all be reviewed. here's
one:
RuleRowStatus - if the StorageType is permanent or readOnly and you try to SET it, I think 'notWritable' is the correct error code. Look at the conditional clauses (the flow) in RFC3416 for SETRequest; the MIB should not specify different error codes than SNMP specifies for a given condition.

10) 10.1 SNMP doesn't actually do "data origin authentication"
(end-to-end authentication for the data), even though USM claims it does. It only does message authentication (hop-to-hop). When a proxy is used, the authentication happens between the origin and the proxy, and then between the proxy and the destination, but there is no authentication by the destination that the data came from the origin, only that the message came from the proxy. SNMP does do (hop-to-hop) identity authentication.
You also left one out - replay protection, and that is very important.
/Compliant MIDCOM MIB implementations MUST support SNMPv3 security
  services including data integrity, data origin authentication and
  data confidentiality./Compliant MIDCOM MIB implementations MUST support SNMPv3 security services including data integrity, identity authentication,
  data confidentiality, and replay protection./

[Ballot discuss]
David Harrington reviewed the document at the request of the Security Area Director. Beyond the security aspects his review fout out a number of other issues. At least one of them seems to have the potential to be a critical issue in the way midcom device configuration is kept accross reboots, and I am holding a DISCUSS until the issue is clarified and answered.

---------

ifIndex is not necessarily persistent across reboots (hence the presence of ifAlias, which is). Because a physical configuration can change during a reboot (e.g., a card is removed from a chassis), ifIndex values can be renumbered. If the MIDCOM tables are persistent across reboots, what happens if the ifIndices change on reboot? The table entries would now point to the wrong interfaces.

The reason why ifAlias was defined is that an agent cannot necesarily tell, after the reboot, which ifIndex was assigned to which component before the reboot, and netiher can the MIDCOM-MIB implementation, so you cannt say just change the indices of your tables to match.

ifAlias helps by being consistent across reboots, but it is not set initially, so you need to make sure it is set to something other than a zero-length string before using it.

--------------

The full text of David's review can be found in the tracker.

[Ballot discuss]
The security considerations lack the usual statement discouraging deployment of SNMP versions
prior to SNMPv3.  The security considerations section of RFC 4898, for example, states:

Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.

Given that SNMPv3 mechanisms are mandatory to implement in this spec, I expected to see
something similar.  What was the rationale for excluding this statement?

[Ballot discuss]
The security considerations lack the usual statement discouraging deployment of SNMP versions
prior to SNMPv3.  The security considerations section of RFC 4898, for example, states:

Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.

Given that SNMPv3 mechanisms are mandatory to implement, I expected to see something similar.
What was the rationale for excluding this statement?

[Ballot discuss]
I don't believe that normative references to architectural or
framework documents are appropriate in this instance.  I don't believe
this is within the scope of down references anticipated by RFC 3967.
If we can get to a point where these documents are not required to
understand the protocol at hand or alternatively reclassify the
architecture document as proposed|bcp.

[Ballot comment]
On the call, I would like to talk about existing implementations, expected future implementations, what we will do with future midcom protocols that are actually in use, and if we might want to do anything about this.

[Ballot comment]
The security considerations section could point
out that there is no need to ensure that the
transactions affect only the owner's IP address.
This is because MIDCOM is mostly targeted for
SIP servers and other similar entities, not client
devices.

I am curious about the current state of the WG
and the plans for implementing this. Are there
any implementations ongoing? Which one of the
multiple solutions that exist in this space
actually are being used?

[Ballot comment]
I am curious about the current state of the WG
and the plans for implementing this. Are there
any implementations ongoing? Which one of the
multiple solutions that exist in this space
actually are being used?

[Ballot discuss]
The document is very clear on requiring authentication
and authorization of the clients. I also liked the
idea that entries created by a particular client remain
accessibly only for that client.

However, there is no discussion about the relationship
of the client authentication and the claimed internal
addresses. Does this mean that if two clients Alice
and Bob have addresses A0_Alice and A0_Bob in the
internal network, either one can create rules for
the other client's address?

Perhaps this is something that already exists
as a part of the SNMP security mechanisms. If
so, please document this. If not, please explain
the implications and/or add mechanisms to prevent
the problem.

[Ballot comment]
From the SecDir Review by Radia Perlman:

  I see no security problems with this document, and commend the
  authors for the very thorough security considerations section.

IANA Last Call Comment:

Upon approval of this document, the IANA will assign a mib-2 number for
midcomMIB in the Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) at the following location:

http://www.iana.org/assignments/smi-numbers

We understand this to be the only IANA Action for this document.

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?  Which chair is the WG
        Chair Shepherd for this document?

Yes, yes, and Melinda Shore (mshore@cisco.com).

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

Yes, the document has been iterated between the authors, the working
group, and the responsible MIB Doctor (Juergen Schoenwaelder) for several
years.  Because the working group is somewhat factionalized, some
participants have been particularly diligent in their reviews.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, internationalization,
        XML, etc.)?

No - at this time the document has received extensive review from
experts in other areas, particularly security and operations and
management.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

I suspect that this document has been overtaken by events outside of
the IETF (in fact, I'm certain of it) but I think it's important to
get the document finalized and published.

  1.e) How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

I think that working group consensus that the document is complete is
quite strong.  Working group consensus that the document is necessary
is somewhat (!!) less strong.  Not many people are happy that SNMPv2
was chosen, but there wasn't a procedural way around the fact that
it was the winner in the evaluation process.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.  (It should be
        separate email because this questionnaire will be entered into
        the tracker).

No.


  1.g) Have the chairs verified that the document checks out against
        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
        Boilerplate checks are not enough; this check needs to be
        thorough.

Yes.

  1.h) Has the document split its references into normative and
        informative?  Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state?

Yes, and no.


Technical summary:

The midcom working group was chartered to develop a protocol to
send requests from network endpoints/application participants to
network devices, initially focusing on firewalls and NATs.  The
charter required that the working group reuse an existing IETF
protocol if possible, and the working group followed an evaluation
process described in RFC 4097.  The protocol that best met
the evaluation criteria was SNMPv2.

The document being submitted for publication is the definition of
a MIB to be used to communicate pinhole requests to a firewall and
NAT table mapping requests to a NAT.

Working group summary:

There is working group consensus that this document is ready to
be published.

Protocol quality:

The protocol has received extensive review by applications experts
in the domain most likely to use a midcom protocol, by SNMP protocol
experts, and by middlebox experts.  We know of no existing
implementations, and it is not clear that it will be implemented given
the existence of competing protocols (for example, SIMCO).  This
protocol received particular attention in its early stages from
David Harrington, Wes Hardaker, and Mary Barnes, and recently from
its MIB Doctor, Juergen Shoenwaelder.