Transcript week10&11-IPSECv0

IP Security
1
IP Security Overview
• We have considered some application
specific security mechanisms
– eg. S/MIME, PGP, Kerberos, SSL/HTTPS
• However there are security concerns that
cut across protocol layers
• Would like security implemented by the
network for all applications
2
Security versus OSI & TCP/IP Model
OSI
TCP/IP
Application
Application
Presentation
Application
Presentation
Security
Applications
Session
Transport
Transport
Network
Internet
Data Link
Data Link
Physical
Physical
Protocol
Cryptography
3
Security Flows
Applications
Protocol
Cryptography
Applications:
Web, email, any application use security
mechanism
Protocol:
SSL, TLS, IPSec
Algorithm:
Symmetric, Asymmetric (i.e.:Cipher, DES, AES)
* This approach is totally under my knowledge and experience, is not a standard, just to understand
4
the layer concept.
IP Security Overview
IPSec is not a single protocol. Instead,
IPSec provides a set of security
algorithms plus a general framework
that allows a pair of communicating
entities to use whichever algorithms
provide security appropriate for the
communication.
5
TCP/IP Example
6
What is IPSec?
• IP Security is a set of protocols and standards to
support the securing of data at the IP layer. IPSec is
a framework, not an implementation.
• Supports authentication and encryption of traffic.
– Certifies the originator of the packet.
– Protects the data from interception and tampering
while in transit.
7
IPSec
• general IP Security mechanisms
• provides
– authentication
– confidentiality
– key management
• applicable to use over LANs, across public
& private WANs, & for the Internet
8
IP Security Overview
• Applications of IPSec
– Secure branch office connectivity over the
Internet
– Secure remote access over the Internet
– Establsihing extranet and intranet connectivity
with partners
– Enhancing electronic commerce security
9
IPSec Uses
10
Benefits of IPSec
• in a firewall/router provides strong security
to all traffic crossing the perimeter
• is resistant to bypass
• is below transport layer, hence transparent
to applications
• can be transparent to end users
• can provide security for individual users if
desired
11
IP Security Architecture
• specification is quite complex
• defined in numerous RFC’s
– incl. RFC 2401/2402/2406/2408
– many others, grouped by category
• mandatory in IPv6, optional in IPv4
12
IPSec Services
•
•
•
•
Access control
Connectionless integrity
Data origin authentication
Rejection of replayed packets
– a form of partial sequence integrity
• Confidentiality (encryption)
• Limited traffic flow confidentiality
13
Why do we want to use IPSec?
14
Why do we want to use IPSec?
•
•
Secure our network
Transparent operation
–
IPSec allows us to secure any IP based protocol
transparent to the application.
–
Support for legacy software which is inherently insecure
(telnet,ftp).
–
An alternative mechanism to implementing application
level security such as using SSL.
•
Widest industry support e.g. Cisco, Microsoft, Network
Associates, CheckPoint Software, Bay Networks, etc.
•
IETF standard – Will be mandatory in IPv6
15
Why not use IPSec?
16
Why not use IPSec?
• Processor overhead to encrypt & verify each
packet can be great.
• Added complexity in network design.
17
IPSec Diagram Structure
IPSec
Control Protocols
IKE
IPsec can be used for:
- two hosts
- two security gateways
- a host and security gateway
Data Protocols
ESP
AH
IKE – Internet Key Exchange
ESP – Encapsulating Security Payload
AH – Authentication Header
18
IPSec Diagram Structure
IKE (ISAKMP)
Key Exchange
(Oakley, SKEME)
Diffle Hellman
Authentication
Connection Security
Message
Integrity
Encryption
DES
3DES
MD5
Shared
Secret
Digital
Signature
Message
Integrity
SHA-1
19
IPSec Diagram Structure
Data Protocols
AH
ESP
Null
DES
Integrity
Integrity
Encryption
3DES
MD5
SHA-1
MD5
SHA-1
20
IPSec Modes
• Transport – Secures the payload part of the
IP packet, leaves the IP header unsecured.
Commonly use for securing traffic on a LAN.
• Tunnel – Secures the entire IP packet and
encapsulates it within a new IP packet.
Commonly used for creating a VPN.
21
IPSec Modes
22
Transport Modes
23
Note
IPSec in the transport mode does not
protect the IP header; it only protects
the information coming from the
transport layer.
24
Tunnel Modes
25
Tunnel Modes
Note
IPSec in tunnel mode protects the
original IP header.
26
IPSec protocols – AH protocol
• AH - Authentication Header
–
–
–
–
–
–
Defined in RFC 1826
Integrity: Yes, including IP header
Authentication: Yes
Non-repudiation: Depends on cryptography algorithm.
Encryption: No
Replay Protection: Yes
Transport Packet layout
IP Header AH Header
Payload (TCP, UDP, etc)
Tunnel Packet layout
IP Header AH Header
IP Header
Payload (TCP. UDP,etc)
27
AH protocol in Transport Mode
28
AH & ESP
29
Note
The AH Protocol provides source
authentication and data integrity,
but not privacy.
30
End-to-end versus End-toIntermediate Authentication
31
IPSec protocols – ESP protocol
• ESP – Encapsulating Security Payload
–
–
–
–
–
–
Defined in RFC 1827
Integrity: Yes
Authentication: Depends on cryptography algorithm.
Non-repudiation: No
Encryption: Yes
Replay Protection: Yes
Transport Packet layout
IP Header ESP Header
Payload (TCP, UDP, etc)
Tunnel Packet layout
IP Header ESP Header
Unencrypted
IP Header
Encrypted
Payload (TCP. UDP,etc)
32
ESP protocol in Transport Mode
33
Note
ESP provides source authentication,
data integrity, and privacy.
34
What protocol to use?
• Differences between AH and ESP:
– ESP provides encryption, AH does not.
– AH provides integrity of the IP header, ESP does not.
– AH can provide non-repudiation. ESP does not.
• However, we don’t have to choose since both protocols can be
used in together.
• Why have two protocols?
– Some countries have strict laws on encryption. If you can’t
use encryption in those countries, AH still provides good
security mechanisms. Two protocols ensures wide
acceptance of IPSec on the Internet.
35
Security Associations
• One of the most important concepts in IPSec is called a
Security Association (SA). Defined in RFC 1825.
• SAs are the combination of a given Security Parameter Index
(SPI) and Destination Address.
• SAs are one way. A minimum of two SAs are required for a
single IPSec connection.
• SAs contain parameters including:
– Authentication algorithm and algorithm mode
– Encryption algorithm and algorithm mode
– Key(s) used with the authentication/encryption algorithm(s)
– Lifetime of the key
– Lifetime of the SA
– Source Address(es) of the SA
36
– Sensitivity level (ie Secret or Unclassified)
Example
• A security is a very complex set of pieces of
information. However, we can show the
simplest case in which Alice wants to have
an association with Bob for use in a twoway communication.
• Alice can have an outbound association (for
datagrams to Bob) and an inbound
association (for datagrams from Bob). Bob
can have the same. In this case, the security
associations are reduced to two small tables
37
for both Alice and Bob.
Example
•
•
The figure shows that when Alice needs to send a datagram to Bob, she uses the ESP
Protocol of IPSec. Authentication is done by using SHA-1 with key X. The encryption is
done by using DES with key Y. When Bob needs to send a datagram to Alice, he uses the
AH Protocol of IPSec.
Authentication is done by using MD5 with key z. Note that the inbound association for
Bob is the same as the outbound association for Alice, and vice versa.
38
How IPSec works: Phase 1
•
Internet Key Exchange (IKE) is used to setup IPSec.
•
IKE Phase 1:
–
Establishes a secure, authenticated channel between the two
computers
–
Authenticates and protects the identities of the peers
–
Negotiates what SA policy to use
–
Performs an authenticated shared secret keys exchange
–
Sets up a secure tunnel for phase 2
–
Two modes: Main mode or Aggressive mode
•
Main Mode IKE
1. Negotiate algorithms & hashes.
2. Generate shared secret keys using a Diffie-Hillman exchange.
3. Verification of Identities.
•
Aggressive Mode IKE
–
Squeezes all negotiation, key exchange, etc. into less packets.
–
Advantage: Less network traffic & faster than main mode.
–
Disadvantage: Information exchanged before a secure channel is
created. Vulnerable to sniffing.
39
How IPSec works: Phase 2
– An AH or ESP packet is then sent using the agreed upon
“main” SA during the IKE phase 1.
– IKE Phase 2
• Negotiates IPSec SA parameters
• Establishes IPSec security associations for specific
connections (like FTP, telnet, etc)
• Renegotiates IPSec SAs periodically
• Optionally performs an additional Diffie-Hellman
exchange
40
How IPSec works: Communication
• Once Phase 2 has established an SA for a particular
connection, all traffic on that connection is communicated
using the SA.
• IKE Phase 1 exchange uses UDP Port 500.
• AH uses IP protocol 51.
• ESP uses IP protocol 50.
41
Question
Can IPSec using AH be used in transport
mode if one of the machines is behind a NAT
box? Explain your answer.
42
Question
Can IPSec using AH be used in transport mode if one
of the machines is behind a NAT box? Explain your
answer.
No.
AH in transport mode includes the IP header in the
checksum. The NAT box changes the source address,
ruining the checksum. All packets will be perceived as
having errors.
43
Security Associations
• a one-way relationship between sender &
receiver that affords security for traffic flow
• defined by 3 parameters:
– Security Parameters Index (SPI)
– IP Destination Address
– Security Protocol Identifier
• has a number of other parameters
– seq no, AH & EH info, lifetime etc
• have a database of Security Associations
44
Authentication Header (AH)
• provides support for data integrity &
authentication of IP packets
– end system/router can authenticate user/app
– prevents address spoofing attacks by tracking
sequence numbers
• based on use of a MAC
– HMAC-MD5-96 or HMAC-SHA-1-96
• parties must share a secret key
45
Authentication Header
46
Transport & Tunnel Modes
47
Encapsulating Security Payload (ESP)
• provides message content confidentiality &
limited traffic flow confidentiality
• can optionally provide the same
authentication services as AH
• supports range of ciphers, modes, padding
– incl. DES, Triple-DES, RC5, IDEA, CAST etc
– CBC most common
– pad to meet blocksize, for traffic flow
48
Encapsulating Security Payload
49
Transport vs Tunnel Mode ESP
• transport mode is used to encrypt &
optionally authenticate IP data
– data protected but header left in clear
– can do traffic analysis but is efficient
– good for ESP host to host traffic
• tunnel mode encrypts entire IP packet
– add new header for next hop
– good for VPNs, gateway to gateway security
50
Combining Security Associations
• SA’s can implement either AH or ESP
• to implement both need to combine SA’s
– form a security bundle
• have 4 cases (see next)
51
Combining Security Associations
52
Question
• Why does IPSec need a security association?
53
Key Management
• handles key generation & distribution
• typically need 2 pairs of keys
– 2 per direction for AH & ESP
• manual key management
– sysadmin manually configures every system
• automated key management
– automated system for on demand creation of
keys for SA’s in large systems
– has Oakley & ISAKMP elements
54
Oakley
• a key exchange protocol
• based on Diffie-Hellman key exchange
• adds features to address weaknesses
– cookies, groups (global params), nonces, DH
key exchange with authentication
• can use arithmetic in prime fields or elliptic
curve fields
55
ISAKMP
• Internet Security Association and Key
Management Protocol
• provides framework for key management
• defines procedures and packet formats to
establish, negotiate, modify, & delete SAs
• independent of key exchange protocol,
encryption alg, & authentication method
56
ISAKMP
57
Summary
• have considered:
– IPSec security framework
– AH
– ESP
– key management & Oakley/ISAKMP
58
IPSec & NAT
59
How NAT affects
IPSec Protocol
60
IPSec & NAT
Network Address Translation (NAT) is typically used to connect a
private network such as a corporate network with private IP addresses
to a public network such as the Internet. Because private addresses
are not routable on the Internet, NAT replaces the private IP addresses
with routable addresses in the public network.
Keep in mind that to function, NAT doesn't just swap IP source and
destination addresses, but it may also swap TCP source and
destination ports, change the IP and TCP header checksums, change
the TCP sequence and acknowledgment numbers, and change IP
addresses contained in the data payload.
NAT is supposed to be transparent to whatever applications it works
with, but this assumption is not true when NAT is used in conjunction
with IPSec.
61
Effect of NAT on AH
AH protects the entire IP packet, including invariant header fields such
as the source and destination IP address, through a message digest
algorithm to produce a keyed hash.
The recipient uses the hash to authenticate the packet. If any field in
the original IP packet is modified, authentication will fail and the
recipient will discard the packet.
AH is intended to prevent unauthorized modification, source
spoofing, and man-in-the-middle attacks. But NAT, by definition,
modifies IP packets. Therefore, NAT on AH does not work.
62
AH & ESP
63
Effect of NAT on ESP
Like AH, ESP also employs a message digest algorithm for packet
authentication. But unlike AH, the hash created by ESP does not
include the outer packet IP header fields. This solves one problem, but
leaves other problems with ESP. When TCP or UDP are involved, as
they are in transport mode ESP, there are two caveats for ESP and NAT
to work together. First, because NAT modifies the TCP packet, NAT
must also recalculate the checksum used to verify integrity. On the
other hand, ESP authentication will fail if NAT updates the TCP
checksum. If NAT does not update the checksum (for example, if the
payload is encrypted), TCP verification will fail.
In tunnel mode, however, ESP has no issues with NAT. In this mode,
the original IP address and transport information is included as
payload. So, NAT and ESP can work together in tunnel mode when the
NAT translation is 1:1 on addresses with no multiplexing of inside
addresses to a single outside address using the transport layer port
for differentiation.
64
Effect of NAT on IKE
IKE has problems when NAT devices transparently modify outgoing
packets. The first issue is that some devices might depend on IKE
negotiation being made by incoming packets sent from UDP port 500.
If a NAT device is introduced, the final packet port will, most surely,
not be the expected port; therefore, IKE negotiation will not even
begin. Another issue comes about when IKE includes IP addresses as
part of the authentication process, which depends on which IKE mode
is used. If the authentication is based on the IP address, the changes
made by a NAT device will cause IKE negotiation to fail.
65
IPSec and NAT Solutions
The easiest way to get around IPSec issues with NAT is to avoid the
problem by performing NAT before IPSec, but this is not always
possible. In this course, you will examine other options for tackling
IPSec issues with NAT .
Solution: NAT Traversal (NAT-T)
66
NAT Traversal (NAT-T)
The IPSec NAT Traversal (NAT-T) feature introduces support for IPSec
traffic to travel through NAT points in the network. There are three
parts to NAT Traversal.
The first is to determine if the remote peer supports NAT Traversal.
• Ability to support NAT
The second is to detect the presence of a NAT function along the
path between the peers.
• To detect on NAT device
The third is to determine how to deal with NAT using UDP
encapsulation.
• Using UDP
67
Ability to support NAT
The ability of a peer to support NAT-T and detection of NAT along the
path is performed as part of the IKE phase 1 negotiation process.
NAT-T capability exchange is done in the first two messages of the
IKE phase 1 exchange with the addition of a new vendor
identification (ID) payload.
Both peers need to exchange the ID for the NAT-T support between
the peers.
Once the NAT-T capability is successfully exchanged, the
detection of NAT along the path is accomplished.
68
To detect on NAT device
To detect whether a NAT device exists along the network path, the
peers send a payload with hashes of the IP address and port of both
the source and destination address from each end.
If both ends calculate the hashes and the hashes match, each peer
knows that a NAT device does not exist on the network path between
them. If the hashes do not match (that is, if the address or port have
been translated), then each peer needs to perform NAT Traversal to
get the IPSec packet through the network.
The hashes are sent as a series of NAT-D payloads. Each payload
contains one hash. If multiple hashes exist, multiple NAT-D payloads
are sent. In most environments, there are only two NAT-D payloads
one for the source address and port and one for the destination
address and port.
69
Using UDP
The destination NAT-D payload is sent first, followed by the source
NAT-D payload, which implies that the receiver should expect to
process the local NAT-D payload first and the remote NAT-D payload
second.
The NAT-D payloads are included in the third and fourth messages in
Main Mode and in the second and third messages in Aggressive Mode.
Once the responder sends the NAT-D payload, the initiator must
change ports when sending the ID payload if there is NAT between the
hosts.
The initiator must set both UDP source and destination ports to 4500.
All subsequent packets sent to this peer must be sent on port 4500.
The changing of the port by IKE is called floating IKE.
70
Using UDP
Figure shows the IKE phase 1 exchange using pre-shared keys and
NAT-T.
71
To detect on NAT device
Similarly, if the responder needs to rekey the phase 1 SA, then it must
start the negotiation using UDP (4500,Y). Any implementation that
supports NAT traversal must support negotiations that begin on port
4500. If a negotiation starts on 4500, then it doesn't need to change
anywhere else in the exchange.
After IKE phase 1 is complete, both peers know if there is NAT
between them. The final decision of using the NAT-T is left to IKE
phase 2 (that is, Quick Mode). The use of NAT-T is negotiated inside
the SA payloads of Quick Mode. In Quick Mode, both ends can also
send the original addresses of the IPSec packets (in case of the
transport mode) to the other end such that the other end has the
possibility to fix the TCP/IP checksum field after NAT. Let's now look at
the packet format of an actual data packet once IKE and IPSec SAs
have been negotiated between the peers using UDP encapsulation.
72
To detect on NAT device
Figure shows the UDP-encapsulated ESP packet in tunnel mode.
73
Using UDP
The UDP header is a standard header where the source port and
destination port must be the same as used by floated IKE traffic. The
checksum should be transmitted as a zero value. After ESP, the UDP
header is inserted and the total length, protocol, and header checksum
is recalculated in the new IP outer header.
At the decryption end, the UDP header is first removed from the
packet and the total length, protocol, and header checksum field is
edited to match the new resulting IP packet and processed for
decryption.
One more thing worth mentioning is that most NAT devices expire the
translation after an idle period of time. To ensure that the translations
do not expire, NAT keepalive messages are sent between the peers
with a payload that resembles the one shown in Figure.
74
NAT Keep alive
To ensure that the translations do not expire, NAT keep alive
messages are sent between the peers with a payload that resembles
the one shown in Figure.
Source Port
Destination Port
Length
Checksum
Source Port
Destination Port
Length
0xFF
The only field that is different here compared to the other UDPencapsulated packets is the checksum field. The sender should use a
one-octet long payload with the value 0xFF. The receiver should ignore
a received NAT keep alive packet.
75
Example using Cisco Router
A topology with a NAT device in front of SPOKE-1-EAST is shown in
Figure below. The configuration and debugs for SPOKE-1-EAST doing
NAT-T negotiation is shown in “this link”. Peers that run IOS code that
support NAT-T automatically exchange this capability. The CLI to
control the NAT keep alive timer to disable NAT-T is also indicated in
configuration and debugs example.
76
VPN Implementation
77
Four Office Company Example
Office D
Main Office
Internet
Office B
78
Office C
Four Office Company Example
Let us now consider a small company, MDDJ, with four offices, a main
office and three remote branch offices.
Communication between these offices is confidential and needs to
be protected.
Wisely, MDDJ has decided to employ IPsec to protect this
communication but that brings up some deployment options and
issues.
Each remote office has a connection to the Internet through which
IPsec-protected packets are routed but access to the Internet need not
be granted at the remote branch offices.
Each of our deployment scenarios for MDDJ will deal with cases
where the remote offices are and are not permitted to have Internet
access. When a device has Internet access it must deal with coexistance with a firewall (see next slide).
79
Co-existance with Firewall
In this scenario of the Four Office Company, each office (remote and
main) represents part of the same company.
The trust relationship between all nodes in the VPN is assumed to
be extensive (employees have physical access to confidential
information) and not suspicious (one node does not trust another
any more or less than the rest).
Because of this trust relationship, the firewall and VPN gateway
will be in a serial configuration with the firewall connected to the
Internet and the VPN gateway connected to the protected network.
This maximizes the security at the cost of minimal firewall
configuration without opening up the protected network to an
attack that does not already exist (namely a disgruntled employee
on the protected network wrecking havoc).
80
Fully-Meshed Configuration
In a fully-meshed configuration there are peer-wise relationships
between each office and the other three offices.
For the small MDDJ network there would be six separate peer-wise
connections for the four offices. As the number of peers grows the
number of peer-wise connections grows faster.
For instance, if MDDJ had five offices there would be ten peer-wise
connections. If there were ten offices there would be forty-five
peer-wise connections.
Once we step through the (relatively) simple fully-meshed
configuration for MDDJ it should be straightforward to imagine how to
implement fully-meshed configurations for much larger networks.
81
Fully-Meshed Configuration
82
Scenario
First, let's consider a simple case where access to the global Internet
access is permitted only from the main office of MDDJ, and that all
peer-wise connections will use the same IPsec and IKE policy suites
to protect the traffic and that all traffic between the sites will be
protected—no need to restrict it to a specific upper-layer protocol.
Each remote site will be configured in a similar manner: policy to
protect traffic from its own protected network to each of the other
three protected networks will be via the gateway for that protected
network and policy for everything else will be via the gateway at the
main office.
83
Configuration
The policy language will consist of keywords (in boldface) and their
options (in italics). For example, IPsec protect policy is represented
as:
protect selector via peer using ipsec-suite establish ike-suite
which specifies what traffic to protect, to whom, how to protect it, and
how to speak IKE. IPsec permit or deny policy is represented as:
permit selector
deny selector
which specifies the traffic to permit or deny.
Now let's define the configuration options themselves. What to protect
consists of a selector which identifies a flow:
selector: address <-- --> address [ ULP [port]]
The peer is identified by an IP address or fully qualified user name:
peer: address user-fqdn
How the traffic is protected is defined as a "suite" for IPsec:
ipsec-suite: protocol authenticator [cipher] mode
How IKE is spoken is defined as a "suite" for IKE:
Ike-suite: cipher hash group auth-method
84
Configuration
Each component of these constructs can then be further defined as:
Address: W.X.Y.Z or a CIDR-style network specification
User-fqdn: email-style name ([email protected])
Protocol: AH, ESP
ULP (Upper Layer Protocol): TCP UDP
Port: a port number for an upper-layer protocol
Authenticator: HMAC-SHA, HMAC-MD5
Cipher: 3DES, AES, CAST
Mode: tunnel, transport
Hash: SHA, MD5
Group: modp-1024, modp-1536
Auth-method: pre-shared, rsa-sig
85
Configuration
Let's view a couple of examples of how to use this language:
protect 165.248/16 <-- --> 10.1.1/24
via 172.24.56.1
using ESP HMAC-SHA CAST tunnel
establish AES SHA modp-1536 pre-shared
This describes a policy to protect all traffic between the 165.248/16
network and the 10.1.1/24 network using ESP with HMAC-SHA and
CAST in tunnel mode with a peer gateway at gateway 172.24.56.1, and
to speak IKE with AES, SHA, pre-shared keys and the Diffie-Hellman
group with the 1536 bit prime modulus.
Policy to allow traffic from 165.248.23.8 to 10.1.1.74 and deny
everything else would be:
permit 165.248.23.8 <-- --> 10.1.1.74
deny 0.0.0.0 <-- --> 0.0.0.0
86
Configuration
Office A will have policy to protect traffic to office B:
protect 10.2/16 <-- --> 10.3/16
via 172.24.16.3
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
policy to protect traffic to office C:
protect 10.2/16 <-- --> 10.4/16
via 172.24.16.4
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
and policy to protect all other traffic to the main office:
protect 10.2/16 <-- --> 0.0.0.0
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
While it is not strictly necessary some may wish to have an explicit
drop rule at the end:
drop 0.0.0.0 <-- --> 0.0.0.0
87
Configuration
The other remote offices will have similar configurations with office B having
policy to office A, office C and the main office; and office C having policy to
office A, office B and the main office. The main office, though, will be different.
It has policy to protect traffic to each of the three remote offices:
protect 0.0.0.0 <-- --> 10.2/16
via 172.24.16.2
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
protect 0.0.0.0 <-- --> 10.3/16
via 172.24.16.3
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
protect 0.0.0.0 <-- --> 10.4/16
via 172.24.16.4
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
88
Configuration
remote access policy to allow Road Warriors to access the each protected
network:
protect 10.1/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 10.2/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 10.3/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 10.4/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
and an explicit permit rule to allow other traffic to be protected by a firewall:
permit 0.0.0.0 <-- --> 0.0.0.0
89
Configuration
Road warriors would need policy to protect traffic to each of the four
protected networks via the main office's gateway:
protect 0.0.0.0 <-- --> 10.1/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.2/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.3/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.4/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
90
Scenario 2
Now let's consider the case where each of the remote branch offices,
in addition to the main office, are permitted to have access to the
global Internet. This will also allow the remote access policies for each
protected network to go directly to that protected network.
There is now no difference between the remote branch office policy
and the main office policy. Each gateway defines protection from its
protected network to the three other protected networks and defines
remote access policy for its protected network.
91
Configuration
Office A will have policy to protect traffic to the main office:
protect 10.2/16 <-- --> 10.1/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
policy to protect traffic to office B:
protect 10.2/16 <-- --> 10.3/16
via 172.24.16.3
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
policy to protect traffic to office C:
protect 10.2/16 <-- --> 10.4/16
via 172.24.16.4
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
92
Configuration
policy for remote access users:
protect 10.2/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
and an explicit permit rule at the end to allow other traffic to be
protected by a firewall:
permit 0.0.0.0 <-- --> 0.0.0.0
93
Configuration
The other remote offices and the main office would all have similar policy
protecting traffic from their local protected network to each other's protected
network and an explicit permit rule at the end.
Since each protected network is permitted to access the Internet directly, Road
Warriors would have gateway-specific policy and no longer need to go through
the main office to access remote office networks:
protect 0.0.0.0 <-- --> 10.1/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.2/16
via 172.24.16.2
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.3/16
via 172.24.16.3
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.4/16
via 172.24.16.4
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
94
Configuration
Fully meshed deployments are nice because there are no extra hops
for a packet to go through to get from one protected network to
another.
Each protected network has a peering relationship with each other
protected network. On the downside they are complicated to set-up
and they don't scale well.
To add a new node to an N-node fully meshed VPN requires N separate
policy statements on the new node and one new policy statement on
the N other nodes. When N grows large, that's a lot of configuration!
95
Hub-And-Spoke Configuration
A way to minimize configuration of large VPNs is to utilize a hub-andspoke configuration. In this configuration each "spoke" has a peerwise configuration with the "hub" but not with all other "spokes". This
makes growth of the VPN more manageable as the size of the VPN
grows because adding a new node to an N-node hub-and-spoke VPN
requires a policy statement on the new "spoke" (to connect it to the
"hub") and a policy statement on the hub (to connect it to the new
"spoke"). The downside is that traffic between "spokes" must be
routed through the "hub". That means double the encapsulation and
double the cryptographic operations to protect the traffic. Network
throughput will, most likely, be affected.
A hub-and-spoke deployment at MDDJ will entail a simple and
essentially identical configuration on the three remote branch offices
(the "spokes") and a more complicated configuration on the main
office (the "hub"), see next slide.
96
Hub-And-Spoke Configuration
Office D
Main Office
Internet
Office B
97
Office C
Configuration
This topology lends itself nicely to the simple configuration—namely,
that the only Internet access is via the main office. This way all the
remote offices merely specify that all traffic is sent to the main office.
For example, office A specifies traffic from its protected network is
sent to the main office:
protect 10.2/16 <-- --> 0.0.0.0
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
Each remote office would be similarly configured. Office B would
specify traffic from its protected network, 10.3/16, etc.
98
Configuration
The main office would then have policy statements to protect traffic to
all the remote office's networks and remote access policies to allow
Road Warriors to access those networks via the main office. In fact,
the hub-and-spoke configuration on the main office's gateway (and the
Road Warrior's remote access policy) is identical to that of the fullymeshed configuration when the only Internet access was via the main
office (see above). The difference between the two is with protected
traffic between remote offices, in the fully-meshed case it was sent
directly, in the hub-and-spoke case it must go through the hub.
99
Configuration
Now, to add a new remote office all that needs to happen is to update
the main office gateway's policy to include a statement to the new
office. Retaining our convention, let's assume the new network is
10.5/16 and the gateway is 172.24.16.5. The new policy added to the
main office gateway would therefore be:
protect 0.0.0.0 <-- --> 10.5/16
via 172.24.16.5
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
100
Configuration
and the new office would require the following policy statement:
protect 10.5/16 <-- --> 0.0.0.0
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
In addition, remote access Road Warriors would need to obtain
updated policy to obtain access to this new protected network:
protect 0.0.0.0 <-- -->10.5/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
But no configuration of the other remote offices—offices A-C—is
needed. When the number of remote offices is large it is easy to see
the benefit to using a hub-and-spoke set-up instead of a fully-meshed
set-up.
101
Configuration
If we wish to allow each remote office to access the Internet directly
but retain our hub-and-spoke configuration for ease of growth each
remote office would need policy for each protected network, including
the new one, via the main office gateway and an explicit permit policy
statement to pass non-VPN traffic to a firewall. It should not be hard to
see what is happening. We have just lost the benefit of the hub-andspoke configuration—addition of a new office now requires all other
offices to be reconfigured!
102
Summary
Deploying IPSec on a network requires care. One must always keep in
mind the threat that IPSec is being deployed to counter against. That
can influence how VPN gateways and firewalls interact and can also
dictate what sort of access is allowed. When supporting remote
access it is important to keep in mind that policies are no longer
symmetric, and that quite often a certification authority will be needed
to bind user's identities to public keys.
Some of the configurations for the various deployment scenarios we
discussed are very similar, even though the network to be protected
and the threats to be protected against were all quite different. It is
important, though, to keep in mind that when planning and designing
a secure network one must look at the needs and the threat to develop
the model and produce the configuration, not the other way around. It
is possible (and less work) to take an existing configuration and
shoehorn in the network design, but that would most likely result in
unforeseen scaling problems at best and security flaws at worst.
103
How Do You Want Protect Your Network System
Thank You
See You Next Week
104