Thesis

Embedded
Virtual Private Network

PerIormance and Scalability

Eric Chan

Bachelor of Engineering (Software)
Department of Information Technology and Electrical
Engineering
University of Queensland

October 2002
Eric Chan
2/62 High Street
Toowong. QLD 4066
Tel. 0412351099

ProIessor Simon Kaplan
Head oI School oI InIormation Technology
And Electrical Engineering
University oI Queensland
St. Lucia QLD 4072
AUSTRALIA

Dear ProIessor.

In Accordance with the requirements oI the degree oI Bachelor oI Engineering in the
division oI SoItware Engineering. I present my thesis titled 'Embedded VPN:
PerIormance and Scalability. This thesis was undertaken in partnership with Mr.
Jerome Lau and Mr. Chun Ko under the supervision oI Dr. Xue Li. I declare that this is
my own work and any text that is not my own has been quoted and attributed
appropriately. I also declare that the work presented has not been previously submitted
Ior assessment at this or any other institution.

Yours Sincerely.

Eric Chan
Embedded Virtual Private Network: PerIormance and Scalability

i
Acknowledgements
I would like to take this opportunity to thank those that helped me throughout the year.
without them I surely would not have come this Iar.

Special thanks goes to Dr Xue Li Ior his support and guidance over the course oI the
year. his guidance and tireless support has given us valuable knowledge and
experiences. and his unique vision has stimulated us to numerous new ideas.

Finally. I would also like to thank other students involved with the eVPN proiect.
Jerome Lau and Chun Ko. you two were the perIect member Ior me.

ii
The Embedded Virtual Private Network (eVPN) proiect describes the design and
implementation issues in developing an Embedded Virtual Network (eVPN) System.
The entire proiect is split into 3 parts The Architecture oI eVPN by Chun Ko. Key
Management oI eVPN by Jerome Lau and PerIormance and Scalability oI eVPN by Eric
Chan.

This thesis outlines the requirements. design and implementation issues oI Embedded
Virtual Private Network (eVPN). It describes the PerIormance and Scalability issues oI
eVPN: research. analysis and evaluation on existing VPN protocols were perIormed.
The goal oI this thesis is to analyze and evaluate existing technologies oI VPN. as well
as oIIering a solution to the design and implementation oI an embedded VPN System. A
compact prototype system is developed Ior testing and analysis purpose.

The prototype system is implemented under Linux platIorm. The overall system is
implemented with 3 workstations 1 workstation acts as the central management
system. network traIIic monitor and providing key management services. while the 2
gateways` on either side oI the network will act as an eVPN device. A secure channel
was setup between the two gateways using OpenVPN to provide secure
communications over the Internet`. Streaming and non-streaming data packets can be
transIerred across the network with the conIidentiality. availability and integrity oI
inIormation ensured. More resources can be integrated into the system to provide a
better model Ior the testing and development oI the eVPN system. Further work will
evolve Irom this prototype system.

iii
Table of Contents

1.0 Introduction------------------------------------------------------------------ 1
1.1 Background---------------------------------------------------------- 1
1.2 Information Security Hacker's point of view--------------- 1
1.2.1 Threats to computer resources---------------------- 2
1.2.2 How they do it-------------------------------------------- 3
1.2.2.1 Brute-force Attack--------------------------- 3
1.2.2.2 Trojan Horse Attack------------------------- 3
1.2.2.3 IP Spoofing------------------------------------ 4
1.2.2.4 Man in the middle Attack------------------ 4
1.2.2.5 Other Attacks--------------------------------- 4
1.3 What is Virtual Private Networks (VPN)---------------------- 5
1.3.1 Private Network----------------------------------------- 5
1.3.2 Internet---------------------------------------------------- 6
1.3.3 Virtual Private Network-------------------------------- 8
1.3.3.1 Topologies------------------------------------ 11
1.3.3.1.1 Host-to-Host----------------------- 11
1.3.3.1.2 Host-to-Network------------------ 12
1.3.3.1.3 Network-to-Network------------- 13
1.4 What is Embedded Virtual Private Networks (eVPN)----- 14
1.5 eVPN Goals--------------------------------------------------------- 15
1.6 Thesis Goals-------------------------------------------------------- 16
1.7 Thesis Overview--------------------------------------------------- 18
1.7.1 Literature Review-------------------------------------- 18
1.7.2 Design and Architecture of eVPN------------------ 18
1.7.3 Implementation----------------------------------------- 18
1.7.4 Analysis and Recommendations------------------- 18
1.7.5 Evaluation------------------------------------------------ 19
1.7.6 Future Work--------------------------------------------- 19
1.7.7 Conclusion----------------------------------------------- 19

2.0 Literature Review--------------------------------------------------------- 20
2.1 Transport Layer Protocols-------------------------------------- 20
2.1.1 TCP------------------------------------------------------- 20
2.1.2 UDP------------------------------------------------------- 22
2.1.3 TCP vs UDP-------------------------------------------- 23
2.2 Tunneling Protocols---------------------------------------------- 25
2.2.1 Standard Tunneling Protocols---------------------- 25
2.2.1.1 PPTP------------------------------------------ 25
2.2.1.2 L2F--------------------------------------------- 26
2.2.1.3 L2TP------------------------------------------- 27
2.2.1.4 IPSec------------------------------------------ 29
2.2.1.5 MPLS------------------------------------------ 31
2.2.2 Non-Standard Tunneling Protocols---------------- 32
2.2.2.1 OpenVPN------------------------------------- 32

iv
2.2.2.2 cIPE-------------------------------------------- 33
2.2.3 Comparisons-------------------------------------------- 33
2.3 Key Management-------------------------------------------------- 35

3.0 Design and Architecture of eVPN------------------------------------ 36
3.1 Specification of eVPN--------------------------------------------- 37
3.1.1 eVPN Device--------------------------------------------- 38
3.1.1.1 Authentication Scheme-------------------- 38
3.1.1.2 Configuration and Services--------------- 39
3.1.2 eVPN Central Server---------------------------------- 40
3.1.2.1 Authentication-------------------------------- 40
3.1.2.2 Access Control------------------------------- 40
3.1.2.3 Session Tracking---------------------------- 41
4.0 Implementation------------------------------------------------------------- 42
4.1 System Architecutre----------------------------------------------- 42
4.2 System Requirements--------------------------------------------- 43
4.3 Setting Up the System-------------------------------------------- 44
5.0 Analysis and Recommendations------------------------------------- 45

5.1 Performance Test-------------------------------------------------- 45
5.1.1 Results---------------------------------------------------- 45
5.2 Analysis-------------------------------------------------------------- 48
5.2.1 IPSec------------------------------------------------------ 48
5.2.2 OpenVPN------------------------------------------------ 48
5.2.3 Summary------------------------------------------------- 49
5.3 Recommendations------------------------------------------------ 49
5.3.1 Performance-------------------------------------------- 49
5.3.1.1 Transport Layer Protocols--------------- 49
5.3.1.2 Tunneling Protocols----------------------- 50
5.3.1.3 Key Management-------------------------- 50
5.3.2 Scalability------------------------------------------------ 51
5.3.2.1 eVPN Device-------------------------------- 51
5.3.2.2 eVPN Central Server---------------------- 52
5.3.2.3 eVPN Resource Server------------------- 53
6.0 Evaluation-------------------------------------------------------------------- 54
6.1 Project Evaluation-------------------------------------------------- 54
6.2 System Evaluation------------------------------------------------- 54
6.3 Thesis Evaluation-------------------------------------------------- 55
6.4 Personal Evaluation----------------------------------------------- 55
6.5 Summary------------------------------------------------------------- 56

7.0 Future Work----------------------------------------------------------------- 57

8.0 Conclusion------------------------------------------------------------------ 58

v
9.0 References------------------------------------------------------------------ 59

10.0 Appendices--------------------------------------------------------------- 62
10.1 eVPN Prototype System Installation Procedure--------- 62
10.2 Performance Test Execution Procedure------------------- 76
10.3 Results of Performance Test--------------------------------- 77

vi
List of Figures

Figure 1. Private Networking----------------------------------------------------- 6
Figure 2. Internet Infrastructure-------------------------------------------------- 7
Figure 3. Virtual Private Network------------------------------------------------ 8
Figure 4. Host-to-Host VPN------------------------------------------------------ 11
Figure 5. Host-to-Network VPN------------------------------------------------- 12
Figure 6. Network-to-Network VPN-------------------------------------------- 13
Figure 7. PPTP Connection------------------------------------------------------ 26
Figure 8. L2TP with IPSec-------------------------------------------------------- 28
Figure 9. IPSec in tunnel mode-------------------------------------------------- 31
Figure10. eVPN Architecture------------------------------------------------------ 36
Figure11. Architecture of eVPN prototype system--------------------------- 42
Figure12. Performance of Insecure Channel---------------------------------- 46
Figure13. Performance of IPSec------------------------------------------------- 46
Figure14. Performance of OpenVPN-------------------------------------------- 47
Figure15. Insecure Channel vs IPSec vs OpenVPN------------------------- 47
Figure16. Replication of eVPN Central Server and Resource Server--- 53

vii
List of Tables

Table 1. TCP vs UDP-------------------------------------------------------------- 24
Table 2a. Tunneling Protocols----------------------------------------------------- 33
Table 2b. Tunneling Protocols----------------------------------------------------- 34
Table 3. Hardware Requirements for eVPN Prototype System--------- 43
Table 4. Software Requirements for eVPN Prototype System---------- 43
Table 5. Recommended Usages of TCP and UDP------------------------- 50

viii
1*
Authentication VeriIy the identity oI the entity to give appropriate access rights

CA CertiIication Authority. issue certiIicates and maintain CRL

CertiIicate Public-key signed by a CA

cIPE Crypto IP Encapsulation

Digital Signatures Encryption with private-key. acting as a signature

eVPN Embedded Virtual Private Network

Eavesdropping Reading public network packets to obtain sensitive data

Hacker Computer proIessionals or cracker

IPSec Internet Protocol Security

IP SpooIing Creation oI TCP/IP packets using somebody else's IP address

L2F Layer 2 Forwarding

L2TP Layer 2 Tunneling Protocol

MPLS Multi-Protocol Label Switching

PPTP Point-to-Point Tunneling Protocol

TCP Transmission Control Protocol

UDP User Datagram Protocol

VPN Virtual Private Network

VPN Topology VPN architecture to support diIIerent applications


1
1.0 Introduction
1.1 Background
The Internet has changed the world undoubtedly. It is a rapidly growing global
phenomenon that has grown Iaster than any innovation in the industrial and inIormation
ages. Ranging Irom small-sized businesses to giant corporations. legitimate users to
national deIense. almost every person/organization in the world makes use oI the
Internet in one way or another.

