lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 4 Jun 2014 00:18:37 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Johannes Berg <johannes@...solutions.net>,
	Liraz Perelmooter <liraz.perelmooter@...el.com>
Cc:	Rostislav Lisovy <lisovy@...il.com>,
	"John W. Linville" <linville@...driver.com>,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	Michal Sojka <sojkam1@....cvut.cz>, s.sander@...dsys.de,
	jan-niklas.meier@...kswagen.de,
	Rostislav Lisovy <rostislav.lisovy@....cvut.cz>,
	wireless-regdb@...ts.infradead.org, green@....qualcomm.com
Subject: Re: [RFC 1/4] cfg80211: Add channel flags limiting availability to
	OCB mode only

On Tue, Jun 03, 2014 at 10:01:33PM +0200, Johannes Berg wrote:
> On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote:
> > IEEE 802.11p operates in its own 5.9GHz band. When there will
> > be a record for the 5.9GHz band in the regulatory daemon,
> > it must be limited to the OCB mode only -- using the newly
> > added flags.
> 
> Is this really a *regulatory* limitation? Rather than a limitation
> elsewhere, e.g. the spec?

Our engaged and capable *real* regulatory folks in the community are:

  * Liraz Perelmooter <liraz.perelmooter@...el.com>
  * Michael Green <green@....qualcomm.com>

Additionally we have the wireless-regdb mailing list [0] which we should
Cc for inquiries and verification on things like this. We hope for their
participation as they are our real experts who grind away at the specs.

Rostislav, can you provide documentation references which would clarify
the stance on 802.11p and restrictions for only allowing  OCB mode?
Also your patches seem to refer to the 802.11p ammendment work to 802.11,
but it is now merged as of IEEE 802.11-2012 as per Jouni's last update to us
on the standards work [1]. As per Jouni's slides 802.11p-2010 made it as an
ammendment into 802.11-2012 and this work is rerrred to as "Wireless  Access
for the Vehicular Environent". It would be *useful* if you'd refer to the IEEE
802.11-2012 standard then and document as part of your patches the exact
sections and references that about Wireless Access for the Vehicular
Environment.

For reference to others this comes in as a full patch series by Rostislav
to add some form of "802.11p" support using OCB (Outside the Context of BSS)
mode. This mode of operation allows devices to send frames not connected
to a BSS. The patch in question above is for the regulatory flag that is
being proposed to be added, the full series of the other patches can be
seen on the mailing list archive [2]. Rostislav clarifies that when OCB
mode is used all the STAs communicate with each other without the need
for a coordinator. The 5.9 GHz band is being clarified to be used for 802.11p,
the patch series also is specifying that when 5.9 GHz is enabled only
OCB mode of operation is allowed on that band. No references are made to
the specific 802.11 ammendment / IEEE 802.11 sections or more importantly it is
not being made clear if the OCB mode is something that differs depending
on regulatory bodies at this point.

Since 802.11p was designed for cars in mind I suspect regulatory bodies
likely do want proper rules followed, but its unclear what countries
that follow either IEEE 802.11 or the ISO equivalent want OCB mode of
operation and if they also have the same restrictions of only allowing
5.9 GHz operation only for OCB. I can also imagine for example of regulatory
bodies that may want to allow 5.9 GHz for non OCB mode, specially if they
need the spectrum. One particular use case which provides a compromise
could be for example to have APs/P2P GOs look for OCB communication and
if its detected to disallow it. Not like I would recommend this given
that it would then introduce crazy regulatory compliance silliness
such as seen with DFS and that pushed crazy implementation and designs,
but -- its certainly possible.

So is this an IEEE compliance thing or regulatory thing? If its a generally
accepted IEEE compliance thing for 802.11-2012 then I don't see why we
don't just hard code this restriction on cfg80211 for the band. That
after all would be the much more saner thing to do than all the silly
mess of discrepencies betwen regulatory bodies. After all cfg80211 is for
802.11, and if we follow the specs and if its mentioned clearly there I
see no resason why not to hard code this. If folks want to override this
(I envision university environments doing research on this) the patch can
add a Kconfig option that depends on CONFIG_CFG80211_CERTIFICATION_ONUS
which will make the check permissive on 5.9 GHz instead of fully enforced.

[0] http://lists.infradead.org/mailman/listinfo/wireless-regdb
[1] http://wireless.kernel.org/en/developers/Summits/Barcelona-2012?action=AttachFile&do=view&target=ieee80211-barcelona-2012.pdf
[2] http://comments.gmane.org/gmane.linux.kernel.wireless.general/121022

  Luis

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