1. strongSwan Workshop for Siemens
Block 1 Overview / IPsec Basics
Prof. Dr. Andreas Steffen

2. Where the heck is Rapperswil?

3. HSR - Hochschule für Technik Rapperswil
University of Applied Sciences with about 1500 students
Faculty of Information Technology ( students)
Bachelor Course (3 years), Master Course (+1.5 years)

4. strongSwan Workshop for Siemens
What is strongSwan?

5. The strongSwan Open Source VPN Project
1999
FreeS/WAN 1.x
X x Patch
FreeS/WAN 2.x
S/WAN = Secure WAN
X x Patch
2000
Super FreeS/WAN
2003
 2004
Openswan 1.x
2004
Openswan 2.x
strongSwan 2.x
2005
New architecture, same config.
IKEv2 RFC 4306
ITA IKEv2 Project …
IKEv1 & partial IKEv2
strongSwan 4.x
2012
strongSwan 5.x
IKEv1 & IKEv2
Monolithic IKE Daemon

6. strongSwan – the OpenSource VPN Solution
Windows Active Directory Server
Linux FreeRadius Server
Corporate Network
High-Availability strongSwan VPN Gateway
Windows 7/8 Agile VPN Client
strongSwan Linux Client
Internet

7. Supported Operating Systems and Platforms
Linux 2.6.x, 3.x, 4.x (optional integration into NetworkManager)
Android 4.x/5.x App (using libipsec userland ESP encryption)
OS X App (using libipsec userland ESP encryption)
OS X (IPsec via PFKEYv2 kernel interface)
FreeBSD (IPsec via PFKEYv2 kernel interface)
Windows 7/ (native Windows IPsec stack, MinGW-W64 build)
Supported Hardware Platforms (GNU autotools)
Intel i686/x86_64, AMD64
ARM, MIPS
PowerPC
Supported Network Stacks
IPv4, IPv6
IPv6-in-IPv4 ESP tunnels
IPv4-in-IPv6 ESP tunnels

8. Free Download from Google Play Store
March 24, 2015: 12’619 installations

9. OS X App

10. IKEv2 Interoperability Workshops
Spring 2007 in Orlando, Florida
Spring 2008 in San Antonio, Texas
strongSwan successfully interoperated with IKEv2 products from Alcatel-Lucent, Certicom, CheckPoint, Cisco, Furukawa, IBM, Ixia, Juniper, Microsoft, Nokia, SafeNet, Secure Computing, SonicWall, and the IPv6 TAHI Project.

11. strongSwan 4.x pluto & charon Daemons
raw socket
IKEv1
IKEv2
ipsec starter
ipsec whack
ipsec stroke
charon
pluto
LSF
UDP/500 socket
native IPsec
Netlink XFRM
socket
Linux 2.6
kernel
ipsec.conf
stroke socket
whack socket
2005

12. strongSwan 5.x charon Daemon
ipsec.conf
IKEv1/v2
ipsec starter
ipsec stroke
2012
stroke socket
charon
libipsec
UDP 4500 socket
Any OS
TUN device
ESPinUDP
Netlink XFRM
socket
Linux 2.6 / 3.x
kernel
native IPsec
UDP 500/4500 socket

13. strongSwan 5.2 charon Daemon
swanctl.conf
IKEv1/v2
swanctl
ruby gem
vici socket
2014
vici socket
charon
libipsec
UDP 4500 socket
Any OS
TUN device
ESPinUDP
Netlink XFRM
socket
Linux 2.6 / 3.x
kernel
native IPsec
UDP 500/4500 socket

14. strongSwan 5.2 charon-systemd Daemon
swanctl.conf
IKEv1/v2
swanctl
systemd utilities
2014
vici socket
charon-systemd
libipsec
UDP 4500 socket
Any OS
TUN device
ESPinUDP
Netlink XFRM
socket
Linux 2.6 / 3.x
kernel
native IPsec
UDP 500/4500 socket

