Visiting the IEEE website, we can find the details about the IEEE 802.11 standards and amendments displayed on a table: http://grouper.ieee.org/groups/802/11/Reports/802.11_Timelines.htm

In order to put them into perspective, I have displayed them on a timeline. 
As the new amendments and standards are released, this timeline will be updated.

Feel free to download and use the timeline as much as you want. As always, please feel free to share your feedbacks so we can make it better together.

The process made me realize that the 802.11 standard is 20 years old this year!

Click on image to open the PDF version:

Note: the timeline only displays the published amendments and standards. This is why you won't find 802.11ax for now!


written by François Vergès

The Magic Quadrant for the Wired and Wireless LAN Access Infrastructure has been released by Gartner on October 17th:

Just like last year, the same companies have been identified as leaders: Cisco and HPE Aruba. To me, this is no surprising at all, they lead and dominate the market. However, we can note that they are positioned a little closer to the visionaries section than last year.

Talking about the visionaries, we can see that Extreme Networks is clearly catching up and getting closer and closer to the leaders. Gartner has recognized the successful acquisitions made by Extreme over the past few months. If you want to learn more about it, Rowell Dionicio and I recorded a Clear To Send podcast episode about it with Mike Leibovitz from Extreme.

Among the new comers, Mist Systems has been positioned as a visionary by Gartner. I believe this was expected knowing that the startup has been growing at a fast pace over the past couple of years. They also focus heavily on AI and, therefore, I am not surprised to see them as visionaries.

The appearance of Mojo Networks as a new comer is also interesting, I believe. Mojo decided to advocate the open networking standards and is actively part of the Open Commute Project. This has modified their business model and impacted the company in a good way. They also focus on AI and machine learning.

We can also note that Ubiquiti Networks is not included in this Magic Quadrant. Having following their progress on the Uni-Fi brand, I believe that they are offering good products. However, according to Gartner, they “do not currently meet our inclusion criteria, but they can address enterprise access layer connectivity in certain usage scenarios. In some cases, these vendors sell to customers outside the traditional IT organization”. I would be interested to see how the company reacts to this MQ knowing the difficult times that they are experiencing right now.

The trend is clearly around software defined networks, artificial intelligence and machine learning. Gartner believes that more and more automation will happen at the access layer of our networks. Here is their prediction: "By 2022, more than 60% of IT organizations will use access layer network automation, up from less than 5% today."

Earlier this year, the Mobility Field Day 2 outlined this trend with presentations from vendors such as Mist Systems, Mojo Networks, Cape Networks and Nyansa.

I believe that, as Network Engineers, we need to prepare for the future and learn more about network automation, scripting and programming.

These are a series of videos and documents which will help you to technically understand KRACK. All you need is about 2 hours.

First, you need to understand the 4-way handshake. Marcus Burton is doing a great job explaining it in this video (6mins):

The following videos will have Hemant Chaskar and Vivek Ramachandran explain all of the KRACK vulnerabilities in technical details. Please watch them in order (79 mins).

Finally, read the research paper from Mathy Vanhoefm explaining his findings in details (25-30mins). 

At the end of this 2h KRACK learning session, you should have a better technical understanding of the different vulnerabilities.

Thank you!


​Written by François Vergès

By now you have probably heard that some WPA2 vulnerabilities have been discovered and made available to the public by Mathy Vanhoel on www.krackattacks.com.
This article will explain the implication of these vulnerabilities on enterprise WLAN networks.

Nine vulnerabilities has be revealed. Eight of them are client related and one of them is AP related.
Let's begin by explaining the client related vulnerabilities.

When a Wi-Fi network is configured using WPA or WPA2, different group of keys are used between the client device and the access point:

• PTK or Pairwise Temporal Key: keys used to protect unicast traffic
• GTK or Group Temporal Key: keys used to protect broadcast and multicast traffic
• IGTK or Integrity Group Temporal Key: keys used to protect management frames

These keys are generated and installed by the client and the AP during the 4-way handshake.  The 4-way handshake is happening right after the WPA2 authentication phase. The authentication phase is when the client is authenticating using a pre-shared key or 802.1X.
​Here is what a 4-way handshake looks like:

