Network Working Group L.A. Sanchez, BBN/GTEI
Internet Draft M.N. Condell, BBN/GTEI
Expires April, 1999 November 18, 1998
Security Policy System
<draft-ietf-ipsec-sps-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
West Coast).
Abstract
This document describes a distributed system that provides the
mechanisms needed for discovering, accessing and processing security
policy information of hosts, subnets or networks of a security domain.
In this system policy clients and servers exchange information using
the Security Policy Protocol. The protocol defines how the policy
information is exchanged, processed, and protected by clients and
servers. The system accommodates topology changes, hence policy
changes, rather easily without the scalability constraints imposed by
static reconfiguration of each client. The protocol is extensible and
flexible. It allows the exchange of complex policy objects between
clients and servers.
Sanchez, Condell [Page 1]
Internet Draft Security Policy System November 1998
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terms and Technical Definitions. . . . . . . . . . . . . . 3
1.1.1 Requirements Terminology . . . . . . . . . . . . . . . 3
1.1.2 Technical Definitions. . . . . . . . . . . . . . . . . 3
1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Policy Master File . . . . . . . . . . . . . . . . . . . . . . 8
4. Policy Database. . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Local Policy Database. . . . . . . . . . . . . . . . . . . 9
4.2 Cache Database . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Security Domain Database . . . . . . . . . . . . . . . . . 10
5. Security Policy Protocol (SPP) . . . . . . . . . . . . . . . . 11
5.1 SPP Message Format . . . . . . . . . . . . . . . . . . . . 12
5.2 SPP Payloads . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1 Query Payload. . . . . . . . . . . . . . . . . . . . . 14
5.2.2 Record Payload . . . . . . . . . . . . . . . . . . . . 15
5.2.3 Signature Payload. . . . . . . . . . . . . . . . . . . 16
5.3 SPP Messages . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1 Query Messages . . . . . . . . . . . . . . . . . . . . 17
5.3.2 Reply Messages . . . . . . . . . . . . . . . . . . . . 17
5.3.3 Policy Messages. . . . . . . . . . . . . . . . . . . . 18
5.3.4 Policy Acknowledgment Messages . . . . . . . . . . . . 18
5.3.4 Transfer Messages. . . . . . . . . . . . . . . . . . . 18
5.3.5 KeepAlive Messages . . . . . . . . . . . . . . . . . . 19
6. Policy Attribute Encoding. . . . . . . . . . . . . . . . . . . 19
7. Policy Queries . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1 Security Gateway Query . . . . . . . . . . . . . . . . . . 21
7.2 COMSEC Query . . . . . . . . . . . . . . . . . . . . . . . 21
7.3 Certificate Query. . . . . . . . . . . . . . . . . . . . . 22
8. Policy Records . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1 Security Gateway Record. . . . . . . . . . . . . . . . . . 24
8.2 COMSEC Record. . . . . . . . . . . . . . . . . . . . . . . 25
8.3 Security Association Record. . . . . . . . . . . . . . . . 26
8.4 Policy Server Record . . . . . . . . . . . . . . . . . . . 28
8.5 Certificate Record . . . . . . . . . . . . . . . . . . . . 29
9. SPP Message Processing . . . . . . . . . . . . . . . . . . . . 30
9.1 General Message Processing . . . . . . . . . . . . . . . . 30
9.2 Query Message Processing . . . . . . . . . . . . . . . . . 30
9.3 Reply Message Processing . . . . . . . . . . . . . . . . . 33
9.4 Policy Message Processing. . . . . . . . . . . . . . . . . 35
9.5 Policy Acknowledgment Message Processing . . . . . . . . . 37
9.6 KeepAlive Message Processing . . . . . . . . . . . . . . . 38
10. Policy Decorrelation Process . . . . . . . . . . . . . . . . . 39
10.1 Decorrelation Algorithm . . . . . . . . . . . . . . . . . 40
11. Policy Resolution Process. . . . . . . . . . . . . . . . . . . 42
12. Usage of SPS with IPSec. . . . . . . . . . . . . . . . . . . . 43
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 46
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Appendix A. DATA_TYPE Definitions. . . . . . . . . . . . . . . . . 47
Appendix B. Decorrelation Example. . . . . . . . . . . . . . . . . 64
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Author Information . . . . . . . . . . . . . . . . . . . . . . . . 69
Sanchez, Condell [Page 2]
Internet Draft Security Policy System November 1998
1. Introduction
The Security Policy System (SPS) is a distributed database of
security policy information. It provides the mechanisms needed for
discovering, accessing and processing security policy information of
hosts, subnets or networks of a security domain.
In SPS, each security domain has a master file that uniquely
defines a security domain by its network resources (hosts, subnets,
networks) and the policies to access them. Security policies and the
entire domain definition is stored in the Master File.
These policies reside in a database local to the security
domain. The Policy Server provides access to these policies to client
applications requesting policy information for a particular host,
subnet or network. SPS provides mechanisms to limit the access of
policy records to authorized hosts and/or users. SPS also provides
procedures to validate the authenticity and integrity of the policy
information exchanged between security domains.
Policy Clients generate query databases of different security
domains using the Security Policy Protocol. SPS provides a standard
set of query types for policy information. New query types can be
incorporated as needed. Policy Servers reply to these requests after
determining the validity of the request.
Since security policies could be highly restrictive and
relative to the intended communication between a source and
destination, it is possible that the replies provided by a Policy
Server would differ depending on the identity of the requestor, making
caching of the policies a plausible but complicated process. SPS
defines an algorithm that makes the caching of security policies a
feasible task.
SPS defines the format of the security policy records and the
encoding of these before transmission. SPS also defines a standard and
extensible message format. SPS specifies the message processing
required at the Policy Servers and Policy Clients.
1.1 Terms and Technical Definitions
1.1.1 Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described
in [Bra97].
1.1.2 Technical Definitions
Security Gateway
A security gateway refers to an intermediate system that
implements IPSec protocols. For example, a router or a
firewall implementing IPSec is a security gateway.
Sanchez, Condell [Page 3]
Internet Draft Security Policy System November 1998
Security Domain
A set of communicating entities and resources that share a
common security policy enforced at one or more enforcement
agents or at an individual host. The definition of security
domain applies to networks protected by security gateways as
well as to single hosts, since a host may be the enforcer of
its own policies. Security domains could exist inside other
security domains.
Security Association (SA)
A simplex "connection" that affords security services to the
traffic it carries. Two types of security associations
are defined: transport mode and tunnel mode. A transport
mode SA is a security association between two hosts. A
tunnel mode SA is essentially an SA applied to an IP tunnel.
For transit traffic, whenever either end of a security
association is a security gateway, the SA MUST be tunnel mode.
Security Association Bundle
A group of security associations that are used to protect
communications that share a common endpoint. For example,
all the SAs that a particular host needs to use to
communicate with another host, including any SAs that host
itself needs with intermediate security gateways.
1.2 Requirements
The architectural requirements of the Security Policy System are as follows:
- Gateway Discovery
SPS must be able to determine a set of necessary security gateways
through which a message must travel to complete a communication
on a single path between two hosts.
- Identity Verification
SPS must allow hosts to verify the identities of security gateways
and other hosts with which they are communicating. It must
also be able to verify that a gateway that claims to represent
a particular host actually does have the authority to represent
that host.
- Require no changes to security protocols
SPS must not require changes, additions or modifications to
security protocols that use it.
- Key Management Protocol Independence
SPS must be independent of any particular key management protocol.
Sanchez, Condell [Page 4]
Internet Draft Security Policy System November 1998
- Minimal Exterior Infrastructure Dependency
SPS SHOULD NOT depend upon an exterior infrastructure,
although implementations may use an exterior infrastructure.
For example, public keys may be distributed using the
existing DNS infrastructure. SPS must not
prohibit other means for distributing keys. Particular
implementations may, however, rely on the DNS for key
distribution, though they may not be as robust as
implementations that provide several key distribution
mechanisms.
2. Overview
The Security Policy System is a distributed system which
provides hosts and security gateways with the policy information
required to establish a secure communication end-to-end through
possibly multiple security gateways. The Security Policy System
provides one or more automated mechanism for hosts to discover primary
and secondary security gateways relevant in an end-to-end
communication. Using the Security Policy System, hosts can validate
the identity of security gateways and verify that the gateways in
question are authorized to represent the source or destination host
which they claim to represent.
SPS is comprised of Policy Servers (PS), Policy Clients (PC),
Master Files and SPS Databases. Master Files contain local policies
and other particular information about a security domain. Local policy
information combined with non-local policies (policies outside the
boundaries of the security domain) form the SPS Databases. Policy
Servers receive request messages from policy clients and other policy
servers, process them, and provide the appropriate policy information
to the requestor based on the request and access control rules. The
servers also maintain the SPS databases by loading local and non-local
policy information received through SPS exchanges. Policy Clients
generate requests for policy information and transform the replies
into the appropriate format required by the application using
SPS. Figure 1.0 depicts the SPS components.
Sanchez, Condell [Page 5]
Internet Draft Security Policy System November 1998
Local :
/ Policies +----------+ :
Master / ---> | SPS | : Non-Local
File \ Security | Database | <----- Policies
\ Domain +----------+ :
Information | :
| :
+----------+ :
| Policy | :
| Server | :
+----------+ :
^ ^ :
+---------+ | | /\
| Policy | | | / \
| Clients |<------ SPP -- --->< SG ><--- SPP ---> External
+---------+ \ / Policy Servers
\/ and Clients
Security :
Domain :
Figure 1 SPS components and interactions
Policy Servers and Clients use the Security Policy Protocol
(SPP) to exchange policy information. SPP transports policy
information from the SPS Database where this information resides to
security gateways and hosts. This protocol provides hosts with the
policy information needed to establish security associations with
security gateways in the communication path to other hosts, without
requiring a-priori knowledge of the identities of the security
gateways.
Suppose Policy ClientA would like to establish an IPSec
protected communication with Policy ClientB. Policy ClientA is unaware
of the existence of Security GatewayB (SGB). Similarly, Policy
ClientB is unaware of the existence of Security Gateway A
(SGA). Furthermore, assumme that SGB and SGA both have policies
stating that any inbound communication must be authenticated using ESP
[KA98b]. Now, if Policy ClientA initiates negotiations for a security
association with Policy ClientB it would fail since SGB requires any
inbound packets to be authenticated using ESP and Policy ClientA
doesn't have a security association with SGB.
SPS provides the mechanisms to resolve this problem. Imagine
that the network administrators for Security Domain Foo and Foobar
prepare a Master File containing the policies of their respective
domains. These are the policies enforced by SGA and SGB do not include
specific policies of any of the clients members of a security
domain. A security domain could be as small as one host acting as its
own Policy Client and Server and, enforcing its own policies, or as
large as many networks with several Policy Servers and Security
Gateways.
Both Master Files are first parsed and verified to avoid
syntax errors. Policies within the Master Files are decorrelated using
the decorrelation process specified in section 10. Policy Server A and
B load the policies from their respective security domains into their
SPS Databases and listen for policy requests.
Sanchez, Condell [Page 6]
Internet Draft Security Policy System November 1998
Security Security
Domain Foo Domain Foo
+----------+ +----------+
| Policy | | Policy |
| ServerA | | ServerB |
+----------+ +----------+
^ ^ ^ ^
+---------+ Q1 | | Q2 /\ /\ Q2 | | Q3 +----------+
| Policy | R1 | | R2 / \ Q2/R2 / \ R2 | | R3 | Policy |
| ClientA |<--- -----><SGA ><------><SGB ><--- ---->| ClientB |
+---------+ \ / \ / +----------+
\/ \/
Figure 2 Example of SPS operation
Now suppose that Policy ClientA had a facility enabling it to
request policy information to Policy Server A dynamically. The policy
request message could be triggered by a message sent from the kernel
to a Key Management Protocol. So, Policy ClientA sends a Query (Q1) to
Policy ServerA. Policy ServerA looks in its cache for a policy record
that matches the query. If it doesn't find one it sends a Query (Q2)
containing the same policy request information destined to Policy
ClientB. This message includes a signature that validates the
authenticity and integrity of the query's content.
(Q2) is intercepted by SGB. SGB forwards the message (Q2) to
Policy ServerB. Policy serverB first verifies that it can accept
queries from Policy ServerA. It then validates the signature in
Q2. It searches its database for the appropriate policy information
after verifying that it is authoritative over Policy ClientB.
Policy ServerB first merges its local policy with the policy
information in (Q2) and it then replies (R2) to Policy ServerA. The
reply includes the original query information and all policy
information needed to allow Policy ClientA to establish a secure
communication with Policy ClientB. The merging or policy resolution
process helps in determining any policy conflicts and ambiguities.
It is possible for Policy ServerB to query Policy ClientB for
its policy with respect to this particular communication. Policy
ServerB could generate then a third query (Q3). Policy ClientB
responds with its policy in (R3). Policy ServerB merges its policy for
this communication and the policy in (R3) before replying to Policy
ServerA. Policy ServerB also attached additional information to the
reply asserting its authority over Policy ClientB. This chain of trust
MUST be validated cryptographically. The merged policy returns in (R2)
to Policy ServerA where it merges its local policy with the external
policy received in (R2) and caches it for later use.
A protocol such as SPP accommodates topology changes, hence
policy changes, rather easily without the scalability constraints
imposed by static reconfiguration of each client. The protocol is
extensible and flexible It allows the exchange of complex policy
objects between clients and servers.
Sanchez, Condell [Page 7]
Internet Draft Security Policy System November 1998
3. Policy Master File
In SPS, policy information of a particular security domain is
stored in a Master File. SPS does not impose a particular format for
the data store in a master file. SPSL [SPSL] defines a vendor
independent language that can be used to define policy information for
a security domain. Master Files however, must contain the information
specified below. The order in which the policy information appears in
the Master File is extremely important since most policy enforcers
search for the first policy entry that matches the characteristics of
a particular packet. Any other applicable policy found after the first
match is ignored.
Master files require the following information:
certificate
This information points to one or more certificates to be
referenced by the maintainer information. The private key
corresponding to the public key found in this certificate is
used to sign the information contained in the master
file. The public key is used to verify the information's
integrity and authenticity.
maintainer
This information defines the entities authorized to create,
delete and modify the policy information in a particular
Master File.
policy-server
This information specifies the identity of the primary
and secondary policy servers for a particular security domain.
nodes
This information identifies a set of interfaces that may have
policies attached to them. There must be at least one node in a
security domain.
gateway
This information identifies a set of interfaces associated
with a host that enforces the policies of a particular
security domain.
domain
The domain information defines a security domain in terms of
the nodes, the security gateways and the policy servers that
are part of it.
policy
An ordered set of policies. These policies cover the domain or
domains describe by the preceding information.
Sanchez, Condell [Page 8]
Internet Draft Security Policy System November 1998
The Master file contains the list of nodes that are part of the
security domain, the list of security gateways protecting the security
domain, a list of the policy rules enforced by the security gateways
and possibly the policy rules enforced at the nodes.
The Master File MUST contain information indicating who is
responsible for the security domain and a pointer to a public key that
can be used to verify the integrity and authenticity of the
information found in the master file.
4. Policy Database
In SPS, every security domain MUST maintain a database
containing the policy information for that domain. Security domains
could be as small as one host or as large as several networks. This
database, called the SPS Database, is comprised of three logical
databases: 1) the Local Policy Database, 2) the Cache Database and, 3)
the Security Domain Database.
The Local Policy Database contains all the policies for the
security domain. It is populated with information coming from the
Master File of the security domain. The Cache Database contains local
and external policies received from other security domains via SPS
exchanges. The policies are merged using the policy resolution process
specified in section 11. The Security Domain Database contains a list
of all hosts, security gateways, and policy servers that are part of
the security domain.
Compliant SPS implementations of a policy client and server do
not need to implement these three databases separately. However, the
information contained in each one of them MUST exist. The Local
Database and the Cache Database MUST keep a distinct sets of policies
since it is not possible to revert cached policy information into
Local Database policy information after the cached items expire.
While it is not necessary to standardize the format of the
database used, the SPS database MUST contain a minimum set of
information. The next three subsections describe each database in
terms of its functionality and requirements.
4.1 Local Policy Database
Every policy client and every policy server MUST keep a
database containing its local policy. In the client case, the policy
is kept in some pre-configured form and loaded into the database. The
database could be the same as the client's Security Policy Database
(SPD) as defined in [kent98]. In the server's case the information
found in the Local Policy Database applies to all the members of the
security domain and therefore it MUST be kept separate from the
server's own policy information found in its SPD.
The Local Policy Database MUST contain the policies expressed
in the Master File for the security domain. Policies are divided into
a clause section and an action section. The clause section describes a
particular communication while the action clause indicates what should
be done with the communication.
Each policy entry MUST contained a unique identifier, an
expiration time, and a single policy clause followed by each action
clause that applies to that policy clause. In terms of the Security
Sanchez, Condell [Page 9]
Internet Draft Security Policy System November 1998
Policy Protocol, the clause portion of the policy is encoded in
communication security records and the action portion (if IPSec
related) is encoded in security association records.
Policies in this database MUST be decorrelated as defined in
section 10. An algorithm for policy decorrelation is presented in
section 10.1. Decorrelated policies allow for efficient reordering and
organization of the policies without affecting the enforcement
process. Policy decorrelation also facilitates the caching of external
policies.
4.2 Cache Database
In addition to the information stored in the Local Policy
Database, every policy client and server MUST keep a cache of merged
local and non-local policy data. Non-local policies are policies which
do not exist in some pre-configured form in a policy client or
server. These policies are learned through SPS exchanges.
Non-local policies are merged with Local Database policies
using the policy resolution process discussed in section 11. The
resultant merged policies MUST be kept logically separate from the
local policies. The cached data then can be used to answer subsequent
queries for the same policy information.
Each policy entry MUST contain a unique identifier, an
expiration time, and typically a single policy clause followed by each
action clause that applies to that policy clause. A policy entry MAY
contain multiple policy clauses each followed by action clauses, if
the policy must be enforced at multiple endpoints. Each policy entry
MUST also contain any assertion information that could indicate the
relationship between the policy server that provide the SPS message
and the information in the policy exchange. It SHOULD also include any
public keying material (e.g. certificates, etc.) that might be needed
to validate the assertions made by policy servers. In terms of the
Security Policy Protocol, policy server assertions, and certificates
are encoded in policy server and certificates records, respectively.
Policy Clients and Servers MUST NOT cache policies
indefinitely, since cached policies have a non-local component that
may change without warning. Each policy entry MUST contain an
expiration time that MUST be considered as the maximum amount of time
that this policy MAY be cached. Longer cache expiry times should be
associated with policies that are less likely to change, while shorter
cache expiry times should be associated with policies that are likely
to change. As in the Local Policy Database, policies in the Cache
Database MUST be decorrelated as defined in section 10.
4.3 Security Domain Database
A Policy Server MUST also maintain information that describes
the security domain for which it is authoritative. This information
includes a list with the identities of each security gateway enforcing
policies at the perimeter of the security domain and an entry
indicating the identities of the nodes that are members of the
security domain.
Sanchez, Condell [Page 10]
Internet Draft Security Policy System November 1998
Policy servers use this information to determine that they
are authoritative over the host for which they are providing policy
information. It also allows policy servers to determine if they
may participate in an SPP exchange without violating the chain
of trust that the recipient of the information will require to
verify the authenticity of the policy.
5. Security Policy Protocol (SPP)
Policy clients and servers exchange information using the
Security Policy Protocol. The protocol defines how the policy
information is exchanged, processed, and protected by clients and
servers. The protocol also defines what policy information is
exchanged and the format used to encode the information. The protocol
specifies six different message types used to exchange policy
information. An SPP message contains a message header section followed
by zero or more SPP payloads, depending on the message type.
Figure 3 depicts the format of an SPP message. The header
section is present in every message. It contains fields identifying
the message, the type of message, the status of the message, the
number of queries and/or record payloads, and the host requesting
policy information. The header also includes a timestamp field that
provides anti-replay protection. Following the header there might be
zero or more SPP payloads. Currently, there are three payload types
defined in SPP: Query, Record, and Signature payloads. See section 5.2
for encoding details.
SPP has six distinct message types. Query messages contain a
specific request for policy information. Reply messages include policy
records that answer specific policy queries. Policy messages include
policy information and are utilized for up/downloading security
policies to and from a policy server. Policy Acknowledgment messages
are utilized to acknowledge corresponding Policy messages but do not
themselves contain policy information. Transfer messages, which
include policy information, are utilized by policy servers to exchange
bulk policy information between servers. Finally, policy servers use
keep alive messages to inform security gateways and/or other
monitoring devices of the status of the server.
SPP messages MUST be authenticated either using IPSec [Kent98]
or another security mechanism. SPP provides a basic security mechanism
that can be used to provide authentication and integrity to its
messages, especially when traversing heterogenous domains and the
identity of the policy server authoritative for the destination is
unknown. These services are provided using digital signatures.
SPP caries signatures in the signature payload. The signature
is calculated over the entire SPP message. When this service is used,
the entity (host, policy server or security gateway) verifying the
signature must have access to the public key that corresponds to the
private key used to sign the SPP message.
Certificate fetching is out of the scope of SPP. However, SPP
provides a simple certificate fetching mechanism for entities that
elect to use it as an alternative to other mechanisms. SPP suports
several Public Key certificates formats.
Sanchez, Condell [Page 11]
Internet Draft Security Policy System November 1998
SPP is modular and extensible. New policy queries and records
can be defined and incorporated easily. This document defines a
minimum set of queries and policy records required in a policy-based
security management system.
5.1 SPP Message Format
An SPP message follows the format depicted in figure 3. It is
comprised of a header and zero or more SPP payloads. This section
defines the encoding for the SPP header. Sections 5.2 and 5.3 cover
the encoding for the SPP payload and message types, respectively.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----
| MESSAGE ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MTYPE | MCODE | QCOUNT | RCOUNT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| IDENTITY TYPE | RESERVED | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | SPP
+ TIMESTAMP + Header
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
~ SENDER IDENTITY ~ |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----
| | SPP
+ SPP PAYLOADS... |Payloads
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----
Figure 3: Format of an SPP Message
The SPP header includes the following fields:
MESSAGE ID
A 4 octet field used to match messages and their responses
(e.g. queries to replies and policy to policy acknoledgement
messages). This value starts at "zero" and MUST be incremented
by (01)hex with every new message.
MTYPE
A 1-octet field indicating the SPP message type.
The currently defined values are:
Sanchez, Condell [Page 12]
Internet Draft Security Policy System November 1998
Value Message Type
00 Value Not Assigned
01 SPP-QUERY
02 SPP-REPLY
03 SPP-POL
04 SPP-POL_ACK
05 SPP-XFR
06 SPP-KEEP_ALIVE
07-255 Reserved
MCODE
A 1-octet field providing information about this message.
See section 5.3 for the codes applicable to each message type.
Code Action
Field Type
00 Value Not Assigned
01 message accepted
02 denied, administratively prohibited
03 denied, timestamp failed
04 denied, failed signature
05 denied, insufficient resources
06 denied, malformed message
07 denied, unspecified
08 partially available
09 unavailable
10 communication prohibited
11-255 reserved
QCOUNT
A 1 octet field indicating the number of Query payloads included
in the message.
RCOUNT
A 1 octet field indicating the number of Record payloads
included in the message.
IDENTITY TYPE
This 1 octet field indicates the type of indentity found in
the Sender Identity field. Valid values are:
Value Identity Type
00 Value Not Assigned
01 IPV4_ADDR
02 IPV6_ADDR
03 Host DNS Name
04-255 Reserved
Sanchez, Condell [Page 13]
Internet Draft Security Policy System November 1998
RESERVED
A 3 octet field used for field 32-bit boundary alignment and
reserved for future use. Set value to all zeros (00)hex.
TIMESTAMP
This 8-octet field contains a timestamp used to provide
limited protection against replay attacks. The timestamp
is formatted as specified by the Network Time Protocol
[RFC1305].
SENDER IDENTITY
A variable length field containing the identity of the sender
(host, security gateway or policy server) of the SPP
message. The IDENTITY_TYPE field indicates the format of the
content in this field. This field does not allow IP address
ranges or wildcards.
5.2 SPP Payloads
5.2.1 Query Payload
The Query payload contains fields to express a particular
request for policy information. Hosts, security gateways, or policy
servers can generate and transmit Query payloads in SPP messages to
policy servers. Figure 4 shows the format of the Query payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCL | PID | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QUERY Data ...
+-+-+-+-+-+-+-+-
Figure 4: Format of Query Payload
The Query Payload fields are defined as follows:
PCL
A 1 octet field indicating the payload class. Query payloads
MUST contain (01)hex in the PCL field.
PID
A 1 octet field containing the ID number that identifies a
particular Query payload within an SPP message. Since one
SPP message can contain multiple Query payloads, each one
MUST be uniquely identified. This number MUST be unique
among the Query payloads within an SPP message.
Sanchez, Condell [Page 14]
Internet Draft Security Policy System November 1998
RESERVED
A 2 octet field reserved for future use. Set value to all
zeros (00)hex.
TYPE
A 2 octet field that specifies the type of query contained in
the QUERY Data fields. The currently defined queries are:
Value Query Payload Type
00 Value Not Assigned
01 Security Gateway Query
02 Communication Security Query
03 Certificate Query
04-65536 Reserved
LENGTH
A 2 octet field indicating the length in octets of the query
data field.
QUERY Data
A variable length field containing a single policy query. See
section 7 for encoding format.
5.2.2 Record Payload
The Record payload contains fields that assert policy
information. Hosts, security gateways, or policy servers can generate
and transmit Record payloads in SPP messages. Figure 5 shows the
format of the Record payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCL | PID | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RECORD Data ...
+-+-+-+-+-+-+-+-
Figure 5: Format of Record Payload
The Record Payload fields are defined as follows:
PCL
A 1 octet field indicating the payload class. Record payloads
MUST contain (02)hex in the PCL field.
Sanchez, Condell [Page 15]
Internet Draft Security Policy System November 1998
PID
This field is used to match queries to Record payloads. If
the record is a reply to a query, then the value for this
field MUST match the correspondent Query payload PID. If it
is not a reply to a query, the value SHOULD be set to zero.
RESERVED
A 2 octet field reserved for future use. Set value to all
zeros (00)hex.
TYPE
A 2 octet field that specifies the type of Record. The
currently defined records are:
Value Record Type
00 Value Not Assigned
01 Security Gateway Record
02 Communication Security Record
03 Security Association Record
04 Certificate Record
05 Policy Server Record
06-65536 Reserved
LENGTH
A 2 octet field indicating the length in octets of the RECORD
data field.
RECORD Data
A variable length field containing a single policy record. See
section 8 for encoding format.
5.2.3 Signature Payload
The Signature Payload contains data generated by the digital
signature function (selected by the originator), over the entire SPP
message, except for part of the Signature payload. This payload is
used to verify the integrity of the data in the SPP message. Figure 6
shows the format of the Signature payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCL | TYPE | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIGNATURE Data ...
+-+-+-+-+-+-+-+-
Figure 6: Signature Payload Format
The Signature payload fields are defined as follows:
Sanchez, Condell [Page 16]
Internet Draft Security Policy System November 1998
PCL
A 1 octet field indicating the payload class. Signature payloads
MUST contain (03)hex in the PCL field.
TYPE
A 1 octet field that specifies the signature algorithm
employed. The currently defined signature types are:
Value Algorithm Type
00 Value Not Assigned
01 RSA
02 DSA
03-255 Reserved
LENGTH
A 2 octet field indicating the length in octets of the
SIGNATURE Data field.
SIGNATURE Data
A variable length field that contains the results from
applying the digital signature function to the entire
SPP message (including the PCL, TYPE, and LENGTH fields
of the Signature payload), except for the Signature Data
field of the Signature payload.
5.3 SPP Messages
5.3.1 Query Message
An SPP-QUERY message is comprised of an SPP header, one or
more Query payloads, zero or more Record payloads, and a Signature
payload, if one is required. Query messages MUST always contain a Query
payload. Record payloads may optionally be included to pass policy
information along with the query. If the Signature payload is employed
it MUST be the last payload in the message. The Query message MTYPE
value is (01)hex. The MCODE field must be set to zero (00)hex.
5.3.2 Reply Message
An SPP-REPLY message is comprised of an SPP header, one or
more Query payloads, zero or more Record payloads which answer the
corresponding Query payload, and a Signature payload, if one is
required. Reply messages MUST contain a Query payload. Reply messages
MUST include a Record payload unless the reply contains an error code
of values (02-08). If the Signature payload is employed it MUST be the
last payload in the message. The MTYPE value for a Reply message is
(02)hex. The following MCODE values may be used for Reply messages:
Sanchez, Condell [Page 17]
Internet Draft Security Policy System November 1998
Code Action
Field Type
01 message accepted
02 denied, administratively prohibited
03 denied, timestamp failed
04 denied, failed signature
05 denied, insufficient resources
06 denied, malformed message
07 denied, unspecified
08 partially available
09 unavailable
10 communication prohibited
5.3.3 Policy Message
An SPP-POL message is comprised of an SPP header, one or more
Record payloads, and a Signature payload, if one is required. Policy
messages MUST NOT include Query payloads. If the Signature payload is
employed it MUST be the last payload in the message. The MTYPE value
for a Policy message is (03)hex. The MCODE field must be set to zero
(00)hex.
5.3.4 Policy Acknowledgement Message
An SPP-POL_ACK message is comprised of an SPP header and a
Signature payload, if one is required. These messages MUST NOT contain
Query or Record payloads. The status of the associated Policy message
is expressed within the MCODE field. If the Signature payload is
employed it MUST be the only payload in the message. The MTYPE value
for a Policy Acknowledgement message is (04)hex. The following MCODE
values may be used for Policy Acknowledgement messages:
Code Action
Field Type
01 message accepted
02 denied, administratively prohibited
03 denied, timestamp failed
04 denied, failed signature
05 denied, insufficient resources
06 denied, malformed message
07 denied, unspecified
5.3.5 Transfer Message
An SPP-XFR message is comprised of an SPP header, one or more
Record payloads, and a Signature payload, if one is required. Transfer
messages MUST NOT include Query payloads. If the Signature payload is
employed it MUST be the last payload in the message. The MTYPE value
for a Transfer message is (05)hex. The MCODE field must be set to zero
(00)hex.
Sanchez, Condell [Page 18]
Internet Draft Security Policy System November 1998
5.3.6 KeepAlive Message
An SPP-KEEP_ALIVE message is comprised of an SPP header and a
Signature payload, if one is required. These messages MUST NOT contain
Query or Record payloads. If the Signature payload is employed it MUST
be the only payload in the message. The MTYPE value for a KeepAlive
message is (06)hex. The MCODE field must be set to zero (00)hex.
6.0 Policy Attribute Encoding
Query and Record payloads include several different selector
types and SA attributes with their associated values. These data are
encoded following a Type/Length/Value (TLV) format to provide
flexibility for representing different kinds of data within a
payload. Certain Data_Types with values of length equal to 2 octets
follow the Type/Value (T/V) format. The first bit of the DATA_TYPE
field is used to distinguished between the two formats. A value of (0)
indicates a TLV format while a value of (1) indicates TV format. This
generic encoding format is depicted in figure 7.
X = 0:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| DATA_TYPE | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA_VALUE...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X = 1:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| DATA_TYPE | DATA_VALUE...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Generic Data Attribute Formats
The generic data attribute fields are defined as follows:
X
This bit indicates if the DATA_TYPE follows the TLV(0) or the
TV(1) format.
DATA_TYPE
A 2 octet field indicating the selector type. The currently
defined values are:
Sanchez, Condell [Page 19]
Internet Draft Security Policy System November 1998
DATA DATA_TYPE X
IPV4_ADDR 1 0
IPV6_ADDR 2 0
SRC_IPV4_ADDR 3 0
SRC_IPV4_ADDR_SUBNET 4 0
SRC_IPV4_ADDR_RANGE 5 0
DST_IPV4_ADDR 6 0
DST_IPV4_ADDR_SUBNET 7 0
DST_IPV4_ADDR_RANGE 8 0
SRC_IPV6_ADDR 9 0
SRC_IPV6_ADDR_SUBNET 10 0
SRC_IPV6_ADDR_RANGE 11 0
DST_IPV6_ADDR 12 0
DST_IPV6_ADDR_SUBNET 13 0
DST_IPV6_ADDR_RANGE 14 0
DIRECTION 15 1
USER_NAME 16 0
SYSTEM_NAME 17 0
XPORT_PROTOCOL 18 0
SRC_PORT 19 0
SRC_PORT_DYNAMIC 20 0
DST_PORT 21 0
DST_PORT_DYNAMIC 22 0
SEC_LABELS 23 0
V6CLASS 24 1
V6FLOW 25 0
V4TOS 26 1
ACTION 27 1
SRC_PORT_RANGE 28 0
DST_PORT_RANGE 29 0
IPSEC_ACTION 50 0
ISAKMP_ACTION 51 0
RESERVED 30-49, 52-32767
LENGTH
A 2 octet field indicating the length of the selector value in
octets, not including any trailing padding added to the
DATA_VALUE field. The padding length is implicit.
DATA_VALUE
A variable length field containing the value of the selector
specified by DATA_TYPE. If the Selector value is not aligned at
the 4 octet boundary the field MUST be padded on the right with
(00)hex to align on the next 32-bit boundary.
Sanchez, Condell [Page 20]
Internet Draft Security Policy System November 1998
7. Policy Queries
7.1 Security Gateway Query
This basic query provides a dynamic mechanism to determine
which relevant security gateways, both primary and backup, are in the
path to a particular destination address. Since the answer to a
request for information could depend on the identity of the requestor,
the host address of the source of the intended communicaton is
included in the query. Figure 8 shows the format of the Security
Gateway Query.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ SOURCE ADDRESS DATA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ DESTINATION ADDRESS DATA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Security Gateway Query Format
The Security Gateway Query fields are defined as follows:
SOURCE ADDRESS DATA
This variable length field contains a single IP address
(unicast) either in IPv4 or IPv6 format. The encoding
format is specified in section 6. The acceptable DATA_TYPE
values are 3 and 9.
DESTINATION ADDRESS DATA
This variable length field contains a single IP address
(unicast) either in IPv4 or IPv6 format. The encoding
format is specified in section 6. The acceptable DATA_TYPE
values are 6 and 12.
7.2 COMSEC Query
The Communication Security Query (or COMSEC query) provides a
dynamic mechanism for a host or security gateway to inquire if a
communication having a particular set of characteristics is
allowed. The communication is described in terms of source and
destination addresses, protocols, source port, destination port, and
other parameters as defined in section 6. These parameters are known
as selectors in the IPSec context and are primarily the contents of
the IP and TCP headers. Figure 9 shows the format of the COMSEC
Query.
Sanchez, Condell [Page 21]
Internet Draft Security Policy System November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ SOURCE ADDRESS DATA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ DESTINATION ADDRESS DATA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SELECTOR DATA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: COMSEC Query Format
The COMSEC Query fields are defined as follows:
SOURCE ADDRESS DATA
This variable length field contains a single IP address
(unicast) either in IPv4 or IPv6 format. The encoding
format is specified in section 6. The acceptable DATA_TYPE
values are 3 and 9.
DESTINATION ADDRESS DATA
This variable length field contains a single IP address
(unicast) either in IPv4 or IPv6 format. The encoding
format is specified in section 6. The acceptable DATA_TYPE
values are 6 and 12.
SELECTOR DATA
This includes one or more fields following the encoding format
specified in section 6. The acceptable DATA_TYPE values are
15-29, inclusive.
7.3 CERT Query
Mechanisms to dispatch and fetch public-key certificates are
not part of SPP. However, in the absence of external request/dispatch
mechanisms, SPP provides for a certificate request query that allows a
host, security gateway, or server to solicit a certificate. Figure 9
shows the format of the CERT Query.
Sanchez, Condell [Page 22]
Internet Draft Security Policy System November 1998
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CERT_TYPE | IDENTITY_TYPE | AUTHORITY_TYPE| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IDENTITY ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ CERTIFICATE AUTHORITY ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Certificate Query Format
The Certificate query fields are defined as follows:
CERT_TYPE
A 1 octet field that contains an encoding of the type of
certificate requested. Acceptable values are listed below:
Certificate Type Value
Value Not Assigned 0
PKCS #7 wrapped X.509 certificate 1
PGP Certificate 2
DNS Signed Key 3
X.509 Certificate - Signature 4
X.509 Certificate - Key Exchange 5
Kerberos Tokens 6
SPKI Certificate 7
RESERVED 8 - 255
IDENTITY_TYPE
This 1 octet field indicates the type of indentity found in
the Identity field. Valid values are listed below:
Value Identity Type
0 Value Not Assigned
1 IPV4_ADDR
2 IPV6_ADDR
3 DNS Name
4 X.500 Distinguished Name
5-255 Reserved
AUTHORITY_TYPE
This 1 octet field indicates the type of authority found in
the Certificate Authority field. Valid values are the same as
IDENTITY_TYPE.
Sanchez, Condell [Page 23]
Internet Draft Security Policy System November 1998
IDENTITY
This variable length field contains the identity of the
principal by which the certificate should be located. The
value MUST be of the type stated in IDENTITY_TYPE.
CERTIFICATE AUTHORITY
A variable length field containing an encoding of an
acceptable certificate authority for the type of certificate
requested. The value MUST be of the type stated in
AUTHORITY_TYPE.
8. Policy Records
8.1 Security Gateway Record
This record contains information that indicates the IP
addresses of the interfaces for the the primary and secondary security
gateways protecting a host or group of hosts. The record contains the
primary and secondary gateways at one point in the path that an IP
datagram originated from the source address listed in the Security
Gateway query will have to traverse to reach the destination address
listed in that query. If the IP datagram must traverse multiple
gateways, a Security Gateway Record must be included for each gateway.
The list of secondary security gateways is optional. Figure 10 shows
the format of the Security Gateway Record.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CACHE-EXPIRY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FLAGS | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ PRIMARY SG ADDRESS ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SECONDARY SG ADDRESSES
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Security Gateway Record Format
The Security Gateway Record fields are defined as follows:
CACHE-EXPIRY
A 4 octet field indicating the maximum amount of time,
in seconds, this policy record MAY be cached.
Sanchez, Condell [Page 24]
Internet Draft Security Policy System November 1998
FLAGS
A 2 octet field indicating different options to aid in
interpreting the security gateway data. If not in use, set
value to all zeros (00)hex. Currently, no flag values are
defined so this field MUST be set to (00)hex.
RESERVED
A 2 octet field reserved for future use. If not in use, set
value to all "zeros".
PRIMARY SG ADDRESS
A variable length field containing the IP address of the primary
security gateway for protecting a particular host. This
variable length field contains a single unicast IP
address. The encoding format is specified in section 6.
The acceptable DATA_TYPE values are 1 and 2.
SECONDARY SG ADDRESSES
This variable length field contains the IP addresses of
secondary security gateways protecting a particular host. This
field may contain a list of single unicast IP addresses. The
encoding format is specified in section 6. The acceptable
DATA_TYPE values are 1 and 2.
8.2 COMSEC Record
The COMSEC record indicates if a communication having a
particular set of characteristics is allowed or not. The communication
is described in terms of source and destination addresses, protocols,
source ports, destination ports, and other attributes defined in
section 6. Figure 11 shows the format of the COMSEC Record.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CACHE-EXPIRY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FLAGS | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ SOURCE ADDRESS DATA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ DESTINATION ADDRESS DATA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SELECTOR DATA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: COMSEC Record Format
Sanchez, Condell [Page 25]
Internet Draft Security Policy System November 1998
The COMSEC Record fields are defined as follows:
CACHE-EXPIRY
A 4 octet field indicating the maximum amount of time,
in seconds, this policy record MAY be cached.
FLAGS
A 2 octet field indicating different options to aid in
interpreting the selector data. If not in use, set
value to all zeros (00)hex. Currently, no flag values are
defined so this field MUST be set to (00)hex.
RESERVED
A 2 octet field reserved for future use. If not in use, set
value to all zeros (00)hex.
SOURCE ADDRESS DATA
This variable length field contains a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), range of addresses (low and high values, inclusive),
address + mask, or a wildcard address. The encoding format is
specified in section 6. The acceptable DATA_TYPE values are
3-5 and 9-11, inclusive.
DESTINATION ADDRESS DATA
This variable length field contains a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), range of addresses (low and high values, inclusive),
address + mask, or a wildcard address. The encoding format is
specified in section 6. The acceptable DATA_TYPE values are
6-8 and 12-14, inclusive.
SELECTOR DATA
This includes one or more fields following the encoding format
specified in section 6. The acceptable DATA_TYPE values are
15-29, inclusive.
8.3 Security Association Record
Security Association Records contain selectors and security
association attributes (APPLIERS) that characterize a particular
Security Association between the source and destination addresses
listed in the record. This record contains data types as defined in
the section 6. Figure 12 shows the format of the SA Record.
Sanchez, Condell [Page 26]
Internet Draft Security Policy System November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CACHE-EXPIRY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FLAGS | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ SOURCE ADDRESS DATA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ DESTINATION ADDRESS DATA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SELECTOR DATA AND APPLIERS...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SA Record Format
The SA record fields are defined as follows:
CACHE-EXPIRY
A 4 octet field indicating the maximum amount of time,
in seconds, this policy record MAY be cached.
FLAGS
A 2 octet field indicating different options to aid in
interpreting the selector data. If not in use, set
value to all zeros (00)hex. Currently, no flag values are
defined so this field MUST be set to (00)hex.
RESERVED
A 2 octet field reserved for future use. If not in use, set
value to all zeros (00)hex.
SOURCE ADDRESS DATA
This variable length field contains a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), range of addresses (low and high values, inclusive),
address + mask, or a wildcard address. The encoding format is
specified in section 6. The acceptable DATA_TYPE values are
3-5 and 9-11, inclusive.
Sanchez, Condell [Page 27]
Internet Draft Security Policy System November 1998
DESTINATION ADDRESS DATA
This variable length field contains a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), range of addresses (low and high values, inclusive),
address + mask, or a wildcard address. The encoding format is
specified in section 6. The acceptable DATA_TYPE values are
6-8 and 12-14, inclusive.
SELECTOR DATA AND APPLIERS
This includes one or more fields following the encoding format
specified in section 6. The acceptable DATA_TYPE values are
15-29 and 50-51, inclusive.
8.4 Policy Server Record
The Policy Server record indicates the host, security gateway,
or policy server for which a particular policy server is
authoritative. It represents an assertion, typically made by a policy
server, with repect to a member of a security domain that the server
represents. The record includes the Identity of the policy server and
the identity of a node (host, security gateway, another server, etc.).
Figure 13 shows the format of the Policy Server Record.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CACHE-EXPIRY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FLAGS | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ POLICY SERVER IDENTITY ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ NODE IDENTITY ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Policy Server record format
The Policy Server Record fields are defined as follows:
CACHE-EXPIRY
A 4 octet field indicating the maximum amount of time,
in seconds, this policy record MAY be cached.
Sanchez, Condell [Page 28]
Internet Draft Security Policy System November 1998
FLAGS
A 2 octet field indicating different options to aid in
interpreting the server and node data. If not in use, set
value to all zeros (00)hex. Currently, no flag values are
defined so this field MUST be set to (00)hex.
RESERVED
A 2 octet field reserved for future use. If not in use, set
value to all zeros (00)hex.
POLICY SERVER IDENTITY
This variable length field contains the identity of the
policy server. It may contain an IP address (unicast)
either in IPv4 or IPv6 format. The encoding format is
specified in section 6 The acceptable DATA_TYPE values
are 1 and 2.
NODE IDENTITY
This variable length field contains the identity of a node
for which the policy server is authoritative. It may contain
an IP address (unicast) either in IPv4 or IPv6 format. The
encoding format is specified in section 6 The acceptable
DATA_TYPE values are 1 and 2.
8.5 CERT Record
The CERT record contains one public key certificate. This
record is provided in SPP as an alternate mechanism for certificate
dispatching. Figure 14 shows the format of the CERT Record.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CACHE-EXPIRY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CERT_TYPE | |
+-+-+-+-+-+-+-+-+ |
~ CERT_DATA ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Certificate Record Format
CACHE-EXPIRY
A 4 octet field indicating the maximum amount of time,
in seconds, this policy record MAY be cached.
Sanchez, Condell [Page 29]
Internet Draft Security Policy System November 1998
CERT_TYPE
This 1 octet field indicates the type of certificate or
certificate-related information contained in the Certificate
Data field. The values for this field are described in
Section 7.3.
CERT_DATA
This variable length field contains the actual encoding of
certificate data. The type of certificate is indicated by the
Certificate Type field.
9. SPP Message Processing
SPP messages use UDP or TCP as their transport protocol.
Messages carried by UDP are restricted to 512 bytes (not counting the
IP or UDP headers). Fragmentation is allowed for messages containing
more than 512 bytes. The SPP-XFR message SHOULD use TCP to transfer
the contents of the SPS Database from a primary to secondary policy
server. SPP uses UDP and TCP ports 501.
9.1 General Message processing
For an SPP-Query or SPP-Pol message, the transmitting entity
MUST do the following:
1. Set a timer and initialize a retry counter.
2. If an SPP-Reply or SPP-Pol_Ack message corresponding to the
appropriate SPP-Query or SPP-Pol message is received within the time
interval, or before the retry counter reaches 0, the transmitting
entity continues normal operation.
3. If an SPP-Reply or SPP-Pol_Ack message corresponding to the
appropriate SPP-Query or SPP-Pol message is not received within the
time interval, and a secondary policy server is available, the
message is sent to the secondary server. If a secondary server
does not exist the message is resent to the primary and the retry
counter is decremented.
4. If the retry counter reaches zero (0) the event should be logged
in the appropriate system audit file.
5. At this point, the transmitting entity will clear state for
this peer and revert to using conventional security mechanisms.
9.2 Query Message (SPP-Query) Processing
When creating a SPP-Query message, the entity (host, security gateway,
or policy server) MUST do the following:
1. Generate the Message ID value. This value starts at "zero" and
MUST be incremented by (01)hex with every new message.
2. Set the value of the MTYPE field to 01
3. Set the MCODE value to (00)hex.
4. Set the QCOUNT and RCOUNT fields. All fields MUST be
set to (00)hex when their corresponding payloads do no exist.
Sanchez, Condell [Page 30]
Internet Draft Security Policy System November 1998
5. Set the flag bits accordingly and set the RESERVED field to (00)hex.
6. Calculate and place the timestamp value used for anti-replay attack
protection.
7. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP
message.
8. Construct the SPP data payloads. A Query payload MUST be present
in this message.
9. Local policy information related to the query MAY be included as
Record payloads following the Query payloads.
10. If the Signature payload is required for message integrity and
authentication, calculate a signature over the SPP header, SPP
payloads, the PCL, TYPE, and LENGTH fields of the Signature
payload. If required, the Signature payload MUST be the last
payload in the message.
When a policy server receives an SPP-Query message it MUST do the
following:
1. Check for SPP access control. If enabled, read the IP address in the
Sender's field of the SPP header.
- Verify whether or not the message is allowed. If the message is
not allowed then:
o send an SPP_Reply message with the error code 02
o discard message and log EVENT if configured to do so
- If the message is allowed, continue.
2. Check timestamp field for anti-replay protection. If a replayed
message is detected:
- send an SPP_Reply message with the error code 03
- discard message and log EVENT if configured to do so
3. If the message requires signature validation.
- Fetch certificate or key corresponding to the IP address found
in the sender field of the SPP header.
- If a certificate or key is not available the entity MAY,
depending on configuration:
o choose to abort validation process, send SPP-Reply message
with error code 05, discard the message, and MAY log
the EVENT.
o send an SPP-Query message to the source of the IP address
found in the sender field of the SPP header with a CERT Query
payload. Keep the SPP-Query message until the SPP_Reply
returns. Extract certificate or key, validate it and
proceed.
Sanchez, Condell [Page 31]
Internet Draft Security Policy System November 1998
- Once a validated certificate or key is available then validate
signature.
o If validation fails, send SPP-Reply message with error
code 05, discard the message, and the EVENT MAY be logged.
4. Parse the Query record. Check the Destination Address Data field to
determine if the message received was intended for a node that is a
member of the server's security domain.
5. If the message is for a node that is a member of the server's
security domain then:
- Using src, dst, and any other applicable fields found in the
Query Payload, search the SPS database for an appropriate policy.
o If a policy is found then construct a SPP-Reply message per
section 9.3 with appropriate payloads
o If a policy is not found then construct a SPP-Reply message
per section 9.3 with appropriate payloads and error code.
6. If the message is for a node that is not part of the server's
security domain then:
- Check the Cache database for any relevant policies that apply to
this communication.
o If a policy is found then construct a SPP-Reply message per
section 9.3 with appropriate payloads
o If a policy is not found then continue.
- Check the Local database for any relevant policies that apply to
this communication.
- If a matching policy is found:
o Generate a new SPP-Query message repeating all payloads and
applicable fields. The Sender Address will be the address of
the server. The destination for this message MUST
be the one in the original SPP-Query received.
o Keep state. Upon reception of the corresponding SPP-Reply the
policy server MUST send an SPP-Reply addressed to sender of the
original SPP-Query.
- If a matching policy is not found then:
o The policy server MUST send the SPP-Query message unchanged.
The server MAY validate the authenticity of the message, if
neccessary, before forwarding it.
Sanchez, Condell [Page 32]
Internet Draft Security Policy System November 1998
9.3 Reply Message (SPP-Reply) Processing
When creating a SPP-Reply message, the policy server MUST do the
following:
1. Copy the Message ID value from the corresponding SPP-Query message
into the Message ID field.
2. Set the value of the MTYPE field to 02
3. Set the MCODE value.
4. Set the QCOUNT and RCOUNT fields. All fields MUST be
set to (00)hex when their corresponding payloads do no exist.
5. Set the flag bits accordingly and set the RESERVED field to (0).
6. Calculate and place the timestamp value used for anti-replay attack
protection.
7. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP
message.
8. Copy the Query payloads from the SPP-Query message to the
SPP-Reply message.
9. Construct the SPP data payload. Unless there is an error, at
least one record corresponding to each Query payload MUST be
present.
10. A policy server record and a CERT record MUST be added to the
SPP-Reply message if the server is not authoritative for the
source of the query (e.g., the address in the Source Address Data
field of the COMSEC Query payload) and,
1) The policy server is authoritative for the address found in
the Destination Address Data field of the query, or
2) The policy server is authoritative for the host in
the Sender ID of the previous reply, or
3) The policy server is authoritative for the host in the
Sender ID of the query to which this is a reply.
11. If the Signature payload is required for message integrity and
authentication, calculate a signature over the SPP header, SPP
payloads, the PCL, TYPE, and LENGTH fields of the Signature
payload. If present, the Signature payload MUST be the last
payload in the message.
12. The SPP-Reply message is sent to the host that is listed in
the Sender ID field of the SPP-Query to which this is a reply.
When a host or security gateway receives an SPP-Reply message it MUST
do the following:
1. Read the Message ID field. If the value does not match the value
of an outstanding SPP-Query message from a policy server then:
- silently discard the message and the event MAY be logged.
2. If Message ID matches, Check the timestamp field for anti-replay
protection. If a replayed message is detected the message is
silently discarded and the event MAY be logged.
Sanchez, Condell [Page 33]
Internet Draft Security Policy System November 1998
3. Establish if the message requires signature validation by
seraching for a Signature payload:
- if signature validation is required proceed with step 4.
- if signature validation is not required proceed with step 6.
4. Validate the signature on the message.
- Fetch certificate or key corresponding to the IP address found
in the sender field of the SPP header.
- If a certificate or key is not available the entity MAY:
o choose, depending on configuration, to abort validation
process, discard the message and MAY log the EVENT.
o send an SPP-query message to the source of the IP address
found in the sender field of the SPP header with a CERT query
payload. Keep SPP-Reply message until the corresponding
SPP_Reply returns. Extract certificate or key, validate it
and proceed.
5. Once a validated certificate or key is available then validate
signature.
If validation fails:
- the message is silently discarded and the EVENT MAY be logged
If validation succeeds, continue processing.
6. For Policy Servers, validate the chain of trust:
- For each Policy Server record, verify that the Policy Server
is authoritative over the Node. This may be done using
information contained in certificates.
- Use the Policy Server records to Create a chain of hosts from
the destination host to this policy server where two records
are linked if the Node in one is the Policy Server in another.
- If the chain has no breaks, then this policy server MUST be
authoritative over the sender of the reply, otherwise drop
the message and stop processing it.
- If the chain has one break, then the last policy server on
the chain MUST be the sender of the reply, otherwise drop
the message and stop processing it.
- If the chain has two or more breaks, then there is an error
in the chain so drop the message and stop processing it.
- Verify that the Policy Server that is authoritative over the
destination host is authoritative over ALL destination hosts
in the reply.
Sanchez, Condell [Page 34]
Internet Draft Security Policy System November 1998
7. If MCODE value is 2-10:
For hosts or security gateways:
- clear all the state and stop processing
For policy servers:
- create an SPP-Reply message using the same MCODE value.
8. If the reply received correponds to a Cert query and the MCODE is
either (01)hex, (08)hex (accept or partially unavailable) process
message that was held up waiting for the cert.
9. For Policy Servers:
- Search the Local Policy Database for a policy entry that
matches the policy expressed in Query payload.
- Merge the local and non-local policy information using the
policy resolution proccess outlined in section 11.
- If the merge fails send an SPP-Reply message with MCODE 10,
Communication Prohibited
- If the merge succeeds:
o cache policy information. This includes all Query and Record
payloads.
o send an SPP-Reply message with the resulting policy records
10. For hosts or security gateways:
- verify that the information in the Record payload corresponds
to the information in the Query payload.
- extract the records and create a policy entry in the SPD
according to local format. The policy is entered in the SPD ONLY
if local configuration allows.
9.4 Policy Message (SPP-Pol) Processing
When creating a SPP-Pol message, the entity (host, security gateway, or
policy server) MUST do the following:
1. Generate the Message ID value. This value starts at "zero" and
MUST be incremented by (01)hex with every new message.
2. Set the value of the MTYPE field to 03.
3. Set the MCODE value to (00)hex.
4. Set the RCOUNT field. The QCOUNT field MUST be set to (00)hex
since no query payloads exist.
5. Set the flag bits accordingly and set the RESERVED field to (0).
6. Calculate and place the timestamp value used for anti-replay attack
protection.
7. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP
message.
8. Construct the SPP data payloads. A Record payload MUST be present
in this message. Query payloads MUST NOT be present.
Sanchez, Condell [Page 35]
Internet Draft Security Policy System November 1998
9. If the Signature payload is required for message integrity and
authentication, calculate a signature over the SPP header, SPP
payloads, the PCL, TYPE, and LENGTH fields of the Signature
payload. If required, the Signature payload MUST be the
last payload in the message.
When a policy server receives an SPP-Pol message it MUST do the
following:
1. Check for SPP access control. If enabled, read the IP address in the
Sender's field of the SPP header.
- Verify whether or not the message is allowed. If the message is
not allowed then:
o send an SPP-Pol_Ack message with the error code 02
o discard message and log EVENT if configured to do so
- If the message is allowed, continue.
2. Check timestamp field for anti-replay protection. If a replayed
message is detected:
- send an SPP_Reply message with the error code 03
- discard message and log EVENT if configured to do so
3. If the message requires signature validation.
- Fetch certificate or key corresponding to the IP address found
in the sender field of the SPP header.
- If a certificate or key is not available the entity MAY,
depending on configuration:
o choose to abort validation process, send SPP-Pol_Ack message
with error code 05, discard the message and MAY log the
EVENT.
o send an SPP-Query message to the source of the IP address
found in the sender field of the SPP header with a CERT Query
payload. Keep SPP-Pol message until the SPP_Reply
returns. Extract certificate or key, validate it and
proceed.
- Once a validated certificate or key is available then validate
signature.
o If validation fails the message is silently discarded and the
EVENT MAY be logged
4. If signature was not required or upon successful validation of a
signature parse the payloads.
5. For hosts and security gateways:
Sanchez, Condell [Page 36]
Internet Draft Security Policy System November 1998
- extract the records and create a policy entry in the cache
database. The policy MAY be entered in the SPD, also, ONLY
if cofiguration allows.
6. For Policy Servers:
- extract the records and create a policy entry in the cache
database.
9.5 Policy Acknowledgement Message (SPP-Pol_Ack) Processing
When creating a SPP-Pol_Ack message, the policy server MUST do the
following:
1. Copy the Message ID value from the corresponding SPP-Pol message
into the Message ID field.
2. Set the value of the MTYPE field to 04
3. Set the MCODE value.
4. Set the QCOUNT and RCOUNT fields. All fields MUST be
set to (00)hex.
5. Set the flag bits accordingly and set the RESERVED field to (0).
6. Calculate and place the timestamp value used for anti-replay attack
protection.
7. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP
message.
8. Query or Record payloads MUST NOT be present.
9. If the Signature payload is required for message integrity and
authentication, calculate a signature over the SPP header, the
PCL, TYPE, and LENGTH fields of the Signature payload.
When a host, security gateway or policy server receives an
SPP-Pol_Ack message the entity MUST do the following:
1. Read the Message ID field. If the value does not match the value
of an outstanding SPP-Pol message from a policy server then:
- silently discard the message and the EVENT MAY be logged.
2. If Message ID matches then check the timestamp field for anti-replay
protection. If a replayed message is detected the message is
silently discarded and the EVENT MAY be logged.
3. If the message is original (not replayed) and the message requires
signature validation then:
- Fetch certificate or key corresponding to the IP address found
in the sender field of the SPP header.
- If a certificate or key is not available the entity MAY:
o choose, depending on configuration, to abort validation
process, discard the message and MAY log the EVENT.
Sanchez, Condell [Page 37]
Internet Draft Security Policy System November 1998
o send an SPP-query message to the source of the IP address
found in the sender field of the SPP header with a CERT Query
payload. Keep SPP-Pol_ack message until the SPP_Reply
returns. Extract certificate or key, validate it and
proceed.
4. Once a validated certificate or key is available then validate the
signature.
If validation fails:
- the message is silently discarded and the event MAY be logged
If validation succeeds:
- read the MCODE field and proceed accordingly. If no errors,
clear all the state for this message and proceed.
9.6 KeepAlive Message (SPP-KEEP_ALIVE) Processing
When creating an SPP-Keep_Alive message, the policy server MUST do the
following:
1. Generate the Message ID value. This value starts at "zero" and
MUST be incremented by (01)hex with every new message.
2. Set the value of the MTYPE field to (06)hex.
3. Set the MCODE value to (00)hex.
4. Set the QCOUNT and RCOUNT fields. All fields MUST be
set to (00)hex.
5. Set the flag bits accordingly and set the RESERVED field to (0).
6. Calculate and place the timestamp value used for anti-replay attack
protection.
7. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP
message.
8. Query or Record payloads MUST NOT be present.
9. If the Signature payload is required for message integrity and
authentication, calculate a signature over the SPP header, the
PCL, TYPE, and LENGTH fields of the Signature payload.
When a host or security gateway receives an SPP-Keep_Alive message it
MUST do the following:
1. Check for SPP access control. If enabled, read the IP address in the
Sender's field of the SPP header.
- Verify whether or not the message is allowed. If the message is
not allowed then discard message and log EVENT if configured to
do so.
2. Check timestamp field for anti-replay protection. If a replayed
message is detected discard message and log EVENT if configured to
do so.
3. If the message requires signature validation then:
- Fetch certificate or key corresponding to the IP address found
in the sender field of the SPP header.
Sanchez, Condell [Page 38]
Internet Draft Security Policy System November 1998
- If a certificate or key is not available the entity MAY
depending on configuration:
o choose to abort validation process, discard the message and
perhaps logged the event.
o send an SPP-Query message to the source of the IP address
found in the sender field of the SPP header with a CERT Query
payload. Keep SPP-Keep_Alive message until the SPP-Reply
returns. Extract certificate or key, validate it and
proceed.
- Once a validated certificate or key is available then validate
signature.
o If validation fails the message is silently discarded and the
event MAY be logged
4. If signature validation was not required or upon successful
validation of a signature, the EVENT MAY be logged.
10. Policy Decorrelation Process
It is not possible for a Policy Server to use policies as they
are written in the SPS master file, since those policies are likely to
be correlated. Two policies are correlated if there is a non-nil
intersection between the values of each of their selectors. Caching
correlated policies can lead to incorrect policy implementation based
on those cached policies, as the following example shows.
H1 --- SG1 --------- SG2 --- H2
| | \__ H3
| |
PS1 PS2
PS2 contains the following policies in its master file:
src dst proto direction action
1) * H2 * inbound permit
2) * * * inbound deny
These two policies are correlated since all the selectors (src, dst,
proto, and direction) overlap. The following SPP exchanges occur:
1) PS1 requests policy for H3.
2) PS2 returns policy #2 to PS1 which then caches policy #2.
3) PS1 now looks up the policy for H2 and discovers that it already
has a matching policy (policy #2) and uses that.
This is clearly wrong, since policy #2 indicates that the
communication to H2 should be denied, though PS2's policy actually
indicates that it should be allowed.
Sanchez, Condell [Page 39]
Internet Draft Security Policy System November 1998
The solution is to remove the ambiguities that may exist in
the master file. The policies of the master file MUST be decorrelated
before they are entered into the Local Policy Database. That is, the
policies must be rewritten so that for every pair of policies there
exists a selector for which there is a nil intersection between the
values in both of the policies.
The policies in the above example could be decorrelated as follows:
src dst proto direction action
1') * H2 * inbound permit
2') * not H2 * inbound deny
Now the exchange is a bit different:
1) PS1 requests policy for H3.
2) PS2 returns policy #2' to PS1 which then caches policy #2'.
3) PS1 now looks up the policy for H2, doesn't have a matching
policy, so it requests a policy for H2.
4) PS2 returns policy #1' to PS1 which then caches policy #1',
which is the correct policy for H2.
All SPAs and SPRs, therefore, MUST decorrelate their master
files before using those policies for SPP. Once the policies are
decorrelated, there is no longer any ordering requirement on the
policies, since only one policy will match any requested
communication. The next section describes decorrelation in more
detail and presents an algorithm that may be used to implement
decorrelation.
10.1 Decorrelation Algorithm
The basic decorrelation algorithm takes each policy in a
correlated set of policies and divides it up into a set of policies
using a tree structure. Those of the resulting policies that are
decorrelated with the uncorrelated set of policies are then added to
that decorrelated set.
The basic algorithm does not guarantee an optimal set of
decorrelated policies. That is, the policies may be broken up into
smaller sets than is necessary, though they will still provide all the
necessary policy information. Some extensions to the basic algorithm
are described later to improve this and improve the performance of the
algorithm.
C A set of ordered, correlated policies
Ci The ith policy in C.
U The set of uncorrelated policies being built from C
Ui The ith policy in U.
A policy P may be expressed as a mapping of selector values to
actions:
Pi = Si1 x Si2 x ... x Sik -> Ai
1) Put C1 in set U as U1
For each policy Cj (j > 1) in C
Sanchez, Condell [Page 40]
Internet Draft Security Policy System November 1998
2) If Cj is uncorrelated with every policy in U, then add it to U.
3) If Cj is correlated with one or more policies in U, create a tree
rooted at the policy Cj that partitions Cj into a set of uncorrelated
policies. The algorithm starts with a root node where no selectors
have yet been chosen.
A) Choose a selector in Cj, Scjn, that has not yet been chosen when
traversing the tree from the root to this node. If there are no
selectors not yet used, continue to the next unfinished branch
until all branches have been completeded. When the tree is
completed, go to step D.
T is the set of policies in U that are correlated with the policy
to this node.
The policy at this node is the policy formed by the selector values
of each of the branches between the root and this node. Any
selector values that are not yet represented by brances assume
the corresponding selector value in Cj, since the values in Cj
represent the maximum value for each selector.
B) Add a branch to the tree for each value of the selector Scjn that
appears in any of the policies in T. (If the value is a superset
of the value of Scjn in Cj, then use the value in Cj, since that
value represents the universal set.) Also add a branch for the
compliment of the union of all the values of the selector Scjn
in T. When taking the compliment, remember that the universal
set is the value of Scjn in Cj. A branch need not be created
for the nil set.
C) Repeat A and B until the tree is completed.
D) The policy to each leaf now represents a policy that is a subset
of Cj. The policies at the leaves completely partition Cj in
such a way that each policy is either completely overriden by
a policy in U, or is uncorrelated with the policies in U.
Add all the uncorrelated policies at the leaves of the tree to U.
5) Get next Cj and goto 2.
6) When all policies in C have been processed, then U will contain an
uncorrelated version of C.
Sanchez, Condell [Page 41]
Internet Draft Security Policy System November 1998
There are several optimizations that can be made to this algorithm.
A few of them are presented here.
It is possible to optimize, or at least improve, the amount of
branching that occurs by carefully choosing the order of the selectors
used for the next branch. For example, if a selector Scjn can be
chosen so that all the values for that selector in T are equal to or a
superset of the value of Scjn in Cj, then only a single branch need to
be created (since the compliment will be nil).
Branches of the tree do not have to procede with the entire
decorrelation algorithm. For example, if a node represents a policy
that is uncorrelated with all the policies in U, then there is no
reason to continue decorrelating that branch. Also, if a branch is
completely overridden by a policy in U, then there is no reason to
continue decorrelating the branch.
An additional optimization is to check to see if a branch is
overridden by one of the CORRELATED policies in set C that has alread
been decorrelated. That is, if the branch is part of decorrelating
Cj, then check to see if it was overridden by a policy Cm, m < j.
This is a valid check, since all the policies Cm are already expressed
in U.
Along with checking if a policy is already uncorrelated in
step 2, check if Cj is overriden by any policy in U. If it is, skip it
since it is not relevant. A policy x is overriden by another policy y
if every selector in x is equal to or a subset of the corresponding
selector in policy y. Appendix B shows an example of applying the
algorithm to a set of correlated policies.
11. Policy Resolution Process
When a policy server receives a reply (Section 9.3), it merges
its local policy for the communication with any non-local policies
contained in the reply. The merging process creates a new policy that
is the intersection of the local and remote policies. It then uses
the merged policy as its reply to the queryand caches it. The policy
resolution process is as follows:
1. Get local and remote policies for the requested communication.
2. Verify that the remote policy answer the query. This may be
accomplished by intersecting the query with each of the answers
to the query and verify that they have a non-nil intersection.
3. For each pair of endpoints described by the policy:
Sanchez, Condell [Page 42]
Internet Draft Security Policy System November 1998
- Find the intersection of the policies between these endpoints.
o If the intersection is nil, then the policies do not permit
the communication and an error should be returned. It is not
necessary to continue processing other endpoints.
o If the intersection is not nil, then the intersection should
be added to the reply policy.
4. The policy created by the intersections is the policy that should
be cached and used as a reply to the query.
Step 3 requires that the policy server must be able to determine all
the sets of endpoints described by the policy. The endpoint
information comes from two places: the source and destination
addresses in the query (which is possibly more specific than those
fields in the policies) and the location information in the
ipsec_action attribute.
The location information may offer the policy server some
flexibility in how it interprets endpoints for the communication. For
example, if the policy indicates a tunnel must be established with any
host or gateway in the source or destination host's domain, the policy
server can choose the endpoint within the bounds of the policy. This
choice can be made randomly, using a set policy (e.g., always choose
the outermost gateway permitted by the policy), or using additional
information the server may maintain for this purpose. For example,
the server may keep track of previous policy decisions it made and use
those as hints to which security associations may already exist. It
can then try to make decisions that will allow these security
associations to be reused.
12. Usage of SPS with IPSec
This section illustrates how the Security Policy System
operates and interacts with IPSec. It describes, step-by-step, the
process from the inital application call to the establishment of the
necessary security associations.
Sanchez, Condell [Page 43]
Internet Draft Security Policy System November 1998
admin. boundary admin. boundary
----------------- ---------------------------
| | | admin. boundary|
| | | ---------------|
| Q1 | Q2 | Q3 | ||
| H1 ---- SG1 ---- (Internet) --- SG2 ---- | SG3 --- H2 ||
| R3 | | R2 | | R1 | | ||
| PS1 | | PS2 | PS3 ||
| | | ---------------|
----------------- ---------------------------
ESP Tunnel
|===============================|
ESP Tunnel
|========================================|
ESP Transport
|================================================|
|==| = security association required by policy
---- = connectivity (or if so labeled, administrative boundary)
Hx = host x
SGx = security gateway x
PSx = policy server x
Qx = query x
Rx = reply x
1. User application attempts to send a message from H1 to H2
(e.g., finger somebody@H2)
2. IPSec on H1 gets the packet and finds a policy for it in the
Security Policy Database (SPD).
3. H1 does not have a security association for the communication and
asks the Key Management Protocol to establish the needed security
association.
4. The policy client in H1 is queried for the policy governing the
communication between H1 and H2.
5. H1's policy client creates an SPP query, Q1, and sends it to PS1,
its configured policy server.
6. PS1 receives the query. Its security domain database indicates that
it is not authoritative over H2 so it checks its cache to see if it
has a cached answer. For this example, it does not, so it creates
a new SPP query, Q2, with the query and sends it to H2.
7. SG2 intercepts Q2 and passes it to PS2.
8. PS2 receives the query. Its security domain database indicates that
it is not authoritative over H2 and PS2 determines it wants to be
involved in the communication. It checks its cache to see if it has
a cached answer. For this example, it does not, so it creates a new
SPP query, Q3, with the query and sends it to H2.
Sanchez, Condell [Page 44]
Internet Draft Security Policy System November 1998
9. SG3 intercepts Q3 and passes it to PS3.
10. PS3 receives the query. It checks its security domain database and
determines that it is authoritative over H2 so it will send a reply.
It checks its cache to see if it has a cached answer. For this
example, it does have one cached from previous information sent to
it by H2. The cached policy indicates ESP transport must be done
with H2 and ESP tunnel must be done with SG3.
11. PS3 creates two messages. One is an SPP reply message, R1, with the
policy indicating the required security associations, a security
server record indicating PS3 is authoritative over H2, and PS3's
certificate in a certificate record. The reply is sent to PS2.
The second message is an SPP policy message to signal SG3 that it
will need a security association with H1.
12. PS2 receives the R1. It verifies that PS3 is authoritative over
H2. It looks up its local policy and resolves it with the policy
in the reply. It caches the resolved policy and creates two messages.
One is the reply to PS1, R2, that contains the resolved policy, PS3's
security server and certificate records and a security server record
that states that PS2 is authoritative over PS3 and PS2's certificate.
The second message is an SPP policy message to signal SG2 that it
will need a security association with H1.
13. PS1 receives the R2. It verifies that PS2 is authoritative over PS3
and PS3 is authoritative over H2, forming a valid chain of trust.
It looks up its local policy and resolves it with the policy in the
reply. It caches the resolved policy and creates R3, a reply to H1.
R3 contains the resolved policy (the security server and certificate
records are no longer needed).
14. The policy client receives the R3 and returns it to the application
that queried for it. The policy indicates that the three security
associations must be established and they must be established in
a particular order.
15. The KMP is given this information and first creates a security
association with PS2 which it can use to set up the security
association with PS3. They both can be used to set up the security
association with H2.
16. Finally, the original message from the application can proceed using
the security associations.
If H2 wanted to get directly involved in the communication,
PS3 would not be authoritative over H2, H2 would be authoritative over
itself. There would then be another pair of messages where PS3 sends
a query to H2 which H2 receives and sends a reply back to PS3 and the
processing continues as outlined above.
Sanchez, Condell [Page 45]
Internet Draft Security Policy System November 1998
Acknowledgments
The authors thank Charles Lynn, Steve Kent and John Zao for their
participation in requirements discussions for the Security Policy
System. Our gratitude to Charlie Lynn, Matt Fredette, Alden Jackson,
Dave Mankins, Marla Shepard and Pam Helinek for the contributions to
this document. We thank Mary Hendrix (INS Corp.) for reviewing this
document. We thank Isidro Castineyra for his contributions to the
early parts of this work.
References
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", RFC2119, March 1997.
[Kent98] S. Kent, R. Atkinson, "Security Architecture for the
Internet Protocol", Internet Draft draft-ietf-ipsec-arch-sec-07,
July 1998.
[KA98b] S. Kent, R. Atkinson, "IP Encapsulating Security
Payload (ESP)", Internet Draft, July 1998.
[isakmp] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet
Security Association and Key Management Protocol (ISAKMP)", Internet
Draft draft-ietf-ipsec-isakmp-10, July 3, 1998
[ALX98] A. Vopilov, "The Locating an IPSec Gateway Algorithm",
Working Draft, February 1998.
[RFC1305] Mills, D., "Network Time Protocol (Version 3):
Specification, Implementation and Analysis", RFC 1305, March
1992.
[RFC2230] R. Atkinson, "Key Exchange Delegation Record for the DNS",
RFC 2230, The Internet Society, November 1997
[PKIXP1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public
Key Infrastructure: X.509 Certificate and CRL Profile".
Internet Draft draft-ietf-pkix-ipki-part1-10, September 1998.
[PolMod] R. Pereira, P. Bhattacharya, "IPSec Policy Data Model", Internet
Draft draft-ietf-ipsec-policy-model-00, February 1998
[Harkins98] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
Internet Draft draft-ietf-ipsec-isakmp-oakley-08, June 1998.
[Piper98] D. Piper, "The Internet IP Security Domain of
Interpretation for ISAKMP", Internet Draft
draft-ietf-ipsec-ipsec-doi-10.txt, July 1998
[SPSL] M. Condell, C. Lynn, J. Zao "Security Policy Specification
Language", Internet Draft draft-ietf-ipsec-spsl-00.txt,
November 1998
Sanchez, Condell [Page 46]
Internet Draft Security Policy System November 1998
APPENDIX A
DATA_TYPE Definitions
The encoding of each selector and SA attribute is decribed here.
Attributes generally encode "any" in one of two ways. If using
the TLV format (X = 0) then the length is set to 0 to indicate any.
If the TV format (X = 1) is used, then the value is set to 0;
Lists are generally expressed by setting the length of the value to a
multiple of the length of a single data value. The multiple used is
the number of elements in the list. If the selector or attribute
may express a list, each element is expressed the same as the element
described in DATA_VALUE.
This section describes the values and DATA_VALUE encoding for each
selector and SA attribute.
A.1 IPV4_ADDR
X 0
DATA_TYPE 1
LENGTH 4 if an IP address is present,
0 if no IP address is present.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2 IPV6_ADDR
X 0
DATA_TYPE 2
LENGTH 16 if an IP address is present,
0 if no IP address is present.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| ADDRESS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sanchez, Condell [Page 47]
Internet Draft Security Policy System November 1998
A.3 SRC_IPV4_ADDR
X 0
DATA_TYPE 3
LENGTH 4 times the number of addresses in the list.
A length of 0 indicates any address.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRC ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.4 SRC_IPV4_ADDR_SUBNET
X 0
DATA_TYPE 4
LENGTH 8 times the number of subnets in the list.
A length of 0 indicates any subnet.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBNET ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBNET MASK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.5 SRC_IPV4_ADDR_RANGE
X 0
DATA_TYPE 5
LENGTH 8 times the number of address ranges in the list.
A length of 0 indicates any address.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOWER BOUND SRC ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UPPER BOUND SRC ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sanchez, Condell [Page 48]
Internet Draft Security Policy System November 1998
A.6 DST_IPV4_ADDR
X 0
DATA_TYPE 6
LENGTH 4 times the number of addresses in the list.
A length of 0 indicates any address.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DST ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.7 DST_IPV4_ADDR_SUBNET
X 0
DATA_TYPE 7
LENGTH 8 times the number of subnets in the list.
A length of 0 indicates any subnet.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBNET ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUBNET MASK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.8 DST_IPV4_ADDR_RANGE
X 0
DATA_TYPE 8
LENGTH 8 times the number of address ranges in the list.
A length of 0 indicates any address.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOWER BOUND DST ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UPPER BOUND DST ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sanchez, Condell [Page 49]
Internet Draft Security Policy System November 1998
A.9 SRC_IPV6_ADDR
X 0
DATA_TYPE 9
LENGTH 16 times the number of addresses in the list.
A length of 0 indicates any address.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SRC |
| ADDRESS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.10 SRC_IPV6_ADDR_SUBNET
X 0
DATA_TYPE 10
LENGTH 32 times the number of subnets in the list.
A length of 0 indicates any subnet.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUBNET |
| ADDRESS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUBNET |
| MASK |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.11 SRC_IPV6_ADDR_RANGE
X 0
DATA_TYPE 11
LENGTH 32 times the number of address ranges in the list.
A length of 0 indicates any address.
list Yes
DATA_VALUE
Sanchez, Condell [Page 50]
Internet Draft Security Policy System November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LOWER BOUND |
| SRC ADDRESS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| UPPER BOUND |
| SRC ADDRESS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.12 DST_IPV6_ADDR
X 0
DATA_TYPE 12
LENGTH 16 times the number of addresses in the list.
A length of 0 indicates any address.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DST |
| ADDRESS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.13 DST_IPV6_ADDR_SUBNET
X 0
DATA_TYPE 13
LENGTH 32 times the number of subnets in the list.
A length of 0 indicates any subnet.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUBNET |
| ADDRESS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUBNET |
| MASK |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sanchez, Condell [Page 51]
Internet Draft Security Policy System November 1998
A.14 DST_IPV6_ADDR_RANGE
X 0
DATA_TYPE 14
LENGTH 32 times the number of address ranges in the list.
A length of 0 indicates any address.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LOWER BOUND |
| DST ADDRESS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| UPPER BOUND |
| DST ADDRESS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.15 DIRECTION
X 1
DATA_TYPE 15
LENGTH TV attribute, no length
list No
DATA_VALUE
1 2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIRECTION |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DIRECTION
In/Outbound 0
Inbound 1
Outbound 2
Direction is with respect to the senders interface.
A.16 USER_NAME
X 0
DATA_TYPE 16
LENGTH 1 plus the length of NAME
A length of 0 indicates any name.
list No
DATA_VALUE
Sanchez, Condell [Page 52]
Internet Draft Security Policy System November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TYPE | NAME ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NAME_TYPE
822_EMAIL 0
DIST_NAME 1
NAME
Name of type NAME.
[**** probably should describe in more detail]
A.17 SYSTEM_NAME
X 0
DATA_TYPE 17
LENGTH 1 plus the length of NAME
A length of 0 indicates any name.
list No
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TYPE | NAME ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NAME_TYPE
DNS_NAME 0
DIST_NAME 1
822_NAME 2
X400_ADDR 3
DIR_NAME 4
EDI_PARTY_NAME 5
URI 6
IPADDR 7
REGID 8
OTHER 255
NAME
Name of type NAME.
[***** probably should describe in more detail]
A.18 XPORT_PROTOCOL
X 0
DATA_TYPE 18
LENGTH 1 plus length of pdata
A length of 0 indicates any address.
list No (see below)
DATA_VALUE
Sanchez, Condell [Page 53]
Internet Draft Security Policy System November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PTYPE | PDATA ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PTYPE Describes the rest of the data:
ANY 0
OPAQUE 1
LIST 2
RANGE 3
PDATA
Not used if PTYPE is ANY or OPAQUE
LIST
indicates a list whose elements look like the following:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| PROTOCOL |
+-+-+-+-+-+-+-+-+
The length of pdata to be used as part of the LENGTH
field is 1 times the number of elements in the list.
RANGE
indicates a range of protocol values whose lower bound
is LOWER, and upper bound is UPPER.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOWER | UPPER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of pdata to be used as part of the LENGTH
field is 2.
A.19 SRC_PORT
X 0
DATA_TYPE 19
LENGTH 2 times the number of ports in the list.
A length of 0 indicates any port.
list Yes
DATA_VALUE
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sanchez, Condell [Page 54]
Internet Draft Security Policy System November 1998
A.20 SRC_PORT_DYNAMIC
X 0
DATA_TYPE 20
LENGTH 4 plus 2 times the number of ports in the list.
A length of 4 indicates any port.
list See Below
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DYNAMIC LOWER BOUND | DYNAMIC UPPER BOUND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT | ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The use of this attribute indicates that dynamic port allocation
is permitted. Communications that are intitiated with any of the
ports indicated, may then dynamically allocate any of the ports
listed within the LOWER and UPPER BOUNDS, inclusive.
DYNAMIC LOWER BOUND
Lower bound of the range of ports that may be dynamically
allocated. If this and DYNAMIC UPPER BOUND are both 0,
then any port may be dynamically allocated.
DYNAMIC UPPER BOUND
Upper bound of the range of ports that may be dynamically
allocated. If this and DYNAMIC LOWER BOUND are both 0,
then any port may be dynamically allocated.
PORT
Port that the communication must be initiated with. This
may be a list of ports.
A.21 DST_PORT
X 0
DATA_TYPE 21
LENGTH 2 times the number of ports in the list.
A length of 0 indicates any port.
list Yes
DATA_VALUE
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sanchez, Condell [Page 55]
Internet Draft Security Policy System November 1998
A.22 DST_PORT_DYNAMIC
X 0
DATA_TYPE 22
LENGTH 4 plus 2 times the number of ports in the list.
A length of 4 indicates any port.
list See Below
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DYNAMIC LOWER BOUND | DYNAMIC UPPER BOUND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT | ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The use of this attribute indicates that dynamic port allocation
is permitted. Communications that are intitiated with any of the
ports indicated, may then dynamically allocate any of the ports
listed within the LOWER and UPPER BOUNDS, inclusive.
DYNAMIC LOWER BOUND
Lower bound of the range of ports that may be dynamically
allocated. If this and DYNAMIC UPPER BOUND are both 0,
then any port may be dynamically allocated.
DYNAMIC UPPER BOUND
Upper bound of the range of ports that may be dynamically
allocated. If this and DYNAMIC LOWER BOUND are both 0,
then any port may be dynamically allocated.
PORT
Port that the communication must be initiated with. This
may be a list of ports.
A.23 SEC_LABELS
X 0
DATA_TYPE 23
LENGTH Variable.
list No
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SECURITY LABEL ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.24 V6CLASS
X 1
DATA_TYPE 24
LENGTH TV attribute, no length
list No
Sanchez, Condell [Page 56]
Internet Draft Security Policy System November 1998
DATA_VALUE
1 2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PADDING | CLASS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PADDING set to 0
CLASS class value
A.25 V6FLOW
X 0
DATA_TYPE 25
LENGTH 4
list No
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PADDING | FLOW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PADDING set to 0
FLOW set to flow value
A.26 V4TOS
X 1
DATA_TYPE 26
LENGTH TV attribute, no length
list No
DATA_VALUE
1 2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PADDING | TOS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PADDING set to 0
TOS type of service value
A.27 ACTION
X 1
DATA_TYPE 27
LENGTH TV attribute, no length
list No
Sanchez, Condell [Page 57]
Internet Draft Security Policy System November 1998
DATA_VALUE
1 2 3
6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACTION |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DIRECTION
Deny 0
Permit 1
A.28 SRC_PORT_RANGE
X 0
DATA_TYPE 28
LENGTH 4 times the number of port ranges in the list.
A length of 0 indicates any port.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT LOWER BOUND | PORT UPPER BOUND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.29 DST_PORT_RANGE
X 0
DATA_TYPE 29
LENGTH 4 times the number of port ranges in the list.
A length of 0 indicates any port.
list Yes
DATA_VALUE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT LOWER BOUND | PORT UPPER BOUND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.30 IPSEC_ACTION
X 0
DATA_TYPE 50
LENGTH Variable
list Yes
DATA_VALUE
Sanchez, Condell [Page 58]
Internet Draft Security Policy System November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----
| PFS | ESP | CIPHER_ALG | INTEGRITY_ALG | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| KEYLENGTH | ROUNDS | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| GROUP | LIFETIME_TYPE | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| LIFETIME | Fixed
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length
| PFS | AH | INTEGRITY_ALG | RESERVED | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| GROUP | LIFETIME_TYPE | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| LIFETIME | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| PFS | IPCOMP_ALG | LIFETIME_TYPE | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| LIFETIME | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----
| LOC_TYPE | LOC_SRC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC_TYPE | LOC_DST...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC_TYPE | LOC_SRC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Variable
| LOC_TYPE | LOC_DST... Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC_TYPE | LOC_SRC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC_TYPE | LOC_DST...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PFS
FALSE 0
TRUE 1
ESP
NOT_REQUIRED 0
TUNNEL_MODE 1
TRANSP_MODE 2
CIPHER_ALG
NONE 0
ANY 1
RFC1829_IV64 2
DES 3
DES3 4
RC5 5
IDEA 6
CAST 7
Sanchez, Condell [Page 59]
Internet Draft Security Policy System November 1998
BLOWFISH 8
3IDEA 9
RFC1829_IV32 10
RC4 11
KEYLENGTH
The first octet corresponds to the minimum value and the
second octet corresponds to the maximum value. If no range
exist the first octet indicates the keylength. The second
octet contains a value of (00)hex.
ROUNDS
The first octet corresponds to the minimum value and the
second octet corresponds to the maximum value. If no range
exist the first octet indicates the rounds. The second
octet contains a value of (00)hex.
INTEGRITY_ALG
NONE 0
ANY 1
HMAC_MD5 2
HMAC_SHA1 3
HMAC_DES 4
KEYED_MD5 5
HMAC_RIPEM 6
GROUP
MODP (modular exponentiation group) 1
ECP (elliptic curve group over GF[P]) 2
EC2N (elliptic curve group over GF[2^N]) 3
values 4-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties.
LIFETIME_TYPE
This 2 octet field indicates type of lifetime.
seconds 1
kilobytes 2
values 3-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties.
LIFETIME
This 4 octet field indicates the SA lifetime. For a given
"Lifetime_Type" the value of the "Lifetime" attribute
defines the actual length of the SA life-- either a number of
seconds, or a number of kilobytes protected.
Sanchez, Condell [Page 60]
Internet Draft Security Policy System November 1998
LOC_TYPE
This 1 octet field indicates the contents of the LOC_SRC or
LOC_DST field. If this field is 0 then the LOC_SRC or LOC_DST
will be omitted.
0 NONE
1 IPv4 address
2 IPv6 address
3 DNS Name
4 Defaults
LOC_SRC
Variable length field depending on LOC_TYPE. IF LOC_TYPE is (04)
then this field is 1 octet in length an it may only take the
following fields:
1 ANY
2 DEST
3 HOST
4 LOCAL-SG
5 REMOTE-SG
LOC_DST
See LOC_SRC.
AH
NOT_REQUIRED 0
TUNNEL_MODE 1
TRANSP_MODE 2
IPCOMP_ALG
ANY 0
OUI 1
DEFLATE 2
LZS 3
V42BIS 4
RESERVED
This 1 or 2 octet field (see paylaod formats above) is
primarily used for padding purposes. Its value is always 0.
A.31 ISAKMP_ACTION
X 0
DATA_TYPE 51
LENGTH 13 BYTES
list No
DATA_VALUE
Sanchez, Condell [Page 61]
Internet Draft Security Policy System November 1998
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MODE | CIPHER_ALG | KEYLENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HASH_ALG | RESERVED | GROUP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LIFETIME_TYPE | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LIFETIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MODE
This octet indicates the IKE mode of operation.
MAIN 0
AGRESSIVE 1
CIPHER_ALG
This octet indicates which cipher should be used for the
ISAKMP phase 1 negotiation.
ANY 0
DES 1
IDEA 2
BLOWFISH 3
RC5 4
DES3 5
CAST 6
KEYLENGTH
The first octet corresponds to the minimum value and the
second octet corresponds to the maximum value. If no range
exist the first octet indicates the keylength. The second
octet contains a value of (00)hex.
HASH_ALG
This octet indicates which algorithm should be used for the
ISAKMP phase 1 negotiation.
ANY 0
MD5 1
SHA1 2
TIGER 3
Sanchez, Condell [Page 62]
Internet Draft Security Policy System November 1998
GROUP
This 2 octet field indicates which group should be used during
the ISAKMP phase 1 or phase 2 negotiation.
MODP (modular exponentiation group) 1
ECP (elliptic curve group over GF[P]) 2
EC2N (elliptic curve group over GF[2^N]) 3
values 4-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties.
LIFETIME_TYPE
This 2 octet field indicates type of lifetime.
seconds 1
kilobytes 2
values 3-65000 are reserved to IANA. Values 65001-65535 are for
private use among mutually consenting parties.
LIFETIME
This 4 octet field indicates the SA lifetime. For a given
"Lifetime_Type" the value of the "Lifetime" attribute defines
the actual length of the SA life-- either a number of seconds,
or a number of kilobytes protected.
RESERVED
This 1 or 2 octet field (see paylaod formats above) is
primarily used for padding purposes. Its value is always 0.
Note: for the variable-size fields (i.e., LOC_SRC and LOC_DST), add
padding until the 4-octet boundary. Since the LEN of the LOC_SRC or
LOC_DST fields is known the receiver can parse the field and then
discard the rest of the bits through the 4-octet boundary.
Sanchez, Condell [Page 63]
Internet Draft Security Policy System November 1998
APPENDIX B
Decorrelation Example.
This appendix demonstrates the decorrelation algorithm on a sample
set of policies. This uses the optimizations presented.
The correlated policy set C:
src dst prot sport dport user sec level
C1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec
C2 199.93/16 199.100.2/24 TCP * * lsanchez conf
C3 199.93/16 199.100.2/24 UDP * * lsanchez *
C4 199.93/16 199.100.2/24 UDP * 52 * *
C5 199.93/16 199.100.2/24 * * * * *
C6 * * * * * * *
B.1 policy C1
src dst prot sport dport user sec level
C1: 199.93/16 199.100.2/24 TCP * 22 lsanchez sec
By step 1, C1 becomes U1:
The current uncorrelated policy set:
U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec
B.2 policy C2
src dst prot sport dport user sec level
C2: 199.93/16 199.100.2/24 TCP * * lsanchez conf
C2 is uncorrelated with U1 because the security levels do not overlap.
By step 2, C2 is added to U.
The current uncorrelated policy set:
U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec
U2 199.93/16 199.100.2/24 TCP * * lsanchez conf
B.3 policy C3
src dst prot sport dport user sec level
C3: 199.93/16 199.100.2/24 UDP * * lsanchez *
C3 is uncorrelated with U because it uses UDP while both policies in
U use TCP. By step 2, C3 is added to U.
The current uncorrelated policy set:
U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec
U2 199.93/16 199.100.2/24 TCP * * lsanchez conf
U3 199.93/16 199.100.2/24 UDP * * lsanchez *
Sanchez, Condell [Page 64]
Internet Draft Security Policy System November 1998
B.4 policy C4
src dst prot sport dport user sec level
C4: 199.93/16 199.100.2/24 UDP * 52 * *
T = U o
nil /| (src) 199.93/16
T = U o
nil /| (dst) 199.100.2/24
T = U o
nil /| (sport) *
T = U o
/ \
~lsanchez / \ (user) lsanchez
We can end the algorithm here, since
1) the ~lsanchez branch:
199.93/16 199.100.2/24 UDP * 52 ~lsanchez *
is uncorrelated with T since ~lsanchez does not overlap any policies
in T.
2) The lsanchez branch:
199.93/16 199.100.2/24 UDP * 52 lsanchez *
is overriden by the policy U3.
The current uncorrelated policy set:
U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec
U2 199.93/16 199.100.2/24 TCP * * lsanchez conf
U3 199.93/16 199.100.2/24 UDP * * lsanchez *
U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez *
Sanchez, Condell [Page 65]
Internet Draft Security Policy System November 1998
B.5 policy C5
src dst prot sport dport user sec level
C5: 199.93/16 199.100.2/24 * * * * *
T = U o
nil /| (src) 199.93/16
T = U o
nil /| (dst) 199.100.2/24
T = U o
nil /| (sport) *
T = U o
_______/|\_______
~UDP,~TCP / | \ (prot) UDP
| o T=U3,U4
| TCP |\_________
| | \
| | lsanchez | (user) ~lsanchez
T=U1,U2 o o T = U4
/ \ (user) / \
~lsanchez / \ lsanchez ~52 / \ (dport) 52
|
T=U1,U2 o
_________/|\_________
~sec,~conf / | \ (sec label) conf
| sec
|
T = U1 o
/ \
~22 / \ (dport) 22
We can end the algorithm here since:
1) The branch:
199.93/16 199.100.2/24 ~UDP,~TCP * * * *
is uncorrelated with T = U.
2) The branch:
199.93/16 199.100.2/24 UDP * * lsanchez *
is overridden by U3.
3) The branch:
199.93/16 199.100.2/24 UDP * ~52 ~lsanchez *
is uncorrelated with T = U4.
4) The branch:
199.93/16 199.100.2/24 UDP * 52 ~lsanchez *
is overridden by U4.
5) The branch:
199.93/16 199.100.2/24 TCP * * ~lsanchez *
is uncorrelated with T = U1, U2.
Sanchez, Condell [Page 66]
Internet Draft Security Policy System November 1998
6) The branch:
199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf
is uncorrelated with T = U1, U2.
7) The branch:
199.93/16 199.100.2/24 TCP * * lsanchez conf
is overridden by U2.
8) The branch:
199.93/16 199.100.2/24 TCP * ~22 lsanchez sec
is uncorrelated with T = U1.
9) The branch:
199.93/16 199.100.2/24 TCP * 22 lsanchez sec
is overridden by U1.
The current uncorrelated policy set:
U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec
U2 199.93/16 199.100.2/24 TCP * * lsanchez conf
U3 199.93/16 199.100.2/24 UDP * * lsanchez *
U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez *
U5 199.93/16 199.100.2/24 ~UDP,~TCP * * * *
U6 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez *
U7 199.93/16 199.100.2/24 TCP * * ~lsanchez *
U8 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf
U9 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec
B.6 policy C6
src dst prot sport dport user sec level
C6: * * * * * * *
T = U o
/|
~199.93/16 / | (src) 199.93/16
T = U o
/|
~199.100.2/24 / | (dst) 199.100.2/24
We can end the algorithm here since:
1) The branch:
~199.93/16 * * * * * *
is uncorrelated with all the policies in T.
2) The branch:
199.93/16 ~199.100.2/24 * * * * *
is uncorrelated with all the policies in T.
3) The branch:
199.93/16 199.100.2/24 * * * * *
is overridden by policy C5.
Sanchez, Condell [Page 67]
Internet Draft Security Policy System November 1998
The uncorrelated version of C:
U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec
U2 199.93/16 199.100.2/24 TCP * * lsanchez conf
U3 199.93/16 199.100.2/24 UDP * * lsanchez *
U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez *
U5 199.93/16 199.100.2/24 ~UDP,~TCP * * * *
U6 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez *
U7 199.93/16 199.100.2/24 TCP * * ~lsanchez *
U8 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf
U9 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec
U10 199.93/16 ~199.100.2/24 * * * * *
U11 ~199.93/16 * * * * * *
Sanchez, Condell [Page 68]
Internet Draft Security Policy System November 1998
Disclaimer
The views and specification here are those of the authors and are
not necessarily those of their employers. The authors and their
employers specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
specification.
Copyright (C) The Internet Society (November 1997). All
Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above
are perpetual and will not be revoked by the Internet Society or
its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Author Information
Luis A. Sanchez Matthew N. Condell
BBN Technologies BBN Technologies
GTE Internetworking GTE Internetworking
10 Moulton Street 10 Moulton Street
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
Email: lsanchez@bbn.com Email: mcondell@bbn.com
Telephone: +1 (617) 873-3351 Telephone: +1 (617) 873-6203
Sanchez, Condell [Page 69]