15. strongSwan 5.3 charon Daemon
swanctl.conf
IKEv1/v2
swanctl
python 2.7/3.x egg
2015
vici socket
vici socket
charon
libipsec
UDP 4500 socket
Any OS
TUN device
ESPinUDP
Netlink XFRM
socket
Linux 2.6 / 3.x
kernel
native IPsec
UDP 500/4500 socket

16. IKE Daemon – Software Architecture
socket
charon
bus
backends
credentials
receiver
sender
kernel interface
scheduler
processor
file logger
sys logger
IKE SA
M a n a g e r
IKE SA
CHILD SA
IPsec stack
16 concurrent worker threads

17. Plugins for charon charon
stroke/vici socket-based control & configuration interface
controller
stroke P l u g i n L o a d e r
vici
credentials
nm DBUS-based plugin for NetworkManager nm
backends
sql
bus
sql Generic SQL interface for configurations, credentials & logging. …
eap_md5
eap
eap_tls
eap_radius
eap_x Any EAP protocol. …

18. Modular Architecture: libcharon plugins I
addrblock
eap-gtc
eap-ttls
medcli
android_dns
eap-identity
error-notify
medsrv
android_log
eap-md5
ext-auth
osx-attr
attr
eap-mschapv2
farp
radattr
attr-sql
eap-peap
forecast
resolve
certexpire
eap-radius ha
smp
connmark
eap-sim
ipseckey
socket-default
coupling
eap-sim-file
kernel-iph
socket-dynamic
dhcp
eap-sim-pcsc
kernel-libipsec
socket-win
dnscert
eap-simaka-pseudonym
kernel-wfp
sql
duplicheck
eap-simaka-reauth
led
stroke
eap-aka
eap-simaka-sql
load-tester
systime-fix
eap-aka-3gpp2
eap-tls
lookip
tnc-ifmap
eap-dynamic
eap-tnc
maemo
tnc-pdp

19. Modular Architecture: libcharon plugins II
uci
unity
updown
vici
whitelist
xauth-eap
xauth-generic
xauth-noauth
xauth-pam

20. Modular Architecture: libhydra plugins
kernel-netlink
kernel-pfkey
kernel-pfroute

21. Plugins for libstrongswan
aes
Non-US crypto code
No OpenSSL library
ECCN: No License Required (NLR)
sha2
crypto P l u g i n L o a d e r
random
Factories …
credentials
x509 …
sqlite
database
mysql
List of all available ciphers • •
Crypto test vectors •
Integrity self-tests •
Public key benchmarks • …
Certificate retrieval (HASH-and-URL)
CRL fetching, OCSP
curl
fetcher
ldap

22. Modular Architecture: libstrongswan plugins
acert
fips-prf
pem
soup
aes
gcm
pgp
sqlite
aesni
gcrypt
pkcs1
sshkey
af-alg
gmp
pkcs7
test-vectors
agent
hmac
pkcs8
unbound
bliss
keychain
pkcs11
winhttp
blowfish
ldap
pkcs12
x509
ccm
md4
pubkey
xcbc
cmac
md5
random
constraints
mysql
rc2
ctr
nonce
rdrand
curl
ntru
revocation
des
openssl
sha1
dnskey
padlock
sha2

23. Modular Architecture: libtnccs plugins
tnc-imc
tnc-imv
tnc-tnccs
tnccs-11
tnccs-20
tnccs-dynamic

24. Modular Architecture: libimcv plugins
imc-attestation
imv-attestation
imc-os
imv-os
imc-scanner
imv-scanner
imc-swid
imv-swid
imc-test
imv-test

25. strongSwan Roadmap Release Cycle Roadmap
Stable minor release (strongSwan x.y.z) every 3 months
Stable major release (strongSwan x.y) every months
Release candidate and code freeze about 2 weeks before release
Roadmap
Windows 10 port (Q3 2015)
Windows 10 Mobile port (Q4 2015)
iOS port (Q4 2015?)
Post-quantum BLISS standardization (Q3 2015)
Public key retrieval via DNSSEC (DANE) (Q4 2015)
Refactoring of entropy generation (Q4 2015)