The Internet`s greatest attractions openness and ubiquity. are also its greatness
weakness. In the absence oI security mechanisms. using the Internet to communicate
private and sensitive inIormation is an extremely dangerous practice it can easily lead
to numerous and unpredictable impacts with the presence oI hackers and
eavesdroppers hence. inIormation must be protected.

Virtual Private Network. or simply VPN. is an evolutionary invention that would
change the world oI computer security Iorever. It oIIers and ensures every single aspect
oI computer security with non-complex design and algorithms. and will surely be the
maior technology that will be employed in the coming decades.

1.2 Information Security - Hacker's point of view
Computers connected to the Internet are always under attack hackers are
causing damages everywhere all the time. So. why do they hack? What do they have to
gain? ProIessional hackers are not iust computer nerds they are extremely intelligent.
prepared and organized personnels they can cause serious damages to any
organization easily without anyone noticing their existence. Their motivation is not
solely Ior money. most oI them hack iust because oI the challenge oI it they tend to
believe that iI a system can be broken. regardless oI the eIIort it takes to perpetrate an
attack. the responsibility rests with the system owner Ior not protecting it well enough.


2
1.2.1 Threats to computer resources

Hackers can perIorm numerous threats to computer resources. below is a list oI
basic threats to organizations that use the Internet Ior corporate data communications:

Accidental Use: The inadvertent misuse oI a Web site or Internet service by a
legitimate user.
Data destruction: The accidental or malicious loss oI data on a web site (or other
Internet-based service and the interception oI data Ilowing to or Irom the
service) whether encrypted or not.
Interference: The derailing oI web sites or Internet services by rerouting data
intended Ior them or by overloading them with data. thus crippling the server.
Misrepresentation: Electronic posturing. where the perpetrator hands out Ialse
credentials. perhaps creating a counterIeit Web site to siphon oII traIIic intended
Ior legitimate destination.
Modification: The altering oI incoming or outgoing data that belongs to a
particular Web site or service whether intentional or not. A particularly
dreadIul hazard. since modiIication is diIIicult to detect in large transmissions.
Repudiation: The denial (on the part oI a consumer or customer) that an online
order was ever placed or the goods ever received.
Unauthorized altering or downloading: The inappropriate use oI data. whether
copying or updating. by someone without the proper security rights.
Unauthorized disclosure: The viewing oI data without the appropriate
permissions.
Unauthorized transactions: Any use oI a Web site or Internet service by
someone without the approval oI the site`s owner.

These threats become more pervasive as the quantity and value oI the data and
services are increased.


3
1.2.2 How they do it
Countless attacks methods exist in the world oI computer security. They are
employed to attack on the conIidentiality. integrity and availability oI inIormation and
services. Some Iundamental and popular attack methods are described in the Iollowing
sub-sections.

1.2.2.1 Brute-force Attack
Brute-Iorce attacks involve harnessing a computer or computers to cycle through

every permutation oI potential possibilities oI either encrypted password or encrypted
data. such as a cryptography system`s public key. Today. many organizations utilize
strong authentication techniques to certiIy user access. Since strong authentication. Ior
the most part. employs some Iorm oI encryption. brute-Iorce attacks are inIeasible Ior
the average hacker because oI the considerable computing resources needed to test
billions oI combinations per second to break the encrypted data.

1.2.2.2 Trojan Horse Attack
Troian horse attacks pose one oI the most serious threats to computer security. A
Troian horse is a destructive program that masquerades as a benign application. Unlike
viruses. Troian horses do not replicate themselves but they can be iust as destructive.
Here is an example oI Troian horse attacks: hackers attach malicious code to email such
that when the network operating system processes it to determine the destination oI the
email. the errant code instructs the operating system to perIorm unauthorized operation
such as creating a new user and user password. AIterwards. the hacker is able to access
the network at any time.

4
1.2.2.3 IP Spoofing

IP spooIing a technique used to gain unauthorized access to computers. whereby
the intruder sends messages to a computer with an IP address indicating that the
message is coming Irom a trusted host. To engage in IP spooIing. a hacker must Iirst use
a variety oI techniques to Iind an IP address oI a trusted host and then modiIy the packet
headers so that it appears that the packets are coming Irom that host.

1.2.2.4 Man in the middle Attack

Man in the middle attack is where the user`s outgoing packets are going not to
the intended destination. but rather to someone who has severed the communication
path between the user and the intended recipient and pretends to be the recipient to the
user and pretends to be the user to the recipient. The man in the middle` will be able to
read. modiIy and delete the packets going into him/her. and thus causing extremely
dangerous security problem.

1.2.2.5 Other Attacks
Brute-Iorce attack. Troian horse attack. IP spooIing and Man in the middle
attack are iust Iew examples out oI the world oI hackers. Other attacks such as Denial oI
Service (DoS) Attack. Rootkit Attack. Flooding. Ping oI Death are also extremely
common and used all over the world. To protect against these attacks. security measures
must be employed. Virtual Private Network (VPN) is one oI the most powerIul and
secure algorithms developed to counter this security crisis.


5
1.3 What is Virtual Private Network (VPN)

To understand what a Virtual Private Network is. one must understand the
meanings oI Private Network and Public Network (or commonly reIerred as Internet)
Iirst.

1.3.1 Private Network

Private networks are wide area networks that connect geographically dispersed
LANs. usually between oIIice and branch oIIices and/or remote PC clients. The
connection is usually a main telecommunication line or a backbone consisting oI leased
lines or dedicated Iiber. LAN-to-LAN or point-to-point connections are sometimes
handled by Irame relay. Ironically. private networks share the sane telecommunications
inIrastructure as the Internet. However. private network lines cost considerably more
than standard telephone lines because they are conIigured Ior higher speeds and greater
bandwidth. Private networks also require another crucial inIrastructure component
called private dial-in access system. which resides at the central site. Access systems
include communication servers. modem banks and toll-Iree telephone numbers. Access
to the private network Irom remote-locations can be accommodated by standard dial-up
or digital telephone lines such as ISDN (Integrated Services Digital Network) or DSL
(Digital Subscriber Line) lines. An illustration oI private network is shown in .

Higher perIormance. speed and security are obvious advantages oI a private
network. Private networks also support a variety oI protocols such as Irame relay.
Asynchronous Transmission Mode (ATM) and TCP/IP as well. However. private
networks can be incredibly expensive. A large enterprise planning to connect many
oIIices located globally via a Iiber-optic telecommunications backbone can literally
spend hundreds oI million oI dollars on the resulting network.

6

Figure 1. Private Aetworking

1.3.2 Internet
Every computer connected to the Internet is part oI a network. even the one in
your home. For example. you may use a modem and dial a local number to connect to
an Internet Service Provider (ISP). At work. you may be part oI a local area network
(LAN). but you most likely still connect to the Internet using an ISP that your company
has contracted with. When you connect to your ISP. you become part oI their network.
The ISP may then connect to a larger network and become part oI their network. The
Internet is simply a network oI networks.
Most large communications companies have their own dedicated backbones
connecting various regions. In each region. the company has a Point oI Presence (POP).
The POP is a place Ior local users to access the company's network. oIten through a
local phone number or dedicated line. The amazing thing here is that there is no overall
controlling network. Instead. there are several high-level networks connecting to each
other through Network Access Points or NAPs. Dozens oI large Internet providers

7
interconnect at NAPs in various cities. and trillions oI bytes oI data Ilow between the
individual networks at these points. The Internet is a collection oI huge corporate
networks that agree to all intercommunicate with each other at the NAPs. In this way.
every computer on the Internet connects to every other (as shown in Figure 2).
With such openness and Ilexibility. Internet introduces many new possibilities.
as well as threats. Since security was not take into account during the design oI the
underlining protocol oI Internet. TCP/IP. thus without security measures implemented.
communications on Internet is not secure at all it`s possible that somebody is
viewing/intercepting/modiIying/Iorging you and your inIormation at anytime anywhere
in the world. Comparing to the private network and Internet. private network use and
deployment is expensive; the Internet is not. Private networks are secure. while the
Internet is notoriously insecure. Private networks guarantee perIormance and a level oI
reliability; the Internet guarantee redundancy and availability. Private networks support
multiple WAN protocols; the Internet supports only TCP/IP. Private networks are
exclusive. rigid. and not easily scalable; the Internet is ubiquitous. Ilexible. and easily
scalable. with virtually unlimited potentials.

Figure 2. Internet Infrastructure - when vou connect to the Internet, vour computer
becomes part of the Aetwork. [33]

8
1.3.3 Virtual Private Network

A Virtual Private Network (VPN) is a private data network that makes use oI the
public telecommunication inIrastructure. maintaining privacy through the use oI a
tunneling protocol and security procedures. To understand Virtual Private Network Iully.
each oI the words in the name must be looked separately. Jirtual. in this case. means
dynamic and possibly changing. as opposed to the static hardwired network that we
normally would think oI. The idea oI a VPN is to make it appear to the hosts on each
end oI the connection. that they are part oI the same network. connected by a traditional
hardwired network. even though they are communicating over the public Internet. The
word Private in Virtual Private Network is a little harder to accurately deIine. Its
general meaning is that communications Irom each oI the endpoints to the other is
encrypted and is thereIore protected Irom snooping and tampering. Other deIinitions oI
a VPN are 'a communications environment in which access is controlled to permit peer
connections only within a deIined community oI interest. and is constructed though
some Iorm oI partitioning oI a common underlying communications medium. where this
underlying communications medium provides services to the network on a non-
exclusive basis. and 'a private network constructed within a public network
inIrastructure. such as the global Internet.

Figure 3. Jirtual Private Aetworks [34]


9
There are two common VPN types:

Remote-access - Also called a Virtual Private Dial-up Network (VPDN). this is a user-
to-LAN connection used by a company that has employees who need to connect to the
private network Irom various remote locations. Typically. a corporation that wishes to
set up a large remote-access VPN will outsource to an Enterprise Service Provider
(ESP). The ESP sets up a network access server (NAS) and provides the remote users
with desktop client soItware Ior their computers. The telecommuters can then dial a toll-
Iree number to reach the NAS and use their VPN client soItware to access the corporate
network.
A good example oI a company that needs a remote-access VPN would be a large
Iirm with hundreds oI sales people in the Iield. Remote-access VPNs permit secure.
encrypted connections between a company's private network and remote users through a
third-party service provider.

Site-to-site - Through the use oI dedicated equipment and large-scale encryption. a
company can connect multiple Iixed sites over a public network such as the Internet.
Site-to-site VPNs can be either:

Intranet-based - II a company has one or more remote locations that they wish to
ioin in a single private network. they can create an intranet VPN to connect LAN
to LAN.

Extranet-based - When a company has a close relationship with another
company (Ior example. a partner. supplier or customer). they can build an
extranet VPN that connects LAN to LAN. and that allows all oI the various
companies to work in a shared environment.


10
OI these 2 common types oI VPNs. there are 4 important VPN technologies exist:

Trusted VPNs
Secure VPNs
Hybrid VPNs
Provider-provisioned VPNs

Trusted VPNs
A VPN customer trusting the VPN provider to maintain the integrity oI circuits
and to use the best available business practices to avoid snooping oI the network traIIic.
It oIIers no real security.

Secure VPNs
VPNs that are constructed using encryption are called Secure VPNs. Encrypted
traIIic acts like it is in a tunnel between the two networks: even iI an attacker can see the
traIIic. they cannot read it. and they cannot change the traIIic without the changes being
seen by the receiving party and thereIore reiected.

Hybrid VPNs
A Secure VPN can be run as part oI a Trusted VPN. thus creating the third type
oI VPN: Hybrid VPNs. The secure parts oI a hybrid VPN might be controlled by the
customer (such as by using secure VPN equipment on their sites) or by the same
provider that provides the trusted part oI the hybrid VPN. Sometimes an entire hybrid
VPN is secured with the secure VPN. but more commonly. only a part oI a hybrid VPN
is secure.

Provider-Provisioned VPNs
VPNs that are administered by a service provider are called Provider-
Provisioned VPNs. All initiations and maintenances oI a Provider-Provisioned VPN are
done by someone other than the user oI the VPN.

11
1.3.3.1 Topologies

There are diIIerent topologies oI VPN depending on the application. Below
illustrates three basic varieties oI VPN topologies.

1.3.3.1.1 Host-to-Host

Host-to-Host VPN topology is the simplest implementation involving only two
end point computers. Figure 4 illustrates this setup - 2 hosts connected together via the
Internet thru their Local Area Network.

Figure 4: Host-to-Host JPA

12
1.3.3.1.2 Host-to-Network

Host-to-Network topology provides the possibility Ior a mobile user to connect
to a network. Figure 5 illustrates this situation:

Figure 5: Host-to-Aetwork JPA

13
1.3.3.1.3 Network-to-Network

Network-to-Network topology can be used to connect intranets. making them
appear to be adiacent to each other. Figure 6 is an illustration oI this conIiguration:

Figure : Aetwork-to-Aetwork JPA


14
1.4 What is Embedded Virtual Private Network (eVPN)
With the availability oI the broadband networks into general public usage and
the local residences. it is expected that embedded systems will soon be widely in use. In
the public Internet. security issues will become a bottleneck Ior such applications. The
Embedded Virtual Private Network (eVPN) is a solution Ior such dilemma.

Embedded Virtual Private Network is not a standard it is a proposed design
and architecture oI integrating the concept oI embedded systems with Virtual Private
Network (VPN). It oIIers numerous advantages over the existing conventional VPN
technologies:

Multi-platIorms eVPN supports multi-platIorms deployment. making
interoperability possible
Multiple-protocols eVPN supports almost every single VPN/tunneling
protocols. solving the problem oI interoperability with ease
Remote conIigurations eVPN can be conIigured anywhere in the world by
the user. with simple procedures via web browsers
Plug-n-Play eVPN is a selI-conIigurable device. take the conIiguration
problems away Irom the user


15
1.5 eVPN Goals

The eVPN proiect outlines the requirements. design and implementation issues
oI an Embedded Virtual Private Network (eVPN) system. and attempts to oIIer a
comprehensive design. architecture and implementation Ior sych system.

This proiect is undertaken by 3 soItware engineering students. Eric Chan. Chun
Ko and Jerome Lau under the supervision oI Dr. Xue Li. Although it is only in its Iirst
year oI running. but the development this interesting and yet challenging proiect will
surely be continued by other students in the Iuture.

The goals oI the eVPN proiect are used as the guidelines Ior each participating
student`s thesis. At such an early stage oI the proiect. it is divided into 3 maior sections:

PerIormance and Scalability oI eVPN
Architecture oI eVPN
Key Management oI eVPN

These areas are being researched and analyzed by students Eric Chan. Chun Ko
and Jerome Lau respectively. Each participating student is to apply the proiect goals to
their own subsection. and oIIer a comprehensive design oI eVPN system by integrating
them together.

Another important goal Ior this proiect is the development oI a prototype system
Ior eVPN.This model will Iorm the basis oI the eVPN system and Iurther development
will evolve Irom it.


16
1.6 Thesis Goal
The goal oI my thesis is to research and analyze the perIormance and scalability
issues oI eVPN. This includes an in-depth investigation on all existing VPN
technologies and protocols.

PerIormance and scalability are the maior concerns Ior the design oI eVPN. For
perIormance. 3 requirements are particularly Iocused:

Speed
Security Level
Quality oI Service

Speed
Speed is the most primary concern Ior eVPN it is the easiest Iorm oI
perIormance that an user can detect and notice. Finding a solution Ior constructing the
eVPN system in order to provide Iast connections to end users is the goal oI this area.
Notice that the speed` and scalability oI the system are deeply related to each other.

Security Level
The degree oI security is another maior design issue Ior eVPN. All security
requirements such as authentication. cryptography must be considered careIully and
thoroughly in order to provide saIe and secure eVPN services to the users.

Quality oI Service
The quality oI service Iocuses on the reliability and connectivity oI eVPN
system. How the eVPN system should be designed and implemented to minimize the
loss oI data and connections is the task Ior this section.


17
On the other hand. the scalability oI eVPN mainly Iocuses on 2 areas:

Scalability oI eVPN architecture
Scalability oI eVPN under operation

Scalability oI eVPN architecture
II new VPN protocols and services are invented or developed. how should they
be appended into the existing eVPN system? Devising suitable algorithms Ior the
scaling oI eVPN system is the goal Ior this section.

Scalability oI eVPN under operation
How the eVPN system should be designed in order to accommodate large
number oI users without compromising the perIormance is the main Iocus oI this
section.

PerIormance and Scalability are the two maior design issues oI eVPN they are
deeply related and must not be separated Irom each other. Analysis and evaluation oI
this 2 issues must be carried out careIully and thoroughly in order to provide a complete
and ideal design Ior eVPN.


18
1.7 Thesis Overview
The remainder oI this thesis explores the Iollowing areas in more detail.

1.7.1 Literature Review

This section outlines the existing VPN technologies developed. Details and
characteristics oI each technology will be discussed thoroughly. It also describes the use
oI the technologies and ways in which they are related to the eVPN proiect.

1.7.2 Design and Architecture of eVPN

This section outlines the design and architecture oI the eVPN system proposed
by the eVPN proiect members. It will be discussed comprehensively to provide an
insight view oI the system.

1.7.3 Implementation

This section outlines how the eVPN prototype system was implemented. All
instructions and procedures that are necessary Ior redeveloping the system will be
included.

1.7.4 Analysis and Recommendations

This section describes the recommend solutions to the PerIormance and
Scalability issues oI the eVPN design. It also relates to the architecture and key
management issues oI eVPN which are described by other two participating members.

19
1.7.5 Evaluation

This section outlines how much oI a success the proiect is. It discusses the
proiect and thesis goals and relates these to the implementation.

1.7.6 Future Work

This section describes what possible Iuture work that can be implemented to the
existing proiect and system.

1.7.7 Conclusion

This section summarizes the eVPN proiect.

Detail background discussions on intro and background can be found in.
[1]. [2]. [3]. [4]. [5]. [6]. [7]. [26]. [28]. [29]. [30]. [33]. [34]


20
2. Literature Review
What technologies make up an eVPN? What protocols should be considered

beIore designing the system? What are their characteristics? How well will they perIorm
and scale? This section Iocuses on the technologies considered during the design
process oI eVPN.

2.1 Transport Layer Protocols
The transport layer is the Iourth layer oI the OSI reIerence model. It provides
transparent transIer oI data between end systems using the services oI the network layer
(e.g. Internet Protocol) below to move data between the two communicating systems.
The transport service is said to perIorm "peer to peer" communication. with the remote
(peer) transport entity. The data communicated by the transport layer is encapsulated in
a transport layer PDU and sent in a network layer SDU. The transport layer relieves the
upper layers Irom any concern with providing reliable and cost eIIective data transIer. It
provides end-to-end control and inIormation transIer with the quality oI service needed
by the application program.
2.1.1 TCP
TCP Transmission Control Protocol. is a connection-oriented. end-to-end
reliable protocol designed to Iit into a layered hierarchy oI protocols which support
multi-network applications. The TCP provides reliable inter-process communication
between pairs oI processes in host computers attached to distinct but interconnected
computer communication networks. Very Iew assumptions are made as to the reliability
oI the communication protocols below the Transport layer - TCP assumes it can obtain a
simple. potentially unreliable datagram service Irom the lower level protocols. In
principle. the TCP should be able to operate above a wide spectrum oI communication
systems ranging Irom hard-wired connections to packet-switched or circuit-switched
networks.

21
TCP Connections

TCP has provisions Ior opening and closing connections. which are like
"conversations" between the local and remote processes. Once a connection has been
established. data may Ilow back and Iorth until the connection is closed.

TCP Ports

Several application programs may be running on one machine using a single
network interIace. Assigning a port number to every TCP connection helps TCP to keep
track oI what data goes to which program. The port number need not be the same on the
local and remote processes. When a TCP segment is received. the TCP knows which
process to pass it to by looking at the port number in the TCP header.

TCP sockets

A TCP socket is deIined as the combination oI the local IP address and the TCP
port number. An application wishing to use the Iacilities oI TCP must request a unique
socket Irom the TCP. This is known as 'opening a socket -
a connection is deIined by the local socket and the remote socket. An application must
know these two things in order to successIully communicate to a remote application
through TCP.

The TCP Header

Whenever TCP is called upon by the upper-layers to transport inIormation over
the network. it adds its own header. containing inIormation that helps TCP perIorm its
various tasks.

22
<!$
UDP User Datagram Protocol is a transport layer protocol deIined by the US

Department oI DeIence (DoD) Ior use with the IP network layer protocol. The service
provided by UDP is an unreliable service. which provides no guarantees Ior delivery
and no protection Irom duplication. The simplicity oI UDP reduces the overhead Irom
using the protocol and the services may be adequate in many cases.

UDP Connections

A computer may send UDP packets without Iirst establishing a connection to the
recipient. The computer completes the appropriate Iields in the UDP header and
Iorwards the data together with the header Ior transmission by the IP network layer.

UDP Ports

Generally. clients set the source port number to a unique number they choose
themselves - usually based on the program which started the connection. Since this
number is returned by the server in responses. this let the sender knows which
'conversation incoming packets are to be sent to. The destination port oI packets sent
by the client is usually set to one oI a number oI well-known ports. A server listens Ior
packets received with a particular well-known port number and tells its local UDP layer
to send packets matching this destination port number to the server program. It
determines which client these packets come Irom by examining the received IP source
address and the received unique UDP source port number. Any responses which the
server needs to send back to a client is sent with the source port number oI the server
(the well-known port number) and the destination port selected by the client.


23
UDP header

The UDP header and data are not processed by Intermediate Systems in the
network. and are delivered to the Iinal destination in the same Iorm as originally
transmitted.

2.1.3 TCP vs UDP
Although both TCP and UDP are transport layer protocols. but there are many
diIIerences exist between them:

UDP is a connectionless protocol. This means it does not perIorm retransmission
oI data and thereIore provides very Iew error recovery services. UDP instead
oIIers a direct way to send and receive datagrams (packets) over the network; it
is more suitable Ior broadcasting messages. multi-media data

TCP. on the other hand. provides a connection-based. reliable data stream.
(Whereas the IP protocol deals only with packets. TCP enables two hosts to
establish a connection and exchange streams oI data.) TCP guarantees delivery
oI data and also guarantees that packets will be delivered in the same order in
which they were sent.

24
A table summarizing the similarities and diIIerences between TCP and UDP is shown
below:
TCP UDP
Connection-oriented Connectionless
Checks Ior error No error checking
Guarantee Delivery Does not Guarantee Delivery
Maintain order oI delivery
Packets may arrive out oI
order
High reliability Low reliability
Retransmit packet oI errors
occur
No resending oI packets
Stream-oriented Packets-oriented
Has Ilow-control No Ilow control
Suitable Ior non-streaming
data transIer (e.g. File
TransIer)
Suitable Ior streaming data
transIer
(e.g. Online video streams)
Not suitable Ior multicasting Suitable Ior multicasting
Duplex Duplex
Not as Iast as UDP Faster than TCP
Large overheads Minimal overheads

1able 1. 1CP vs UDP


25
2.2 Tunneling Protocols

Many tunneling protocols exist in the market. and they can be categorized into 2
diIIerent classes Standard Tunneling Protocols and Non-Standard Protocols.

2.2.1 Standard Tunneling Protocols

Standard Tunneling Protocols are protocols that are developed by
authorities/giant companies such as MicrosoIt and Cisco. and standardized by IETF(The
Internet Engineering TaskForce) . usually widely employed by the public.

2.2.1.1 PPTP

PPTP Point-to-Point Tunneling Protocol. is a standard tunneling protocol
developed by PPTP Forum which consists oI MicrosoIt and some other remote access
vendors. Basically. PPTP is a protocol which allows the Point to Point Protocol (PPP) to
be tunneled through an IP network. PPTP does not speciIy any changes to the PPP
protocol but rather describes a new vehicle Ior carrying PPP.

