IPSec is a framework for ensuring secure private
communication over IP networks and is based on standards developed
by the International Engineering Task Force (IETF). IPsec provides
security services at the network layer of the Open Systems Interconnection
(OSI) model by enabling a system to select required security protocols,
determine the algorithms to use for the security services, and implement
any cryptographic keys required to provide the requested services.
You can use IPsec to protect one or more paths between a pair of hosts,
between a pair of security gateways (such as routing platforms), or
between a security gateway and a host.
The terminology and components of IPSec can be
intimidating to first-time users. However, if you learn a few key
concepts, you can quickly master and deploy IPSec in your network.
The main concepts you need to understand are as follows:
The first choice you need to make when implementing
IPSec on a JUNOS software-based routing platform is the type of Physical
Interface Card (PIC) you wish to use. There are three types of PICs
available for M-series and T-series platforms:
The ES PIC is a first-generation PIC that provides encryption
services and software support for IPSec.
The Adaptive Services (AS) PIC is a next-generation PIC
that provides IPSec services and other services, such as Network Address
Translation (NAT) and stateful firewall.
The AS II Federal Information Processing Standards (FIPS)
PIC is a special version of the AS PIC that communicates securely
with the Routing Engine by using internal IPSec. You must configure
IPSec on the AS II FIPS PIC when you enable FIPS mode on the routing
platform. For more information about implementing IPSec on an AS II
FIPS PIC installed in a routing platform configured in FIPS mode,
see the Secure Configuration Guide for Common Criteria and
JUNOS-FIPS.
The MultiServices PICs supply hardware acceleration for
an array of packet processing-intensive services in the M-series and
T-series routers. These services include IPSec services and other
services, such as stateful firewall, NAT, IPSec, anomaly detection,
and tunnel services.
The J-series Services Routers also perform IPSec
services in a manner similar to the AS and MultiServices PICs. However,
the J-series Services Routers do this using the JUNOS software without
a corresponding PIC. For more information about implementing IPSec
on a J-series Services Router, see the J-series Services
Router Advanced WAN Access Configuration Guide.
Authentication Algorithms
Authentication is the process of verifying the
identity of the sender. Authentication algorithms use a shared key
to verify the authenticity of the IPSec devices. The JUNOS software
uses the following authentication algorithms:
Message Digest 5 (MD5) uses a one-way hash function to
convert a message of arbitrary length to a fixed-length message digest
of 128 bits. Because of the conversion process, it is mathematically
infeasible to calculate the original message by computing it backwards
from the resulting message digest. Likewise, a change to a single
character in the message will cause it to generate a very different
message digest number.
To verify that the message has not been tampered
with, the JUNOS software compares the calculated message digest against
a message digest that is decrypted with a shared key. The JUNOS software
uses the MD5 hashed message authentication code (HMAC) variant that
provides an additional level of hashing. MD5 can be used with authentication
header (AH), Encapsulating Security Payload (ESP), and Internet Key
Exchange (IKE).
Secure Hash Algorithm 1 (SHA-1) uses a stronger algorithm
than MD5. SHA-1 takes a message of less than 264 bits in length and
produces a 160-bit message digest. The large message digest ensures
that the data has not been changed and that it originates from the
correct source. The JUNOS software uses the SHA-1 HMAC variant that
provides an additional level of hashing. SHA-1 can be used with AH,
ESP, and IKE.
SHA-256, SHA-384, and SHA-512 (sometimes grouped under
the name SHA-2) are variants of SHA-1 and use longer message digests.
The JUNOS software supports the SHA-256 version of SHA-2, which can
process all versions of Advanced Encryption Standard (AES), Data Encryption
Standard (DES), and Triple DES (3DES) encryption.
Encryption Algorithms
Encryption encodes data into a secure format so
that it cannot be deciphered by unauthorized users. Like authentication
algorithms, a shared key is used with encryption algorithms to verify
the authenticity of the IPSec devices. The JUNOS software uses the
following encryption algorithms:
Data Encryption Standard cipher-block chaining (DES-CBC)
is a symmetric secret-key block algorithm. DES uses a key size of
64 bits, where 8 bits are used for error detection and the remaining
56 bits provide encryption. DES performs a series of simple logical
operations on the shared key, including permutations and substitutions.
CBC takes the first block of 64 bits of output from DES, combines
this block with the second block, feeds this back into the DES algorithm,
and repeats this process for all subsequent blocks.
Triple DES-CBC (3DES-CBC) is an encryption algorithm that
is similar to DES-CBC, but provides a much stronger encryption result
because it uses three keys for 168-bit (3 x 56-bit) encryption. 3DES
works by using the first key to encrypt the blocks, the second key
to decrypt the blocks, and the third key to reencrypt the blocks.
Advanced Encryption Standard (AES) is a next-generation
encryption method based on the Rijndael algorithm developed by Belgian
cryptographers Dr. Joan Daemen and Dr. Vincent Rijmen. It uses a 128-bit
block and three different key sizes (128, 192, and 256 bits). Depending
on the key size, the algorithm performs a series of computations (10,
12, or 14 rounds) that include byte substitution, column mixing, row
shifting, and key addition. The use of AES in conjunction with IPSec
is defined in RFC 3602, The AES-CBC Cipher Algorithm and
Its Use with IPsec.
IPSec Protocols
IPSec protocols determine the type of authentication
and encryption applied to packets that are secured by the routing
platform. The JUNOS software supports the following IPSec protocols:
AH—Defined in RFC 2402, AH provides connectionless
integrity and data origin authentication for IPv4 and IPv6 packets.
It also provides protection against replays. AH authenticates as much
of the IP header as possible, as well as the upper-level protocol
data. However, some IP header fields may change in transit. Because
the value of these fields may not be predictable by the sender, they
cannot be protected by AH. In an IP header, AH can be identified with
a value of 51 in the Protocol field of an IPv4 packet
and the Next Header field of an IPv6 packet. An example of
the IPSec protection offered by AH is shown in Figure 62.
Note:
AH is not supported on the T-series, M120, and
M320 routing platforms.
Figure 62: AH Protocol
ESP—Defined in RFC 2406, ESP can provide encryption
and limited traffic flow confidentiality, or connectionless integrity,
data origin authentication, and an anti-replay service. In an IP header,
ESP can be identified a value of 50 in the Protocol field of an IPv4 packet and the Next Header field of an
IPv6 packet. An example of the IPSec protection offered by ESP is
shown in Figure 63.
Figure 63: ESP Protocol
Bundle—When you compare AH with ESP, there are some
benefits and shortcomings in both protocols. ESP provides a decent
level of authentication and encryption, but does so only for part
of the IP packet. Conversely, although AH does not provide encryption,
it does provide authentication for the entire IP packet. Because of
this, the JUNOS software offers a third form of IPSec protocol called
a protocol bundle. The bundle option offers a hybrid combination of
AH authentication with ESP encryption.
Security Associations
Another IPSec consideration is the type of security
association (SA) that you wish to implement. An SA is a set of IPSec
specifications that are negotiated between devices that are establishing
an IPSec relationship. These specifications include preferences for
the type of authentication, encryption, and IPSec protocol that should
be used when establishing the IPSec connection. An SA can be either
unidirectional or bidirectional, depending on the choices made by
the network administrator. An SA is uniquely identified by a Security
Parameter Index (SPI), an IPv4 or IPv6 destination address, and a
security protocol (AH or ESP) identifier.
You can configure IPSec with a preset, preshared
manual SA or use IKE to establish a dynamic SA. Manual SAs require
you to specify all the IPSec requirements up front. Conversely, IKE
dynamic SAs typically contain configuration defaults for the highest
levels of authentication and encryption.
IPSec Modes
The last major consideration is the type of IPSec
mode you wish to implement in your network. The JUNOS software supports
the following IPSec modes:
Tunnel mode is supported for both AH and ESP in the JUNOS
software and is the usual choice for a routing platform. In tunnel
mode, the SA and associated protocols are applied to tunneled IPv4
or IPv6 packets. For a tunnel mode SA, an outer IP header specifies
the IPsec processing destination, and an inner IP header specifies
the ultimate destination for the packet. The security protocol header
appears after the outer IP header, and before the inner IP header.
In addition, there are slight differences for tunnel mode when you
implement it with AH and ESP:
For AH, portions of the outer IP header are protected,
as well as the entire tunneled IP packet.
For ESP, only the tunneled packet is protected, not the
outer header.
When one side of a security association
is a security gateway (such as a routing platform), the SA must use
tunnel mode. However, when traffic (for example, SNMP commands or
BGP sessions) is destined for a routing platform, the system acts
as a host. Transport mode is allowed in this case because the system
does not act as a security gateway and does not send or receive transit
traffic.
Transport mode provides a security association between
two hosts. In transport mode, the protocols provide protection primarily
for upper layer protocols. For IPv4 and IPv6 packets, a transport
mode security protocol header appears immediately after the IP header
and any options, and before any higher layer protocols (for example,
TCP or UDP). There are slight differences for transport mode when
you implement it with AH and ESP:
For AH, selected portions of the IP header are protected,
as well as selected portions of the extension headers and selected
options within the IPv4 header.
For ESP, only the higher layer protocols are protected,
not the IP header or any extension headers preceding the ESP header.
Digital Certificates
For small networks, the use of preshared keys in
an IPSec configuration is often sufficient. However, as a network
grows, it can become a challenge to add new preshared keys on the
local routing platform and all new and existing IPSec peers. One solution
for scaling an IPSec network is to use digital certificates.
A digital certificate implementation uses the public
key infrastructure (PKI), which requires you to generate a key pair
consisting of a public key and a private key. The keys are created
with a random number generator and are used to encrypt and decrypt
data. In networks that do not use digital certificates, an IPSec-enabled
device encrypts data with the private key and IPSec peers decrypt
the data with the public key.
With digital certificates, the key sharing process
requires an additional level of complexity. First, you and your IPSec
peers request a certificate authority (CA) to send you a CA certificate
that contains the public key of the CA. Next, you request the CA to
enroll a local digital certificate that contains your public key and
some additional information. When the CA processes your request, it
signs your local certificate with the private key of the CA. Then
you install the CA certificate and the local certificate in your local
routing platform and load the CA certificate in the remote devices
before you can establish IPSec tunnels with your peers.
When you request a peering relationship with an
IPSec peer, the peer receives a copy of your local certificate. Because
the peer already has the CA certificate loaded, it can use the CA’s
public key contained in the CA certificate to decrypt your local certificate
that has been signed by the CA’s private key. As a result, the
peer now has a copy of your public key. The peer encrypts data with
your public key before sending it to you. When your local routing
platform receives the data, it decrypts the data with your private
key.
In the JUNOS software, you must implement the following
steps to be able to initially use digital certificates:
Configure a CA profile to request CA and local digital
certificates—The profile contains the name and URL of the CA
or registration authority (RA), as well as some retry timer settings.
Configure Certificate Revocation List support—A
certificate revocation list (CRL) contains a list of certificates
canceled before their expiration date. When a participating peer uses
a CRL, the CA acquires the most recently issued CRL and checks the
signature and validity of a peer’s digital certificate. You
can request and load CRLs manually, configure an LDAP server to handle
CRL processing automatically, or disable CRL processing that is enabled
by default.
Request a digital certificate from the CA—The request
can be made either online or manually. Online CA digital certificate
requests use the Simple Certificate Enrollment Protocol (SCEP) format.
If you request the CA certificate manually, you must also load the
certificate manually.
Generate a private/public key pair—The public key
is included in the local digital certificate and the private key is
used to decrypt data received from peers.
Generate and enroll a local digital certificate—The
local certificate can be processed online using SCEP or generated
manually in the Public-Key Cryptography Standards #10 (PKCS-10) format.
If you create the local certificate request manually, you must also
load the certificate manually.
Apply the digital certificate to an IPSec configuration—To
activate a local digital certificate, you configure the IKE proposal
to use digital certificates instead of preshared keys, reference the
local certificate in the IKE policy, and identify the CA in the service
set.
Optionally, you can do the following:
Configure the digital certificate to automatically reenroll—Starting
in JUNOS Release 8.5, you can configure automatic reenrollment for
digital certificates.
Monitor digital certificate events and delete certificates
and requests—You can issue operational mode commands to monitor
IPSec tunnels established using digital certificates and delete certificates
or requests.
The Adaptive Services PIC supports two types of
service sets when you configure IPSec tunnels. Because they are used
for different purposes, it is important to know the differences between
these service set types.
Next-hop service set—Supports multicast and multicast-style
dynamic routing protocols (such as OSPF) over IPSec. Next-hop service
sets allow you to use inside and outside logical interfaces on the Adaptive Services PIC to connect with
multiple routing instances. They also allow the use of Network Address
Translation (NAT) and stateful firewall capabilities. However, next-hop
service sets do not monitor Routing Engine traffic by default and
require configuration of multiple service sets to support traffic
from multiple interfaces.
Interface service set—Applied to a physical interface
and similar to a stateless firewall filter. They are easy to configure,
can support traffic from multiple interfaces, and can monitor Routing
Engine traffic by default. However, they cannot support dynamic routing
protocols or multicast traffic over the IPSec tunnel.
In general, we recommend that you use next-hop
service sets because they support routing protocols and multicast
over the IPSec tunnel, they are easier to understand, and the routing
table makes forwarding decisions without administrative intervention.
