IEEE 802 LIAISON UPDATE
IEEE 802 Review of IETF Documents
The 802.11 WIEN study group has reviewed draft-adrangi-eap-network-discovery-03.txt as promised, and are now in the process of reviewing draft-ietf-eap-netsel-problem-01.txt. This review was originally requested by Stuart Kerry, Chair of 802.11, in order to prevent potential conflicts with the work of the 802.11 WIEN study group (now about to be chartered as 802.11u).
IETF Review of IEEE 802 Documents
Dan Romascanu and Dave Harrington have provided review of multiple revisions of 802.1ab, and Dave Harrington has provided “MIB Doctor” reviews of the revisions.
NEW WORK REVIEW
In terms of new work review, 802.11 has recently begun Letter Ballot 72, a vote to approve the Wireless Network Management PAR. The PAR, described in 11-04-0537-08-0wnm-draft-par-ieee-802-11-wnm_re-formatted.doc, cites deficiences in SNMP as justification for design of a new management framework for 802.11. Some of these deficiencies are being addressed in ISMS, and some of the claimed deficiencies are not correct (such as the claim that SNMP requires IP transport, despite RFC 1089). I don’t recall this PAR being included on the New Work list, but there does appear to be some potential for conflict (or at least misunderstanding) here. Dave Harrington’s analysis of the WNM PAR below.
A question has come in from IETF community relating to the PAR of 802.11u (formerly 802.11 WIEN). The PAR includes within its scope discovery mechanisms, and as such would appear to overlap with the PARs for 802.21, 802.1af, and potentially 802.1ab. The question has arisen about the distinctions between these groups. I have posed this question to IEEE 802.1 (the group responsible for IEEE 802 architecture), but it would appear that there is not universal agreement on the divison of responsibility between the existing and recently proposed PARs.
Given this, it is possible that new work on a media independent approach will be proposed in the IETF. At one point a BOF was proposed on DDP (see
http://www.watersprings.org/pub/id/draft-marques-ddp-00.txt) but this was subsequently withdrawn.
In other news, there are indications that NIST will refuse to certify the IEEE 802.11i standard as FIPS compliant. Details on the ruling are not available at this time, but questions have arisen as to whether changes will be required in 802.11i, in IETF documents cited by 802.11i (such as RFC 3579 & 3748) or IETF documents relating to 802.11i (such as draft-ietf-eap-keying-03.txt). At this point the implications of the potential ruling are unclear. A request for clarification has been sent to NIST.
APPENDIX A – Review of the IEEE 802.11 WNM PAR
I just reviewed the PAR. I agree there is potential for conflict, both with the SNMP efforts underway, and to a degree with the XMLConf efforts, and there are some misunderstandings.
The PAR makes assertions that may require further consideration; here is my analysis
- The purpose is to “enables management of attached stations in a centralized or in a distributed fashion (e.g. monitoring, configuring, and updating) through a layer 2 mechanism.” yet the next sentence in the PAR limits this, “While the 802.11k task group is defining messages to retrieve information from the station, the ability to configure the station is not in its scope.” Our experience with SNMP is that the write capabilities are the most difficult to “get right”.
Focusing on only the monitoring capabilities could lead to a protocol that will be inadequate for configuration. I am concerned that a monitoring-only protocol developed by the IEEE 802.11 WG could repeat the errors of SNMPv1. Attempting to “bolt-on” security and configuration after the monitoring portion is standardized could prove as difficult to develop and to configure as SNMPv3.
SNMPv1 is considered a good monitoring protocol. SNMPv1 has not been widely deployed for configuration because it does not address security; SNMPv3 has been developed to provide SNMP security. SNMPv3 has not been widely deployed for configuration because it is itself difficult to configure; as pointed out, improving the ease of configuration of SNMPv3 is being addressed by the ISMS WG. For further information, see IAB Network Management Workshop,
Because SNMP has design constraints that conflict with the common CLI approach to configuration, XMLConf is under development to provide a standardized programmatic interface for configuration. XMLConf also includes the ability to retrieve information from the configured device.
So I suggest that if the PAR is approved, it should be for a protocol that addresses monitoring, configuration, and updating, including security.
- “Very few stations in the market include SNMP capabilities” seems at odds with the input we have received. Of course, “the market” isn’t defined here, so it is difficult to argue with (or support) the assertion. Enterasys competes in the 802.11 market, and most of our competitors appear to support SNMP in their 802.11 devices, so I think there should be further clarification of this assertion. Operators use SNMP widely for monitoring; see the NANOG survey results presented in
http://www.ietf.org/proceedings/04aug/slides/isms-1.pdf , and the input to the IAB Network Management Workshop in
- “The use of secure SNMP protocol (e.g. SNMPv3) requires significant pre-configuration of the station” is actually a common misunderstanding. Just as with a UNIX box, the only pre-configuration required is to define a “root” user with full read-write access; once this is done, all other users and access rights (if desired) can be configured by the “root” user using SNMPv3. SNMPv3 uses “groups” to minimize the amount of update needed to add or delete a user’s configuration. Most environments require a very small number of groups (i.e. less than 3 )with different access rights. In addition, a number of widely-deployed NMS platforms in the market support defining an SNMPv3 “user” that corresponds to the application, and all requests are performed by the application on behalf of its authenticated/authorized users, thus simplifying the configuration of SNMPv3.
- “Management of a station may be required prior to the establishment of an IP connection. There are cases where a device must be managed because it cannot get IP connectivity.” As Bernard pointed out, SNMP does not need to run only on IP; adding a layer2 “transport” should be easily accomplished by defining a layer2 trasnport mapping for SNMP, using an existing layer 2 protocol to carry SNMP messages. See RFC 3417 for examples of transport mappings. This would be far simpler than defining a new management protocol from scratch.
- I agree that the current MIB does not support all current and emerging features. As a MIB Doctor, I recommend that the current MIB be “supplemented” with new mib modules to manage the new features.