IP SECURITY POLICY
Fundamental to the operation of IPsec is the concept of a
security policy applied to each IP packet that transits from a source to a destination. IPsec policy is determined primarily by the interaction of two databases, the security association database
(SAD) and the
security
policy
database (SPD). This section provides
an overview of these two databases and then summarizes their use during
IPsec operation. Figure 19.2 illustrates the relevant relationships.
Security Associations
A key concept that appears in both the
authentication and confidentiality mecha- nisms for IP is the security
association (SA). An association is a one-way
logical con- nection between
a sender and a receiver that affords security services to the traffic carried on it. If a peer relationship is needed for two-way secure
exchange, then two security associations are required.
Security services are afforded to an SA for the use of AH or ESP, but not both.
A security association is uniquely
identified by three parameters.
•
Security Parameters Index
(SPI): A bit string
assigned to this
SA and having local significance only. The SPI is carried in AH and ESP headers
to enable the receiving
system to select the SA under
which a received packet will be processed.
•
IP Destination Address: This is the address of the destination endpoint of the SA,
which may be an end-user
system or a network system
such as a firewall or router.
•
Security
Protocol Identifier: This field from the
outer IP header indicates whether the association is an AH or ESP security association.
Hence, in any IP packet,
the security association is uniquely identified by the Destination
Address in the IPv4 or IPv6 header and the SPI in the enclosed exten- sion header (AH or ESP).
Security Association Database
In each IPsec implementation, there is a
nominal2 Security
Association Database that defines the parameters associated with each SA. A security
association is nor- mally defined by the following parameters in an SAD entry.
•
Security Parameter Index: A 32-bit
value selected by the receiving end of an SA
to uniquely identify
the SA. In an SAD entry for an outbound
SA, the SPI is used to construct the packet’s AH or ESP header. In an
SAD entry for an inbound SA, the SPI is used to map traffic
to the appropriate SA.
•
Sequence Number Counter: A
32-bit value used to generate the Sequence Number field in AH or ESP headers, described in Section 19.3 (required for all
implementations).
•
Sequence Counter Overflow: A flag indicating
whether overflow of the Sequence
Number Counter should generate an auditable event and prevent further transmission of packets on this SA (required for all implementations).
•
Anti-Replay Window: Used to determine
whether an inbound AH or ESP packet is a replay, described in Section 19.3 (required for all implementations).
•
AH Information: Authentication
algorithm, keys, key lifetimes, and related parameters being used with AH (required for AH implementations).
•
ESP Information: Encryption
and authentication algorithm, keys, initializa-
tion values, key lifetimes, and related
parameters being used with ESP (required
for ESP implementations).
•
Lifetime of this Security
Association: A time interval
or byte count after which an SA must be replaced with a
new SA (and new SPI) or terminated, plus an
indication of which of these actions should
occur (required for all implementations).
•
IPsec Protocol Mode: Tunnel, transport, or wildcard.
•
Path MTU: Any
observed path maximum transmission unit (maximum size of a packet that can be transmitted without
fragmentation) and aging variables (required for all implementations).
The key management mechanism that is used to distribute keys
is coupled to the authentication and privacy mechanisms only by way of the Security Parameters Index (SPI). Hence, authentication and privacy have been specified
independent of any specific key management mechanism.
IPsec provides the user with considerable flexibility in the way in which
IPsec services are applied to IP traffic. As we will see later, SAs can
be combined in a number of ways to yield
the desired user configuration. Furthermore, IPsec provides a high degree of granularity in discriminating between
traffic that is afforded IPsec protection and traffic that is allowed
to bypass IPsec, as in the former case relating IP traffic to specific SAs.
Security Policy Database
The means by which
IP traffic is related to specific SAs
(or no SA in the
case of traffic allowed to bypass IPsec)
is the nominal Security Policy Database
(SPD). In its sim- plest form, an SPD contains entries, each of which
defines a subset
of IP traffic and points to an SA for that traffic.
In more complex
environments, there
may be multiple
entries that potentially relate to a single SA or multiple
SAs associated with a single SPD entry. The reader
is referred to the relevant IPsec documents for
a full discussion. Each SPD entry is defined by a set of IP and upper-layer protocol field values, called selectors. In effect, these
selectors are used
to filter outgoing traffic in order
to map it into a
particular SA. Outbound processing obeys the following general
sequence for each IP packet.
1.
Compare the values of the appropriate fields in the packet (the selector fields) against
the SPD to find a matching SPD entry, which will point to zero or more SAs.
2.
Determine the SA if any for this packet
and its associated SPI.
3.
Do the required IPsec
processing (i.e., AH or ESP processing).
The
following selectors determine an SPD entry:
•
Remote IP Address: This may be a single IP address,
an enumerated list or range
of addresses, or a wildcard
(mask) address. The latter two are required to support more than one destination system sharing the same SA (e.g., behind a firewall).
•
Local IP Address: This may be a single
IP address, an enumerated list or range of
addresses, or a wildcard (mask) address.
The latter two are required to sup-
port more than one source
system sharing the
same SA (e.g., behind
a firewall).
•
Next Layer Protocol: The IP protocol
header (IPv4, IPv6,
or IPv6 Extension) includes a field (Protocol for
IPv4, Next Header for IPv6 or IPv6 Extension) that designates the protocol
operating over IP. This is an
individual protocol number, ANY, or for IPv6 only, OPAQUE. If AH or ESP is used, then this IP protocol header immediately precedes
the AH or ESP header in the packet.
•
Name: A user identifier from the operating
system. This is not a field in the IP or upper-layer headers
but is available if IPsec is running
on the same operat- ing system
as the user.
•
Local and Remote Ports: These may be individual TCP or UDP port values, an enumerated list of ports, or a wildcard
port.
Table 19.2 provides an example of an SPD on a host system (as
opposed to a network system
such as a firewall or router). This
table reflects the following config- uration: A local network
configuration consists of two networks. The basic
corporate network configuration has the IP network number 1.2.3.0/24. The local
configura- tion also includes a secure LAN, often known as a DMZ, that is
identified as 1.2.4.0/24. The DMZ
is protected from both the outside world and the rest of the corporate LAN by
firewalls. The host in this example
has the IP address 1.2.3.10, and it is authorized to connect to the server 1.2.4.10 in the DMZ.
The entries in the SPD should be self-explanatory. For example,
UDP port 500 is the designated port for IKE. Any
traffic from the local host to a remote host for purposes of an IKE exchange bypasses
the IPsec processing.
IP Traffic Processing
IPsec is executed on a packet-by-packet
basis. When IPsec is implemented, each outbound IP packet is processed by the
IPsec logic before transmission, and each inbound packet is processed by the
IPsec logic after reception and before passing the packet contents on to the
next higher layer (e.g., TCP or UDP).
We look at the logic of these two
situations in turn.
OUTBOUND PACKETS Figure
19.3 highlights the main elements of IPsec processing for outbound traffic. A block of data from a
higher layer, such as TCP, is passed down
to the IP layer and an IP packet is formed, consisting of an IP header and
an IP body.
Then the following steps occur:
1.
IPsec searches
the SPD for a match
to this packet.
2.
If no match is
found, then the packet is discarded and an error message is generated.
1.
If a match is found, further
processing is determined by the first matching
entry in the SPD. If the policy for this packet
is DISCARD, then the packet is
discarded. If the policy is BYPASS, then there is no further IPsec processing;
the packet is forwarded to the network for transmission.
2.
If the policy is PROTECT,
then a search is made of the SAD for a matching entry. If no entry is found,
then IKE is invoked to create
an SA with the appro- priate keys and an entry is made in the SA.
3.
The matching entry in the SAD
determines the processing for this packet. Either encryption, authentication,
or both can be performed, and either transport
or tunnel mode can be used. The packet
is then forwarded to the network for transmission.
INBOUND PACKETS Figure 19.4 highlights the main elements of IPsec
processing for inbound traffic. An incoming IP packet triggers the IPsec
processing. The following steps occur:
IPsec determines
whether this is an unsecured IP packet or one that has ESP or AH headers/trailers,
by examining the IP Protocol field (IPv4) or Next Header field (IPv6).
1.
If the packet
is unsecured, IPsec searches
the SPD for a match to this packet. If the first matching
entry has a policy of BYPASS,
the IP header is processed and stripped off and the packet
body is delivered
to the next higher layer, such as TCP. If the first matching entry has a policy of PROTECT or DISCARD, or if
there is no matching entry, the packet is discarded.
2.
For a secured packet, IPsec
searches the SAD. If no match is
found, the packet is discarded.
Otherwise, IPsec applies the appropriate ESP or AH processing. Then,
the IP header is processed
and stripped off and the packet
body is delivered to the next higher
layer, such as TCP.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.