[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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]