Atoca WG Gabor Bajko
Internet Draft Nokia
Intended Status: Informational October 31, 2011
Expires: April 30, 2012
Emergency Alert Service support in IEEE 802.11 networks
draft-bajko-atoca-wlan-eas-01
Abstract
The IEEE 802.11 specification is evolving by defining new amendments
to it, which are then rolled into the base spec. The 802.11u
amendment, published in November 2010, contains support for Citizen
to Authority type of Emergency Calls and Authority to Citizen type
of Alerts.
This document attempts to explain what level of support for
Authority to Citizen type of Emergency Alerts has been defined for
IEEE 802.11 protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bajko Expires April 30, 2012 [Page 1]
EAS in wlan October 31, 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Content
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
3. Emergency Alert Service indication at a wifi AP . . . . . . . . 3
4. Retrieving an EAS message . . . . . . . . . . . . . . . . . . . 5
5.
Bajko Expires April 30, 2012 [Page 2]
EAS in wlan October 31, 2011
1. Introduction
This document assumes the reader is familiar with the basics of the
802.11 protocol.
A STA first listens in a channel to see if there are any APs
operating in that channel. If there are, then the STA will receive a
beacon. This is the so-called passive scanning procedure. The STA
may also choose to send a Probe Request in the channel and wait for
a Probe Response. The Probe Request is sent to a broadcast address
and contains conditions which an answering AP must satisfy. This is
called active scanning.
A STA can only exchange data frames with an AP after the so-called
association and authentication (if required) procedure. Management
frames however, can be exchanged even before the association and
authentication procedure, which the 802.11 specification calls pre-
association frame exchange.
2. Conventions and Terminology
2.1 Conventions used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
2.2 Terminology
STA station, a device communicating with an 802.11 access point
GAS Generic Advertisement Service Protocol, defined in 802.11
3. Emergency Alert Service indication at a wifi AP
An AP compliant with the IEEE 802.11-2011 specification will have a
MIB variable called dot11EASActivated which has the following
definition:
dot11EASActivated OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is a control variable.
It is written by an external management entity or the SME. Changes
take effect as soon as practical in the implementation. This
attribute when true, indicates the STA is capable of supporting
emergency alert system. The capability is disabled otherwise. "
DEFVAL {false}
::= { dot11StationConfigEntry 128 }
Bajko Expires April 30, 2012 [Page 3]
EAS in wlan October 31, 2011
When this MIB variable is set to TRUE, then the AP supports this
feature. Else the AP does not support this feature.
When this MIB variable is set to true and there are emergency alert
messages in the network, then the beacon will contain one Emergency
Alert Information Element for each active alert message, in the
beacon. These Emergency Alert Information Elements have to also be
included in the Probe Response Frames, when a STA asks for it in a
Probe Request Frame.
The Emergency Alert Identifier element provides a hash to identify
instances of the active EAS messages that are currently available
from the network. The hash allows the STA to assess whether an EAS
message advertised by an AP has been previously received and
therefore whether it is necessary to download from the network. The
format of the Emergency Alert Identifier element is:
0 7 13 79
+---------------------------------------------------+
| Element ID | Length | Alert Identifier Hash|
+---------------------------------------------------+
The Length is a 1-octet field whose value is equal to 8.
The Alert Identifier Hash (AIH) is an 8-octet field. It is a unique
value used to indicate an instance of an EAS message. The value of
this field is the hash produced by the HMAC-SHA1-64 hash algorithm
operating on the EAS message.
AIH =HMAC-SHA1-64("ES_ALERT", Emergency_Alert_Message)
where AIH is then truncated to the first 64 bits of this function.
The Emergency_Alert_Message is the EAS message itself.
NOTE: The same value of hash will be computed by each AP in an ESS
and by each AP in different ESSs. Thus a STA, which can download
emergency alert messages when in a pre-associated state, can
unambiguously determine that it has already downloaded the message,
avoiding unnecessary duplicates.
4. Retrieving an EAS message
The STA can find out whether there are any EAS messages in the
network by looking for Emergency Alert Information Elements in the
beacon or Probe Response messages.
When the STA finds out that there are EAS messages in the network,
it can access those messages with the protocol defined in 802.11-
2011.
The STA can check if it had previously downloaded that alert message
by computing a hash of the message and comparing it with the hash
Bajko Expires April 30, 2012 [Page 4]
EAS in wlan October 31, 2011
value present in the Emergency Alert Information Element of the
beacon or probe response frame.
The STA does not have to be associated with an AP in order to access
and download the EAS message, it can do that in the pre-associated
state as well. The STA needs to send a GAS Request public action
frame to the AP by setting the Element-ID of the request to the EAS
value and including the hash of the EAS message into the Query
Request field. Then, in the GAS Response frame, the AP will deliver
the requested EAS message to the STA.
According to the 802.11 specifications, the EAS message in the GAS
Response frame is expected to be formatted in accordance with OASIS
EDXL.
A STA which is already associated and authenticated with an AP, can
also use GAS ANQP protocol to download the URI of a local Emergency
Alert Server. The STA can then retrieve the EAS message using a URI
formed by concatenating the downloaded local Emergency Alert Server
URI with the hexadecimal numerals of the Alert Identifier Hash
converted to UTF-8 encoded characters and the ".xml" file extension.
For example, if the Emergency Alert Server URI is
http://eas.server.org and the Alert Identifier Hash is
"0x1234567890abcdef", then the URI would be
http://eas.server.org/1234567890abcdef.xml
The XML file is expected to be formatted in accordance with OASIS
EDXL.
The mechanism by which the EAS message is retrieved from the formed
URI is not specified in the 802.11 specification.
When an EAS Message has expired, an AP with dot11EASActivated set to
TRUE shall remove the corresponding instance of an Emergency Alert
Identifier element from its Beacon and Probe Response frames.
5. Protocol considerations
An Emergency Alert distribution protocol intended to work with WiFi
Access Points will need to deliver the Alert message to the AP,
which in turn will need to save it in a MIB variable. Currently
there are no MIB variables defined in the 802.11 standard to store
Alert messages.
Once the AP, which has EAS implemented and enabled, receives an
Alert message, it needs to include an Emergency Alert Information
Element into the beacon and probe responses, and remove it once the
Alert message expires.
The AP would probably need to register itself to an Alert
Distribution Server in order to receive the Alerts.
6. IANA considerations
Bajko Expires April 30, 2012 [Page 5]
EAS in wlan October 31, 2011
None.
7. Security considerations
This document is provided for information to the IETF community. The
protocol described here relies on the existence of a protocol which
can distribute emergency alert messages to the wifi access points.
As described here, the STAs can access an alert message in pre-
associated state as well, when the STA did not authenticate the AP
or the network behind the AP. Careful consideration should be taken
on when such an alert message can be trusted and be displayed on the
screen of a wifi device.
8. Normative References
9. Informative References
http://standards.ieee.org/getieee802/download/802.11-2007.pdf
http://standards.ieee.org/getieee802/download/802.11-2011.pdf (to be
available in 2012)
10. Author's Addresses
Gabor Bajko
gabor.bajko@nokia.com
Bajko Expires April 30, 2012 [Page 6]