There is a problem with some assertions made in the PANA Framework draft with respect to the operation of 802.11. The specific paragraphs are the following in section 10.2.2, PANA with Bootstrapping WPA/IEEE 802.11i: " This model does not require any change in the current WPA and IEEE 802.11i specifications. This also means that PANA doesn't provide any link-layer security features beyond those already provided for in WPA and IEEE 802.11i. The IEEE 802.11 specification [802.11] allows Class 1 data frames to be received in any state. Also, IEEE 802.11i [802.11i] optionally allows higher-layer data traffic to be received and processed on the IEEE 802.1X Uncontrolled Ports. This feature allows processing IP- based traffic (such as ARP, IPv6 neighbor discovery, DHCP, and PANA) on IEEE 802.1X Uncontrolled Port prior to client authentication." 802.1X does indeed allow the option of additional protocol entities operating over the uncontrolled port. This is described in clause 5.2 of 802.1X-2004. This being an option of 802.1X, it is very likely to be inconsistently implemented. In 802.11i, clause 6.1.4 describes the following: "The IEEE 802.1X Controlled/Uncontrolled Ports discard the MSDU if the Controlled Port is not enabled or if the MSDU does not represent an IEEE 802.1X frame." This is an additional, more restrictive requirement that goes beyond the 802.1X requirement. This additional requirement of 802.11i would seem to make the operation of any other protocol entity on the uncontrolled port problematic. Finally, the framework claims that data frames are class 1 and available to be sent and received at any time. This is the case only for an independent BSS (ad hoc WLAN), when both the To DS and From DS bits are zero. See 5.5 a) 3) i) in 802.11-1999. In an infrastructure network with an AP, where either the To DS or From DS bit is set to 1, data frames are class 3 and available only after both association and authentication. See 5.5 c) 1). These problems would seem to prevent this bootstrapping mode from operating without requiring changes to 802.11 and/or 802.11i. I would suggest that removal of this section from the draft would resolve these problems. The remaining modes described using 802.11 and 802.11i are not impacted by these problems. -Bob Bob O'Hara Cisco Systems - WNBU _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf