1. Overview

If a secret piece of news is divulged by a spy before the time is ripe, he must be put to death, together with the man to whom the secret was told.
- The Art of War, Sun Tzu

Information security is important thing in internet nowadays, when you deliver information over internet. It has a lot of possibility tapped, changed, or others harmful things. There are a lot of way to secure your information that delivered, using secure application that encrypted from client apps to server apps. Or securing your traffic in IP network level that we called IP Security or IPSec.


1.1 IPSec Overview

1.1.1 System Overview

Secure Network was defined in RFC 1636 - Security in the Internet Architecture, this accomplished to prevent unauthorized monitoring and control of traffic and also to secure end-user-to-end-user traffic using authentication and encryption mechanism. IP-level Security encompasses three functional area: authentication, encryption due confidentially, and key management. The authentication has responsibility to ensure the "sender" and “receiver” has a right to transmitted and received packet. Encryption make sure the packet keep secure and prevent to eavesdropping by third party. And the last is key management that concerned for secure key exchange.
Figure 1 - Top Level IPSec Processing Model
IPSec create boundary between protected and unprotected network. Traffic traversing the boundary is a subject to access controls that specified by user or administrator responsible for IPSec configuration. From the control, the traffic maybe cross the boundary with afforded security services via AH or ESP, or are discarded.

1.1.2 IPSec Policy

Fundamental of IPSec service is the concept of security policy that determined by two database. Those are, Security Policy Database (SPD), and Security Association Database (SAD). This policy applied to each IP packet that transit from a source to a destination.

  1. Security Association
    Security Association is a key concept to both node exchange information about authentication and encryption mechanism. An association is a one-way logical connection between a sender and a receiver that affords security services to the traffic carried on it
    Figure 2- IPSec Architecture
    There are three parameter that identify the security association:
    1. Security Parameters Index (SPI), bit string carry IPSec protocol header information to enable receiving system to select packet that will be received
    2. IP Destination Address, the endpoint address of IPSec
    3. Security Protocol Identifier, this field from the outer IP header indicates whether the association is an AH or ESP security association
  2. Security Association Database
    In each IPsec implementation, there is a nominal Security Association Database that defines the parameters associated with each SA. This database stored a parameter to build IKE SA and IPSec SA. Below the parameter in an SAD entry:
    1. Security Parameter Index: A 32-bit value selected by the receiving end of an SA to uniquely identify the SA
    2. Sequence Number Counter: A 32-bit value used to generate the Sequence Number field in IPSec Protocol headers.
    3. Sequence Counter Overflow: A flag indicating whether overflow of the Sequence Number Counter should generate an auditable event and prevent further transmission of packets on this SA
    4. Anti-Replay Window: Used to determine whether an inbound AH or ESP packet is a replay
    5. AH Information: Authentication algorithm, keys, key lifetimes, and related parameters being used with AH
    6. ESP Information: Encryption and authentication algorithm, keys, initialization values, key lifetimes, and related parameters being used with ESP (required for ESP implementations).
    7. Lifetime of this Security Association: A time interval or byte count after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur
    8. IPsec Protocol Mode: Tunnel, transport, or wildcard
    9. Path MTU: Any observed path maximum transmission unit (maximum size of a packet that can be transmitted without fragmentation) and aging variables
  3. Security Policy Database
    Security policy stores the IP traffic that related to specific SA, it means SPD contains the entries, each entry defines a subset of IP traffic and points to an SA for that traffic. Each SPD entry is defined by IP and upper-layer protocol field values, called selector. These selector is used to filter outgoing traffic in order to map it in to a particular SA. The following selectors determine an SPD entry:
    1. Remote IP Address: This may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address for remote private network
    2. Local IP Address: This may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address for local private network
    3. Next Layer Protocol: The IP protocol header (IPv4, IPv6, or IPv6 Extension) includes a field (Protocol for IPv4, Next Header for IPv6 or IPv6 Extension) that designates the protocol operating over IP
    4. Name: A user identifier from the operating system. This is not a field in the IP or upper-layer headers but is available if IPsec is running on the same operating system as the user.
    5. Local and Remote Ports: These may be individual TCP or UDP port values, an enumerated list of ports, or a wildcard port.

1.1.3 IPSec Protocol

IPSec using protocol Authentication Header (AH), and Encapsulation Security Payload (ESP), to provide traffic security services. Both protocols are described in detail in their respective RFCs [4303, 4302]. The IP Authentication Header (AH) offers integrity and data origin authentication, with optional (at the discretion of the receiver) anti-replay features. The Encapsulating Security Payload (ESP) protocol offers the same set of services, and also offers confidentiality. ESP can work with a variety of encryption and authentication algorithms, including authenticated encryption algorithms such as GCM. Both AH and ESP offer access control, enforced through the distribution of cryptographic keys and the management of traffic flows as dictated by the Security Policy Database.
Commonly, ESP using in Virtual Private Network or underlay network context, and we will focus with this protocol than Authentication Header. Because in service provider network, we often meet this kind of protocol.
Figure 3 - Top-Level Format of an ESP Packet

ESP Protocol header contains the following fields:

  • Security Parameters Index (32 bits): Identifies a security association.
  • Sequence Number (32 bits): A monotonically increasing counter value; this provides an anti-replay function, as discussed for AH.
  • Payload Data (variable): This is a transport-level segment (transport mode) or IP packet (tunnel mode) that is protected by encryption.
  • Padding (0–255 bytes): The purpose of this field is discussed later.
  • Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.
  • Next Header (8 bits): Identifies the type of data contained in the payload data field by identifying the first header in that payload (for example, an extension header in IPv6, or an upper-layer protocol such as TCP).
  • Integrity Check Value (variable): A variable-length field (must be an integral number of 32-bit words) that contains the Integrity Check Value computed over the ESP packet minus the Authentication Data field.

1.1.4 Transport Mode VS Tunnel Mode

Security Association (SA) can be configured two mode IPSec operation, they are Tunnel mode or Transport mode. Transport mode provides protection primarily for upper-layer protocols. That is, transport mode protection extends to the payload of an IP packet. Typically, transport mode is used for end-to-end communication between two hosts (e.g., a client and a server, or two workstations). When a host runs AH or ESP over IPv4, the payload is the data that normally follow the IP header. ESP in transport mode encrypts and optionally authenticates the IP payload but not the IP header. AH in transport mode authenticates the IP payload and selected portions of the IP header
Figure 4 - ESP Transport mode Data-gram
Tunnel mode provides protection to the entire IP packet. To achieve this, after the AH or ESP fields are added to the IP packet, the entire packet plus security fields is treated as the payload of new outer IP packet with a new outer IP header. With tunnel mode, a number of hosts on networks behind firewalls may engage in secure communications without implementing IPsec. The unprotected packets generated by such hosts are tunneled through external networks by tunnel mode SAs set up by the IPsec software in the firewall or secure router at the boundary of the local network
Figure 5 - ESP Tunnel mode Data-gram
Figure 6 - Tunnel Mode and Transport Mode Functionality
From this information, we can mapping the pros and cons from each mode, like below:
  • Transport mode
    • Pros
      • Provides End to End security
      • Lower overhead than tunnel mode
      • Larger MTU
      • Negotiation of connection-specific selectors is common practice
    • Cons
      • Requires IPsec to be implemented on the IPS entities
      • Greater difficulties with NAT traversal (TCP checksum invalidation)
  • Tunnel mode
    • Pros
      • More compatible with existing VPN gateways
      • Don’t have to implement IPsec on the IPS entity
      • Easier to traverse NATs
    • Cons 
      • More overhead
      • Smaller MTU
      • Secure operation within IPS scenarios would require negotiation of connection-specific selectors – not current practice
      • For hosts with dynamically assigned addresses (iSCSI), interoperability is poor
      • Existing implementations typically utilize proprietary extensions for configuration (mode config) or authentication (XAUTH)
      • To avoid normative references to proprietary protocols, iSCSI and IPS security drafts would need to cite draft-ietf-ipsec-dhcp-13.txt for config and possibly draft-ietf-ipsra-pic-04.txt – which adds significantly complexity

1.1.5 IP Traffic Processing

IPSec is executed on a packet on packet-by-packet basis. When IPSec implemented, each outbound packet is processed by IPSec logic before transmission. The Packet that sent must be consulted with the Security Policy Database (SPD) (or associated caches). If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded, vice versa.
Figure 7 - Processing Model for Outbound Packets
Figure 8 - Processing Model for Inbound Packets

1.1.6 IPSec Implementation and Application Scenario


There are many ways to implement IPSec in host, or conjunction with firewall or router to create security gateway. IPSec may integrated into the native IP stack with access the IP source code. IPSec may in a “bump-in-the-stack” (BITS) implementation, IPsec is implemented "underneath" an existing implementation of an IP protocol stack, between the native IP and the local network drivers. Or "bump-in-the-wire" (BITW) implementation. Where IPSec put in inline security protocol processor.
Some Application of IPSec are:
  1. Secure branch office connectivity over the Internet
  2. Secure remote access over the Internet
  3. Establishing extranet and intranet connectivity with partners
  4. Enhancing electronic commerce security
Figure 9 - An IPSec Scenario

1.2 Strongswan Overview

1.2.1 The Open Source IPsec-based VPN Solution

StrongSwan is an Open Source IPsec implementation. It was originally based on the discontinued FreeS/WAN project and the X.509 patch that we developed. In order to have a stable IPsec platform to base the extensions of the X.509 capability on, we decided to launch the strongSwan project in 2005.
Since then a new IKE daemon has been written in a modern object-oriented coding style so that the current code base does not share code with its ancestor anymore. Initially that daemon only supported IKEv2, while IKEv1 was handled by an extended version of FreeS/WAN's Pluto daemon. But because adoption of IKEv2 by other vendors took longer than anticipated support for IKEv1 was added to the new daemon with strongSwan 5.0.0.
StrongSwan originally was designed for Linux, but has since been ported to Android, FreeBSD, Mac OS X, Windows and other platforms. The focus of strongSwan is on:

  1. Simplicity of configuration
  2. Strong encryption and authentication methods
  3. Powerful IPsec policies supporting large and complex VPN networks
  4. Modular design with great expandability

The maintainer of the strongSwan project is Andreas Steffen, who is a professor for security in communications and head of the Institute for Internet Technologies and Applications at the University of Applied Sciences Rapperswil in Switzerland and president of the consulting firm strongSec GmbH.

1.2.2 System Consideration Related deploy in centOS

For lab test, I using CentOS Operating System. There are limitation in system, The CentOS/RHEL repo's only ship Libreswan. Strongswan shipped in EPEL project from fedora. Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).
Figure 10 - Epel from Fedora Project

2. Test LAB

2.1 Topology, Interface and Parameter Information

Below the topology that tested in LAB. There are 6 routers. 3 routers as L1 and L2 router and 3 router as L1 router.
Figure 11 - Strongswan Site-to-Site Topology
Below the parameter information:
Figure 12 - Strongswan Parameter

2.2 Pre-deploy Strongswan IPSec using centos 7

Before we use this, let me share how to install it. As information described point 1.2.2, Strongswan need epel repo to run in RHEL/CentOS.

  1. Install epel repository, in this lab, I grab it from kambing.ui.ac.id
    $ yum install http://kambing.ui.ac.id/epel/7/x86_64/e/epel-release-7-6.noarch.rpm
  2. Install strongswan
    $ yum install strongswan
  3. Check the configuration file, strongswan.conf, you free to modify this file depend on your own and concern
    [root@strongswan-achyarnurandidotnet-s1 ~]# cat /etc/strongswan/strongswan.conf
# strongswan.conf - strongSwan configuration file
#
# Refer to the strongswan.conf(5) manpage for details
#
# Configuration changes should be made in the included files

charon {
        load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }
}