26. KVM VPN Testbed

27. strongSwan Workshop for Siemens
IPsec Transport Mode using AH or ESP

28. IPsec – Transport Mode Internet secure IP connection
2001:1620:f00::1
2001:620:130:a036::121
IP connection
secure
Authenticity of IP connections
• In order to prevent IP spoofing and connection hijacking, as well as to secure the content of IP datagrams against any unauthorized modifications, all IP datagrams sent over the Internet should be authenticated.
Privacy of IP connections
• In order to guarantee privacy, all IP datagrams sent over the Internet should be encrypted by employing strong cryptography.
Encryption and Authentication
• Encryption without authentication is vulnerable to various attacks. Therefore encryption must always be combined with authentication.
Secure Host to host connection
IP datagrams must be authenticated
IP datagrams should be encrypted and authenticated

29. IPsec – Transport Mode IP Authentication Header (AH)
Original IP Header
TCP Header
Data
IPv4
Before applying AH
AH: RFC 4302
After applying AH
IPv4
authenticated
except for mutable fields
Original IP Header
AH Header
TCP Header
Data
IP Authentication Header (AH)
• The IPsec AH Protocol is specified in RFC 4302.
• AH protects both IP header and IP payload against modifications by computing a keyed message authentication code (MAC) over most octets of the IP datagram.
• Excluded from the cryptographic checksum are the following mutable header fields:
• Type of Service (TOS) • Fragment Offset (always zero since AH is applied to non-fragmented packets, only) • Flags • Time to Live (TTL) • IP header checksum
The above header fields could possibly get modified by intermediate routers en-route from source to destination.
• The secured checksum is transmitted in the AH header, together with an arbitrary bit Secure Parameters Index (SPI) uniquely identifying the Security Association and a 32 bit Sequence Number preventing replay attacks.
• The AH header has the structure of an IPv6 extension header but can also be carried over IPv4.
• Not only TCP and UDP but any transport layer protocol can be protected by AH. The Protocol field in the original IP header is set to the decimal value 51, designating the AH protocol and the Next Header field in the AH header carries the original protocol number(e.g. 1 for ICMP, 6 for TCP, 17 for UDP), identifying the transport layer payload carried in the IP datagram.
IP protocol number for AH: 51
Mutable fields: Type of Service (TOS), Fragment Offset, Flags, Time to Live (TTL), IP header checksum

30. IPsec – Transport Mode IP Encapsulating Security Payload (ESP)
Original IP Header
TCP Header
Data
IPv4
Before applying ESP
ESP: RFC 4303
Original IP Header
ESP Header
IPv4
After applying ESP
encrypted
authenticated
TCP Header
Data
ESP Trailer
ESP Auth
IP Encapsulating Security Payload (ESP)
• The IPsec ESP Protocol is specified in RFC 4303.
• ESP encrypts the transport payload of the IP datagram using a strong symmetric encryption algorithm, (AES, CAMELLIA, 3DES, etc.).
• An ESP trailer is appended prior to encryption in order to align the payload data to a 4-byte boundary required by the ESP packet format. It may also be used to adapt the plaintext size to the block size of the block cipher (e.g. 64 bits for 3DES).
• Since IP packets could get lost, the encrypted payload is usually preceded by an initialization vector (IV) that is used by the receiver to initialize the block cipher algorithm used for the decryption of each IP payload.
• The ESP header has the structure of an IPv6 extension header but can also be carried over IPv4. Similar to the AH header it contains a 32 bit Secure Parameters Index (SPI) and a 32 bit Sequence Number.
• Any transport layer protocol can be encapsulated by ESP. The Protocol field in the original IP header is set to the decimal value 50, designating the ESP protocol and the Next Header field in the ESP header carries the original protocol number identifying the transport layer protocol carried in the encrypted IP payload.
• Optionally the ESP payload can be authenticated by computing a keyed message digest over the body of the IP datagram and appending the MAC value as authentication data at the end of the encrypted payload. The IP header is not included in the checksum and therefore is not protected.
• In the case of an IPsec transport mode application where besides encryption also the protection of the IP header is required, the ESP and AH protocols can be cascaded by first encrypting the original IP payload using ESP and then authenticating both the original IP header and the ESP payload using AH.
IP protocol number for ESP: 50
ESP authentication is optional
With ESP authentication the IP header is not protected.

