Tải bản đầy đủ
2 The Policy Problem 187

2 The Policy Problem 187

Tải bản đầy đủ

188

Demystifying the IPsec Puzzle

protected but not encrypted, individual hosts can require encryption as well.
Of course, adding more stringent policy requirements can result in preventing communications with entities not equipped to meet those demands. On
the other hand, some companies might want to dictate policy and not allow
clients to change it; they might require that all traffic be IPsec-protected and
all traffic be routed through a security gateway.
9.2.2

Policy Servers

If IPsec policy is to be centrally distributed and administered, a new entity
can be injected into the equation: a policy server. This entity is either a security gateway that also assumes those functions or a separate host dedicated to
its policy functions. The policy server knows which hosts it is responsible for.
Its policy-related information is configured by a network administrator. That
information is then distributed to the network hosts for which the policy
server is responsible, to the hosts’ potential peers, or to both. All policyrelated information affecting a local host can be distributed to that host at
boot time, when policy changes occur, or as the result of a query. More limited information can be sent to a nonlocal host that wishes to communicate
with a local host; that action will always result from a query.
If the policy server resides within a protected network, communications with local hosts that also reside within the same network can be unprotected. But communications with road warriors that are physically located
outside the network and receive their policy instructions from the policy
server must be protected. Communications with potential peers must be
authenticated and, possibly, encrypted as well. In addition, the gateway’s
SPD must contain rules that allow policy-related queries to reach the policy
server and allow policy-related responses to exit the gateway.
There currently is no clear consensus regarding protection of policyrelated communications. On the one hand, potential peers need to know the
policy server’s location and need to be able to query the policy server. On the
other hand, revealing too much network-related and policy-related information can increase the network’s vulnerability to attacks.
9.2.3

Gateway Discovery

When a host sets off on the journey toward IPsec-protected communications, a number of factors not under the host’s control can facilitate or
impede that journey. Before an IKE negotiation can proceed, a host needs to
know whether its peer is empowered to conduct its own IKE negotiations

The Missing Puzzle Piece: Policy Setting and Enforcement

189

and provide its own IPsec protections, or whether those protections will be
provided by one or more security gateways. In the latter case, it must be able
to determine the location and identity of the gateways.
A host may be ignorant of the location of its own security gateways.
That can happen in a complex, multilayered network or because of changes
to network topology. In such cases, gateway discovery necessitates the identification of all security gateways that lie between a host and its peer, whether
those gateways provide IPsec protection for the initiating host or for the peer.
There are a number of facets to security gateway discovery.
• Locating the security gateway. This can be done either directly or indi-

rectly. A query can be directed to a policy server or a secure DNS
repository, which then responds with the security gateway’s address.
Alternatively, some sort of gateway probe message can be sent to the
peer and intercepted by the gateway. The gateway can then respond
with its address. There is a dichotomy inherent in this type of
exchange. On the one hand, allowing bona fide peers to discover
the identity of a network’s security gateway is an essential enabler
for secure communications. On the other hand, handing out that
information unnecessarily can allow attackers to map out network
topology that is not publicly available.

• Authenticating the gateway. Not only does the peer have to prove its

identity to the host, but its security gateway must also authenticate
itself.

• Proving that the gateway is authorized to act on behalf of the host. This

issue is separate from gateway authentication. A host has to have
irrefutable proof that the peer’s IPsec protection is actually provided
by the gateway.

• Locating a backup gateway. If a gateway fails, communications with

the peer will come to a standstill, even though the peer is still available. A backup gateway can pick up where the original gateway
halted and renegotiate SAs to account for the revised gateway location and identification.

9.2.4

Policy Discovery

It also can be beneficial to know in advance whether an IKE negotiation has
a chance of succeeding. When the SPD’s rules are somewhat complex,
involving selectors other than IP addresses, it is doubtful that an IKE

190

Demystifying the IPsec Puzzle

