Internet Engineering Task Force Authors:
INTERNET DRAFT R. Rajan, S. Kamat
IBM
P. Bhattacharya
Cisco
26/February/1999
Networking Policy Condition Information Model
draft-ietf-policy-conditions-00.txt
Status of Memo
This document is an Internet-Draft and is in full
conformance with all the provisions of Section 10 of RFC2026
except for the right to produce derivative works.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document defines an information model for
networking policy conditions as part of the general
information model for representing networking policy
defined in draft-ietf-policy-core-schema-02.txt. The
information model described in this document is focussed
on the structural class networkingPolicyCondition
that extends the class policyCondition described
draft-ietf-policy-core-schema-02.txt. Five auxiliary
rajan,kamat,bhattacharya Expires 25/August/1999 [Page i]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
classes are defined to describe conditions that refer to
(1) the communicating hosts, (2) the communicating users
(3) application data (4) routing information at the device
enforcing the policy and (5) layer 2 or data link layer
information of the device. This document is based on the
QoS and IPSec schema first described in [3] and [4].
rajan,kamat,bhattacharya Expires 25/August/1999 [Page ii]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
1. Introduction
This document extends the Policy Framework Core Information
Model Class Hierarchy (PFCIM)[1] which presents a schema for
representing networking policies. The schema contains five core
classes: policyGroup, policyRule, policyCondtion, policyAction, and
policyValidityPeriodCondition. The classes comprising the PFCIM
are intended to serve as an extensible class hierarchy (through
specialization) for defining policy objects that enable application
developers, network administrators, and policy administrators to
represent policies of different types. Please refer to [1] for
details on the classes and their relationships to one another.
Policy conditions are meant to represent criteria that administrators
use in enforcing control over behavior of devices or users in a
network. This document is NOT concerned with all possible conditions
that may arise with respect to computing and communication devices.
It is particularly targeted at the needs of controlling resource
usage and securing communication between users in an IP network.
As mandated by the policy working group, the ability to represent
policy requirements of integrated services with RSVP, differentiated
services and IPSec are the first targets of this effort.
In keeping with the focus of this effort, we identify 5
conditional categories that are commonly used by administrators
in controlling access to network resources and services. These
are host, user, application and routing and layer 2 or data
link layer information. We extend the class policyCondition to
the subclass networkingPolicyCondition, and define 5 auxiliary
classes: hostConditionAuxClass, userConditionAuxClass,
applicationConditionAuxClass, routeConditionAuxClass and
layer2ConditionAuxclass. The auxiliary classes may be attached to
networkingPolicyCondition in order to create fully formed conditional
statements that are appropriately structured for the purpose at hand.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, reference
[5].
2. Extending policyCondition
2.1. The Class Hierarchy
As defined in [1] the class policyCondition inherits from the
class top. We extend the class policyCondition to the subclass
netwokingPolicyCondition. The class netwokingPolicyCondition has 5
auxiliary classes: hostConditionAuxClass, userConditionAuxClass,
rajan,kamat,bhattacharya Expires 25/August/1999 [Page iii]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
applicationConditionAuxClass, routeConditionAuxClass and
layer2ConditionAuxclass.
top
|
|
|----policyCondition
| |
| networkingPolicyCondition ~~~~~
| |(auxiliary classes)
|-----------------hostConditionAuxClass
|---------------- userConditionAuxClass
|-----------------applicationConditionAuxClass
|-----------------routeConditionAuxClass
|-----------------layer2ConditionAuxClass
2.2. Class Definitions
The class definition of policyCondition, repeated from [1] is as
follows:
NAME policyCondition
DESCRIPTION A class representing a condition to be evaluated
in conjunction with a policy rule.
DERIVED FROM top
TYPE structural
AUXILIARY CLASSES none
POSSIBLE SUPERIORS policyRule
OID <to be assigned>
MUST cn
PolicyConditionName
MAY
The class policyCondition is specialized to networkingPolicyCondition
for extensibility. The class definition is as follows:
NAME networkingPolicyCondition
DESCRIPTION A class representing a networking condition to be
evaluated in conjunction with a policy rule.
DERIVED FROM policyCondition
TYPE structural
AUXILIARY CLASSES hostConditionAuxClass
userConditionAuxClass
applicationConditionAuxClass
routeConditionAuxClass
layer2ConditionAuxClass
POSSIBLE SUPERIORS policyRule
rajan,kamat,bhattacharya Expires 25/August/1999 [Page iv]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
OID <to be assigned>
MUST
MAY
The following auxiliary classes are used to append attributes to the
class networkingPolicyCondition.
NAME hostConditionAuxClass
DESCRIPTION An auxiliary class representing a condition to be
evaluated in conjunction with a policy rule. The
condition is based on the communicating end hosts.
DERIVED FROM top
TYPE auxiliary
AUXILIARY CLASSES none
POSSIBLE SUPERIORS networkingPolicyCondition
OID <to be assigned>
MUST
MAY sourceIPAddressRange
destinationIPAddressRange
sourceHostID
destinationHostID
NAME userConditionAuxClass
DESCRIPTION An auxiliary class representing a condition to be
evaluated in conjunction with a policy rule. The
condition is based on the communicating users.
DERIVED FROM top
TYPE auxiliary
AUXILIARY CLASSES none
POSSIBLE SUPERIORS networkingPolicyCondition
OID <to be assigned>
MUST
MAY senderID
receiverID
NAME applicationConditionAuxClass
DESCRIPTION An auxiliary class representing a condition to be
evaluated in conjunction with a policy rule. The
condition is based on the nature of traffic, the
transport layer in use and the application.
DERIVED FROM top
TYPE auxiliary
AUXILIARY CLASSES none
POSSIBLE SUPERIORS networkingPolicyCondition
OID <to be assigned>
MUST
MAY applicationName
rajan,kamat,bhattacharya Expires 25/August/1999 [Page v]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
sourcePortRange,
destinationPortRange,
protocolNumberRange,
receivedTOSByteCheck
NAME routeConditionAuxClass
DESCRIPTION An auxiliary class representing a condition to be
evaluated in conjunction with a policy rule. The
condition is based on the routing of the packet
through a device e.g. incoming and outgoing
interfaces.
DERIVED FROM top
TYPE auxiliary
AUXILIARY CLASSES none
POSSIBLE SUPERIORS networkingPolicyCondition
OID <to be assigned>
MUST
MAY interface
NAME layer2ConditionAuxClass
DESCRIPTION An auxiliary class representing a condition to be
evaluated in conjunction with a policy rule. The
condition is based on the nature of traffic, the
transport layer in use and the application
generating data.
DERIVED FROM top
TYPE auxiliary
AUXILIARY CLASSES none
POSSIBLE SUPERIORS networkingPolicyCondition
OID <to be assigned>
MUST
MAY sourceMACAddress
destinationMACAddress
802.1QVLANId
SNAPHeaderValue
etherTypeValue
DSAP
SSAP
encapsulationType
encapsualtionValue
rajan,kamat,bhattacharya Expires 25/August/1999 [Page vi]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
2.3. Rationale behind the class structure
There are two design choices that we need to justify in the manner
of extending policyCondition. First, the decision to choose
particular condition categories and the second the choice of class
structures, especially the use of auxiliary classes. The three
categories - users, hosts and applications - are very natural to
administrative decision making. The need to define policies in terms
of a dynamic category such as routing requires some explanation,
however. Consider, for instance, a corporation that has its
campuses connected by a leased line infrastructure with a backup
connection over the internet. When the primary network is down, it
is prudent policy to require that inter-campus traffic be encrypted.
There are many ways to enforce this, for instance instruct access
routers to encrypt traffic based on the destination as well as the
outgoing interface. Similar examples may be considered for QoS as
well, where a high grade reservation is made over a primary ISP
backbone, with a lower grade backup reservation triggered by routing
changes. A number of different class hierarchies are feasible
even when we have determined the categories we wish to represent,
and their attributes. For instance, one choice would have been to
associate all the attributes of users, applications, hosts, etc,
to the class policyCondition. Why subclass at all? The answer
is extensibility. Suppose the same information model is used to
represent policy conditions for DHCP. While we would like to have
host attributes to express this condition, layer 2 attributes may
be totally irrelevant. The subclass networkingPolicyCondition
allows us to group all the conditions required for the purpose of
expressing networking policy without requiring that all extensions
have the same condition attributes. Now the design choice that
comes directly from the above is to associate all attributes we
want - those of users, hosts, applications, etc - all the class
networkingPolicyCondition (as optional attributes, say). Will this
not have the same result as the structure presented above? The issue
again is extensibility. If one vendor desires to extend the category
application, a second only wants to represent users in greater
depth, and a third wants to do both, then they dont have to extend
networkingPolicyCondition in slightly different ways. Further,
the auxiliary classes hostPolicyAuxClass, etc, may be associated
with other subclasses of policyCondition, DHCPpolicyCondition for
instance, in a selective manner. Finally, the advantage of auxiliary
classes is that they allow us to mix and match attributes creating
fewer objects, when compared to subclasses.
3. Attributes of HostConditionAuxClass
NAME sourceIPAddressRange
rajan,kamat,bhattacharya Expires 25/August/1999 [Page vii]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
DESC Source IP addresses to which the policy applies
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
FORMAT sourceIPAddressRange may be described in any of the
following formats.
1 The string ``1''
Indicates policy applies to locally generated packets.
2-<IPv4Address>-<CIDRPrefixLength>
Three dash (-) seperated strings. The IP-v4
address is in dotted decimal format. The
CIDRPrefixLength is the number of unmasked leading
bits. A packet matches the condition if the
unmasked bits on the packet are identical to the
unmasked bits on the condition.
3-<IPv4Address>-<IPv4Address>
IP-v4 addresses in dotted decimal format. The
second address must be no smaller than the first.
The first denotes the start of the range, and the
second denotes the end of the range. A packet
matches the condition if its source address is no
smaller than the first IP address in the
condition, and no larger than the second.
4-<IPv6Address>-<IPv6Address>
IP-v6 addresses in any of the formats supported in
RFC 2373. The second address must be no smaller
than the first. The first denotes the start of the
range, and the second denotes the end of the
range. A packet matches the condition if its
source address is no smaller than the first
address in the condition, and no larger than the
second.
DEFAULT Defaults to the entire address range, i.e., every
packet matches the source address range condition.
EXAMPLES 2-83.23.23.1-24
A packet with source address 83.23.23.5 matches.
A packet with source address 83.23.24.1 does not.
3-83.23.23.0-83.28.28.0
A packet with source address 83.23.23.5 matches.
A packet with source address 83.29.24.1 does not.
NAME destinationIPAddressRange
rajan,kamat,bhattacharya Expires 25/August/1999 [Page viii]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
DESC destination IP addresses to which policy applies
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
FORMAT Identical to that of sourceIPAddressRange above.
The value of ``1''indicates a locally destined
packet.
DEFAULT Defaults to the entire address range, i.e., every
packet matches the destination address range
condition.
NAME sourceHostID
DESC Source Host Identifier
SYNTAX IA5String
EQUALITY caseExact1A5Match
MULTI-VALUED
FORMAT Two strings, colon (`:) seperated, the first
describing the ID type and the second the ID
value. The following IdTypes and their
corresponding values are as defined in [2].
Host-FQDN:<ID>
X500-DN:<ID>
X500-GN:<ID>
Key-Id:<ID>
DEFAULT Any ID is considered valid.
NAME destinationHostID
DESC Destination Host Identifier
SYNTAX IA5String
EQUALITY caseExact1A5Match
MULTI-VALUED
DEFAULT Any ID is considered valid.
FORMAT Same as SourceHostID.
4. Attributes of UserConditionAuxClass
NAME senderID
DESC Source User Identifier
SYNTAX IA5String
EQUALITY caseExact1A5Match
MULTI-VALUED
FORMAT Two strings colon (:) seperated, the first
describing the ID type and the second the ID
value. The following ID Types and their
corresponding values are as defined in [2].
User-FQDN:<ID>
X500-DN:<ID>
rajan,kamat,bhattacharya Expires 25/August/1999 [Page ix]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
X500-GN:<ID>
Key-Id:<ID>
DEFAULT Any ID is considered valid.
NAME receiverID
DESC Destination User Identifier
SYNTAX IA5String
EQUALITY caseExact1A5Match
MULTI-VALUED
DEFAULT Any ID is considered valid.
FORMAT Same as SourceHostID.
5. Attributes of ApplicationConditionAuxClass
NAME sourcePortRange
DESC Source Ports to which policy applies
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
FORMAT String consisting of two colon separated positive
integers, the second no smaller than the first, or
one positive integer.
DEFAULT Defaults to the entire port range 0 to 65535, i.e.
every packet matches the destination address range
condition.
EXAMPLE 8000:8080 (ports 8000 to 8080),
8000 (only port 8000)
NAME destinationPortRange
DESC Destination Ports to which policy applies
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
FORMAT String consisting of two colon separated positive
integers, the second no smaller than the first, or
one positive integer.
DEFAULT Defaults to the entire port range 0 to 65535, i.e.
every packet matches the source address range
condition.
NAME protocolNumberRange
DESC Protocol numbers to which policy applies
SYNTAX INTEGER
EQUALITY integerMatch
MULTI-VALUED
FORMAT String consisting of two colon separated positive
integers, the second no smaller than the first, or
rajan,kamat,bhattacharya Expires 25/August/1999 [Page x]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
one positive integer.
DEFAULT Defaults to the entire protocol range 0 to 255,
i.e., every packet matches the ip protocol range
condition.
EXAMPLE 50:51 (protocol 50 to 51),
50 (only protocol 50)
NAME receivedTOSByteCheck
DESC A condition attribute used to select traffic based
on the contents of the TOS byte of the received
packet's IP header
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
FORMAT String of the form xxxxxxxx:xxxxxxxx, where each
of the x's is either 0 or 1.
SEMANTICS Each of the substrings is treated as specifying an
8-bit field. The left substring is termed Mask and
the right substring Match. The TOS byte of the
received packet's IP header is ANDed with Mask and
the result is compared against Match. The
combination of Mask and Match allows definition of
TOS byte based conditions where certain bits in
the TOS byte may be ignored for the purpose of
comparison. Note that <Mask> is superior to
<Match> in that TOS bit positions corresponding to
a Mask bit of 0 are ignored irrespective of the
corresponding <Match> bit.
EXAMPLE An incoming packet with TOS byte 11001010 matches
the condition specified by a value of
00111100:00001000 for receivedTOSByte.
6. Attributes of RouteConditionAuxClass
NAME interface
DESC An attribute that limits the scope of the policy
to packets on specified interface(s) and the
direction(s) of traffic on these.
SYNTAX IA5String
EQUALITY caseExactIA5Match
MULTI-VALUED
FORMAT Three colon separated strings. The left-most
string is a numeral denoting the type of the
specification, followed by the incoming and
outgoing interface identifiers. Currently defined
type/value formats are
rajan,kamat,bhattacharya Expires 25/August/1999 [Page xi]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
1-<IPv4Address>-<IPv4Address>
2-<IPv6Address>-<IPv6Address>
3-<InterfaceID>-<InterfaceID>
The IP addresses are in dotted decimal notation.
The interface IDs are integers unique to the host
device. The first address string specifies a
restriction of the rule to traffic inbound on the
interface, and the rightmost string specifies a
corresponding restriction of the rule to traffic
outbound from that interface. An unspecified
interface(s) defaults to all interfaces on the
device that this rule applies to.
DEFAULTS Defaults to traffic inbound on all interfaces,
outbound on all interfaces.
EXAMPLE 1-9.3.1.52-9.2.1.54
(Applies to traffic inbound on 9.3.1.52
and outbound on 9.3.1.54)
1-9.3.1.32-
(Applies to traffic inbound on 9.3.1.52 outbound
on any interface)
1- -3
(Applies to traffic outbound on interface 3 and
inbound on any interface)
7. Attributes of Layer2ConditionAuxClass
NAME sourceMACAddress
DESC The sourceMACAddress(es) to which the policy
applies.
EQUALITY CaseIgnoreIA5String
SYNTAX IA5String
MULTI-VALUED
FORMAT The IEEE Canonical representation of the MAC
address.
Default Entire range of values
NAME destinationMACAddress
DESC The destination MAC Address(es) to which the
policy applies.
EQUALITY CaseIgnoreIA5String
SYNTAX IA5String
MULTI-VALUED
FORMAT Same as sourceMACAddress
rajan,kamat,bhattacharya Expires 25/August/1999 [Page xii]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
Default Entire range of values
NAME 802.1QVLANID
DESC The VLAN identified by the value in the 802.1Q
VLAN tag.
EQUALITY IntegerMAtch
SYNTAX Integer
MULTI-VALUED
FORMAT The VLAN id in the 802.1Q defined header.
Default Entire range of values
NAME SNAPHeaderValue
DESC The value contained in the SNAP header that
identifies the protocol contained in the frame.
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
MULTI-VALUED
FORMAT A string representing the hexadecimal value that
would appear in the SNAP header to identify the
protocol.
Default Entire range of values
NAME ethertypeValue
DESC The value contained in the ethertype portion of
the frame header identifying the protocol
contained in the frame.
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
MULTI-VALUED
FORMAT A string representing the hexadecimal value that
would appear in the ethertype header to identify
the protocol.
NAME DSAP
DESC The value contained in the destination SAP of
the frame that can be used to identify the frame
e.g. a DSAP value of 0x04 identifies SNA frames.
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
MULTI-VALUED
FORMAT A string representing the hexadecimal value that
would appear in the DSAP header to identify the
protocol.
NAME SSAP
DESC The value contained in the source SAP of the frame
that can be used to identify the frame
rajan,kamat,bhattacharya Expires 25/August/1999 [Page xiii]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
e.g a SSAP value of 0x04 identifies SNA frames.
EQUALITY caseIgnoreIA5Match
SYNTAX IA5String
MULTI-VALUED
FORMAT A string representing the hexadecimal value that
would appear in the SSAP header to identify the
protocol.
8. Security Considerations
There are two potential security considerations, both of which may
be addressed through standards compliant mechanisms. The first
is the unauthorized access to read or change policy rules and
related objects in the directory repository. The schema in this
document SHOULD be used in conjunction with an LDAP access control
mechanisms. The second exposure for violation of security lies in
the communication between policy decision point and the directory
repository. Such communication SHOULD be secured, with both ends
mutually authenticated using SSL/TLS or IPSec.
Acknowledgments
We would like to acknowledge Debasish Biswas for his original
suggestion to use auxiliary classes in this context. We would like
to also thank Jean Christophe Martin, Michael See and Skip Booth for
many useful suggestions.
References
[1] J. Strassner and E. Ellesson, Policy Framework Core Information
Model", draft-ietf-policy-core-schema-01.txt, February 1999.
[2] D. Piper, ``The Internet IP Security Domain Of Interpretation
for ISAKMP'', draft-ietf-ipsec-doi-07
[3] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan,
"An LDAP Schema for Configuration and Administration of IPSec
based Virtual Private Networks (VPNs)", Internet-Draft work in
progress, October 1998
[4] Rajan, R., and J. C. Martin, S. Kamat, M. See, R. Chaudhury,
D. Verma, G. Powers, R. Yavatkar, "Schema for Differentiated
Services and Integrated Services in Networks", Internet-Draft
work in progress, October 1998
rajan,kamat,bhattacharya Expires 25/August/1999 [Page xiv]
Internet Draft draft-ietf-policy-conditions-00 26/February/1999
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
AUTHOR'S ADDRESS
Raju Rajan IBM Research 30 Saw Mill River Road Hawthorne, NY 10532
email: raju@watson.ibm.com
Full Copyright Statement
Copyright (C) The Internet Society (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 implementation 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.
rajan,kamat,bhattacharya Expires 25/August/1999 [Page xv]