31. strongSwan Workshop for Siemens
IPsec Tunnel Mode using ESP

32. IPsec – Tunnel Mode Virtual Private Network (VPN)
Subnet /16
Subnet /16
Internet
Security Gateway
secure IP tunnel
Virtual Private Networks
• A Virtual Private Network (VPN) can be used by an enterprise to connect its subnets or individual hosts located at various sites over shared public or semi-public communication channels. Compared to dedicated leased lines a VPN solution can offer significant cost savings without incurring any compromises regarding security requirements.
• VPNs can be realised using the Layer 2 Tunneling Protocol (L2TP) defined by the IETF or the now obsolete Point-to-Point Tunneling Protocol (PPTP). Layer 2 tunnels are often transported over IP based networks using UDP as a transport medium but emulating a link layer dial-in line from source to destination.
• An elegant and increasingly popular VPN solution is based on layer 3 mechanisms using secure IP tunnels based on the IPsec protocol suite.
IPsec Tunnels
• Two enterprise subnets can be securely connected with each other over the public Internet using an encrypted and authenticated IPsec tunnel. IP packets from a host on the local subnet to a host on the remote subnet are forwarded to the local Security Gateway (SEGW) which in turn tunnels the IP packets to the Security Gateway on the remote end of the IPsec tunnel where they are delivered to the destination host. The hosts belonging to the subnets are not aware of any security mechanisms. For them the Security Gateways have the function of simple routers.
• The encapsulation provided by the IPsec tunnels allows the use of private network addresses (e.g /24 in one subnet and /24 in the second subnet) which are normally not routable over the Internet.

33. IPsec Tunnel Mode using ESP
Original IP Header
TCP Header
Data
IPv4
Before applying ESP
Encapsulating Security Payload (ESP): RFC 4303
Outer IP Header
ESP Header
IPv4
After applying ESP
encrypted
authenticated
Original IP Header
TCP Header
Data
ESP Trailer
ESP Auth
IP protocol number for ESP: 50
ESP authentication is optional but often used in place of AH
Original IP Header is encrypted and therefore hidden

34. ESP Header (Header / Payload / Trailer)
encrypted
authenticated
After applying ESP
Security Parameters Index (SPI)
Anti-Replay Sequence Number
Payload Data (variable, including IV)
Padding (0-255 bytes)
Authentication Data (variable) 1 2 3
4 bytes
Next Header
Pad Length
ESP Overhead DES AES
• SPI
• Sequence Number
• IV
• Padding (worst-case)
• Pad Length / Next Header 2 2
• Authentication Data
-- --
IPsec Transport Mode bytes
• Outer IP Header
IPsec Tunnel Mode bytes
MTU bytes ==== ====
Usually Path MTU discovery based on "fragmentation needed" ICMP messages" automatically reduces the MTU from a standard LAN MTU of 1500 bytes down to a payload data size that does not lead to fragmentation when the IPsec overhead is added.

35. IPsec Tunnel Mode CBC Packet Overhead
Outer IP Header 20 12 16 24 32 20 8 7 15 2
SPI / Seq. Number 8
3DES_CBC IV 8
AES_CBC IV 16
3DES_CBC max Pad 7
AES_CBC max Pad 15
Pad Len / Next Header 2
HMAC_SHA1_96 12
AES_XCBC_96 12
HMAC_SHA2_256_128 16
HMAC_SHA2_384_192 24
HMAC_SHA2_512_256 32 50 54
Best Case Overhead 62 70 58 78
Bytes
Worst Case Overhead 57 61 69 77 73 85 93

