Over a million developers have joined DZone.

Effect of Security Mechanisms and Protocol Overhead to User Experience in Mobile Networks

This article makes a contribution to evaluate how security mechanisms and protocol overhead changes the user experience in mobile networks for applications which are alternative to the services in circuit switch networks like voice and messaging.

· Mobile Zone

Abstract

Today mobile devices roam around and they encounter different network conditions. Several dynamic parameters affect the quality and network becomes unstable.

Applications installed on smartphones that tolerate such kind of variations gain advantage over their competitors.

Besides, users want to make sure about they are using secure applications and their personal data is protected well. To ensure such demand several security mechanisms are used for data on the device and on the network. These mechanisms introduce extra messaging on network, and in bad network conditions they have effects on quality of service from the user’s perspective. Another parameter that affects user experience is the protocol overhead which is used for client-server communication. This article makes a contribution to evaluate how security mechanisms and protocol overhead changes the user experience in mobile networks for applications which are alternative to the services in circuit switch networks like voice and messaging.

1- Introduction

Users just pay for data plans and satisfy their needs like messaging and voice calls by mobile applications on smartphones. User experience in circuit switch networks has determined customer quality perception for such kind of services. Achieving this goal in mobile broadband networks is too hard because mobility means encountering different types of networks. Sometimes clients attach to low bandwidth access points or sometimes they are far away from the radio source. Such kind of network quality differences have strong influence on service quality especially for applications that are used for messaging and VoIP.

In the following work connection startup time will be evaluated in bad network conditions. It is aimed to show how connection setup is affected when we reduce security levels and protocol overhead in a bad network. Extensible Messaging and Presence Protocol (XMPP) protocol is chosen for evaluation.

Test steps are determined in the following order:

  • Avoiding transferring whole key chain of Secure Sockets Layer (SSL) certificate.
  • Implementing SSL session identifier.
  • Changing authentication mechanism from digest to plain (XMPP digest and plain or basic authentication is derived from Hypertext Transfer Protocol (HTTP) [4].
  • Reducing protocol overhead by customization.

2- Transport and Application Layer Security

For transport layer security most of the applications use SSL. Protocols like Session Initiation Protocol (SIP)[1] and XMPP depends on SSL for transport layer security. XMPP SSL/TLS handshake mechanism is well defined in recommendation XEP-0035[2]. For basics of SSL handshake please refer to The Secure Sockets Layer (SSL) Protocol Version 3.0 [3].

For this paper initial TLS capability control messaging is overridden and client directly starts to TLS handshake. This messaging is illustrated in Figure 1.

Image title

Fig. 1. Initial messaging for identifying if the server supports TLS.

Whole messaging for connection and authentication in XMPP is shown in Figure 2.

Image title


Fig. 2. Full messaging sequence of connection and authentication in XMPP.

For detailed information please refer to "A New Approach for Authentication and Resource Binding for XMPP" [5].

3. Effect of Extra Messaging on Connection Setup

There will be several tests executed to measure the overhead of every single security mechanism and protocol overhead to connection startup.

3.1. Testing Environment

During our tests following hardware and software is used.

  • IPhone 5S
  • Openfire XMPP server
  • xmppframework library

From IOS “Developer” menu in settings network link conditioner is enabled with the following parameters in order to simulate bad network conditions.

  • In bandwidth: 1000 kbps
  • In packet loss: %5
  • In delay: 500 milliseconds
  • Out bandwidth: 1000 kbps
  • Out packet loss: %5
  • Out delay: 500 milliseconds

3.2. Tests

Test cases that will be run are listed in Table 1.

Id

Certificate chain

Session identifier

Authentication

mechanism

1

Yes

No

Digest

2

No

No

Digest

3

No

Yes

Digest

4

No

Yes

Plain

5

No

Yes

Plain(custom)

Table 1. List of test cases

Test 1: Whole certificate chain is transferred in connection start up. Client doesn’t implement session identifier mechanism and requests certificate in every connection attempt.

Test 2: Only user certificate is transferred. No intermediate or root certificate is sent to client.

Test 3: Client sends session identifier to server after it receives certificate in the initial connection attempt. If the identifier is still valid, server doesn’t send certificate again.

Test 4: Client login to server by using plain authentication method.

Test 5: For XMPP XEP-178[6] Simple Authentication and Security Layer (SASL) mechanism discovery method is disabled. Client directly assumes that server supports PLAIN authentication. Figure 3 shows the final messaging after SSL handshake.

Image title

Fig. 3. Client authentication after SSL handshake.

4. Evaluation

In the first test server sent whole certificate chain.

Id

Duration(sec)

1

28.58

2

18.27

3

15.17

4

21.84

5

18.79

Table 2. Results of test #1

Second test server only sent user certificate.

Id

Duration(sec)

1

17.68

2

13.28

3

9.84

4

14.01

5

10.09

Table 3. Results of test #2

In third test client stored session identifier and every time sent it to the server. By this way, server didn’t send certificate again and again.

Id

Duration(sec)

1

9.96

2

10.41

3

12.56

4

10.24

5

9.89

Table 4. Results of test #3

For test #4 in the server configuration we only changed SASL authentication mechanism from digest to plain.

Id

Duration(sec)

1

11.79

2

12.24

3

9.02

4

10.43

5

9.32

Table 5. Results of test #4

Finally in the last test we override the SASL discovery method and directly sent the login message to the server after SSL handshake.

Id

Duration(sec)

1

3.81

2

3.35

3

3.34

4

3.28

5

3.61

Table 6. Results of test #5

These tests show us less messaging means high-speed connectivity when the matter is packet drop.

As the bandwidth is not limited (1 mbps), there is no significant change between PLAIN and DIGEST authentication. The main difference in those two mechanisms is the huge response with nonce that is sent to server. We couldn’t identify if the size of the response has an effect on the connection setup with the conditions above.

The main improvement in connection setup duration is reducing the protocol overhead. By this way duration decreased to ~3 seconds.

5. Conclusions

In conclusion, this article has shown more messaging for more secure communication has negative effect on user experience. There is a tradeoff between customer perception and security. With the evolution of mobile networks, more advanced security mechanisms will be applicable without disturbing end users.

Another lesson learned is the effect of protocol overhead. Application developers should consider it and try to reduce inside the protocol boundaries or customize it as the above example.

People who are working on mobile applications which communicate with a backend benefit from the output of this paper. There would be a competitive advantage over their rivals if the balance between security, well-defined protocol, and the user experience. For developing high performance and secure mobile applications consideration of the output of this paper should save time for delivery.

For now, especially in countries in which 3G/4G or other high-speed mobile networks are not widespread, application developers should compromise from security in order to make applications useful. Some mobile applications publish lite versions for such kind of countries. This strategy, of course, has an extra development cost but satisfying different needs in different markets makes inevitable to diversify.

Topics:
xmpp ,sip ,tls ,ssl

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}