negotiation can succeed without some foreknowledge of the peer’s security
requirements. If a host can discover, prior to IKE initiation, whether any
of its approved security policies also will be acceptable to its peer, that
eliminates a major obstacle. If multiple security gateways are involved, policy
discovery may have to be performed recursively, to accommodate multiple
SAs with differing endpoints.
There are two models of peer policy discovery. In the centralized
model, there are multiple security policy domains, each consisting of a collection of hosts and security gateways. Each domain also has one or more policy
servers, which are responsible for distributing IPsec policies to subsidiary
hosts and gateways. Hosts external to the domain would also be able to
obtain policy information from the server prior to initiating an IKE negotiation with one of the domain’s hosts. In the distributed model, each host is an
island of IPsec independence. It can obtain its policy from another source,
but responsibility for communicating those policies to potential peers rests
solely on the individual host.
The question of whether gateway discovery information should be protected from eavesdroppers also applies to policy discovery. In both cases, the
information clearly needs to be authenticated and integrity protected. But it
is not as clear-cut whether it should be encrypted. If not, it can be exchanged
before an IKE phase 1 exchange; if it requires encryption, it can be
exchanged under the protection of an IKE SA.
Another issue is whether policy discovery should be combined with
either gateway discovery or policy server discovery. An obvious benefit is
minimizing the amount of traffic necessary to conduct the pre-IKE policy
processing. However, separating the processes can result in greater security.
Once the gateway or policy server has been authenticated, the policy
information will be delivered only to a known and trusted entity. In
addition, policy discovery can take place in a more secure manner, with
encryption if that is viewed as desirable.
9.2.5

Policy Exchange

To ensure a productive IKE negotiation and subsequent IPsec communications, it may not be sufficient to engage in unilateral policy discovery. The
peers may have to conduct a pre-IKE policy exchange, so that each peer
knows exactly what types of SAs are required by the peer and its security
gateways. A series of prioritized policy alternatives may have to be offered.
Each alternative may require multiple SAs, some with the same endpoints

The Missing Puzzle Piece: Policy Setting and Enforcement

191

and some with different endpoints. The IKE payloads do not lend themselves to this type of complex, multilayered exchange. Thus, in addition to
a protocol that will be used to conduct the policy exchange, a new language
or message format is required that will facilitate the pre-IKE policy
discovery.
9.2.6

Policy Resolution

Once the peers have exchanged prioritized policy discovery information, one
of the peers must attempt to resolve the peers’ disparate policies and find
out whether any common ground can be found. Thus, the language used
for pre-IKE policy exchange should lend itself to the resolution process as
well. Alternatively, it should be in a format that can be easily translated into
a resolution-applicable format. The policy exchange language must be well
defined, vendor neutral, and capable of interoperability. It should be easy
for humans to understand, so that security snafus and black holes can be
avoided. It also should be amenable to automated processing and verification. If the policy resolution language is distinct from the policy exchange
language, it can be proprietary.
Policy resolution does not necessarily have to be performed by the end
hosts. If a policy server is involved, it can handle the policy discovery and
resolution for the end hosts and gateways. An added benefit is that the policy
server can cache other hosts’ policy requirements, making the process more
efficient in the long run. The policy server can also sign and authenticate the
policy information, removing those burdens from the end hosts as well.
Adding pre-IKE policy discovery, exchange, and resolution increases
the processing burden and could leave hosts open to a massive denial-ofservice attack. That possibility is mitigated by the fact that the most expensive operations are borne by the initiator.
9.2.7

Policy Decorrelation

As we have seen, the SPD contains an ordered set of policy rules. The use
of wildcards in one or more selector fields can result in overlapping policy
entries. For SPD processing, as it is defined in the document on IPsec architecture, careful ordering of the rules generally prevents the unintended application of a general rule to traffic that necessitates a more specific one. When
we attempt to connect the SPD’s policy rules with other aspects of policy
processing, overlapping selectors can be extremely problematic.

192

Demystifying the IPsec Puzzle

If a host receives its policy configuration rules from more than one
source, or if a local network administrator is allowed to override the default
policy configuration rules imposed by a central policy server, it may be necessary to merge two sets of ordered policy rules, which can be a complex undertaking and may result in unintended consequences. In the areas of policy
exchange and policy resolution, two peers are exchanging and resolving sets
of alternative and possibly complex policy rules. Evaluating each rule or bundle of rules as an independent entity is enough of a task; adding the aspect of
interplay between the alternatives would make it an impossible undertaking.
Thus was born the notion of policy rule decorrelation, which is a requirement
that, within a set of policy-related rules, the selectors of any two rules cannot
apply to the same packet. Figure 9.5(a) shows a sample set of SPD rules
for scenario 2, and Figure 9.5(b) shows the decorrelated version of the same
set of rules. In general, the only difference is the transformation of wildcard
Rule Src Dest
#
Addr Addr
1
2
3
4
5

SG1
SG1
H1-1
Any
N1

SG2
SG2
Any
H2-1
N2

Src
Port

Dest
Port

Prot

Action

500
Any
Any
Any
Any

500
Any
Any
Any
Any

Any
Any
Any
Any
Any

Accept
IPsec
IPsec
IPsec
IPsec

IPsec Enc
Hdr Alg
—

