IPSec - the basics

Following on from GRE (which I'll come back to on another occasion), IPSec is an IETF standard (RFC 2401 - 2412) which can be considered to be a 'suite' of protocols.

IPsec operates at the Nework layer of the OSI model, and authenticates every packet, offers data integrity for every packet, and provides confidentiality.

IPsec is available from IOS 11.3(T) and PIX OS 5.0 or later.

IPsec is main up of 3 components:

1. Internet Key Exchange (IKE) - UDP 500, which is a framework for negotiating security parameters and authentication keys.
2. Encapsulation Security Payload (ESP)  - IP port 50, encrypts (using DES, 3DES, AES), secures (MD5 or SHA-1), and authenticates data (MD5 or SHA-1).
3.  Authentication Header (AH) - IP port 51, offers secures data and offers authentication (MD5 or SHA-1).

 IPsec creates secure tunnels, known as Security Associations (SA), between 2 peers such as routers. Tunnels are unidirectional and are established via ESP or AH.

Internet Key Exchange Overview
IPsec uses IKE to authenticate peers and generate symmetrical encryption keys for data communications
Symmetrical keys are generated by Diffe Helman (DH)

IKE also manages the negotiation between peers for settings such as what data to be protected, key strengths, hash method to use (outlined later).

You can manually set the parameters in IPSec for the generation of keys, refresh interval of the keys, an SA characteristics however it's much easier to have IKE configure this automatically. IKE achieves this using ISAKMP or Internet Security Association and Key Management Protocol.

IKE has 2 phases in its method for setting up an IPSec tunnel.
Phase1 - Authenticates the actual peer so each peer knows the other peer is who it says it is. Operates in either 'Main Mode' or 'Agressive Mode'
Phase1.5 - is optional and it is at this stage you can authenticate an actual user. This may be via a RADIUS server, local accounts on the terminating peer (i.e router), or other means.
Phase2 - Establishes the actual IPSec tunnel and operates in 'Quick Mode'

IKE Modes
Main Mode - consists of 3 exchanges, the initiator sends a propsal to the peer containing what encryption, authentication, key duration settings to use (amoungst others).
The remote peer selects an appropriate proposal and replies
DH public keys and then exchanged resulting in all further comms being encryped in the inital IKE tunnel (SA)
A 3rd exchange authenticates the ISAKMP session.
Once complte phase 2 ocurs.
Aggressive Mode - Everything is sent over in a single exchange and the remote peer then responds accordingly
Quick Mode - Within IKE phase2, the IPSec SA is established but comms are protected by the IKE SA configured in Phase1.
Quick mode negotiates the SA for data to be exchanged.

Generic Routing Encapsulation – GRE

•  GRE is IP protocol 47 (that's Protocol NOT port)
  
• GRE can encapsulate a wide variety of protocol packets inside IP tunnels
• Creates virtual Point-to-Point links to Cisco router (prepriortary)
• Uses IP for transport
• Additional Header supports any other layer3 protocol in the payload (eg IPX, AppleTalk, et al)
• Stateless – Tunnel end point doesn’t keep any information on the state/availability of the remote end point.
• Offers NO security, confidentiality, integrity checking, data authentication
• Uses 24-byte overhead by default – 20-byte IP header plus 4-byte GRE header
• 4-byte header contains GRE flag setting out a checksum, key (if used), sequence number, version number, protocol type id field.
• Protocol typre id field is used to identify the protocol of the payload, e.g, 0x800 indicates IP. This is the field that allows GRE to tunnel any protocol.

 Benefits:

•  Good at tunneling
•  Supports multiple protocols
• Allows routing protocols (OSPF, EIGRP) to be used

Costs:

• Poor security – only plain text authentication used
• Cannot accommodate confidentiality, integrity, and data authenication

GRE and IPSEC

•  GRE can be used in conjunction with IPSEC
•  IPSEC offers confidnetiality via 3DES or AES (for example)
•  Authentication is provided via a HMAC such as MD5 or SHA-1
•  Integrity is via MD5 or SHA-1
•  IPSEC is not perfect though, older IOS’ don’t support IP multicast
•  IPSEC was designed to support IP only

 Configure a basic GRE tunnel in IOS

•  Here is a typical GRE tunnel config.
• Each router needs needs a tunnel interface on the end points of the tunnel
• Simplest type of tunnel

 R1(config)#int tu0
R1(config-if)#tunnel source S0/0
R1(config-if)#tunnel dest 192.168.20.1
R1(config-if)#ip address 172.16.10.1 255.255.255.0

R2(config)#int tu0
R2(config-if)#tunnel source s0/1
R2(config-if)#tunnel dest 192.168.10.1
R2(config-if)#ip address 172.16.10.2 255.255.255.0

*use the ? to inspect further options in tunnel interface mode

Note

• The ‘int tu0’ cmd creates the GRE tunnel
• ‘ip address’ is a network used exclusively by the tunnel end points
•  ‘tunnel source’ is a physical interface on the route
•  ‘tunnel dest’ is the ip of the physical interface on the remote router
•  Default mode of the tunnel is GRE and so we have not needed to configure the mode in this example
• GRE can pass OSPF/EIGRP so you use this in association with IPSEC (which cannot) if you are wishing to distribute routing information
• Where you use IPSEC and GRE the ipsec crypto map will be assigned to the physical interface NOT the tunnel interface
• IPSEC will be discussed in further detail later.