PPTP uses a TCP connection known as the PPTP control connection to create.
maintain. and terminate the tunnel and a modiIied version oI Generic Routing
Encapsulation (GRE) to encapsulate PPP Irames as tunneled data. The payloads oI the
encapsulated PPP Irames can be encrypted or compressed or both.
PPTP assumes the availability oI an IP internetwork between a PPTP client (a
VPN client using the PPTP tunneling protocol) and a PPTP server (a VPN server using
the PPTP tunneling protocol). The PPTP client might already be attached to an IP
internetwork that can reach the PPTP server. or the PPTP client might have to dial into a
network access server (NAS) to establish IP connectivity as in the case oI dial-up
Internet users.

26
Not long aIter PPTP`s original release. many experts have discovered many
Ilaws with the implementation especially with authentication and encryption
algorithms. As described in Cryptanalysis oI MicrosoIt`s PPTP Authentication
Extensions (MS-CHAPv2)`( by Bruce Schneier and Mudge. the Iundamental
weakness oI the authentication and encryption protocol is that it is only as secure as the
password chosen by the user. Even though the PPTP`s encryption key may theoretically
have 128-bits oI entropy. the actual passwords used Ior key generation have much less.
and this allow cryptographic analysis to derive the key and plaintext relatively easily.
Another maior Ilaw with PPTP is that there is no method Ior a PPTP client to
authenticate the PPTP server. allowing attackers to impersonate the server and thus
compromising the security oI the inIormation.

Figure 7. PP1P connection
-

As opposed to PPTP. L2F (Layer 2 Forwarding) is the tunneling solution
developed by Cisco is 1996. As its name suggested. L2F protocol permits the tunneling
oI the link layer (layer 2 in the OSI model) oI higher-level protocols. Using such
tunnels. it is possible to divorce the location oI the initial dial-up server Irom the
location at which the dial-up protocol connection is terminated and access to the
network provided.


27
L2F`s essential diIIerence Irom PPTP is the ability to use protocols at layer 2 oI
the network protocol stack Ior tunneling purpose. including ATM (Asynchronous
TransIer Mode) and Frame Relay. In the basic setup. the user makes a PPP or similar
connection to a local ISP. At the request oI the user. the NAS. using the L2F soItware.
initiates a tunnel to the user`s destination. The end point that is. the corporate router
running L2F strips oII the tunneling headers. logs the traIIic and allows
communication to take place.

Although L2F oIIers many beneIits such as:

Protocol Independence (e.g. IPX. SNA)
Media Independence (e.g. ATM. X.25. Frame Relay)
Accounting

However. there are also some maior Ilaws exist. Since L2F`s intended usage is Ior
hardware switches and routers. the authentication and encryption schemes are not
implemented as well as it should be. And that`s the reason why L2TP and IPSec comes
into play.

$
Layer 2 Tunneling Protocol. or simply reIer as L2TP. is an extension oI the

Point-to-Point Protocol (PPP). It combines the best Ieatures oI PPTP and L2F it
merges the 2 protocols into a single standard. The motivation oI this action is
straightIorward by combining PPTP and L2F together. conIusion and interoperability
problems in the marketplace can be avoided.


28
So. what Ieatures are implemented in L2TP? How are they diIIerent Irom PPTP
and L2F? A list oI the Ieatures oIIered by L2TP is shown in below:

Encapsulates PPP
Utilizes UDP
Reliable signaling channel
Unreliable data channel (i.e. UDP)
Data channel sequencing
Tunnel level authentication

L2TP oIIers the same Iull-range spectrum oI Ieatures as L2F. but oIIers
additional Iunctionality. A L2TP-capable home gateway will work with an existing L2F
network access server and will concurrently support upgraded components running
L2TP. One oI the key diIIerences between L2TP and L2F is that L2TP requires
mandatory tunnel authentication. whereas L2F does not oIIer this Ieature. On the other
hand. PPTP and L2TP oIIer diIIerent Iunctionality. L2TP's design lets you use it over
non-IP-based networks. and the protocol establishes tunnel maintenance and control
using the same message Iormat and protocols. In contrast. PPTP works only over IP and
uses a separate TCP control connection Ior tunnel maintenance.

Since both L2F and L2TP do not have any strong cryptographic algorithm.
IPSec is usually employed along with L2TP; and since L2TP and IPSec operate at
diIIerent layers (L2TP Data Link Layer 2. IPSec at Network Layer). they can be used
together Ior added security.