36. Authenticated Encryption with Associated Data (AEAD)
Salt IV
Salt IV 1
Salt IV 2
AEAD is based on special block cipher modes:
Block size: 128 bits
Key size: /256 bits
Tag size : 128/96/64 bits
Nonce size: 96 bits 32 bits bits bits
Recommended AEAD Modes: AES-Galois/Counter Mode AES-GMAC (auth. only)
Alternative AEAD Modes: AES-CCM CAMELLIA-GCM CAMELLIA-CCM
Key K
Key K
Salt IV
Counter
NIST Special Publication D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November 2007
This Recommendation specifies an algorithm called Galois/Counter Mode (GCM) for authenticated encryption with associated data. GCM is constructed from an approved symmetric key block cipher with a block size of 128 bits, such as the Advanced Encryption Standard (AES) algorithm. Thus, GCM is a mode of operation of the AES algorithm.
GCM provides assurance of the confidentiality of data using a variation of the Counter mode of operation for encryption. GCM provides assurance of the authenticity of the confidential data (up to about 64 gigabytes per invocation) using a universal hash function that is defined over a binary Galois (i.e., finite) field. GCM can also provide authentication assurance for additional data (of practically unlimited length per invocation) that is not encrypted.
If the GCM input is restricted to data that is not to be encrypted, the resulting specialization of GCM, called GMAC, is simply an authentication mode on the input data. In the rest of this document, statements about GCM also apply to GMAC.
The two functions of GCM are called authenticated encryption and authenticated decryption. Each of these functions is relatively efficient and parallelizable; consequently, high-throughput implementations are possible in both hardware and software.
IPsec ESP Overhead: 8 octet IV, 16/12/8 octet authentication tag
• RFC 4106 “The Use of Galois/Counter Mode (GCM) in IPsec ESP”
• RFC 4309 “Using AES CCM Mode with IPsec ESP“
• RFC 4312 “The Camellia Cipher Algorithm and Its Use With IPsec”
Hash Subkey Derivation
Hash Subkey H
0………………..0
Key K

37. IPsec Tunnel Mode AEAD Packet Overhead
Outer IP Header 20 20 20 20
Additional Authenticated Data:
SPI / Seq. Number 8 8 8 8 1 2 3
AES_GCM IV 8 8 8 8
Security Parameter Index
AES_CNT max Pad 3 3 3 3
Sequence Number
Pad Len / Next Header 2 2 2 2 or
AES_GCM_64 Tag 8 8
AES_GCM_96 Tag 12 12 1 2 3
AES_GCM_128 Tag 16 16
Security Parameter Index
Best Case Overhead 46 50 54
Extended Sequence Number
Worst Case Overhead 49 53 57
Bytes

38. strongSwan Workshop for Siemens
Layer 3 VPN vs Layer 4 VPN

39. Layer 3 Tunnel based on IPSec
Payload
Private Network
Internet IP
ISP
VPN Client
VPN Gateway
PSTN
IPsec Tunnel IP
ESP
Payload
PPP
PSTN IP
ESP
Payload

40. Layer 4 Tunnel based on SSL/TLSIP
Payload
Private Network
Internet IP
ISP
TLS Client
TLS Proxy Server
PSTN
SSL/TLS Tunnel IP
TCP*
TLS
Payload
PPP IP
PSTN
TCP*
TLS
Payload
*OpenVPN uses TLS over UDP

41. Layer 3 versus Layer 4 VPN Layer 3 – IPSec Layer 4 – TLS (OpenVPN)
IPsec is an Internet standard
ESP and AH don’t have ports and thus cannot traverse NAT routers
But with ESP-in-UDP encapsulation NAT-Traversal becomes simple
First generation IPsec with IKEv1 was complex and difficult to set up
Second generation IPsec with IKEv2 is fast, simple and robust
High throughput because encryption is handled by kernel
Layer 4 – TLS (OpenVPN)
Although available on many platforms, OpenVPN is not a standard
Easy to handle NAT situations since single TCP or UDP socket is used
Fast, simple and robust connection setup
Lower throughput (factor 2..3) because encryption is done in userland