ads

Style6

Style3[OneLeft]

Style3[OneRight]

Style4

Style5[ImagesOnly]

Style2

Harden RRAS IKEv2

How To:  

Harden Windows Server 2012R2 Routing and Remote Access (RRAS) VPN server.  Implement strong IKEv2 VPN cryptography:
• Diffe-Hellman Group (DH) 14 or DH Group 19
• Enable AES256 and SHA256 L2TP/IPsec and IKEv2 on Windows Server VPNs.

This simple method significantly improves security strength for Windows 2012 IPsec VPNs.

Problem:  

Windows RRAS server negotiates insecure IKEv2 and L2TP/IPsec cryptographic algorithms:

  • DH2-3DES-SHA1.   
Weak security strength risks data integrity and confidentiality.  IKE SA authenticates with RSA certificates.

This problem impacts all RRAS VPN clients:  Windows 10 phones, iPhones, Android, Cisco, Juniper and Sawn.  

Solution:  

Enable strong IPsec security algorithms in the Windows server registry:

  • IKEv2 DH14-AES256-SHA256

This (mostly) original approach is hands-down the easiest way to secure a Windows 2012 IKEv2 or L2TP/IPsec VPN.

Step 1:  Regedit:

HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IKEV2\

Step 2:  Create new key:

\IKEv2CustomPolicy\

Step 3:  Create new DWORDs (Table 1):



Table 1
IKEv2CustomPolicy DWORD Attributes

IntegrityMethod1Integrity check algorithm to be negotiated during MM SA negotiation [RFC4306].
INTEGRITY_SHA1 (0x1)
INTEGRITY_SHA_256 (0x2)
EncryptionMethod4Encryption algorithm to be negotiated during MM SA negotiation [RFC4306].
CIPHER_AES_128 (0x2)
CIPHER_AES_256 (0x4)
CipherTransformConstant5Encryption algorithm to be negotiated during QM SA negotiation [RFC4306].
(0x3) CIPHER_CONFIG_CBC_AES_128
(0x5) CIPHER_CONFIG_CBC_AES_256
AuthTransformConstant1Specifies the hash algorithm to be negotiated during QM SA negotiation [RFC4306].
AUTH_CONFIG_HMAC_SHA_1_96 (0x1)
HMAC secret key authentication algorithm. SHA-1 (Secure Hash Algorithm) data integrity and data origin authentication algorithm. [RFC2404].
AUTH_CONFIG_HMAC_SHA_256_128 (0x2).
HMAC secret key authentication algorithm. SHA-256 data integrity and data origin authentication algorithm.
DHGroup3Type of Diffie-Hellman group used for Internet Key Exchange (IKE) key generation during MM SA negotiation [RFC4306].
DH_GROUP_2 (0x2)
DH_GROUP_14 (0x3)
DH_GROUP_2048 (0x3) - IKE for DH-14. Name change to match standard terminology
PfsGroup0Diffie-Hellman algorithm to be used for Quick Mode Perfect Forward Secrecy (PFS) [RFC4306].
PFS_NONE (0x0)
PFS_2 (0x2)
PFS_2048 (i.e., DH-14) (0x3)
PFS_MM (0x6) - Uses same DH as MM that contains this QM.
Note: DWORD values for IKEv2 Custom Policy Key: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IKEV2\IKEv2CustomPolicy\
This method also supports stronger security (e.g., DH-EC and GCM).  See MSDN MS-RRASM for additional options.

Additional Thoughts:

Client Requirements:

VPN clients must support the same cryptography in order to connect.  Consider how Windows clients use DH2-3DES-SHA1 by default (yikes).  I'll provide instructions on how to update Windows 10, iPhones, and Android IPsec clients in an upcoming article.

PowerShell:

PowerShell can implement stronger IKEv2 secuirty targets for both Windows 8.1 and 2012R2:

New-NetIPsecMainModeCryptoProposal -Encryption AES256127 -Hash SHA256 -KeyExchange DH19
Be warned, the process is challenging.  If you go this route don't test it out on production servers.  Also, the TechNet examples create new GPO policy specific to IKEv2.  It does not account for all the other firewall rules.  In other words, it creates a new firewall policy that only permits IKEv2 traffic -it's easy to get locked out without console access.  

