2 IP Security OverviewWe have considered some application specific security mechanismseg. S/MIME, PGP, Kerberos, SSL/HTTPSHowever there are security concerns that cut across protocol layersWould like security implemented by the network for all applications
3 Security versus OSI & TCP/IP Model ApplicationApplicationApplicationApplicationsPresentationPresentationSessionTransportTransportProtocolNetworkInternetData LinkData LinkPhysicalPhysicalCryptography33
4 Security Flows Protocol Applications Protocol: SSL, TLS, IPSec Web, , any application use securitymechanismCryptographyAlgorithm:Symmetric, Asymmetric (i.e.:Cipher, DES, AES)* This approach is totally under my knowledge and experience, is not a standard, just to understandthe layer concept.44
5 IP Security OverviewIPSec 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.
7 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.
8 IPSec general IP Security mechanisms provides authenticationconfidentialitykey managementapplicable to use over LANs, across public & private WANs, & for the Internet
9 IP Security Overview Applications of IPSec Secure branch office connectivity over the InternetSecure remote access over the InternetEstablsihing extranet and intranet connectivity with partnersEnhancing electronic commerce security
11 Benefits of IPSecin a firewall/router provides strong security to all traffic crossing the perimeteris resistant to bypassis below transport layer, hence transparent to applicationscan be transparent to end userscan provide security for individual users if desired
12 IP Security Architecture specification is quite complexdefined in numerous RFC’sincl. RFC 2401/2402/2406/2408many others, grouped by categorymandatory in IPv6, optional in IPv4
13 IPSec Services Access control Connectionless integrity Data origin authenticationRejection of replayed packetsa form of partial sequence integrityConfidentiality (encryption)Limited traffic flow confidentiality
15 Why do we want to use IPSec? Secure our networkTransparent operationIPSec 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
17 Why not use IPSec?Processor overhead to encrypt & verify each packet can be great.Added complexity in network design.
18 IPSec Diagram Structure Data ProtocolsIKEESPAHIPsec can be used for:- two hosts- two security gateways- a host and security gatewayControl ProtocolsIKE – Internet Key ExchangeESP – Encapsulating Security PayloadAH – Authentication Header
19 IPSec Diagram Structure IKE (ISAKMP)Connection SecurityDES3DESMD5Key Exchange(Oakley, SKEME)AuthenticationDiffle HellmanEncryptionDigitalSignatureSharedSecretMessageIntegritySHA-1
20 IPSec Diagram Structure Data ProtocolsESPNullDESMD5AHEncryptionIntegritySHA-13DES
21 IPSec ModesTransport – 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.
34 ESP provides source authentication, data integrity, and privacy. NoteESP provides source authentication, data integrity, and privacy.
35 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.
36 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 modeEncryption algorithm and algorithm modeKey(s) used with the authentication/encryption algorithm(s)Lifetime of the keyLifetime of the SASource Address(es) of the SASensitivity level (ie Secret or Unclassified)
37 ExampleA 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 two-way 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 for both Alice and Bob.
38 ExampleThe 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.
39 How IPSec works: Phase 1Internet Key Exchange (IKE) is used to setup IPSec.IKE Phase 1:Establishes a secure, authenticated channel between the two computersAuthenticates and protects the identities of the peersNegotiates what SA policy to usePerforms an authenticated shared secret keys exchangeSets up a secure tunnel for phase 2Two modes: Main mode or Aggressive modeMain Mode IKENegotiate algorithms & hashes.Generate shared secret keys using a Diffie-Hillman exchange.Verification of Identities.Aggressive Mode IKESqueezes 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.
40 How IPSec works: Phase 2An AH or ESP packet is then sent using the agreed upon “main” SA during the IKE phase 1.IKE Phase 2Negotiates IPSec SA parametersEstablishes IPSec security associations for specific connections (like FTP, telnet, etc)Renegotiates IPSec SAs periodicallyOptionally performs an additional Diffie-Hellman exchange
41 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.
42 QuestionCan IPSec using AH be used in transport mode if one of the machines is behind a NAT box? Explain your answer.
43 QuestionCan 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.
44 Security Associations a one-way relationship between sender & receiver that affords security for traffic flowdefined by 3 parameters:Security Parameters Index (SPI)IP Destination AddressSecurity Protocol Identifierhas a number of other parametersseq no, AH & EH info, lifetime etchave a database of Security Associations
45 Authentication Header (AH) provides support for data integrity & authentication of IP packetsend system/router can authenticate user/appprevents address spoofing attacks by tracking sequence numbersbased on use of a MACHMAC-MD5-96 or HMAC-SHA-1-96parties must share a secret key
48 Encapsulating Security Payload (ESP) provides message content confidentiality & limited traffic flow confidentialitycan optionally provide the same authentication services as AHsupports range of ciphers, modes, paddingincl. DES, Triple-DES, RC5, IDEA, CAST etcCBC most commonpad to meet blocksize, for traffic flow
50 Transport vs Tunnel Mode ESP transport mode is used to encrypt & optionally authenticate IP datadata protected but header left in clearcan do traffic analysis but is efficientgood for ESP host to host traffictunnel mode encrypts entire IP packetadd new header for next hopgood for VPNs, gateway to gateway security
51 Combining Security Associations SA’s can implement either AH or ESPto implement both need to combine SA’sform a security bundlehave 4 cases (see next)
53 Question Why does IPSec need a security association? Stallings Fig
54 handles key generation & distribution typically need 2 pairs of keys Key Managementhandles key generation & distributiontypically need 2 pairs of keys2 per direction for AH & ESPmanual key managementsysadmin manually configures every systemautomated key managementautomated system for on demand creation of keys for SA’s in large systemshas Oakley & ISAKMP elements
55 Oakley a key exchange protocol based on Diffie-Hellman key exchange adds features to address weaknessescookies, groups (global params), nonces, DH key exchange with authenticationcan use arithmetic in prime fields or elliptic curve fields
56 ISAKMP Internet Security Association and Key Management Protocol provides framework for key managementdefines procedures and packet formats to establish, negotiate, modify, & delete SAsindependent of key exchange protocol, encryption alg, & authentication method
61 IPSec & NATNetwork 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.
62 Effect of NAT on AHAH 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.
64 Effect of NAT on ESPLike 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.
65 Effect of NAT on IKEIKE 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.
66 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)
67 NAT Traversal (NAT-T) Ability to support NAT To detect on NAT device 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 NATThe second is to detect the presence of a NAT function along the path between the peers.To detect on NAT deviceThe third is to determine how to deal with NAT using UDP encapsulation.Using UDP
68 Ability to support NATThe 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.
69 To detect on NAT deviceTo 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.
70 Using UDPThe 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 All subsequent packets sent to this peer must be sent on port The changing of the port by IKE is called floating IKE.
71 Using UDPFigure shows the IKE phase 1 exchange using pre-shared keys and NAT-T.
72 To detect on NAT deviceSimilarly, 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 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.
73 To detect on NAT deviceFigure shows the UDP-encapsulated ESP packet in tunnel mode.
74 Using UDPThe 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.
75 NAT Keep aliveTo 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.The only field that is different here compared to the other UDP-encapsulated 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.Source PortDestination PortLengthChecksum0xFF
76 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.
78 Four Office Company Example Office DMain OfficeInternetOffice BOffice C
79 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 co-existance with a firewall (see next slide).
80 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).
81 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.
83 ScenarioFirst, 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.
84 ConfigurationThe 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-suitewhich 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 selectordeny selectorwhich 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-fqdnHow the traffic is protected is defined as a "suite" for IPsec:ipsec-suite: protocol authenticator [cipher] modeHow IKE is spoken is defined as a "suite" for IKE:Ike-suite: cipher hash group auth-method
85 ConfigurationEach component of these constructs can then be further defined as:Address: W.X.Y.Z or a CIDR-style network specificationUser-fqdn: -style nameProtocol: AH, ESPULP (Upper Layer Protocol): TCP UDPPort: a port number for an upper-layer protocolAuthenticator: HMAC-SHA, HMAC-MD5Cipher: 3DES, AES, CASTMode: tunnel, transportHash: SHA, MD5Group: modp-1024, modp-1536Auth-method: pre-shared, rsa-sig
86 ConfigurationLet's view a couple of examples of how to use this language:protect /16 <-- --> 10.1.1/24 via using ESP HMAC-SHA CAST tunnel establish AES SHA modp-1536 pre-sharedThis describes a policy to protect all traffic between the /16 network and the /24 network using ESP with HMAC-SHA and CAST in tunnel mode with a peer gateway at gateway , 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 to and deny everything else would be:permit <-- --> deny <-- -->
87 ConfigurationOffice A will have policy to protect traffic to office B:protect 10.2/16 <-- --> 10.3/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-sharedpolicy to protect traffic to office C:protect 10.2/16 <-- --> 10.4/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-sharedand policy to protect all other traffic to the main office:protect 10.2/16 <-- --> via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-sharedWhile it is not strictly necessary some may wish to have an explicit drop rule at the end:drop <-- -->
88 ConfigurationThe 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 <-- --> 10.2/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-shared protect <-- --> 10.3/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-shared protect <-- --> 10.4/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-shared
89 Configurationremote access policy to allow Road Warriors to access the each protected network:protect 10.1/16 <-- --> via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig protect 10.2/16 <-- --> via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig protect 10.3/16 <-- --> via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig protect 10.4/16 <-- --> via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sigand an explicit permit rule to allow other traffic to be protected by a firewall:permit <-- -->
90 ConfigurationRoad warriors would need policy to protect traffic to each of the four protected networks via the main office's gateway:protect <-- --> 10.1/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig protect <-- --> 10.2/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig protect <-- --> 10.3/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig protect <-- --> 10.4/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig
91 Scenario 2Now 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.
92 ConfigurationOffice A will have policy to protect traffic to the main office:protect 10.2/16 <-- --> 10.1/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-sharedpolicy to protect traffic to office B:protect 10.2/16 <-- --> 10.3/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-sharedpolicy to protect traffic to office C:protect 10.2/16 <-- --> 10.4/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-shared
93 Configuration policy for remote access users: protect 10.2/16 <-- --> via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sigand an explicit permit rule at the end to allow other traffic to be protected by a firewall:permit <-- -->
94 ConfigurationThe 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 <-- --> 10.1/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig protect <-- --> 10.2/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig protect <-- --> 10.3/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig protect <-- --> 10.4/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sig
95 ConfigurationFully 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!
96 Hub-And-Spoke Configuration A way to minimize configuration of large VPNs is to utilize a hub-and-spoke configuration. In this configuration each "spoke" has a peer-wise 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.
97 Hub-And-Spoke Configuration Office DMain OfficeInternetOffice BOffice C
98 ConfigurationThis 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 <-- --> via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-sharedEach remote office would be similarly configured. Office B would specify traffic from its protected network, 10.3/16, etc.
99 ConfigurationThe 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 fully-meshed 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.
100 ConfigurationNow, 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 The new policy added to the main office gateway would therefore be:protect <-- --> 10.5/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-shared
101 Configurationand the new office would require the following policy statement:protect 10.5/16 <-- --> via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 pre-sharedIn addition, remote access Road Warriors would need to obtain updated policy to obtain access to this new protected network:protect <-- -->10.5/16 via using ESP HMAC-SHA AES tunnel establish CAST SHA modp-1536 rsa-sigBut 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.
102 ConfigurationIf 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-and-spoke configuration—addition of a new office now requires all other offices to be reconfigured!
103 SummaryDeploying 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.
104 Thank You See You Next Week How Do You Want Protect Your Network System
Your consent to our cookies if you continue to use this website.