The vulnerabilities discovered are exploiting the fact that these keys (PTK, GTK, IGTK) can be re-installed by either the client or the AP. The attacks are, therefore, focusing on messages 3 and 4.

The fact of re-installing already-in-use keys will force some variables such as the Packet Number and the Nonce to be reset. This is important because these variables are used to generate the key stream ultimately used to encrypt data. If the keys are re-installed, the same key stream could be used more than once to encrypt data. The attacker will then be able to retrieve the plain text by applying a simple mathematical formula to encrypted packets transmitted using the same encryption key stream.

This means that all WPA2 networks are impacted (WPA2-Personal and WPA2-Enterprise).

This is a high level description of the following CVE:

• CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
• CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
• CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
• CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
• CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.​
• CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
• CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
• CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.​

For more details on each of them, I would encourage you to watch these really thorough videos produced by Mojo Networks and Pentester Academy: ​http://blog.mojonetworks.com/wpa2-vulnerability.

Now, let's go over the AP related vulnerability.
​
These keys (PTK, GTK, IGTK) are also installed by the client and APs during the 802.11r (or FT) handover. This is not done using the EAPOL packets used during the 4-way handshake. Instead, it is done using the 802.11 management packets used when a client roams:

• Authentication Request
• Authentication Response
• Re-Association Request
• Re-Association Response

 
Here is an example of these packet exchanges:

Unlike what the KRACK attacks website is stating, I don't believe that these weaknesses are in the Wi-Fi standard itself. I believe they are all implementation issues. This is a good news because it means that they can be fixed by applying patches!

You remember the 8 client related vulnerabilities? Is it easy to exploit them?
Well, a man in the middle (MiTM) attack is required in order for an attacker to be able to take advantage of these vulnerabilities. This involves the attacker creating a fake AP with 2 radio interfaces:

• One radio interface to talk to the AP on channel x
• One radio interface to talk to the client on channel y

The fake AP will need to spoof the MAC address of the real AP when talking to the client device in order for this attack to succeed.
Moreover, in order to have the victim client device connecting to the fake AP (rather than connecting to the real AP), the attacker would need to place the fake AP close to the victim client device.
These facts increase the complexity of executing such an attack.

Now, how could we fix these vulnerabilities?
The fix would be to have the client NOT re-installing keys if they are already installed. This can be done by updating the implementation of WPA2 on the client device by applying a patch (no hardware change required). This can be tedious if you are supporting a lot of Wi-Fi devices and need to apply patched to all of them. However, it is doable over time.

The issue arise if the vendor do not release any patch to fix this issue. What could you do then, to mitigate KRACK?
In order to mitigate KRACK, you can upgrade the code of your APs and controllers in order to have them mitigating the issue. The AP could stop re-transmitting packets during the 4-way handshake, therefore avoiding the attack to ever take place. The side effect of this mitigation technique could be the generation of false positives. In order to avoid them, you could have the AP de-authenticating the client and forcing the client to go through a full new connection.

Moreover, you could use WIPS (Wireless Intrusion Prevention System) to detect the MiTM attacks and prevent the client devices to connect to these fake APs.

Now, what about the AP related vulnerability (802.11r handover)? Is it easy to exploit it?
It is actually much easier to exploit this vulnerability. No MiTM attack is required. The attacker will be sniffing the packets and replaying them later. This is called a replay attack.

How could we fix this issue?
Since there is no way for the AP to know if the traffic received is traffic coming from a replay attack, the only way to fix is to have the AP NOT re-installing keys if they are already installed.
This can be done by changing the implementation of WPA2 on the controller or AP applying a patch.
Some vendors have already released their patch code and the rest of them will in the coming days.

Following the arguments presented in the previous section, I don't believe this is the end of WPA2. In the coming days, we will see vendors starting to roll out patches in order to avoid these type of vulnerabilities to be exploited.

Most companies have acknowledged the KRACK vulnerabilities and some of them have already released their patches. See this really good article from Andrew Von Nagy for more details: http://www.revolutionwifi.net/revolutionwifi/2017/10/wpa2-krack-vulnerability-getting-information