—

Auth
Alg

Mode

—

—

AH
ESP
ESP AES HMAC-SHA-1 Tunnel
ESP 3DES HMAC-SHA-1 Tunnel
HMAC-SHA-1 Tunnel
AES HMAC-SHA-1 Tunnel

Figure 9.5(a) Sample SPD rules before decorrelation.

Rule Src Dest
# Addr Addr

Src
Port

Dest
Port Prot

500
Not
500

500
Not
500

Any

Accept

—

—

Any

IPsec

AH

—

Action

IPsec Enc
Hdr Alg

Auth
Alg

Mode

—

—

1

SG1 SG2

2

SG1 SG2

3

H1-1

Not
H2-1

Any

Any

Any

IPsec

ESP

AES HMAC-SHA-1 Tunnel

4

Not
H2-1
H1-1

Any

Any

Any

IPsec

ESP

AES HMAC-SHA-1 Tunnel

5

Not Not
H1-1 H2-1

Any

Any

Any

IPsec

ESP 3DES HMAC-SHA-1 Tunnel

Figure 9.5(b) Sample SPD rules after decorrelation.

HMAC-SHA-1 Tunnel

The Missing Puzzle Piece: Policy Setting and Enforcement

193

selectors to a list of values to which the rule does not apply. The values are
the ones for which other rules have already been defined.
9.2.8

Policy Compliance Checking

Even after a host has configured its policy, decorrelated the rules, and
exchanged and resolved policy information with every possible communicating peer for every possible type of traffic, eternal vigilance is still necessary.
Inbound and outbound traffic must be inspected to ensure that no packets
contrary to policy sneak through. Although the preliminary steps may be
more complicated and processor intensive, without constant policy compliance checking the whole edifice will crumble. The SPD processing incorporates such checks; implementing them would require each implementation
to code and debug this critical and complex methodology. The SPD rules
and their relationship to the SAD have given rise to much confused and
befuddled debate. Another, quite possibly safer approach is to define a universal policy language for which an automated compliance checker can be
developed. This language’s use could be restricted to compliance checking,
or it could also be used for some of the other policy-related exchanges as well.

9.3 Revisiting the Road Warrior
Chapter 6 discussed the ways in which a road warrior can establish or prove
its identity-related credentials to conduct an IKE negotiation. A number of
policy ramifications also affect the road warrior.
An important issue is the placement, both actual and virtual, of the
road warrior within the corporate network. If a remote client is assigned an
internal network address, but it physically resides outside the network, the
client could conduct two distinct types of communications: direct Internet
communications from its actual physical address and indirect communications from its virtual address via the security gateway. Figure 9.6 shows both
types of traffic. Solid lines 1 and 2 constitute an IPsec-protected tunnel from
the remote host to the security gateway. If the client was assigned an internal
network address, it can then send unprotected traffic inside the network, represented by dotted line 5, or protected traffic outside the network covered by
SG2’s policy, represented by solid line 3. From its external address, it can
send traffic, represented by broken line 4, that is controlled by its own local
policy. Alternatively, SG2’s security policy might prohibit that type of traffic

194

Demystifying the IPsec Puzzle

Internet
#3
Host H1

Network N2
Host H2-1

Host H2-2

#5
#2

#4
#1

Gateway
SG2

Host H2-3

Figure 9.6 Road warrior communications.

and require the client to route all traffic through the gateway, as it would if
the client physically resided on the network.

9.4 IPsec Policy Solutions
The current outlook is a little chaotic. A number of solutions have been proposed, each of which tackles one or more aspects of the IPsec policy thicket.
It is not yet clear which of them, if any, will be the mandated solution. When
and if specific approaches are officially blessed, it will be necessary to specify
how the various pieces of the policy puzzle fit together and interact with each
other. At that point, some approaches may be discarded. If the policy server
approach is adopted, a separate gateway discovery process is not necessary.
The policy server will be able to identify any intervening gateways in the
inquiring host’s domain and specify the gateways’ security requirements.
A major unresolved issue is whether each aspect of the solution should
be defined as an independent entity or whether some aspects should be
combined in a unified protocol. For example, should the discovery aspects of
policy (gateway or server discovery, peer policy discovery) be combined
or separate? An obvious benefit to the combined approach is to limit the
amount of preliminary policy-related traffic. However, developers are leery
of a new complex and interlocking protocol. If multiple protocols are
defined, changes to one need not affect the others. The same pluses and
minuses apply to the bundling of policy discovery, exchange, and resolution.
Unfortunately, too many separate pieces can well lead to confusion, ambiguity, and security holes.