Figure 8. L21P with IPSec (

29
2.2.1.4 IPSec
IPSec stands Ior IP security. perhaps it is the most widely recognizable and
employed tunneling protocols exist currently. IPSec is a Iramework oI open standards
that provides data conIidentiality. data integrity. and data authentication between
participating peers.

IPSec provides its service at the network layer. and uses several technologies Ior
establishing a VPN. such as:

DiIIie-Hellman key exchange
Digital Signatures
DES encryption
Keyed hash algorithm

Basically. IPSec provides security with 2 steps:

1. Encapsulate an IP packet by wrapping another packet around it
2. Encrypt the result

And the IP packets are encrypted through the Iollowing steps:

1. Original packet includes unencrypted header and data
2. The original packet is encapsulated with another header and space Ior
a message digest to serve as checksum
3. The checksum is created by Iollowing a message-digest Iormula
4. The entire packet is encrypted and transIerred to the destination


30
IPSec has two modes oI operation transport mode and tunnel mode:

Transport Mode

The transport mode oI IPSec can be used only when security is desired end to
end. When security is not enabled. transport layer packets such as TCP and UDP Ilow
into the network layer. IP. which adds the IP header and calls into the data link layer.
When security in transport layer is enabled. the transport layer packets Ilow into the
IPSec component. The IPSec component is implemented as part oI the network layer
(when integrated with OS). The IPSec component adds the AH. ESP. or both headers.
and invokes the part oI the network layer that adds the network layer header.

Tunnel Mode

IPSec in tunnel mode is normally used when the ultimate destination oI the
packet is diIIerent Irom the security termination point. The tunnel mode is used in cases
when security is provided by a device that did not originate packets - as in the case oI
VPNs. or when the packet needs to be secured to a destination that is diIIerent Irom the
actual destination.

IPSec established its outstanding position as the best tunneling protocol when it
was integrated as part oI the MicrosoIt Windows 2000 release and included as a
mandatory part oI the Ipv6 implementation. Because oI its growing popularity and
usage. many open source IPSec implementation Ior operating systems other than
MicrosoIt are emerged. One oI the most successIul implementation is the FreeS/WAN
VPN Ior Linux.

Although IPSec is such a widely recognizable and employed tunneling protocol.
but does this mean it has no weakness at all? In paper Cryptographic Evaluation oI
IPSec` # by Niel Ferguson and Bruce Schneier. IPSec is criticized to be too complex.
IPsec contains too many options and too much exibility; there are oIten several ways oI
doing the same or similar things - the complexity has lead to a large number oI

31
ambiguities. contradictions. ineIIiciencies. and weaknesses. Another disadvantages oI
IPSec is the interoperability currently. only MicrosoIt`s operating systems have
included IPSec along their release; iI users want to employ IPSec on other operating
systems. it can be an annoying and complex procedure (e.g. compiling Linux Kernel).

Figure 9. IPSec in 1unnel Mode

2.2.1.5 MPLS

Multiple Protocol Layer Switching (MPLS) is an IETF (Internet Engineering
Task Force) standardized label distribution protocol proposed by Cisco in 2001.
Basically. MPLS is a packet-Iorwarding technology which uses labels to make data
Iorwarding decisions. With MPLS. the Layer 3 header analysis is done iust once (when
the packet enters the MPLS domain). Label inspection drives subsequent packet
Iorwarding. Additionally. it decreases the Iorwarding overhead on the core routers.
MPLS technologies are applicable to any network layer protocol.

By providing better perIormance and scalability over all existing VPN
technologies. MPLS is regarded as the replacement and standard oI VPN applications in
the Iuture.


32
2.2.2 Non-Standard Tunneling Protocols

Non-standard Tunneling Protocols Protocols that are developed by small
companies/individuals. usually not widely used by the public.

2.2.2.1 OpenVPN

OpenVPN is an open source proiect developed by networking expert James
Yonan this implementation was the winner oI openChallenge in 2001. Fundamentally.
OpenVPN is a conIigurable VPN (Virtual Private Network) daemon which can be used
to securely link two or more private networks using an encrypted tunnel over the
Internet.

There are many distinguishable Ieatures implemented in OpenVPN:

OS independent it can be run on Linux. Solaris. OpenBSD.
FreeBSD. and MAC OS X
It uses industrial-strength security model designed to protect against
both active and passive attacks. OpenVPN's security model is similar
to that oI IPSec but with a much lighter Iootprint and no kernel or IP
stack modiIication requirements.
OpenVPN uses OpenSSL PKI Ior session authentication. the TLS
protocol Ior key exchange and the HMAC algorithm Ior
authenticating tunnel data

However. there are also disadvantages associated with OpenVPN since
OpenVPN operates in a high layer oI session layer. it adds a Iair amount oI overheads to
the packets and hence seriously reducing the network throughput. in other words.
downgrading the perIormance oI the network.


33
2.2.2.2 cIPE

Crypto IP Encapsulation (cIPE) is a simple. lightweight package that provides
Ior tunneling oI encrypted IP packets over UDP. At present. CIPE can be run on both
Linux and MicrosoIt Windows. making interoperability possible. Features oI CIPE
include:
Supports dynamic addresses
NAT Network Address Translation
SOCKS proxies

Similar to OpenVPN. CIPE provides its services in session layer Iair amount
oI overheads exist and hence degrading the network perIormance.

2.2.3 Comparisons

There are many tunneling protocols exist they can be categorized into two
categories: Standard Tunneling Protocols and Non-Standard Protocols. The 2 tables
shown below summarizes all tunneling protocols (except MPLS it is not part oI the
scope Ior the eVPN design) discussed in previous sections:

Layer NAT
Behind
Firewall
Multiple
Protocols
SOCK
PPTP Link
Not
Supported
Not
Supported
Not
Supported
Not
Supported
L2F Link
Not
Supported
Not
Supported
Supported
Not
Supported
L2TP Link
Not
Supported
Not
Supported
Supported
Not
Supported
IPSec Network
Not
Supported
Not
Supported
Not
Supported
Not
Supported
OpenVPN Session Supported Supported Supported Supported
CIPE Session Supported Supported Supported Supported

1able 2a. 1unneling Protocols

34
Overhead Encryption Authentication
PPTP Small Weak Weak
L2F Small Weak Weak
L2TP Small Medium Medium
IPSec Medium Strong Strong
OpenVPN High Strong Strong
CIPE High Strong Strong

1able 2b. 1unneling Protocols

35
2.3 Key Management
Key Management is another signiIicant topic associated with the PerIormance

and Scalability issues oI eVPN design. The main Key Management and Authentication
Protocols being researched by eVPN proiect are:

Interent Key Exchange (IKE in IPSec)
Transport Layer Security (TLS in OpenVPN)
Kerberos
EHA

Please reIer to paper Embedded Virtual Private Network - Key Management`
by Jerome Lau Ior Iurther discussions.

Reference used in Section 2. [8]. [9]. [10]. [11]. [12]. [13]. [14]. [15]. [16]. [17]. [18].
[19]. [20]. [21]. [22]. [23]. [24]. [25]. [27]. [31]. [32]. [35]. [36]. [37]

36
3.0 Design and Architecture of eVPN

This section describes the generic design and architecture oI eVPN proposed by
eVPN proiect team. All components in the system will be outlined individually Iollow
by discussions on their Iunctionalities.

Figure 1. eJPA Architecture

37
3.1 Specification of eVPN

Embedded Virtual Private Network (eVPN). is a revolutionary design proposed
by the eVPN proiect team in 2002. As its name suggested. eVPN combines the
embedded system concepts along with existing Virtual Private Network technologies. It
utilizes VPN. network and embedded system technologies to produce an exciting and
yet distinctive design that cannot be Iound anywhere in the market.

The deployment oI eVPN is highly recommendable. as it oIIers numerous
advantages and unique Ieatures over conventional VPN applications:

Multi-platIorms
Whether the user is using MicrosoIt Windows. Linux or other Operating
System. he/she is able to connect to the network securely using eVPN.
Services are capable oI oIIering its Iull Iunctionality to every user
connected regardless oI their platIorms.

Multi-protocols
eVPN supports multiple VPN protocols IPSec. CIPE. OpenVPN.
PPTP. L2TP. etc. Users can connect to the any services they desired
without worrying about the problems oI installing. compiling and using
diIIerent protocols in their system.

Remote conIigurations
The embedded VPN device can be conIigured remotely under a secure
manner by using SSH or Web Services.

Plug-and-Play
eVPN will do everything Ior you it will automatically select the best
protocols available Ior connection. generate/re-generate certiIicates and

38
download drivers or updates when necessary. It requires minimum
conIiguration to provide VPN Iacilities.

eVPN has a simple and yet powerIul architecture. with essentially 2 maior
components exist in the system eVPN device and eVPN Central Server.

3.1.1 eVPN Device
The proposed eVPN device should be compact and portable. It should only
contains minimal amount oI system resource such as memory. and all eVPN services
can be achieved by allowing the device to dynamically download and update protocols
and other related inIormation Irom the Internet. It can be actively controlled by a user.
or passively iust providing end services to authenticated users. Ior example. a web-
enabled camera Ior traIIic monitoring system.

To protect against unauthorized usage. each eVPN device is associated with a
unique serial number - this serial number is used in the authentication scheme.

3.1.1.1 Authentication Scheme

Authentication is the key requirement Ior every security system. Authentication
scheme must be designed and implemented cautiously and entirely to ensure the
conIidentiality. integrity and availability oI inIormation and services. Since eVPN is
such an open and scalable system. authentication scheme must be employed.

Each eVPN device contains a unique identiIier - serial number. Along with
public key and digital certiIicate. the three oI them Iorm the basis oI the components
used in the authentication scheme. The authentication scheme is described below:

1. On initialization. each eVPN device will generate two keys automatically:
i. Private key must be kept secret and must not be unveiled in
any circumstances

39
ii. Public key can be sent across network Ior authentication
purpose. open to everybody

2. eVPN device sends its public key to CertiIicate Authority to obtain a Digital
CertiIicate
3. eVPN device connects to the eVPN Central Server through predeIined login
module
4. Establish VPN connection with the desired device

(Step 1 will only be perIormed on its Iirst connection/when the digital certiIicate has
expired)

This authentication scheme Iollows the Public Key InIrastructure (PKI). Please
reIer to paper Embedded Virtual Private Network Key Management` by Jerome Lau
Ior a more detailed version.

3.1.1.2 Configuration and Services

Once the eVPN device has been authenticated. it will be able to perIorm its
desired operation. Depending on its nature. conIiguration may be required.

The proposed eVPN device is intelligent - aIter analyzing the setup and
connection. it will be able to make all the necessary conIigurations automatically. For
example. iI the desired tunneling protocol Ior the connection is not supported. the eVPN
device will download all mandatory Iiles and packages. and perIorm the installation
automatically. AIter Iinishing this automated procedure. the eVPN device can perIorm
the desired operation with maximum eIIiciencies and perIormance with the established
connection.

Recommendations to the choice oI tunneling protocol Ior eVPN connection are
presented in the section 5 oI this paper. Please reIer to paper Embedded Virtual Private

40
Network Architecture` by Chun Ko Ior a in-depth discussion on the conIiguration oI
eVPN device.

3.1.2 eVPN Central Server
The eVPN Central Server is responsible Ior several tasks in the system. They are
described in the Iollowing pages.

3.1.2.1 Authentication
The eVPN Central Server must be able to authenticate multiple eVPN devices.
Device`s public key. password (generated using eVPN device`s serial-number) and
digital certiIicate must be veriIied iI any oI them Iails during the authentication
process. its request will be reiected; iI the device is successIully authenticated. the
request will be recorded.

3.1.2.2 Access Control

Access control is also one oI the many tasks that the eVPN Central Server
perIorms. Access control is probably the central Iunction oI computer security
conIidentiality. integrity and availability all concern the prevention oI certain types oI
access.

In eVPN system. once an eVPN device is authenticated. its request will be
checked against the ACL (Access Control List) stored in the central server. An ACL
describes which obiects have access to which obiects/subiects. and what sort oI access
privileges. II the request is valid. the eVPN Central Server will connect to the target
eVPN device - note that the automated conIiguration. authentication scheme and access
control validation must also be perIormed on the target device.


41
3.1.2.3 Session Tracking
Session tracking is yet another duty responsible Ior eVPN Central Server. Once
the automated conIiguration. authentication scheme and access control validation has
been perIormed on both parties. a VPN connection can be established.

All VPN connections are recorded by the eVPN Central Server by tracking all
existing sessions. the central server can utilizes this inIormation to enhance the overall
perIormance and scalability oI the system. as well as perIorming actions such as port
conIigurations. At the end oI the each VPN connection. the eVPN Central Server will
update its database with the new inIormation oI the eVPN devices.

42
4.0 Implementation

A prototype eVPN system is implemented by eVPN proiect team. This section
describes all relevant details regarding system.

4.1 System Architecture

The eVPN prototype is implemented under Linux operating platIorm. A
minimum oI 3 computers are required Ior the setup - 1 workstation will act as the
central management system. network traIIic monitor and providing key management
services. while the other 2 gateway machines on either side oI the network will act as an
eVPN device; additional computers can be integrated into the system by placing them
behind the gateways (act as host machine).

A tunnel is setup between the two gateways using OpenVPN (or FreeS/WAN
IPSec) to provide secure communications over an insecure channel. Streaming and non-
streaming data packets can be transIerred across the network with the conIidentiality.
availability and integrity ensured. The system layout is illustrated in Figure 11:

Workstation Embedded VPN #2
Monitor/Centre Server
Embedded VPN #1 Workstation
192.168.1.0/24
192.168.0.0/24
10.0.0.0/24 10.0.1.0/24
Video
.1.2
1.1. .0.1
.0.2
.0.254 .0.1 .1.254 .1.1

Figure 11. Architecture of eJPA prototvpe svstem


43
The middle computer (reIerred to as the Internet machine. with IP 192.168.0.1
and 192.168.1.1) has two network interIaces and is acting as an Internet router. It also
served as the CertiIication Authority to sign certiIicates Ior the VPN computers/devices.
Since this machine behaves as the public Internet. it will also perIorm traIIic monitoring
and 'packet sniIIing. This computer has been implemented using Linux platIorm.

Embedded VPN#1 and Embedded VPN#2 are two VPN gateways that provide
all necessary security support to the two 10.0.X.X internal networks. Both FreeS/Wan
IPsec and OpenVPN are enabled to provide host-host. host-network and network-
network topology VPN systems.

4.2 System Requirements
The hardware and soItware requirements Ior the eVPN prototype system is listed
in the Iollowing table:

CPU Pentium III or equivalent class
RAM 256 mb
Hardrive Space 4 GigaBytes
Others 2 Network InterIace Card
1able 3. Hardware Requirements for eJPA prototvpe svstem

OS Linux Redhat 7.2
SoItware Packages OpenSSL http://www.openssl.org
OpenSSH http://www.openssh.org
FreeS/WAN IPSec http://www.Ireeswan.org
PHP http://www.php.net
Apache Web Server http://www.apache.org
OpenVPN http://openvpn.sourceIorge.net
MPEG4IP Video Streaming Package
http://mpeg4ip.sourceIorge.net/
IPGrab http://ipgrab.sourceIorge.net
1able 4. Software Requirements for eJPA prototvpe svstem


44
4.3 Setting up the System
In order Ior the eVPN prototype system to Iunction Ilawlessly. all hardware and
soItware requirements described in the previous section must be IulIilled. With the
diIIerent Iunctionalities provided by the monitoring machine and the 2 VPN gateways.
diIIerent setups are applied to them.

On all machines. install:

openSSL provides security modules
openSSH provides security modules

On the monitoring machine. install:

IPGrab provides all monitoring Iunctions
Apache provides web services
PHP provides dynamic web page generation

On the VPN gateways. install:

OpenVPN provides tunneling in session layer
FreeS/WAN provides tunneling in network layer
MPEG4IP provides video streaming modules

Detail descriptions oI the installation procedure are attached to the Appendices section.

45
5.0 Analysis and Recommendations

This section outlines the analysis perIormed using the results obtained Irom tests
carried out on the prototype system described in Section 4. Recommendations to
perIormance and scalability issues oI the eVPN design are also described in this section.

5.1 Performance Test
As described in Section 4. two tunneling protocols are installed in the prototype

system IPSec (standard tunneling protocol) and OpenVPN (non-standard tunneling
protocol). Networking command ping` is used Ior testing the perIormance oI the 2
protocols. This test is also perIormed on insecure network (i.e. no tunneling) to provide
some guidelines Ior the results.

A shell script Iile is written Ior the test. and it is attached in Section 10 oI this
paper. The script Iile executes the ping` command a total oI 324 times with an
increased packet size in every 30 executions. The packet sizes used in the test are (in
bytes): 8. 64. 128. 256. 512. 1024. 2048. 4096. 8192. 16384. 32768. 65507 respectively.
The results obtained are also attached to the Appendices section.

5.1.1 Results

Graphical representations oI the results are shown in the Iollowing pages.


46

Figure 12. Performance of Insecure Channel

Figure 13. Performance of IPSec

47

Figure 14. Performance of OpenJPA

nsecure Channel PSec OpenVPN
Figure 15. Insecure Channel vs IPSec vs OpenJPA

48
5.2 Analysis

As the graphs illustrated. IPSec is by Iar the better tunneling protocol option
over OpenVPN.

5.2.1 IPSec

The perIormance oI IPSec goes downhill as the packet size grows. This is due to
the Iact that IPSec adds additional headers as well as perIorms encryption on the
original packets the time Ior IPSec to encapsulate the packet keeps getting longer and
longer as the packet size gets bigger. One interesting note to notice is that the
perIormance keeps almost constant when dealing with packets that are between 16384
and 32768 bytes aIter this range. the perIormance goes back to its downhill trend
again.

5.2.2 OpenVPN
Similar to IPSec. the perIormance oI OpenVPN goes downhill as the packet size
grows. but in a much more dramatic scale. The time required Ior transmission grows
wildly aIter the packet size reaches 8192 bytes only two out oI thirty packets sent
were received when the packet is set to 16384 bytes. and the time required Ior those
transmissions are around 2 seconds; the remaining 28 packets are regarded as loss since
they took much longer than the speciIied interval oI ping` command to transmit. The
100 loss oI packets with packet size 32768 and 65507 can be explained with the
same reason they iust took too long to transmit even the ping` command stopped
waiting Ior them. This occurrence is totally unacceptable Ior eVPN as the overall
system perIormance will suIIer heavily undoubtedly.


49
5.2.3 Summary
Although the perIormance oI both IPSec and OpenVPN suIIer greatly as the
transmit packet size grows. but it is not diIIicult to see that which one has the more
catastrophic eIIect. The primary cause to such occurrence is the diIIerence in the layers
that the two protocols Iunction in: IPSec works in Network Layer whereas OpenVPN
works in Session Layer. IPSec perIorms its routines in a very deep level (kernel level)
oI the system the time required Ior operations such as encryption is kept as minimal as
possible; OpenVPN operates in a much higher level the need to call external soItware
packages (e.g. openSSL) Ior the necessary operations makes the perIormance suIIer
deeply. let alone the signiIicant amount oI overheads generated. Overall. IPSec is
absolutely the more preIerable choice oI tunneling protocol over OpenVPN.

5.3 Recommendations

This section describes the recommendations to the eVPN design and architecture
with the limitations to time and resources. the accuracy oI these recommendations
may be aIIected due to the assumptions and lack oI experimentations made during the
implementation.

5.3.1 Performance

Recommendations to the perIormance oI eVPN system are presented in this
section.

5.3.1.1 Transport Layer Protocols

Which one is better? TCP or UDP? With diIIerent Ieatures oIIered by the two
protocols. it`s an extremely diIIicult task to draw an absolute answer so generally
speaking. the answer is it depends`.


50
In eVPN. TCP and UDP can be employed Ior diIIerent purposes - when dealing
with applications that require high reliability and control. TCP will be the preIerable
choice; when dealing with applications where speed preIerred rather than reliability.
UDP is the more preIerable choice. Below is a list oI recommended applications Ior the
usage oI the two protocols:

TCP UDP
File TransIer. Online Transactions Streaming Audio/Video. Monitoring
Systems
1able 5. Recommended usages of 1CP and UDP

5.3.1.2 Tunneling Protocols

The results and analysis presented in section 5.1 and 5.2 have shown that
standard tunneling protocols are a much more preIerable choice Ior eVPN than non-
standard tunneling protocols.

PPTP. L2F. L2TP and IPSec are the primary considerations Ior eVPN. and out
oI these protocols. IPSec has proven to be the best solution. Although IPSec is criticized
to be too complex. but it oIIers by Iar the best security compare to other tunneling
protocols. One minor concern oI IPSec is the interoperability problem at present. only
MicrosoIt Windows have included IPSec as part oI their operating system release the
need Ior installation and compilation may prove to be a signiIicant issue to the eVPN
system. Nonetheless. enabling IPSec is strongly recommended to every eVPN device
and component in the eVPN architecture.

5.3.1.3 Key Management

Please reIer to paper Embedded Virtual Private Network Key Management`
Ior recommendations regarding key management issues.

51
5.3.2 Scalability
Recommendations to the scalability oI eVPN system are presented in this

section. With the limitations to time and resources. all recommendations stated in this
particular section are based on theoretical analysis and assumptions.

In order Ior a system to scale. there are many considerations need to be taken.
PerIormance is again the Iundamental issue oI scalability Ior a system to be scalable.
the overall perIormance oI the system should stays steady regardless oI the number oI
users/devices connected; it needs not to be best perIormance. but it needs to be constant
under any circumstances.

The Iollowing sections describe several design and implementations
recommendations to eVPN system.

5.3.2.1 eVPN Device

The eVPN device is the primary source` oI scalability it is the one that
provides end services to users. Depending on the scale oI the eVPN system. several
hundreds or even millions oI these devices can be connected at any given time.

Simplicity is the goal Ior the design oI eVPN device. Since it will interact with
the eVPN Central Server and other devices Irequently. the inIormation that required Ior
these interactions should be minimal. As proposed in the eVPN design and architecture
described in Section 3. an eVPN device will only contain the necessary inIormation Ior
all interactions and communications:

Unique Serial Number
Digital CertiIicate
Private Key
Public Key

52
Regarding the physical appearance oI the device. it should be designed as
compact as possible in order provide maximum portability to users only minimal
system resources such as memory and processor should be contained in the device.

5.3.2.2 eVPN Central Server

eVPN Central Server is the heart eVPN system. How it should be structured.
implemented and operated are the most important concerns oI the design and
architecture oI eVPN.

The eVPN Central Server is the bottleneck oI the entire system every eVPN
device must make itselI present to the central server beIore initiating any VPN
connection thereIore. any malIunctioning oI the eVPN Server represents a Iailure to
the entire eVPN system; in other words. it is the single point oI Iailure oI the entire
system.

Replicating this eVPN Central Server is a possible solution to this dilemma.
With consistent and accurate rules implemented. the eVPN system can be conIigured to
be scalable easily.

II the eVPN network covers a wide area (e.g. country-wide). the central
server can be replicated and placed in diIIerent branches oI the network
to provide Iaster and more eIIicient VPN connections
eVPN Central Server should only record and store the minimal
inIormation required to maintain its service and system
II the eVPN Central Server is replicated. all inIormation should be
propagated as Iast as possible to other copies` to maintain a consistent
state oI the system
II replication is not implemented. a backup server should still be
developed and ready to operate in case oI any malIunctioning oI the
current server in place.

53
5.3.2.3 eVPN Resource Server

New protocols are invented every now and then. In order to provide the most up-
to-date technologies and services. the underlying design oI eVPN must be Ilexible in
order to scale.

As mentioned in the previous sections. eVPN is a highly intelligent system it
oIIers multi-platIorms. multi-protocols. remote conIigurations and plug-n-play Ieatures
to all eVPN users. All necessary protocols. Iiles and drivers required to establish VPN
connections must be downloadable and available to every eVPN device thereIore.
when new protocols and services are deIined. it is not hard to integrate them into the
eVPN system.

eVPN Central Server is the heart oI the eVPN system. and because oI the
Irequent accesses by eVPN devices. the tasks oI providing protocols. Iiles and drivers
should be separated Irom it. A eVPN Resource Server` is recommended to be
implemented in the eVPN architecture the eVPN Resource Server will only supply the
Iiles. protocols and drivers to all the eVPN devices its existence can oIIload the
demands Ior eVPN Central Server and hence. making the system more scalable. Similar
to the central server. the Resource Server can also be replicated and located in diIIerent
branches oI the network. Any new resources can be integrated into the eVPN system by
placing them in the resource server.

Figure 1. Replication of eJPA Central Server and Resource Server

54
6.0 Evaluation
This section outlines the overall evaluation oI the eVPN proiect. The entire
evaluation is divided into 4 distinctive segments proiect evaluation. system evaluation
thesis evaluation and personal evaluation.

6.1 Project Evaluation
Did all eVPN proiect goals have been achieved? The answer is no but with
some partial successes. Although a generic design and architecture oI eVPN has been
proposed by the eVPN proiect team. but with the lack oI experimentations and
implementations. it is diIIicult to iudge rather it is successIul or not. The limitations to
time and resources can be concluded as the contributing Iactors oI such happening. as
they restrict the possibility oI Iurther developments. However. this proiect should be
served as the guidelines and basis oI any evolutions oI eVPN.

6.2 System Evaluation

The development oI an eVPN prototype system is one oI the maior goals oI the
proiect. As stated previously. the lack oI time and resources restricts the possibility oI
any advanced development oI the system. Because oI eVPN`s special requirements.
University oI Queensland had not been able to oIIer any resources at all throughout the
proiect.

The current state oI the eVPN prototype system is very generic a minimum oI
3 computers is required Ior such implementation no eVPN device and eVPN Central
Server are implemented in place. let alone the proposed eVPN Ieatures. Given more
time and resources. the overall system state should be much more advanced compare to
the present status. The recommended Iurther developments are discussed in Section 7 oI
this document.

55
6.3 Thesis Evaluation

This thesis is partially successIul the obiectives have only partially achieved.

The goal oI this thesis is the research and analysis oI the PerIormance and
Scalability issues oI eVPN as the consequences oI the limitations mentioned. only the
perIormance issues were being successIully researched and analyzed.

The study oI perIormance oI transport layer protocols and tunneling Protocols is
the one oI the primary obiectives Ior this thesis. and it had been successIully carried out
through researching and testing - results and analysis oI the perIormance are used to
draw out the recommendations presented.

On the other hand. the study oI scalability is rather a disappointing area to this
thesis no physical tests and implementations regarding this area were actually
developed. and again. due to the limitations oI the eVPN proiect. All recommendations
presented are only based on assumptions and theoretical analysis.

6.4 Personal Evaluation
The key obiective oI an undergraduate thesis is to give the student a challenge

similar to that oI an industrial proiect. The student is oIten required to expose to new
technologies and adapt to changing requirements.

Some oI the areas in which the author perIormed well are:

Working in a team environment
Communication and presentation skills
Learning and working with unIamiliar technologies


56
Some oI the areas in which the author could improve are:

Organizing and managing the thesis more eIIectively
Be more motivated
IdentiIies and reports any Ioreseeing diIIiculties immediately

6.5 Summary
Overall. this thesis is considered to be a success by the author. Given the

restricted and extreme state oI the proiect. this thesis presentation should be considered
as at least commendable. While some obiectives are not completed entirely. yet this
thesis should serve as an ideal guideline Ior any Iurther developments.

57
7.0 Future Work

With the partially completed obiectives. room Ior Iuture developments deIinitely
exists in eVPN proiect.

Generally speaking. eVPN proiect is only in its initial phase. ModiIications and
reIinements are deIinitely needed to be made to the design and architecture proposed in
this paper. The key to any Iuture developments is the availability oI resources there is
no point evaluating and modiIying the existing design without any implementations and
experimentations. The implementation oI eVPN Central Server will surely be the next
important step oI the proiect as it is the heart oI the entire design.

Regarding the perIormance issues oI eVPN. the testing and analysis on other
tunneling protocols is strongly recommended. especially the MPLS protocol. as it is
regarded as the Iuture standard oI all VPN applications. However. the analysis oI
scalability issues relies on the Iuture developments to the prototype system and
availability oI resources.

In summary. the eVPN proiect still has a long way to go beIore its completion
Iuture developments are required in order to produce a working prototype system
matching the design and architecture proposed.

58
8.0 Conclusion

The eVPN proiect set out to create a revolutionary. scalable and state-oI-art
embedded VPN system by combining embedded system concepts with existing VPN
technologies. Limited number oI similar technologies exist but with not the same
speciIic design goals in mind. The lack systematic approach in these technologies is
improved upon in the eVPN proiect.

A generic design oI eVPN has been proposed by the eVPN team research and
analysis on architecture. perIormance and scalability. and key management issues oI
eVPN were carried out throughout the course oI this proiect. The outcome oI these
studies are presented in 3 thesis document Embedded Virtual Private Network
Architecture` by Chun Ko. Embedded Virtual Private Network: PerIormance and
Scalability` by Eric Chan and Embedded Virtual Private Network Key Management`
by Jerome Lau.

A Iully Iunctioning prototype system has not been the result oI the team`s eIIort.
The lack oI support and resources was the maior contributing Iactor oI such happening.
The implementation oI eVPN Central Server is a vital step oI the entire proiect. and it is
recommended as the next milestone to achieve by Iuture developments. However. the
outcome oI this proiect should be used as the starting point oI any Iuture work to the
eVPN system.


59
9.0 References

|1| Oleg Kolesnikov. Brian Hatch. Building Linux Private Networks (JPNs). New
Riders Publishing. United oI States oI America. 2002

|2| Mark Merkow. Jirtual Private Networks For Dummies. IDG Books Worldwide Inc..
Forest City. CA. 1999

|3| David Leon Clark. IT Managers Guide to Jirtual Private Networks. McGraw-Hill.
New York. 1999

|4| David McDysan. JPN Applications Guide Real Solutions Enterprise Networks.
Wiley Computer Publishing. Canada. 2000

|5| Steven Brown. Implementing Jirtual Private Networks. McGraw-Hill. New York.
1999

|6| Steve Heath. Embedded Svstems Design. OxIord. Boston. Newnes. 1997

|7| Bob Toxen. Real World Linux Securitv. Intrusion Prevention. Detection and
Recoverv. Prentice Hall PTR. 2000
|8| D. Harkins. D. Carrel. The Internet Key Exchange (IKE). RFC 2409
http://www.ietI.org/rIc/rIc2409.txt. November 1998

|9| S. Kent. R. Atkinson. Authentication Header. RFC 2402.
http://www.ietI.org/rIc/rIc2402.txt. 1998.

|10| S. Kent. R. Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406.

|11| M.A. PADLIPSKY. TCP-ON-A-LAN. RFC 0872.
http://www.ietI.org/rIc/rIc0872.txt. September 1982

|12| S. Kent. R. Atkinson. Security Architecture Ior the Internet Protocol. RFC 2401.
http://www.ietI.org/rIc/rIc2401.txt. November 1998.

|13| J. Postel. The TCP Maximum Segment Size and Related Topics. RFC 0879.

60
|14| W. Townsley. A. Valencia. A. Rubens. G. Pall. G. Zorn. B. Palter. Layer Two
Tunnelling Protocol "L2TP". RFC 2661. http://www.ietI.org/rIc/rIc2661.txt. August
1999.

|15| K. Hamzeh. G. Pall. W. Verthein. J. Taarud. W. Little. G. Zorn. Point-to-Point
Tunnelling Protocol (PPTP). RFC 2637. http://www.ietI.org/rIc/rIc2637.txt. July 1999.

|16| C. Shue. W. Haggerty. K. Dobbins. OSI connectionless transport services on top of
UDP. Jersion 1. RFC 1240. http://www.ietI.org/rIc/rIc1240.txt. June 1991

|17| A. Valencia. M. Littlewood. T. Kolar. Cisco Layer Two Forwarding (Protocol)
"L2F". RFC 2341. http://www.ietI.org/rIc/rIc2341.txt. May 1998.

|18| J. Postel. User Datagram Protocol. RFC 0768. http://www.ietI.org/rIc/rIc0768.txt.
August 1980

|19| K. Hamzeh. G. Pall. W. Verthein. J. Taarud. W. Little. G. Zorn. Point-to-Point
Tunneling Protocol (PPTP). RFC2637. http://www.ietI.org/rIc/rIc2637.txt. July 1999

|20| B. Gleeson. A. Lin. J. Heinanen. G. Armitage. A. Malis. A Framework Ior IP
Based Virtual Private Networks. RFC2764. http://www.ietI.org/rIc/rIc2764.txt.
February 2000

|21| J. Schiller. Strong Security Requirements Ior Internet Engineering Task Force
Standard Protocols. RFC3365. http://www.ietI.org/rIc/rIc3365.txt. August 2002

|22| B. Patel. B. Aboba. W. Dixon. G. Zorn. S. Booth. Securing L2TP using IPsec. RFC
3193. http://www.ietI.org/rIc/rIc3193.txt. November 2001.

|23| Tim Clark. How to design A Windows 2000 Server Networking Infrastructure to
Interoperate With Windows NT Server 4.0.
http://www.microsoIt.com/TechNet/tcevents/itevents/ Iall/tnq20002/html/TNQ200-
02.ppt. 2002

|24| Niels Ferguson. Bruce Schneier. A Crvptographic Evaluation of IPSec.
http://www.counterpane.com/ipsec.pdI. 2000

|25| Bruce Schneier. Mudge. Crvptanalvsis of Microsofts PPTP Authentication
Extensions (MS-CHAPv2). http://www.counterpane.com/pptpv2.pdI. 1999

61
|26| JPN Technologies. Definitions and Requirements. VPN Consortium. June 2002.
http://www.vpnc.org/vpn-technologies.pdI

|27| Securitv of the MPLS Architecture. Cisco Systems. Inc. Posted: Fri Sep 20
12:50:54 PDT 2002.
http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/mxinIds.pdI

|28| Designing Large-Scale IP Internetworks. Cisco Systems. Inc. Posted: Wed Apr 10
10:53:13 PDT 2002.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd2003.pdI

|29| Paul Ferguson. What is JPN.
http://www.nanog.org/mtg-9806/ppt/Ierguson/Iergeson.PPT. 1998

|30| J. Holmwood. K.Reichert. B.Feniak. Provideing Secure Access to Information
using the Internet.
http://www.usenix.org/publications/library/proceedings/lisa-
nt2000/Iullpapers/holmwod/holmwood.pdI.
Sep 2002.

|31| J.d.Leeuw. Microsoft L2TP/IPSec JPN Client. FreeS/WAN interoperabilitv.
http://www.iacco2.dds.nl/networking/msl2tp.html. July 2002.

|32| BT Ignite. Application Note.Using WebPort & PPTP
http://www.ignite.com/uk/products/webport/WebPortPPTPTunnelling.pdI. April 2002

|33| How Internet InIrastructure Works. Available at
http://www.howstuIIworks.com/internet-inIrastructure.htm. Last Accessed: 13-10-2002

|34| How Virtual Private Network Works. Available at
http://www.howstuIIworks.com/vpn.htm. Last Accessed: 13-10-2002

|35| ConIiguring Layer 2 Tunneling Protocol (L2TP) over IPSec. Available at
http://www.cisco.com/warp/public/707/24.html. Last Accessed: 13-10-2002

|36| OpenVPN. Available at http://openvpn.sourceIorge.net/. Last Accessed 13-10-2002

|37| cIPE - Crypto IP Encapsulation. Available at
http://sites.inka.de/sites/bigred/devel/cipe.html . Last Accessed 13-10-2002

62
10.0 Appendices

10.1 eVPN Prototype System Installation Procedure

*Section 10.1 is a shared work section combining the work by student Eric
Chan, Chun Ko and Jerome Lau*

OpenSSL

Download OpenSSL package openssl-0.9.6g.tar.gz (or latest version)
from http://www.openSSL.org

Installation Procedures
- - - - - - - - - - - -

First unzip the package using command:

tar -xvf openssl-0.9.6g.tar.gz

After unzipping, execute the following commands in the OpenSSL
directory:

$ ./config

$ make

$ make test

$ make install

____________________________________________________


63
IPgrab

IPgrab Installation and Usage
- - - - - - - - - - - - - - - - - - - - - - - - -

Download the IPgrab source from its website. Unzip the file: ipgrab-
0.9.8.tar.gz and then run:

$ ./configure

$ make

$ make install

These are the commands used to configure IPgrab to capture different
information for analysis in the system.

To display payload of the incoming and outgoing packets for the first
network card: This can be used for eavesdropping in the network.

$ ipgrab -atnlp -i eth0

To display transport layer header information: (This can examine the
size of the length of the packet, ports used, protocol etc.)

$ ipgrab -anl -i eth0

To display network layer header information: (This can examine the
source and destination IP addresses, protocols and various header
information such as length and checksum etc.)

$ ipgrab -atl -i eth0

to display data-link layer header information: (This can examine the
hardware source and destination addresses.)

$ ipgrab -atn -i eth0

______________________________________________________________________

64
OpenVPN

Requirement software packages for OpenVPN:
(1) tun and/or tap driver.
Necessary to allow user-space programs to control a virtual
point-to-point IP or Ethernet devices.
See http://vtun.sourceforge.net/tun/ for information and source
download.

Optional:
(1) OpenSSL library, version 0.9.5 or higher required.
Necessary for encryption which was needed for this prototype.
See Appendix A.
(2) LZO real-time compression library, required for link
compression, See http://www.oberhumer.com/opensource/lzo/ for
information and source download.
User can disable this by using --disable-lzo with the
configuration command. This option was excluded in the prototype
system.
(3) Pthread library.

Download OpenVPN package openvpn-1.3.1-1.rh72.i386.rpm or openvpn-
1.3.1-1.rh73.i386.rpm depending on the platform available. Source
files openvpn-1.3.1.tar.gz are also available.

- - - - - - - - - - - -

Install the package using:

$ rpm -ivh openvpn-1.3.1-1.rh72.i386.rpm

After installing the RPM, run configure with:

$ ./configure

Note. To disable LZO, use ./configure --disable-lzo

65

then run:

$ make

$ make install

Key Management With OpenSSL
- - - - - - - - - - - - - -

OpenVPN can support different key management methods. TLS assymetric
key was used in the prototype. New CA certificates can be generated
using:

$ openssl req -nodes -new -x509 -keyout ca.key -out ca.crt

The .key file is the private key and .crt file is the CA's certificate
that is signed by itself. Sample keys tmp-ca.key and tmp-ca.crt are
provided in the package but new keys should be generated for a secure
system. This step is done on the CA machine.

Then create a pem file (containing Diffie Hellman parameters). Using:

$ openssl dhparam -out dh1024.pem 1024

This step is required for --tls-server only.

Then generate keys for each VPN peer needed for the system:

$ openssl req -nodes -new -keyout mycert.key -out mycert.csr

Here the .csr file is a "Request to sign" public-key file to be send
to CA.

The CA can then sign requests by:

$ openssl ca -out mycert.crt -in mycert.csr

66
Now the two peers (e.g. Alice and Bob) can connect using:

Alice:
$ openvpn --remote alice_IP --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --
tls-client --ca ca.crt --cert alice.crt --key alice.key --reneg-sec 60
--verb 5

Bob:
$ openvpn --remote bob_IP --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --
tls-server --dh dh1024.pem --ca ca.crt --cert bob.crt --key bob.key --
reneg-sec 60 --verb 5

This configuration gives Alice a virtual address 10.4.0.2 and Bob
10.4.0.1. Refer to OpenVPN documentation for other options.

A web based interface is developed in this prototype for such
operations.

Routing Table Configuration
- - - - - - - - - - - - - -

Modification to the routing table and other setting are needed to
support other topologies such as network-to-network VPN.

To be able to allow internal traffic to transfer to the Internet over
the VPN channel, these settings are required. First enable IP
forwarding by:

$ echo 1 > /proc/sys/net/ipv4/ip_forward

Also it is possible to enable tun packet forwarding through the
firewall:

$ iptables -A FORWARD -i tun+ -j ACCEPT

Then to enable secure outgoing traffic from the local network, add
these entries to the routing table as follows: (10.0.0.0 and 10.0.1.0
are the local networks.)

67
Alice:
$ route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.4.0.2
Bob:
$ route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.4.0.1

After setting the OpenVPN channel, the route table should look
something like this:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.4.0.2 * 255.255.255.255 UH 0 0 0 tun1
10.0.0.0 * 255.255.255.0 U 0 0 0 eth1
10.0.1.0 10.4.0.2 255.255.255.0 UG 0 0 0 tun1
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 ipsec0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
______________________________________________________________________


68
FreeS/WAN IPSec

Kernel Compilation
- - - - - - - - - -
The Linux kernel needs to be compiled before the installation of
FreeS/WAN IPSec, the recommended kernel version is 2.2.19 or above for
2.2 kernels, or kernel 2.4.5/2.4.6.

Kernel Compilation Procedures
- - - - - - - - - - - - - - -

Obtain the kernel source code from http://www.kernel.org or one of its
mirrors. Version 2.4.6 is used for this example.

Once the file has been downloaded, unzip the package by executing the
following command:

For gzip:

$ tar zxvf linux-2.4.6.tar.gz

For bzip2

$ tar Ixvf linux-2.4.6.tar.bz2

Then execute the following commands:

$ cd /usr/src
$ mv linux linux-2.4.6
$ ln -s linux-2.4.6 linux

$ cd /usr/include
$ mv linux linux.old
$ mv asm asm.old
$ ln -s ../src/linux/include/linux linux
$ ln -s ../src/linux/include/asm asm


69
then finally, configure the kernel:

$ cd /usr/src/linux
$ make menuconfig
$ make dep
$ make bzImage

FreeS/WAN Compilation
- - - - - - - - - - -

If the kernel has been successfully compiled, grab the latest
FreeS/WAN package from http://www.freeswan.org. The version used in
the eVPN prototype system is 1.91

- - - - - - - - - - - -

First, untar the source in the /use/src directory

$ cd /usr/src
$ tar zxvf freeswan-1.91.tar.gz

that will create the directory /usr/src/freeswan-1.91.
Go inside the directory and type the following:

$ cd /usr/src/freeswan-1.91
$ make menugo

Once FreeS/WAN has been successfully compiled, install the modules:
$ cd /usr/src/linux
$ make modules_install

$ cd /usr/src/linux/arch/i386/boot
$ cp bzImage /boot/vmlinuz-2.4.6


70
Configuring FreeS/WAN
- - - - - - - - - - -

After all installation procedures have been completed successfully,
FreeS/WAN is now ready to be configured.

Key Generations
- - - - - - - -

For secure tunneling, generation of private key and public key are
required for the end machines.

In a secure working directory (Permission set to 700), type the
following:

$ ipsec rsaigkey --verbose 2048 > rsakey.tmp

A pair of keys will be generated and shown in the rsakey.tmp file.

The format of the file is:
: RSA {
<TAB> output of rsakeygen
<TAB>
<TAB> }

You can put an index in front the RSA key you have just generated.
For example, on the eVPN gateway machine, put

@eVPN1.org: RSA {
<TAB> output of rsakeygen
<TAB>
<TAB> }

Then, copy the content of rsakey.tmp to ipsec.secrets:

$ cp -f rsakey.tmp /etc/ipsec.secrets


71
Network Configuration
- - - - - - - - - - -

After the RSA keys have been generated, IPSec is ready to be
configured. There are 3 types of network configurations available:

- host-to-host
- host-to-network
- network-to-network

These configurations can be specified in the ipsec.conf file.

The ipsec.conf file used in the eVPN prototype system is shown on the
next page.


72
config setup
interfaces="ipsec0=eth0"
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes

conn %default
keyingtries=0
authby=rsasig

conn eVPNNetwork
left=192.168.0.2
leftsubnet=10.0.0.0/24
leftid=@eVPN1.org
leftnexthop=192.168.0.1
leftrsasigkey=0sAQN8EXZpwThNOtvEDOw0Aw8XQ5fAVob6/TnAjBHOEsgKt6Zy
BazeBVOXi4Wxb6pImRBgjyxVPxDlJ/FcDQ4L+Opw67yZNKiWr3twGbhinTMLhJ0j04G3EY
RkIje15Wv3tE5+Xkx5vF2Re5asIBQboBUK2i6JH7ZCCmifwcKH9mjYdfhVqdB0TO+Fcevy
I6Bwehh4RjBA1V5Y4vtvXVjiu9seftmZGlGm+TgPYcy0sJjt616XWbBfpLuipX34G0uiEr
DrAXmL/PiDWuWWj+G17xS3VhW0MkSWQNksxJE773QQoCd1KTK/AdOpuucvXF45ejsutlqH
w0++9StqfwcMQ4p3
right=192.168.1.2
rightsubnet=10.0.1.0/24
rightid=@eVPN2.org
rightnexthop=192.168.1.1
rightrsasigkey=0sAQPWHP9sgUN1vygBuVGPvNEcLBu66ByvmvwAKDYT3mpI/bG
StC9E0BIwKr+yuafz+qPfmnAtDKb4BIPTheZ4qtFPlQaDYmxMA8ErsaxFMtX11arjB9o8v
rPz2DpJ6DOWyU2QG7gTuMajfNN/q6yh9FGjoOjWZz7/ZC6KiM2wyVFNmqZJxp7gJB+KD15
MOG2nHeq96ZJUEXBpsrjAho3wR2LALhMVoMOs9BWsetSoo/ap6OFFFP5fSrhCizGMn+uPG
wKEhYj2FzMRfKk1LJ8x/om0AC4qW7TnAQvKDWdv++gggw6SAUSssZCBTZ+w3OBphSHKB/R
K/JqtzJUjsUR5EGiH
auto=add

conn eVPNhost
left=192.168.0.2
#leftsubnet=10.0.0.0/24
leftid=@eVPN1.org
leftnexthop=192.168.0.1
leftrsasigkey=0sAQN8EXZpwThNOtvEDOw0Aw8XQ5fAVob6/TnAjBHOEsgKt6Zy
BazeBVOXi4Wxb6pImRBgjyxVPxDlJ/FcDQ4L+Opw67yZNKiWr3twGbhinTMLhJ0j04G3EY
RkIje15Wv3tE5+Xkx5vF2Re5asIBQboBUK2i6JH7ZCCmifwcKH9mjYdfhVqdB0TO+Fcevy
I6Bwehh4RjBA1V5Y4vtvXVjiu9seftmZGlGm+TgPYcy0sJjt616XWbBfpLuipX34G0uiEr
DrAXmL/PiDWuWWj+G17xS3VhW0MkSWQNksxJE773QQoCd1KTK/AdOpuucvXF45ejsutlqH
w0++9StqfwcMQ4p3
right=192.168.1.2
#rightsubnet=10.0.1.0/24
rightid=@eVPN2.org
rightnexthop=192.168.1.1
rightrsasigkey=0sAQPWHP9sgUN1vygBuVGPvNEcLBu66ByvmvwAKDYT3mpI/bG
StC9E0BIwKr+yuafz+qPfmnAtDKb4BIPTheZ4qtFPlQaDYmxMA8ErsaxFMtX11arjB9o8v
rPz2DpJ6DOWyU2QG7gTuMajfNN/q6yh9FGjoOjWZz7/ZC6KiM2wyVFNmqZJxp7gJB+KD15
MOG2nHeq96ZJUEXBpsrjAho3wR2LALhMVoMOs9BWsetSoo/ap6OFFFP5fSrhCizGMn+uPG
wKEhYj2FzMRfKk1LJ8x/om0AC4qW7TnAQvKDWdv++gggw6SAUSssZCBTZ+w3OBphSHKB/R
K/JqtzJUjsUR5EGiH
auto=add


73
IP forwarding and RP filtering
- - - - - - - - - - - - - - - -

IP forwarding must be enabled in all gateway machines. This can done
by executing command:

$ echo 1 > /proc/sys/net/ipv4/ip_forward

Also, RP filtering must be disabled in all machines:

$ echo 0 > /proc/sys/net/ipv4/rp_filter

Execution
- - - - -

Start an IPSec VPN tunnel with command:

$ ipsec auto --up <connection-name>

Starting, Stopping and Restarting IPSec
- - - - - - - - - - - - - - - - - - - -

Under directory /etc/rc.d/init.d/:

Start IPSec - $ ipsec start
Stop IPSec - $ ipsec stop
Restart IPSec - $ ipsec restart

After running IPSec, the resulting route table should be generated
automatically:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.1.0 * 255.255.255.0 U 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 ipsec0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0


74
Please reIer to |1| Ior more detail instructions.

MPEG4IP

Download the MPEG4IP Video Streaming Package from following address
http://mpeg4IP.sourceforge.net

After downloading the package, type following command to install the
MPEG4IP Package:

$ tar -zxvf mpeg4ip-0.9.5.1.tar.gz

then go to the newly generated directory
$ cd mpeg4ip-0.9.5.1
$ ./bootstrap
$ make all
$ make install

To start the streaming module:

$ cd /var/www/html

$ mp4live

To start the receiving module:

$ gmp4player http://<ip>/capture.sdp


75
Apache & PHP

- - - - - - - - - - - -
Locate the .rpm installation files from Red Hat Linux 7.2 CD. The
files are:

apache - apache-1.3.20-16.i386.rpm
php - php-4.0.6-7.i386.rpm

Run the installations using the following commands:

$ rpm -ivh apache-1.3.20-16.i386.rpm
$ rpm -ivh php-4.0.6-7.i386.rpm

After installing, go to directory `/etc' and edit the content of the
php.ini file. Change `file_uploads = off' to `files_uploads = on'

Testing Installation Procedures
- - - - - - - - - - - - - - - -

1. goto /var/www/html
2. remove file index.html
3. create a new index.php with following content
<?php phpinfo(); ?>
4. Then load the html page with any web browser

A setup screen shown below should be displayed indicating that apache
and php have been successfully installed.


76
10.2 Performance Test Execution Procedure

Insecure Channel & IPSec on the gateway machine with IP address 192.168.0.2.
execute the shell script written Ior the test by entering ./pingTest1` to the command line

Contents of file ping1est1
ping-c30-s8192.168.1.2>output
ping-c30-s64192.168.1.2>>output
ping-c30-s128192.168.1.2>>output
ping-c30-s256192.168.1.2>>output
ping-c30-s512192.168.1.2>>output
ping-c30-s1024192.168.1.2>>output
ping-c30-s2048192.168.1.2>>output
ping-c30-s4096192.168.1.2>>output
ping-c30-s8192192.168.1.2>>output
ping-c30-s16384192.168.1.2>>output
ping-c30-s32768192.168.1.2>>output
ping-c30-s65507192.168.1.2>>output

OpenJPA on the gateway machine with IP address 10.4.0.1. execute the shell script
written Ior the test by entering ./pingTest2` to the command line

Contents of file ping1est2
ping-c30-s810.4.0.2>output
ping-c30-s6410.4.0.2>>output
ping-c30-s1638410.4.0.2>>output
ping-c30-s3276810.4.0.2>>output
ping-c30-s6550710.4.0.2>>output

77
10.3 Results of Performance Test
Insecure Channel
PING 192.168.1.2 (192.168.1.2) from 192.168.0.2 : 8(36) bytes of data.
16 bytes from 192.168.1.2: icmp_seq=0 ttl=254 time=334 usec

--- 192.168.1.2 ping statistics ---
30 packets transmitted, 30 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.195/0.242/0.334/0.023 ms

78




79



80
2056 bytes from 192.168.1.2: icmp_seq=0 ttl=254 time=1.107 msec



81



82




83
$




84



85



86



87



88




89
7



90



91



92



93

16392 bytes from 10.4.0.2: icmp_seq=0 ttl=255 time=1.993 sec
16392 bytes from 10.4.0.2: icmp_seq=1 ttl=255 time=1.999 sec




Thesis

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Thesis

Hochgeladen von

Copyright:

Verfügbare Formate

Embedded

Virtual Private Network

5.0 Analysis and Recommendations------------------------------------- 45

Embedded Virtual Private Network: PerIormance and Scalability

Brute-Iorce attacks involve harnessing a computer or computers to cycle through

Embedded Virtual Private Network: PerIormance and Scalability

What technologies make up an eVPN? What protocols should be considered

UDP User Datagram Protocol is a transport layer protocol deIined by the US

Embedded Virtual Private Network: PerIormance and Scalability

Layer 2 Tunneling Protocol. or simply reIer as L2TP. is an extension oI the

Key Management is another signiIicant topic associated with the PerIormance

As described in Section 4. two tunneling protocols are installed in the prototype

Recommendations to the scalability oI eVPN system are presented in this

The key obiective oI an undergraduate thesis is to give the student a challenge

Overall. this thesis is considered to be a success by the author. Given the

Embedded Virtual Private Network: PerIormance and Scalability

Das könnte Ihnen auch gefallen