Patches will be able to fix most of the devices out there. But now, what about these IoT devices that you will never patch? What about these devices that will never receive patches? 8 out of the 9 vulnerabilities revealed will be able to be exploited against them.

So what is next? Do we need a WPA3? 
I believe that, for now, these patches will protect most of the enterprise WLAN networks. However, sooner or later, we will need to provide better security for IoT devices connecting to Wi-Fi networks. Does it mean WPA3? Does it mean that the IEEE will release a new security 802.11 amendment? I guess we will have to wait and see.

To be honest, I am a little worried by the way Mathy Vanhoel concluded his article: 

Here is a list of additional ressourses used to write this article or useful to learn more about KRACK:

• The KRACK attacks website:  https://www.krackattacks.com/
• The detailed research paper:  https://papers.mathyvanhoef.com/ccs2017.pdf
• The series of videos from Mojo Networks:  http://blog.mojonetworks.com/wpa2-vulnerability
• The great summary from Andrew Von Nagy:  http://www.revolutionwifi.net/revolutionwifi/2017/10/wpa2-krack-vulnerability-getting-information
• A security point of view from WiFiTraining.com:  https://wifitraining.com/blog/wpa2-vulnerability-krack-know/
• A great summary from Alex Hudson: https://www.alexhudson.com/2017/10/15/wpa2-broken-krack-now/
• Cisco's security advisory message: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa
• Aruba's security advisory message: http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007.txt

Thank you!

Cheers,


​written by François Vergès

​Wi-Fi, as most of us know, operates on the 2.4GHz or 5 GHz band. But there are, actually, others 802.11 protocols utilizing other frequency bands (900MHz, 60GHz,...). Today, we will be talking about the regulations of using the 60GHz frequency band in Canada. This band is used for the 802.11 protocols known as 802.11ad (now 802.11-2016 Clause 20) and 802.11ay.

In Canada, ISED (previously Industry Canada) is in charge of regulating frequencies. The information you will find in this blog article are coming from the following document published by ISED called RSS-210 — Licence-Exempt Radio Apparatus: Category I Equipment.

The section we are interested in today is called Annex J — Devices Operating in the Band 57-64 GHz.

​There are 3 channels available in the 60GHz band in Canada. These channels are 2.16GHz wide:

• 1st channel: from 57.24 GHz to 59.40 GHz
• 2nd channel: from 59.40 GHz to 61.56 GHz
• 3rd channel: from 61.56 GHz to 63.72 GHz

Below is a graphic showing which other channels are used in this 60 GHz band across the world. You will notice that channel 2 is available everywhere:

Here are the power regulations for indoor devices:

• Output power: max. 500 mW
• Average EIRP: max. 40 dBm (10 W)
• Peak EIRP: max. 43 dBm (20 W)

The regulations for outdoor devices are more complicated and you can find them under section J.2.2. However, I believe that most of the 802.11ad and 802.11ay products will be intended to be used indoor.

Here are a few links to learn more about the subject:

• 802.11ad white paper from IEEE: http://ieeexplore.ieee.org/document/6979964/?reload=true
• IEEE 802.11ay task group: http://www.ieee802.org/11/Reports/tgay_update.htm
• Dragos Mihai Amzucu' blog: http://nextwirelessstandard.blogspot.ca/
• ISED document: http://www.ic.gc.ca/eic/site/smt-gst.nsf/eng/sf01320.html
• Ekahau Webinar: WiGig and Ha-Low – Wi-Fi at New Frequency Bands

Thank you for stopping by and reading the blog.

Cheers!


written by François Vergès

A while back, I worked on a reference sheet on the most useful Cisco AireOS commands. It was well received and Cédric Terrier from WattisWiFi contacted me to build a similar reference sheet for the ArubaOS. He has a lot of experience with Aruba and came up with a list of all the commands he uses on a regular basis. I recently worked on an Aruba deployment and thought it would be the perfect time to work on building this reference sheet. So this reference sheet is a result of our collaboration.

Feel free to download and use the reference sheet as much as you want. Don't hesitate to tell us what you think. This is the first version and we are hoping to improve it with your feedbacks.