The trick is to copy ALL firewalls rules and IPsec rules, crypto-sets, and IPsec rules (and anything else I haven't thought of) to the new GPO -all through PowerShell.  Alternately, use the GUI to copy the existing firewall settings to a separate firewall policy (i.e., separate from the PowerShell IKEv2 GPO).  Do not use the GPO GUI to edit the IKEv2 (i.e., PowerShell) firewall or you risk corrupting it.   You can then apply both GPOs to the VPN server.     

Also, we may be able to accomplish the same thing by saving the object to the local policy store.  Don't take my word on this because I haven't tried it yet.  So yeah, this is a bit more work but the benefits should provide solid security and greater interoperability.   

If anyone completes this script before I get around to it please forward me your work!  Either way, I'm sure it will be good material for another blog article.

That's it!  

References:

https://msdn.microsoft.com/en-us/library/hh536658.aspx
https://technet.microsoft.com/en-us/library/jj573824(v=wps.630).aspx
https://technet.microsoft.com/en-us/library/jj554897(v=wps.630).aspx


IPsec Security Levels

What are security bits?

VPN Problem:  

What is the most secure VPN cryptographic algorithm?   What is the best-practice for choosing IPsec security strength?

Solution:

Use Key Management methodology to determine IPsec security strength.

Key Management

The National Institute of Standards and Technology (NIST) publishes up-to-date guidance for choosing appropriate VPN ciphers.  It uses Key Management methodology to rate the effectiveness of different cryptographic algorithms.

Security Strength 

Security strength is a Key Management assessment that estimates the effectiveness of cryptographic algorithms against known attacks over time.  New or improved attacks may affect these equivalencies in the future.

Security strength uses bits-of-security to represent cipher strength.  Security-bits are not the same thing as key-length bits.  For example, a 1024-bit RSA certificate provides 80-bits of security.

In addition, different security algorithms may share common security strength levels (Table 1).  It's best practice to match similar security strength when working with different sets of cryptography algorithms (e.g., transfer-sets and cipher-sets).  Consider, one depreciated algorithm can compromise the entire security target.

IPsec Cipher Assessment

Use Key Management security strength assessments to implement secure IKEv2 and L2TP/IPsec VPN.  Consider how security-bits represents cipher strength:

  • 89 security-bits are vulnerable to known attacks.
  • 103 security-bits are not vulnerable to known attacks -for now.  Status forecast to depreciate in the near-future (may be months or years).
  • 128 security-bits are not vulnerable to known attacks.  Status forecast remains secure for near-future.
  • 192 security-bits are not vulnerable to known attacks.  Status forecast remains secure for long-term future (years).
Cisco dubs 192-bit security as Next Generation (NG).  NG security strength includes DH-19 that uses 256-bit key with elliptic-curve algorithms.  It provides a 1024-bit key exchange and does not require intensive hardware resources -wow!




Table 1
VPN Security Strength 

Security Strength DH RSA IKE Encryption IKE Hash ESP Encryption ESP HMAC Hash Assessment***
80-bit 5 1024 AES-128 SHA1 AES-128 SHA1 Bad
89-bit 5 2048 AES-128 SHA1
SHA256
AES-128 SHA1
SHA256
Bad
103-bit 14 2048 AES-128 SHA1
SHA256
AES-128 SHA1
SHA256
Good
128-bit 15 3072 AES-128 SHA256
SHA384
AES-128 SHA1
SHA256
Better
192-bit* 16 4096** AES-256 SHA256**
SHA384
AES-256 SHA1
SHA256**
Best

Note:  DH-EC not included in this table -for simplicity.  DH-EC provides for a 1024 or 7068 security bit key exchange.
*192-bit security level requires 7680-bit RSA. Some systems do not support 7680-bit RSA.
 **Security level mismatch. 4096-RSA security-strength is 140-bit (i.e., not 192-bit). This mismatch impacts all security levels.
***The assessment column is not official NIST Key Management.  It is this author's independent qualitative interpretation derived from NIST Key Management.


Table 2
Diffie-Hellmand (DH) Security Strength Levels.

DH Group DH Key Security Strength
(i.e., Bits of Security)
DH5 1536 bits 89 bits
DH14 2048 bits 103 bits
DH15 3072-bit 128 bits
DH16 4096 bit 192 bits
DH19 (ECP) 256-bit (ECP) 1024
DH20 (ECP) 384-bit ECP 7680




Table 3
Encryption Security Strength Levels

AES AES Key Security Strength
(i.e., Bits of Security)
AES-128 128 128
AES-256 256 256


Table 4
RSA Security Strength

Certificate RSA Key Symmetric Key
RSA 1024-bit 80-bit
RSA 2048-bit 112-bit
RSA 3072-bit 128-bit
RSA 4096-bit 140-bits*
RSA 15360 -bit* 256-bit**

 *No formal recommendation for Symmetric key.
RSA 4096 offers marginal 28bit increase for symmetric key.
**15360 is not usable. Therefore, use RSA 3072-bit key.


Table 5
Hash Security Strength

Hash Hash-only HMAC Security Strength
(i.e., Bits of Security)
SHA SHA-1
SHA-256
SHA-512
SHA-1
SHA-256
SHA-512
80
SHA SHA256
SHA384
SHA256
SHA-1
SHA-256
SHA-512
112
SHA SHA256
SHA384
SHA256
SHA-1
SHA256
SHA-512
128
SHA SHA-384
SHA-512
SHA-256
SHA-384
SHA-512
192
SHA SHA512 SHA-256
SHA-384
SHA-512
SHA256

Note: Hash security level determined by algorithm,
scheme or application and by the minimum security-strength provided.


That's it!


References:
https://www.nist.gov/
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
http://infosecurity.ch/20100926/not-every-elliptic-curve-is-the-same-trough-on-ecc-security/
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf





Disable Juniper Ports

Problem:  

How to shutdown a Juniper switchport or interface.  This simple JUNOS task frustrates Cisco-minded folks.  So where does JUNOS hide the shutdown command?

Solution:  

"Disable" is the JUNOS command for "shutdown".  Examples:

     Disable:        root@host> set interface ge-0/0/1 disable
     Enable  root@host> del set interface ge-0/0/1 disable

That's it!

Clear BGP Sessions

Problem: 

How to reset BGP peering and re-announce BGP routes.  Inbound traffic is supposed to traverse through the preferred ISP.  However, traffic splits between different ISPs after maintenance or short outages.

Solution: 

Clear BGP sessions to update BGP routes after an outage or maintenance.

Command: 

     clear bgp neighbor soft

This processes re-announces BGP routes to upstream neighbors. Clear a BGP session whenever inbound/outbound policy changes are made; or after outages or maintenance.

Before: 

After:

That's it!

Troubleshoot Wi-Fi Legacy Data Rates

Summary:

How to troubleshoot smartphone or tablet that can't connect to Wi-Fi network due to legacy data rates (e.g., 802.11a, 802.11b and 802.11g).

Problem:

Staff member's personal smartphone won't connect to the guest Wi-Fi network.  All other devices connect to wireless network without issues.

Problem Device:
  • Older Kyocera Android phone.  
  • Problem device only connects with 2.4GHz radios.

Topology:

Multiple access point and wireless controller.  Single 2.4GHz SSID broadcast throughout the office.  Recent changes were made to roaming, data rates/ cell size, and power tuning (background).  Independent BSSIDs broadcast on separate radios: 802.11na and 802.11ng.    Legacy 802.11b data rates are disabled. The network continues support for 802.11G data rates (i.e., 54 Mbps):
set service-profile Guest_2.4 transmit-rate 11g mandatory 12,24.0,36.0,48.0,54.0 disabled 1.0,2.0,5.5,6.0,9.0,11.0,18.0 beacon-rate 24.0 multicast-rate AUTO

Solution:

  1. Identify client session:
    
    *WLC# sh sessions network verbose
    
    Name:               last-resort-Guest 2.4GHz-570
    
    SSID:               Guest 2.4GHz
    
    MAC:                6c:xx:xx:xx:xx:xx
    
    AP/Radio:           1/1
    
    State:              DEASSOCIATED
    
    Device type:        android-generic (AAA)
    
    Radio type:         802.11ng
    
    Last packet rate:   6.0 Mb/s
    
    Last packet RSSI:   -49 dBm
    
    Last packet SNR:    46
    
    Session interpretation:
    • Session state is deassociated.  
    • Excessive of roaming attempts.  
    • Good signal strength and SNR.  
    • Last packet rate is only 6.0 Mb/s. 
    Data indicates the phone probably uses legacy wireless standards -it's old!

  2. Enable log tracing to debug connection attempts:
    *WLC#set log trace enable severity debug
    *WLC#set trace dot1x level 10 mac
    *WLC#set trace sm level 10 mac
    *WLC#sh log trace
    SM Apr 14 13:45:08.197931 DEBUG SM-EVENT: Cannot set ipaddr for 6c:76:60:59:9e:6a
    SM Apr 14 13:45:08.743477 DEBUG sm_do_flood_announce: 6c:76:60:59:9e:6a flood announce
    SM Apr 14 13:45:16.176513 DEBUG SM-EVENT: (4601) rssi -69, rate code 0x0018, idle 48 secs
    SM Apr 14 13:45:16.176661 DEBUG SM-EVENT: (4601) idle timer 132755 left, reset to 132000 ms
    SM Apr 14 13:45:16.177599 DEBUG SM-EVENT: (4556) rssi -56, rate code 0x0018, idle 9 secs
    SM Apr 14 13:45:16.177756 DEBUG SM-EVENT: (4556) idle timer 150259 left, reset to 171000 ms
    SM Apr 14 13:45:16.179532 DEBUG SM-EVENT: (5415) rssi -76, rate code 0x0018, idle 20 secs
    SM Apr 14 13:45:16.179653 DEBUG SM-EVENT: (5415) idle timer is tracking (160258 to go)
    SM Apr 14 13:45:16.180066 DEBUG SM-EVENT: (4551) rssi -63, rate code 0x0018, idle 6 secs
    SM Apr 14 11:12:44.674414 DEBUG SM-DOT11: sm_dot11_handle_deassociate: ev type 5 (good), token 0, mac 6c:76:60:59:9e:6a
    SM Apr 14 11:12:44.674576 DEBUG SM-STATE: (2462) mac 6c:76:60:59:9e:6a, flags 1801800028834dh, to change state ACTIVE -> DEASSOCIATED, by sm_dot11_handle_deassociate
    Log Interpretation:
    • SM=Session Management.
    • SM-DOT11=World Mode Multi-Domain Operation.  The DOT11D option makes access points advertise local settings, such as frequencies and power levels.
    • Rate code 0x0018 = 11Mb per Multi-band Atheros Wi-Fi (MADwifi) 5212.
    The deassociation was based on DOT11D.  In other words, due to AP frequency or power level restrictions.

  3. Check the configuration for frequency or power restrictions:
    set service-profile Guest_2.4 transmit-rate 11g mandatory 12,24.0,36.0,48.0,54.0 disabled 1.0,2.0,5.5,6.0,9.0,11.0,18.0 beacon-rate 24.0 multicast-rate AUTO
    Snap!  The service profile indicates that devices must connect at a minimum, 12Mbps -normally good policy.  However, we have a single client that can only connect at 6Mbps.

Available Options:

  1. Remove 6Mbps from the list of disabled data rates.  N.B., Legacy devices on the BSSID has a negative impact for the entire wi-fi network. Is one person worth the trouble?  It certainly is if that person is your boss!
  2. Create a dedicated legacy SSID -diplomatic solution.
  3. Ask the employee to get rid of the stone-age device!   Suggest or provide a modern device that handles 802.11na!
 Thant's It!

References:

http://www.cisco.com/web/techdoc/wireless/access_points/online_help/eag/123-02.JA/1400BR/h_ap_network-if_802-11_c.html
http://web.mit.edu/freebsd/head/sys/dev/ath/ath_hal/ar5212/ar5212_phy.c

Fix iPhone Wi-Fi Problems: Part I

Executive Summary:

How to fix iPhone Wi-Fi problems.  Why can't that shiny new iPhone stay connected to the wireless network?  FYI, it's probably not your IT department's fault.  There are steps, however, that can be made to improve the overall connection.  Target audience is for IT professionals but this information is helpful for all end-users.












Problem:

Complaints of poor iPhone (Wi-Fi) performance. iPhones are inconsistently kicked off the Wi-Fi.  iPhones may only connect at low data rates.  End-uses are frustrated when iPhones and iPads disconnect.

Topology:

Corporate Wi-Fi uses Juniper wireless controllers and access point (APs).  Most smart phones connect to dedicated guest network. Wireless network seems to work well for most Android and Windows devices. Majority of problems are with iPhones and iPads.  N.B., topology is similar to Cisco controllers.  Topology is also similar, to a lesser extent, to personal wireless systems.

Symptoms:

iPhones and iPads experience disconnects, delays, packet drops, or total loss from Wi-Fi network. In other instances, Apple devices consistently connect to 802.11n networks at 24Mbps.

Cause:

Aggressive roaming causes most Wi-Fi problems for iPhones and iPads.  Roaming occurs when multiple APs broadcast identical SSIDs.  These Apple devices are quick to jump ship compared to other clients (e.g., Android). Excessive roaming causes wireless drops, slow data rates, and poor battery life.  What's more, all roaming decisions are made by wireless client (i.e., iPhone) –not the wireless AP or controller.

Additional factors can also influence wireless grief:  iPhone standby settings; spectrum preference; legacy rates; encryption; and signal strength -too much or too little.

Influencing Factors: 


  1.  Power save handler. iPhones enter standby/ sleep mode based on application activity. iPhones generally disconnect Wi-Fi in standby mode. End-users should understand this behavior is by design (à la Apple). It is not a limitation of their corporate Guest network.
  2. Roaming. Clients may disconnect if the roaming process takes too long.
  3. Spectrum preference. iPhones prefer the 2.4GHz spectrum over the 5Ghz spectrum. Wireless clients work best on the 5GHz spectrum. Consider disabling 2.4GHz radios from the APs.
  4. Data Rates. Legacy 2.4GHz data rates (e.g., 802.11b and 802.11g) harm 802.11n wireless networks. Disable 802.11b and consider disabling 802.11g (i.e., adjust roaming cell size). Wireless networks realize 30% to 50% increases in throughput after disabling 1,2,5.5, and 11 Mbps data rates.
  5. Encryption and Ciphers. WPA and TKIP caps/limits Wi-Fi networks to 54Mbps. Juniper recommends only implementing WPA2 with CCMP cipher for 802.11n transmissions. Pre-shared key is acceptable. 802.1X (i.e., WPA2-Enterprise) is better.
  6. Range. Signal strength affects client roaming decisions. 802.11b (2.4GHz) has nearly twice the range of 802.11a (5GHz). Adjust radio power levels (i.e., transmit power) so that 5GHz RSSI is great than the 2.4GHz RSSI. For example, set 2.4GHz to 4 dBm; and set 5GHz to 12dBm. 

Power Save:

Apple IOS devices (e.g., iPhones and iPads) use standby/ sleep mode to improve battery life. The phone enters standby five minutes after it locks (i.e., requires PIN to unlock). Active sessions (e.g., web download) transition to standby after thirty minutes.

In most situations, the iPhone disconnects Wi-Fi after it enters standby. It makes sense –who enjoys one hour power? Non-persistent Wi-Fi becomes less of an issue because most devices automatically reconnect when unlocked. N.B., auto-connect introduces security risks via Man-in-the-Middle (MMTM) –we’ll save that discussion for another day.

In some circumstances, there are exceptions to Apple’s non-persistent Wi-Fi policy. For example, some applications use a background task handler (e.g., Exchange ActiveSync) that keeps Wi-Fi connected at all times. Other users experience persistent Wi-Fi while streaming music via Spotify or Pandora.

Provide a power source (i.e., plug it in) or entirely disable the screen lock (also not recommended) are alternate methods for Wi-Fi persistence.

Roaming Rates

Normally, iPhones roam between APs within a few milliseconds. However, in some circumstances clients may take up-to five seconds to complete –ay caramba! Most APs disconnect the session after three minutes. End-users without auto-connect require manual reconnection. Either way, it’s best to keep roaming to a minimum.

Spectrum Preference:

iPhones often prefer the 2.4GHz over 5Ghz spectrum. This 2.4GHz preference is not necessarily by design. The preference results from a combination of roaming thresholds, dual-band APs, and imprecise interpretation of the RSSI signals.

Why does spectrum matter? 2.4 GHz only provides three non-overlapping channels: 1, 6, and 11. In addition, the majority of wireless devices operate on the 2.4GHz spectrum. In contrast, the 5 GHz spectrum provides 23 non-overlapping channels. Relatively few devices use the 5GHz spectrum.

For example, a quick wireless scan shows a total of 81 neighbor APs within range of my office.


This scan shows 86% of my neighbors transmit on the 2.4GHz spectrum; compared to only 13% on the 5GHz spectrum.



This data also shows only six 5GHz channels are in use. That leaves us with 16 pure unused virgin 5GHz channels for unadulterated throughput! Contrast that with the surrounding APs (all 70 of them) saturating the only three 2.4GHz channels: 1, 6, and 11. Additionally, microwaves and cordless phones operate on the same 2.4GHz spectrum.

What is the actual impact of an entire office building sharing the same three channels? Expect a wide range of clients and usage in large office buildings. Neighbor APs share the limited bandwidth across wireless channels. 802.11g radios provide roughly 300Mbps of total throughput. Wi-Fi bandwidth increases (per SSID) with 802.11ng and MIMI antennas. These innovations may further reduce neighbors’ throughput by up to 90%.


Table 1. 
Comparison of Wi-Fi Rates and Channels
Standard
802.11a
802.11b
802.11g
802.11ng
802.11na
Spectrum
(5GHz)
(2.4GHz)
(2.4GHz)
(2.4GHz)
(5GHz)
Max Speeds
54 Mbps
11Mbps
54Mbps
300Mbps
 300Mbps
Range
50 feet
100 feet
100 feet
50 feet
 50 feet
Non-overlapping Channels
24
3
3
3
24

Spectrum Throughput

Data can transmit roughly twice as far over the 2.4GHz spectrum compared to the 5GHz spectrum. The range is impressive but it’s not necessarily better. For example, it’s prudent to keep wireless beacons confined to the office perimeter (i.e., security).

Additionally, 2.4GHz has a negative impact on client data rates and roaming. Sticky clients (e.g., Android) may connect from the parking lot at 1Mb connection rate. These clients may be stuck with low connection rates throughout the day because of their low roaming aggressiveness. Recall the negative impact legacy rates have on the entire network. Likewise, non-sticky clients may experience unnecessary roams. Also, consider the negative impact of signal noise. Wi-Fi works better when it doesn’t detect every neighbor on the block.

RSSI, SNR, and Throughput:

Data transmission rates (i.e., throughput) can be estimated in relation to RSSI and Signal Noise Ratio (SNR). RSSI is the RF signal strength. Large RSSIs represent strong signal strength. For example, -60 dBm is greater than -70 dBm.
SNR is an expression of signal strength minus signal noise. SNR generates a positive number expressed in decibels (dB). For example, SNR is 20 if the RSSI value is -75db and Noise value is -95db. In general, SNR above 20 dB is an acceptable level for transmission.

Table 2.  Legacy Data Rates Estimates.
Rate (Mb/s)
1
2
5.5
11
6
9
12
18
24
36
48
54
SNR (dB)
4
6
8
10
4
5
7
9
12
16
20
21
Signal level (dBm)
-81
-79
-77
-75
-81
-80
-78
-76
-73
-69
-65
-64

Table 3.  802.11ng (2.4GHz) Data Rate Estimates.
2.4GHz Rate (Mb/s)
(20MHz)
14.4
28.9
43.3
57.8
86.7
115.6
130
144.4
SNR (dB)
11
14
16
19
23
27
28
29
Signal level (dBm)
-82
-79
-77
-74
-70
-66
-65
-64

Table 4.  802.11na (5GHz) Data Rate Estimates.
5 GHz Rate (Mb/s)
(40MHz)
30
60
90
120
180
240
270
300
SNR (dB)
11
14
16
19
23
27
28
29
Signal level (dBm)
-79
-76
-74
-71
-67
-63
-62
-61

iPhone Roaming Process:

iPhone roaming algorithm is based on AP signal strength and client activity:

  1. iPhone compares current BSSID (based on radio Mac) and other available AP BSSID signal levels.
  2. The roaming decision based on client activity: (a) idle session (phone in pocket) or (b) active session (e.g., web surfing). iPhone searches for a better signal level in both 2.4GHz and 5GHz bands.
     (a.) Idle clients search for new BSSIDs when current signal strength is -70dB or less (e.g. -71dB).

  • iPhone roams when it locates another AP with a signal at least +12dB better.
  • iPhone scans in 90 second intervals until its current signal strength improves (e.g., -69 dB) or it locates a different BSSID with 12dB stronger signal strength. 
     (b.)  Active client attempts to locate a stronger signal if current signal strength is -70dB or less.

  • iPhone chooses new BSSID if it has +8dB or greater RSSI.
  • iPhone continues to scan in 90 second intervals until current signal improves or locates a different BSSID at least 8 dB or better. 
Extenuating factors also influence iPhone roaming decisions: (a) Different spectrum signals and (b) client detection imprecision.

The 2.4GHz signal is roughly 7dB higher than the 5GHz signal. Physical attributes of BSSID antenna accounts for the difference in signal strength -it is not a limitation of the AP. By itself, the +7dB difference between RSSI strength is not enough to initiate roaming. Recall, the iPhone only initiates roaming after it identifies a BSSID  with RSSI at least +8dB or greater.

Wireless roaming reaches critical mass the client does not measure RSSI accurately (i.e. client imprecision).  This imprecision accounts for an additional plus or minus 4dBs. In other words, iPhones generally prefer 2.4GHz radios over 5GHz radios

Encryption and Ciphers

WPA and TKIP slows Wi-Fi traffic connection rates to a maximum 54Mbps. These standards are superseded by WPA2 encryptions and CCMP cipher. Do not enable WPA2 and WPA simultaneously. Likewise, do not enable WPA2 and CCMP and TKIP.

*Read the following post for specific fixes, recommendations, and best practices.

References: 

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming.html
http://kb.juniper.net/InfoCenter/index?page=content&id=KB20295&actp=search&viewlocale=en_US&searchid=1301446020120
http://www.greatwhitewifi.com/2015/07/12/fixing-hallway-fi-vol-1/
http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-does-the-quot-beacon-rate-quot-profile-work/ta-p/179242
http://kb.juniper.net/InfoCenter/index?page=content&id=KB28153&actp=search&viewlocale=en_US&searchid=1373982600826
https://en.wikipedia.org/wiki/IPhone
http://www.juniper.net/documentation/en_US/network-director1.5/topics/concept/wireless-encryption-and-ciphers.html
http://blogs.cisco.com/wireless/wi-fi-taxes-digging-into-the-802-11b-penalty
http://www.cisco.com/c/en/us/td/docs/wireless/technology/apdeploy/8-0/Cisco_Aironet_3700AP.html
https://www.wireless.att.com/support_static_files/KB/KB3895.html
http://kb.juniper.net/InfoCenter/index?page=content&id=KB20248&actp=search&viewlocale=en_US&searchid=1456780940943
https://www.youtube.com/watch?v=tihSXW6Yg1M