include strongswan.d/*.conf
[root@strongswan-achyarnurandidotnet-s1 ~]#

  4. You modify feature or create your code under include strongswan.d/

2.3 IPSec Site-to-Site Configuration


  1. Strongswan-s1
    1. Ipsec.conf
      [root@strongswan-achyarnurandidotnet-s1 ~]# cat /etc/strongswan/ipsec.conf
config setup

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1
        authby=secret

conn server1-server2
        left=10.0.2.1
        leftsubnet=192.168.223.0/24
        leftid=@s1.achyarnurandi.net
        ike=aes128-md5-modp1024
        esp=aes128-sha1-modp1024!
        leftfirewall=yes
        right=10.0.2.2
        rightsubnet=192.168.222.0/24
        rightid=@s2.achyarnurandi.net
        auto=start

[root@strongswan-achyarnurandidotnet-s1 ~]#
    2. In strongswan, Pre-Shared Key is created in ipsec.secrets file.
      [root@strongswan-achyarnurandidotnet-s1 ~]# cat /etc/strongswan/ipsec.secrets
# ipsec.secrets - strongSwan IPsec secrets file

@s1.achyarnurandi.net @s2.achyarnurandi.net : PSK 3k1Eb0el4d


[root@strongswan-achyarnurandidotnet-s1 ~]#
  2. Strongswan-s2
    1. Ipsec.conf
      [root@strongswan-achyarnurandidotnet-s2 ~]# cat /etc/strongswan/ipsec.conf
config setup

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1
        authby=secret

conn server2-server1
        left=10.0.2.2
        leftsubnet=192.168.222.0/24
        leftid=@s2.achyarnurandi.net
        ike=aes128-md5-modp1024
        esp=aes128-sha1-modp1024!
        leftfirewall=yes
        right=10.0.2.1
        rightsubnet=192.168.223.0/24
        rightid=@s1.achyarnurandi.net
        auto=start
[root@strongswan-achyarnurandidotnet-s2 ~]
    2. Creat ipsec.secrets file and add your secreet in it.
      [root@strongswan-achyarnurandidotnet-s2 ~]# cat /etc/strongswan/ipsec.secrets
# ipsec.secrets - strongSwan IPsec secrets file

@s1.achyarnurandi.net @s2.achyarnurandi.net : PSK 3k1Eb0el4d

[root@strongswan-achyarnurandidotnet-s2 ~]#

  3. Enabling IP forwarding in CentOS, we need it because strongswan put the ip traffic processing in different ip rule show in operating system. 
    1. Check your operating system ip forwarding
      $ sysctl net.ipv4.ip_forward
    2. If the value = 1, is done for you. But the value = 0, you should change the value in /etc/sysctl.conf, add the parameter net.ipv4.ip_forward=1
      $ net.ipv4.ip_forward=1
    3. Restart your network, then verify again
      $ sysctl restart network

2.4 Validation

After configuration, do restart in each server with command #strongswan restart, then do verify in each server like below:
    1. Make sure endpoint is reachable with do look at  ip route-table and ping test
      [root@strongswan-achyarnurandidotnet-s1 ~]# ip route
10.0.2.0/30 dev enp0s8  proto kernel  scope link  src 10.0.2.1  metric 100
192.168.223.0/24 dev enp0s3  proto kernel  scope link  src 192.168.223.101  metric 100
[root@strongswan-achyarnurandidotnet-s1 ~]# ping 10.0.2.2 -c 5
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=64 time=0.910 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=64 time=0.575 ms
64 bytes from 10.0.2.2: icmp_seq=3 ttl=64 time=0.584 ms
64 bytes from 10.0.2.2: icmp_seq=4 ttl=64 time=0.429 ms
64 bytes from 10.0.2.2: icmp_seq=5 ttl=64 time=0.635 ms

--- 10.0.2.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 0.429/0.626/0.910/0.159 ms
[root@strongswan-achyarnurandidotnet-s1 ~]#
    2. Check strongswan status, make sure the auth and enc algorithm that ike and esp using is correct with parameter is defined (look at table parameter in point 2.1)
      [root@strongswan-achyarnurandidotnet-s1 ~]# strongswan statusall
Status of IKE charon daemon (strongSwan 5.3.2, Linux 3.10.0-327.18.2.el7.x86_64, x86_64):
  uptime: 16 minutes, since Jun 04 22:25:38 2016
  malloc: sbrk 1593344, mmap 0, used 468576, free 1124768
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon aes des rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac ctr ccm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp
Listening IP addresses:
  192.168.223.101
  10.0.2.1
Connections:
server1-server2:  10.0.2.1...10.0.2.2  IKEv1
server1-server2:   local:  [s1.achyarnurandi.net] uses pre-shared key authentication
server1-server2:   remote: [s2.achyarnurandi.net] uses pre-shared key authentication
server1-server2:   child:  192.168.223.0/24 === 192.168.222.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
server1-server2[1]: ESTABLISHED 16 minutes ago, 10.0.2.1[s1.achyarnurandi.net]...10.0.2.2[s2.achyarnurandi.net]
server1-server2[1]: IKEv1 SPIs: 6e2171a515d98589_i* 42aba19a2981ae27_r, pre-shared key reauthentication in 37 minutes
server1-server2[1]: IKE proposal: AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
server1-server2{1}:  REKEYED, TUNNEL, reqid 1, expires in 3 minutes
server1-server2{1}:   192.168.223.0/24 === 192.168.222.0/24
server1-server2{4}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c7e583a1_i cded3be7_o
server1-server2{4}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 16 minutes
server1-server2{4}:   192.168.223.0/24 === 192.168.222.0/24
server1-server2{3}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c32ac819_i c0d3e391_o
server1-server2{3}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 14 minutes
server1-server2{3}:   192.168.223.0/24 === 192.168.222.0/24
[root@strongswan-achyarnurandidotnet-s1 ~]#
    3. Strongswan reserved kernel routing in 220 routing database, each strongswan ipsec established, route mapping will install in this Routing Database. After establish information. Check the route was installed and do ping test.
      [root@strongswan-achyarnurandidotnet-s1 ~]# ip route list table 220
192.168.222.0/24 via 10.0.2.2 dev enp0s8  proto static  src 192.168.223.101
[root@strongswan-achyarnurandidotnet-s1 ~]# ping 192.168.222.101 -c 5
PING 192.168.222.101 (192.168.222.101) 56(84) bytes of data.
64 bytes from 192.168.222.101: icmp_seq=1 ttl=64 time=0.804 ms
64 bytes from 192.168.222.101: icmp_seq=2 ttl=64 time=0.801 ms
64 bytes from 192.168.222.101: icmp_seq=3 ttl=64 time=0.822 ms
64 bytes from 192.168.222.101: icmp_seq=4 ttl=64 time=0.849 ms
64 bytes from 192.168.222.101: icmp_seq=5 ttl=64 time=0.693 ms

--- 192.168.222.101 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 0.693/0.793/0.849/0.064 ms
[root@strongswan-achyarnurandidotnet-s1 ~]#
    4. Verify the ipsec datagram using xrfm, xfrm is an IP framework which can transform the format datagram. Make sure the enc and auth suitable. And make sure the private network Subnet installed in this policy
      [root@strongswan-achyarnurandidotnet-s1 ~]# ip -s xfrm state
src 10.0.2.1 dst 10.0.2.2
        proto esp spi 0xc4d97574(3302585716) reqid 1(0x00000001) mode tunnel
        replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
        auth-trunc hmac(sha1) 0x53b9e69ac7322ff9babd8ec2d26ee27acea23c51 (160 bits) 96
        enc cbc(aes) 0xcac265f99341cc66d5313984ad77e6a3 (128 bits)
        lifetime config:
          limit: soft (INF)(bytes), hard (INF)(bytes)
          limit: soft (INF)(packets), hard (INF)(packets)
          expire add: soft 839(sec), hard 1200(sec)
          expire use: soft 0(sec), hard 0(sec)
        lifetime current:
          1344(bytes), 16(packets)
          add 2016-05-30 12:03:36 use 2016-05-30 12:04:43
        stats:
          replay-window 0 replay 0 failed 0
src 10.0.2.2 dst 10.0.2.1
        proto esp spi 0xccbee1c2(3435061698) reqid 1(0x00000001) mode tunnel
        replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
        auth-trunc hmac(sha1) 0xc8f0318dd8dca4e0a00d3b83b3f30cb1dfd2a15f (160 bits) 96
        enc cbc(aes) 0x37f0f5ea3a534c7b473c58bf3f30b731 (128 bits)
        lifetime config:
          limit: soft (INF)(bytes), hard (INF)(bytes)
          limit: soft (INF)(packets), hard (INF)(packets)
          expire add: soft 984(sec), hard 1200(sec)
          expire use: soft 0(sec), hard 0(sec)
        lifetime current:
          1344(bytes), 16(packets)
          add 2016-05-30 12:03:36 use 2016-05-30 12:04:43
        stats:
          replay-window 0 replay 0 failed 0
src 10.0.2.1 dst 10.0.2.2
        proto esp spi 0xc7fcdba6(3355237286) reqid 1(0x00000001) mode tunnel
        replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
        auth-trunc hmac(sha1) 0xa5d7c83318aa3fb840e3799c91e212a37e6ff40c (160 bits) 96
        enc cbc(aes) 0x5a16b956d6604c2ea8a9d8fd7ab07bae (128 bits)
        lifetime config:
          limit: soft (INF)(bytes), hard (INF)(bytes)
          limit: soft (INF)(packets), hard (INF)(packets)
          expire add: soft 881(sec), hard 1200(sec)
          expire use: soft 0(sec), hard 0(sec)
        lifetime current:
          0(bytes), 0(packets)
          add 2016-05-30 12:03:29 use -
        stats:
          replay-window 0 replay 0 failed 0
src 10.0.2.2 dst 10.0.2.1
        proto esp spi 0xc8f11738(3371243320) reqid 1(0x00000001) mode tunnel
        replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
        auth-trunc hmac(sha1) 0x349bacecb19c8fb80b4ce51a32c416afc4b1fb74 (160 bits) 96
        enc cbc(aes) 0xb97240c8de4a23fc274a3d5a66d4dd8b (128 bits)
        lifetime config:
          limit: soft (INF)(bytes), hard (INF)(bytes)
          limit: soft (INF)(packets), hard (INF)(packets)
          expire add: soft 988(sec), hard 1200(sec)
          expire use: soft 0(sec), hard 0(sec)
        lifetime current:
          0(bytes), 0(packets)
          add 2016-05-30 12:03:29 use -
        stats:
          replay-window 0 replay 0 failed 0
[root@strongswan-achyarnurandidotnet-s1 ~]#
Below documentation video about this lab:

3. Reference

  1. Fedoraproject. EPEL. https://fedoraproject.org/wiki/EPEL  (Accessed: 21 February 2016)
  2. IETF. 2001. Draft-ietf-ips-security-06.txt. https://www.ietf.org/proceedings/52/slides/ips-1/sld005.htm  (Accessed: 2 June 2016)
  3. Linux foundation. iproute2. http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2  (Accessed: 21 March 2016)
  4. R. Braden, C. Huitema, D. Clark, S. Crocker. 1994. Report of IAB Workshop on Security in the Internet Architecture. IETF
  5. S. Kent, K. Seo. 2005. RFC 4301 - Security Architecture for the Internet Protocol. IETF
  6. SS64. ip xfrm. http://ss64.com/bash/ip-xfrm.html  (Accessed: 20 May 2016)
  7. Stallings, William. 2011. Network Security Essentials: Applications and Standards. 4th ed. New Jersey: Pearson Education, Inc
  8. Strongswan. About Strongswan. https://www.strongswan.org/about.html (Accessed: 2 January 2016)
  9. Strongswan. Strongswan IKEv1 Cipher Suites. https://wiki.strongswan.org/projects/strongswan/wiki/IKEv1CipherSuites . (Accessed: 2 January 2016)