​Click on the image to open the PDF version:

written by François Vergès

Wifitraining.com is offering a series of videos, in which I participated, called Rockstar Wireless Networking (RWN) introducing the Wi-Fi technology. Please register on the wifitraining.com website to gain free access to these videos at https://www.wifitraining.com/register.

The goal of these videos is to introduce the Wi-Fi technology to anyone who would be interested in.

They cover the following topics:

• RF Fundamentals
• Wi-Fi (IEEE 802.11) Fundamentals
• Wi-Fi Design
• Wi-Fi Security
• Wi-Fi Troubleshooting

The videos will go live on May 21st, 2017.
Please feel free to share this with your friends and colleagues. 
If you have any feedback about this course, please send us a review through this link.

Here is the course introduction:

If you want more details about this course, please visit the following link:
wifitraining.com/blog/rockstar-wireless-networking-release-52117/
​
I hope you will enjoy these videos.

Cheers,



written by François Vergès

Today’s exercice is simple: study the beacon frame and try to figure out what characteristics of the Wi-Fi network are advertised.

In this article, we will be focusing on IEEE 802.11k support.

IEEE 802.11k-2008 or "Radio Resource Measurement" (not to confused with the Radio Resource Management used by Cisco Wireless LAN Controllers) is an amendment which was publish in 2008 and added to the IEEE 802.11-2012 standards. Various types of measurements are defined that enable 802.11 stations to request measurements from other stations. Information that needs to be measured to optimize the radio network. For example, with 802.11k, stations are able to assess how occupied or idle a frequency channel is. The corresponding request and report mechanisms, and the formats of the frames through which the measurement requests and results are communicated among stations, are defined by the 802.11k amendment.

If you want to learn more about how IEEE 802.11k, please read the following documents from the IEEE:

• ​IEEE 802.11k document: https://standards.ieee.org/findstds/standard/802.11k-2008.html
• Section "Clause 10.11 Radio measurement procedures" of the 802.11-2012 standard: Link to download the IEEE 802.11-2012 standard
• Section "Clause 11.11 Radio measurement procedures" of the 802.11-2016 standard: Link to download the IEEE 802.11-2016 standard

Looking at a beacon frame in order to find 802.11k support, we need to validate that these different information elements (IE) are there:

• The "Country" element
• The "Power Constraint" element
• The "Radio Management (RM) Enable Capabilities" element

If these information element are not present in the Beacon, the Wi-Fi network does not support 802.11k. Here is an example of a Beacon only advertising the "Country" element. As you can see , the "RM Enable Capabilities" and "Power Constraint" elements are missing.

Now we are going to enable 802.11k support on the SSID.

In order to enable 802.11k support on a WLAN profile on a WLC, you will need to:

• Navigate to the "WLAN" menu
• Select the WLAN profile that you would like to configure. This will open up the configuration view
• In the configuration view, select the "Advanced" tab
• Finally, in the "Advanced" tab, under the 11k section, check the following check boxes:
  • "Assisted Roaming Prediction Optimization" & "Neighbor List": the controller will create an optimized list of neighbors to send to the client
  • "Neighbor List Dual Band": By default, the neighbor list contains only neighbors in the same band with which the client is associated. This option allows 802.11k to return neighbors in both bands.

You can now apply and save your new configurations.

Once the configurations have been applied and that the APs start broadcasting the new beacons frames, you are now able to see all the specific informations elements (IE):

Thank you for reading, in the next post, we will explain how to check if a Wi-Fi network is supporting 802.11r.

If you want to know how the client devices can take advantage of 802.11k to better roam, head over to Rasika's blog: 
mrncciew.com/2014/09/11/cwsp-802-11k-ap-assisted-roaming/

If you want learn how to check if a Wi-Fi network is supporting 802.11v, head over to this post:
www.semfionetworks.com/blog/wireshark-how-to-check-if-a-wi-fi-network-supports-80211v
​
If you want to optimize the way you use Wireshark to perform Wi-Fi analysis, head over to this post:
www.semfionetworks.com/blog/wireshark-most-common-80211-filters

Cheers'


written by François Vergès

