VSN Jubileumreis 2011 - Dubai
65 Photos
Dag 1: Woensdag 6 April 2011
11.30 – 12.30 uur: Transfer per luxe touringcar van Venray naar Dusseldorf Internatiol Airport, met aansluitend de check-in.
15:25 – 23:55 uur: Vlucht EK056 van Dusseldorf International Airport naar Dubai.
00:45 – 01:00 uur: Transfer naar het JW Mariott Hotel, met aansluitend de check0in. Overnachting in het JW Mariott Hotel.
Dag 2: Donderdag 7 April 2011
08:00 – 09:00 uur: Ontbijt in de ontbijtzaal van het hotel en check-out.
09:00 uur: Verzamelen in de lobby en transfer naar startpunt Dubai City Rally.
09:30 – 12:30 uur: Dubai City Rally.
Na een goed ontbijt is het tijd om op een leuke manier, in teamverband, kennis te maken met de hotspots van Dubai zoals de traditionele wijk Bastakiya en de Souks.
13:00 – 14:30 uur: Lunch in Kaleidoscope Restaurant (Atlantis de Palm).
13:30 – 14:50 uur: Transfer naar het Jumeirah Beach strand.
16:30 uur: Vertrek per 4×4 Jeep naar de woestijn.
19:00 uur: Aankomst in het bedoeienkamp.
Na de lunch vertrekken we naar het Jumeirah Beach strand, tijd om nog even te ontspannen alovrens we per jeep de woestijn in zullen gaan. Midden in de woestijn maken we onder het genot van een glas champagne live de zonsondergang mee, om vervolgens op zoek te gaan naar de plaats waar ons kamp is opgezet…
20:00 – 22:00 uur: BBQ diner in de traditionele bedoeiententen. Overnachting in het kamp.
Dag 3: Vrijdag 8 April 2011
07:15 – 08:15 uur: Ontbijt in het kamp.
08:30 – 09:00 uur: Transfer naar de rand van de woestijn.
09:00 – 10:30 uur: Woestijnactiviteiten (Quad rijden, sandboarden, 4×4 selfdrive).
Alvorens we de woestijn verlaten staan er nog een aantal sportieve woestijnactiviteiten op het programma. Wat dacht je van rondscheuren over de uitgestrekte zandvlakte in een 4×4 jeep of op een quad of je boardkunsten vertonen onder de zon? De verschillende activiteiten worden afgewisseld en tussendoor wordt gezorgd voor een lekker drankje.
10:45 – 11:15 uur: Transfer naar de Dubai Marina Yacht Club.
11:15 – 14:15 uur: Catamaran BBQ Cruise.
Gedurende drie uur varen we langs de kust van Dubai en het bekende palmeiland Palm Jumeirah. Het anker wordt uitgegooid vlakbij het Burj Al Arab. Bij het Burj Al Arab heb je de gelegenheid om te zwemmen of snorkelen, terwijl de crew aan boord een barbeque lunch voorbereidt. Je ontvangt van ons een handdoek en snorkeluitrusting.
14:30 – 15:00 uur: Transfer naar de grootste overdekte sneeuwpiste ter wereld.
15:00 – 17:00 uur: Ski Dubai.
Ski Dubai telt meer dan 20.000 m2 skipiste verdeelt over 5 afdalingen. Skien in de woestijn: dat moet je meegemaakt hebben. De ski sessie zal ongeveer twee uur in beslag nemen. We hebben 3 leraren gereserveerd zodat de beginners onder begeleiding de eerste basisbeginselen kunnen leren. De volledige skiuitrusting (kleding en materiaal) is verzorgd.
17:15 – 17:45 uur: Transfer naar JW Mariott Hotel, met aansluitend check-in.
17:45 – 19:30 uur: Tijd om je even op te frissen of een drankje te doen aan de bar.
19:30 – 20:00 uur: Transfer naar restaurant Beachcombers (Jumeirah Beach Hotel).
20:00 – 22:30 uur: Diner bij restaurant Beachcombers met uitzicht op het Burj Al Arab.
22:30 – 23:00 uur: Transfer terug naar het hotel. Overnachting in het JW Mariott Hotel.
Dag 4: Zaterdag 9 April 2011
07:00 – 08:40 uur: Ontbijt in de ontbijtzaal van het hotel.
08:55 – 09:40 uur: Transfer naar het Jebel Ali International Hotel.
09:55 – 11:30 uur: Rondvlucht per Cessna watervliegtuig.
Aanschouw de kunstmatig aangelegde palmeilanden en de vele bijzondere gebouwen die Dubai rijk is vanuit de lucht. Terwijl 16 personen tegelijk van de rondvlucht kunnen genieten, kan de rest van de groep heerlijk relaxen bij het zwembad van het hotel en gebruik maken van de strandfaciliteiten.
12:30 – 14:00 uur: Lunch bij het Jebel Ali International Hotel.
14:15 – 15:00 uur: Transfer naar Burj Khalifa / Dubai Mall.
15:00 – 17:30 uur: Bezoek aan Burj Khalifa en vrije tijd in Dubai Mall.
17:30 – 18:00 uur: Transfer terug naar het hotel.
Na de lunch bij Jebel Ali International Hotel is het tijd om een bezoek te brengen aan de 124e verdieping van de Burj Khalifa, met 828 meter sinds begin 2010 het hoogste gebouw van de wereld. Aansluitend krijgt iedereen vrije tijd om zelf de naastgelegen Dubai Mall verder te ontdekken.
19:00 – 20:00 uur: Transfer naar de Dubai Creek.
20:00 – 22:00 uur: Diner aan boord van een traditioneel jacht (Dhow).
22:15 – 22:45 uur: Transfer terug naar het hotel. Overnachting in het JW Mariott Hotel.
Dag 5: Zondag 10 April 2011
Ontbijt, terugvlucht.
Concepts and terminology
Tunneling techniques use encapsulation; the original datagram is encapsulated inside a new datagram sent from one tunnel peer to another. The receiving tunnel peer decapsulates the data and forwards the original datagram.
Various tunnel protocols exist:
- GRE (Generic Routing Encapsulation);
- L2TP (Layer 2 Tunneling Protocol);
- IPSec (IP Security);
One of the issues to address with any tunnel protocol is how secure your data is as it traverses the public network. Without some sort of strategy, theoretically, anyone connected to the public network can intercept your data.
The need for security
- Confidentiality: Keep data secure and hidden;
- Integrity: Ensure that data has not been changed;
- Authentication: Did it really come from the advertised source?;
Symmetric key encryption
Symmetric key encryption is called symmetric because the key used to encrypt the data is the same key used to decrypt it. Symmetric key sizes vary between 40 bits and 1024 bits. They are very fast and widely used for bulk data encryption.
Examples: RC4, DES, AES and Blowfish.
Public key encryption
Figure 1 Public key encryption
Public key sizes vary from 512 bits to 2048 bits. Because of the large size, public keys are extremely slow and generally not feasible for bulk data encryption. However, public keys are widely used for user and device authentication.
Examples: Digital certificates, RSA
Data integrity
Hash functions are used to provide integrity services. A hashing algorithm has to be one way; you cannot determine the original data from the hash value. The hash function also has to be collision resistant; a collision occurs when two different inputs give the same output. Above all, it should not be possible to prodict a different input value that will give the same output.
The most secure hash function that is widely used at present is the SHA-1. SHA-1 is preferred over MD5, although MD5 is still widely supported. These functions produce a fixed-length output, which is useful when working with IP packets because the overhead of transmitting the hash value is predictable.
Source authentication
Source authentication is performed using the Hashed Method Authentication Code (HMAC).
- The sender appends a secret preshared key to the data;
- The sender performs a hash function over the data;
- Receiver must append same key value to the data before performing the hash function;
The key itself is never transmitted along with the data.
How do keys get exchanged?
One option is to manually configure the keys on both sides of the connection.
- Prone to configuration errors;
- Rarely changed;
Automating the key exchange process is a fine idea, but we must overcome the problem of sending keys across a public network. Anyone intercepting the key has the ability to decode the data.
The Diffie Hellman Key Exchange
The DH algorithm is a method whereby two parties can agree upon a secret key that is known only to them. The strength of the technique is that it allows the participants to create the secret value over an unsecured medium without exchanging the secret value itself. It is also impossible to reverse-generate the secret if it is somehow intercepted.
Diffie-Hellman Groups
The DH groups consist of 5 groups of very large prime numbers (and a generator) used as the modulus for the DH algorithm, JN supports groups 1, 2, and 5.
- Group 1 uses a 768 bit prime;
- Group 2 uses a 1024 bit prime;
- Group 5 uses a 1535 bit prime;
The larger the prime number, the stronger the key, and the more computationally intensive the calculation.
The DH key exchange process
Using the same DH group, each device creates a unique public/private key. These keys are mathematically related using the DH algorithm.
- The public key values are exchanged across the network.
- Each peer then runs its local private key and the received public key value through the DH algorithm to compute a common session key.
- The session key itself is never passed across the network.
Figure 2 Diffie Hellman Key Exchange
IP security
IPSec is an industry standard for providing IP data security and integrity services. IPSec works at the IP layer, supports unicast traffic, and uses two protocols to provide traffic security:
- ESP (Encapsulating Security Payload Protocol) Provides for confidentiality, integrity and authentication of data.
- AH (Authentication Header Protocol) Provides verification on integrity and authentication of the data.
IPSec is a set of standards that defines how the encryption, validation, and authentication methods we just are actually implemented in networks.
IPSec modes
- Tunnel mode: Implemented between an IPSec gateways or an IPSec gateway and a remote client providing secure access to the networks behind the gateway. The end systems are not aware of the IPSec protocol suite.
- Transport mode: Implemented between IPSec end systems.
ESP (Encapsulating Security Payload Protocol)
ESP does not use a transport protocol like TCP or UDP; it rides directly on top of IP using protocol number 50. ESP uses symmetric key algorithms like DES, 3DES or AES, and hash methods like MD5 and SHA-1 to provide security services.
Anti-replay services ensure that datagrams cannot be captured by a third party and retransmitted. By checking sequence numbers, a receiver can determine whether a packet was already received and can discard any repetitions.
Figure 3 IPSec EPS
ESP Header:
- TCP protocol number, indicating that it is an TCP packet: 50;
- Security Parameter Index (SPI): 32 bit value that, in combination with the destination IP and security protocol (ESP) uniquely identifies the security association for this datagram;
- Sequence number: Unsigned 32 bit field containing a sequence number;
ESP auth is the integrity check value (ICV, hash value) for this packet.
Authentication header
Figure 4 Authentication header
Authentication Header:
- TCP Protocol number, indicating that it is an TCP packet: 51;
- Next header, which is information on the next expected segment;
- Payload length, which indicates the size of the payload;
- Security Parameter Index (SPI): 32 bit value that, in combination with the destination IP and security protocol (ESP) uniquely identifies the security association for this datagram;
- Sequence number: Unsigned 32 bit field containing a sequence number;
Internet Key Exchange Protocol
IKE is a secure key management protocol used by IPSec to have information exchanged in a secure and dynamic manner with little or no intervention. IKE proposal exchange is the phase one of the IPSec tunnel establishment process. The following attributes are exchanged between IPSec peers as a part of the IKE process:
- Encryption algorithm;
- Hash algorithm;
- Authentication group;
- DH group;
Once these attribures are negotiated between the IPSec peers, IKE is used to secure future attribute exchanges used to protect data. IKE exchanges are authenticated using one of the following methods:
- Pre-shared keys;
- Digital Signatures;
- Public key encryption;
IKE establishes security associations for creating IPSec VPN tunnels:
-
- Negotiates proposals containing encryption and authentication algorithms;
- Creates encryption and authentication keys automatically, which provides ability to be rekeyed frequently;
- Provides gateway identity function;
Phase 1
IKE phase 1′s purpose is to establish a secure authenticated communication channel by using the Diffie-Hellman key exchange algorithm to generate a shared secret key to encrypt further IKE communications. This negotiation results in one single bi-directional ISAKMP Security Association (SA). The authentication can be performed using either pre-shared key (shared secret), signatures, or public key encryption. Phase 1 operates in either Main Mode or Aggressive Mode. Main Mode protects the identity of the peers (only in static IP mode); Aggressive Mode does not (only in dynamic IP mode, DHCP).
Main mode:
Attributes:
- Encryption algorithm;
- Hash algorithm;
- DH Group;
- Authentication method:
- Pre-shared keys;
- Digital signatures;
- Public key encryption;
Figure 5 IKE phase 1 main mode
Aggressive mode:
Figure 6 Aggressive mode
IKE aggressive mode is used when one of the tunnel peers has a dynamic IP address, which could be a remote end user dialing in to the internet, or a remote site using DHCP to acquire an IP address.
Phase 2
During IKE phase 2, the IKE peers use the secure channel established in Phase 1 to negotiate Security Associations on behalf of other services like IPsec. The negotiation results in a minimum of two unidirectional security associations (one inbound and one outbound). Phase 2 operates only in Quick Mode. The ProxyID is used to identify which SA is referenced for VPN.
Figure 7 IKE phase 2
A single Phase 1 channel can be used to establish multiple Phase 2 SAs or VPNs. If you want, you can enable perfect forward secrecy (PFS), which creates a second DH exchange that is performed during Phase 2 to negotiate a new tunnel key.
In an authenticated key-agreement protocol that uses public key cryptography, perfect forward secrecy (or PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised if one of the (long-term) private keys is compromised in the future.
ISAKMP (Internet Security Association Key Management Protocol)
ISAKMP defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). ISAKMP typically utilizes IKE for key exchange, although other methods can be implemented. Preliminary SA is formed using this protocol; later a fresh keying is done.
ISAKMP defines procedures and packet formats to establish, negotiate, modify and delete Security Associations. SAs contain all the information required for execution of various network security services, such as the IP layer services (such as header authentication and payload encapsulation), transport or application layer services, or self-protection of negotiation traffic. ISAKMP defines payloads for exchanging key generation and authentication data. These formats provide a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism.
Security Associations (SA)
SAs are a set of policies and keys used to protect information between two peers:
- SA is uniquely identified for:
- SPI, an internal index number;
- Destination IP address;
- Security Protocol (ESP / AH);
- SAs are established during IKE phase 1 and phase 2 negotiations;
- Phase 1 SA is bidirectional, and phase 2 SA is unidirectional;
An IPSec SA proposal contains the following:
- Phase 1 authentication method (main mode or aggressive mode);
- DH group member;
- Encryption algorithm;
- Authentication algorithm;
- Key lifetime;
The Phase 2 proposal contains:
- ESP or AH;
- DH group member (0 for no Perfect Forward Secrecy (PFS);
- Encryption algorithm;
- Authentication algorithm;
- Key lifetime;
- ProxyID (policy rule);
- DH public keys (optional if using PFS);
SA Database
Figure 8 SA Database
ProxyID
The ProxyID is used to:
- Exchange & check policy rules between two VPN peers:
- Use if configuration on the peer gateways support multiple tunnels; otherwise, the IKE session will fail!
- Can disable policy checking when only one policy is configured between the two peers.
- There are 2 values for each VPN:
- Local ProxyID Must match remote ProxyID of peer;
- Remote proxy ID Must match local ProxyID of peer;
The policy that is sent via the ProxyID will be compared to the locally configured policy. It is critical that address book entries match.
Example:
If a device A uses a policy with:
- Source address: 10.1.10.0/24
- Destination address: 10.1.210.0/24
The device B must use the same address definitions when creating the policy. If device B uses a policy with destination address 10.1.210.3/32 instead of the subnet /24, the policy statements will not match and the VPN will not be established.
IPSec tunnel establishment – summary
- IKE Phase 1 establishes a secure channel between gateways using the DH key exchange;
- IKE Phase 2 establishes an SA for a specific policy set and VPN;
- One Phase 2 is completed successfully; data can flow through the IPSec tunnel. Data will be encrypted (if ESP is used), authenticated, and encapsulated according to IPSec standards.
Packet handling and receiving
- The packet arrives at remote device;
- The device looks up destination route. The route is crossing zones;
- The device looks up policy. Traffic matches a tunnel policy;
- The original packet is encrypted;
- The packet is hashed with authentication key;
- The tunnel packet is built with a new IP header, IPSec header, and hash value. The new packet is sent to tunnel peer.
- The corporate device receives the encrypted packet;
- The corporate device looks up incoming SPI in local SA database. Matching record contains encryption and authentication algorithms, and keys;
- The device compares locally calculated hash with received hash;
- The device decrypts the packet;
- The device performs routing lookup for decrypted packet;
- The device checks policy match for decrypted packet. Forward if tunnel policy exists for packet;’