This post is directly related to the following previous article: "Wireshark: How to check it a Wi-Fi Network Supports 802.11v".

In the previous article, we talked about how to check if a specific Wi-Fi network is supporting IEEE 802.11v, from the access point perspective. Like anything in Wi-Fi, we need support from both the access point and the STAs in order for it to work.

So in this article, we are going to explain how we can validate is a specific client device supports 802.11v.

I would like to address special thanks to Phil Morgan for providing useful information and giving me the idea to write this follow up post.

We were checking the Beacon frame broadcasted by the AP in order to validate if a specific SSID was supporting 802.11v. In order to check if a specific client supports it, we need to take a look at the Association Request frame sent by the client device when it connects to the Wi-Fi network. (cf. diagram below)

Note: before we start looking deeper into the association request frame, something important needs to be noted regarding 802.11v client support. Since the support of 802.11v is advertised by the AP in the beacon frames the station will be aware of 802.11v support within the BSS and will only advertise its support for 802.11v in its association request if it is advertised by the AP in the beacon frame.
So if you are performing your own packet captures, make sure you enable 802.11v support on the access point first.

Once again, looking at the association request frame in order to find 802.11v support, we need to focus on the Extended Capabilities Information Element number 127 and look at the 4th bit of the 3rd octet. This bit is most commonly named the "BSS Transition bit". If the bit is set to "1", the client device support 802.11v.

The following screenshot shows the BSS Transition bit of an association request sent by a Samsung Galaxy S7 Edge. This is taken from the .pcap files available on Mike Albano's website.

Mike Albano did a really good job studying the most common Wi-Fi client devices. He documented his work on his website called clients.mikealbano.com. I'm talking about his website because there is an option to filter only the devices supporting 802.11v.

Make sure to read the note at the bottom of the page related to IEEE 802.11v support.

So if you are not sure if a specific client supports 802.11v, you can head over to his website and perform a quick research. You can even download a .pcap file for every device containing an association request.

On a Cisco Wireless LAN Controller, there is a way to check if an associated client supports IEEE 802.11v. Obviously, as explained earlier, this client device has to be associated to an SSID already advertising the BSS transition capability.

So once the client is associated to the Wi-Fi, head over to the "Monitor" page, on the left menu, select "Clients".  This will open up a new page displaying all the client devices connected to your different Wi-Fi networks supported by the controller.
Click on the mac address of the client that you want to study. This will open up a new page providing more detailed information related to this specific client.
​On this page, you will be able to see if it support IEEE 802.11v, as shown below, under the "802.11v BSS Transition" sub-section:

If the client device supports it, you will see "Supported", if it doesn't, you will see "Not Supported".


Thank you for reading!

Cheers'


​
written by François Vergès

Today's exercice is simple: study the beacon frame and try to figure out what characteristics of the Wi-Fi network are advertised.

In this first article, we will be talking about 802.11v.

Looking at a Beacon frame in order to find 802.11v support, we need to focus on the Extended Capabilities Information Element number 127 and look at the 4th bit of the 3rd octet. This bit is most commonly named the "BSS Transition bit".

Below is a look at a Beacon of a Wi-Fi network not supporting 802.11v. As you can see, the BSS Transition bit is set to "0".

Now, we are going to enable 802.11v support on this same SSID.

In order to enable 802.11v on a WLAN profile on a Cisco WLC, you need to

• Navigate to the "WLAN" menu
  
• Select the WLAN profile you want to modify in order to open up the configuration view
  
• In the configuration view, select the "Advanced" tab
  
• Finally, in the advanced tab, under the "11v BSS Transition Support" section, select the "BSS Transition" option as shown in the image bellow:

You can now apply and save your new configurations.

Once the configurations have been applied and that the APs start broadcasting the new beacon frames, you are now able to see that the BSS Transition bit has been set to "1".

Thank you for reading. In the next post, we will explain how to check if a Wi-Fi network is supporting 802.11k.

If you want to optimize the way you use Wireshark to perform Wi-Fi analysis, head over to this post: www.semfionetworks.com/blog/wireshark-most-common-80211-filters

Cheers'

​
written by François Vergès